聊聊消息中间件的关键特性和问题总结( 二 ) _消息中间件

文章插图

可靠性和消息持久化在整个技术架构中引入了消息中间件后，虽然达到了异步解耦的作用，但实质是增加了整个集成架构的复杂度，同时也影响了整体架构的可靠性。
对于消息中间件如何增加可靠性，一个方面是高可用集群架构，一个则是消息本身要支持持久化存储。通过消息持久化存储来确保消息不丢失。

文章插图

对于消息持久化，一般来说分为文件和数据库两大类。对于文件本身又分为了本地磁盘文件和共享文件系统两个方式。
本地磁盘方式可以看到，如果当前Broker节点宕机，虽然消息可以在本地暂存，但是在当前节点没有手工恢复前，消费端无法及时获取消息。对于这个问题的实际解决思路是启用类似Master-Slave的部署架构方式，即消息会快速的实时同步到Slave节点。这样即使Master节点无法访问，订阅端也可以快速的从Slave节点获取消息。
对于共享文件系统或数据库方式，实际消息只持久化到一个集中的地方，因此不存在消息多点复制的操作，某个节点宕机，共享存储的消息也可以快速的恢复到其它冗余节点。
分布式事务
在前面谈到过基于消息中间件来实现消息最终一致性，具体如下：

场景：在采购系统中拟制采购订单，在提交单据申请的时候既需要将单据成功保存到本地，同时又需要启动远程流程平台提供的流程启动服务。在该场景中，第二个步骤属于必须要最终完成的操作，同时业务上也允许最终一致（不要因为流程平台本身问题导致单据提交不成功，启流程失败如何重试是系统内部的事情）

对于该场景，基于消息实现最终一致性逻辑如下：

文章插图

可以看到，报账单提交和流程启动仍然需要控制到一个事务里面，这个本身也是一个分布式事务控制场景。特别是在消息中间件需要在获取到消息进行持久化的时候。

文章插图

也就是说从报账单提交，到消息发送给消息中间件，两个活动需要控制在一个事务里面。而对于消息中间件本身又有两种做法。
一种是只要获取到消息，消息还在内存里面就认为成功并返回给发送端，即异步刷盘。还有一种就是拿到消息后必须持久化写入成功后才返回，即同步刷盘。
因此要确保无任何消息丢失，必须是同步刷盘模式，确保消息持久化成功才能够返回。
持久化还有什么作用？
当订阅端取消息的进度缓慢，或者说订阅端迟迟不取走消息，那么消息就一直在消息中间件中堆积，消息中间件内存容量优先，必须将更多的历史消息先进行持久化处理进行内存释放。否则消息中间件本身也很难应对。
那么消息大量积压如何办？常用的方式就是设置消息的过期机制，比如设置为5天，那么超过5天订阅端还没有取走的消息就自动废弃。但是这种方式本身也影响到消息发送的完整性。
当然对于挤压消息也可以手工清理。
比如当前已经产生1亿条消息，分别由ERP分发给SRM和CRM系统，但是CRM系统对这些消息没有消费而处于积压状态。我们需要手工对CRM订阅的这部分消息进行清理。这个时候可以看到和基于数据库进行大表的Delete条件删除差不多。
即性能极其缓慢。因为清理消息过程实际就是条件删除过程，同时这些数据还可能存在于多个磁盘文件中，清除后还需要对磁盘文件进行重整。对于消息的持久化存储前面谈到，写消息到磁盘文件性能极高，比数据库快很多，但是一遇到这种条件删除或消息清理场景，那么性能就会极差。
JMS还是AMQPJMS（JAVA Messaging Service）是Java平台上有关面向消息中间件(MOM)的技术规范，它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发，翻译为Java消息服务。
传统企业内部使用的消息集成中间件，比如IBM MQ，Weblogic JMS, 开源的ActiveMQ等基本都基于JMS标准规范和协议。支持点对点队列模式，也支持消息发布订阅。
AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。