56_ActiveMQ消息持久化机制之JDBC With Journal

来同学们那讲到这儿，我们已经深度的了解了GDBC的存储结构，那么。还是那句话，跟前面一样。讲过NIO案例以后，有没有NIO案例的增强呢？一样？你生产上，你肯定在公司里面为了保证高可用和持久化，是需要了解和配置的，那么已经讲过的GDBC消息存储了，那么有没有GDBC？这对应的增强呢？那这个东东具体又是个什么呢？在持久化的。机制讲解里面有一个GDBC消息存储伴随着active MQ的journal，那这个东东是个啥？Journal意思什么？呃，日常翻译呢，是杂志报刊，我们这儿呢，翻译成日志，说白了，高速缓存，也就是说在activity tmq和MYCQ之间可以打一层。再加个journal，那么好，我们来看看，首先它是个什么东东，来吧。

跑到这儿。我们可以看到啊，官网上的原话，长期的你要长时间的长久的这个持久化的话，我们推荐呢，你要用GDBC。然后且伴随着我们高速。高性能的general这样的一种机制啊，如果你只是用GDBC的话呢，你除非你希望呢，你能够忍受这个什么，它比较慢，那它什么意思呢。从这个高性能的这个general，这种带高速缓存日志的这个短，从4.0以后就开始有了，那么为了达到一种高性能的话，对于持久化消息，在active MQ4.0以后的版本，我们强烈推荐你使用我们的高速缓存配置journal，那么所以说不废话。他具体而言是什么呢。GDBC嘛，我们前面讲过了，数据库好倒是好，它倒是连上了，但是呢。每次消息过来，我都要去什么写和读，尤其这个读，刚才我们讲过，对于队列而言，我要做连接，用户名、密码验证生产者有消息了。

人大数据库啊。队列的消息消掉了，要从数据库拿走。那么读写读写好。对于我们这个呢，它是使用一种高速缓存的技术，大大提高了性能，啥意思啊MK。JA到MYSQL中间挡一层，那么当消费者的消息速度能够跟得上生产者的生产速度的时候，它就可以大大的减少需要写入的DB，说白了就是说生产者干了一天，这一天先是先会保存到这个文件，如果消费者的消费速度也很快的情况下，那么在交文件还没有同步到MYCQL之前，消费者可以先从这个日志文件里面看吗？能跟上我们就消息了，假设已经干掉了90%以上的消息消生产者快往日志里面写，消费者也快，那干脆我往日志里面拿，那么这个时候只需要同步剩余的10%的消息到买色QL，那么这个时候干嘛就非常适合用这种方法，但是呢，如果说消费者的速度也很慢了，那么这个时候的这个的文件就可以批量的方式写到DB，有点类似于是什么，好吧，那么生产的很快。

我们呢，MYSQL呢有点慢，那么比MYSQL反应更快的有个日志啊JA那么扔进去，那么大家要消费的时候可以先找他，那么最后我们再在剩余的再同步给MYSQL，那么相当于说在MYSQ前面又挡了一层，好，那么怎么配置呢？来，同学们，以前我们是不是配的是GDBC，现在我们要配。干嘛？Journal的持久化适配器就这么一个东东，那么好，同学们，那么我们把它呢，拷贝出来，你看哈，这个配置是不是一个比一个难，一个比一个繁琐，但是呢，功能呢，也就一个比一个是吗？强大，好那么跑到这儿你看还是引用这个data source是MYSQDSMYSQDS，好吧，那么过来吧，我们呢这呢要重新做一些变化那呃。

默认的可看DB被我们改成了GDBC，那么现在同样的命运，这两个都注掉了，干嘛？在这个的GDBC正下方，我们开启这个含有带高速缓存的这个来做一定的讲解和说明，好，那么同学们，我们跑到这儿哈。我们呢，直接过来，那么这边哈。我们呢，直接。住点。那么这边直接注掉，那么。我们来。过来。粘我们带这个高速缓存的东都好，那么粘贴那么来同学们，那么这些呢，是它的一些这个参数配置，那么你用我弄好的一般的，那么你可以参考官网，那进去一定的这个修改好，那么OK，那么过来吧。这之后我们来看一下我们的MYSQL呢。不动，但是我们的这个要进行一下处理，那么这块就会有点失切，好那么我们呢，配置完成以后，那么再start给它激活，好那么稍微等他一会儿。

好同学。继续我们呢，等了他一会儿以后，这个时候呢，我们来看home o了吧，那么队列这些呢，都没有那么干干净净的，那么注意我们这做的变更和修改，默认是可看DP，现在呢，变成了我们的GDBC，然后现在呢又变成了我们这个东东，那么这块的话呢。请同学们在粘贴的过程当中一定要注意啊，那么引用的还是我们原来的这个小细节。尤其是红色的这哈井号是引用好不多说了，那接下来我们重启以后文件配置激活的都OK，那么这呢是重新打开了一下，给大家来看看我刚才配了一些什么。默认JDBC到journal带高速缓存日志的这样的一种。

持久化方案性能呢，按照官网的要求和它的介绍是吧，官网上说的话呢，直接也说了是最好的，而且干嘛这个伴随着这个journal这样的日志的话，Which is enabled by default，有可能将来会变成一种默认的支持，好吧，好，那么接下来我们来验证，那么这个时候这个验证呢，可能呢，稍微和以前有点不一样，注意以前是什么，我们来看啊。以前我们的代码呢，我一运行生产者这三条是不是在我们的MYSQL里面发送，然后在我们的message里面，大家都知道的，干嘛100%是不是马上就看到，因为当前的时候，现在我们数量少，只有三条。连接验证几乎都是什么纳秒级别，很快，所以说还记得吧，刚才我们这个一弄这队列是不是就有三条，但是现在由于前面是高速缓存，我先写到缓存里面，我的生产者先跟MQ的缓从打交道，之后有什么事再从缓存慢慢的同步到我们这个里面，这么说能理解好，那么同学们请看啊。

现在我们呢，先跑起来三条。完成，那么队列3030老版本绝对标准答案，那么现在我们来看一下我们的这个已执行。我刷我刷，我刷刷刷有没有没有，为啥？因为现在挡在我们前面的不再是买CQ了，挡在我们前面的是这个带日这个journal的这个日志啊，同学们没问题吧，现在有什么事找他了，他过一会儿他才会同步给我们的MYSQL数据库啊，他就不是像是以前那样马上就写到数据库里面，那么这样是不是大大降低了我们买CQ的这个冲击和压力啊，那么杨哥那能不能进行消费呢？完全可以，那么这个时候不影响，那么大家看。我跑。OK，收到了吧，GDBC这三条，那么大家not一眼，是不是我们这儿是GDBC的这三条，那么现在我们再看MYCQL服务器，0033，一切都是规规矩矩健康的，那么这这个时候怎么着？抱歉，这儿根本就没有，那么你你们在做测试的时候呢，你杨哥应该怎么测呢？就是说。

以前是直接写进MYSQL，现在没有，现在呢，是先写进了我们的这个journal，那么如果你晚上去做测试，你可以先发一条生产100%证券，那么过来这等着，那么等大概多长时间呢？呃，默认用它的话，我这边大概是七八分钟，好，那么这个时候八终于会有这三条，什么意思啊，有什么数据先到找general，那么我在general上挡在MYSQL前面，有事先找我这个门卫，再进去找主人，然后长时间没人用了，我再慢慢的同步回我的MYSQL数据库，OK，那么如果同步你假设哈，你就做完这个案例以后，你就十分钟，你先去休息一会儿，听个音乐，十分钟回来以后不停的反复的刷，那么这才会有生产者。

生产的刚才那三条消息，也就是从高速缓存日志啊，同步给买CQL了，那么一样，如果我消费掉了以后干嘛呢？你再去刷这个买CQL，以前我们讲过，只要一消费掉，它是不是就被删除就没有了，这个时候你会发现我删也是先从高速缓存删，然后再从高速缓存同步给买CQL，我删完以后刷半天，他这还是存在着，这个时候干嘛？实现了我们的读写分离，有点这种思想，那么MYCQL的负担被大大降低，那么再来看看它的这个说明，那么我们来看。如果消费者消费速度很快的情况下，这个高速缓存日志还没有同步到买SQ之前，消费者就已经消费掉了，那么只这个时候只需要剩余什么，只需要同步什么剩余的，那么沿下那些消费的就可以少，或者是不玩马赛克数据库写，所以说有时候呢，看不到OK，好，那么这个就是我们对于GDBC配合着是吗？我们高速缓存的一个案例和证明，那么有兴趣。