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

比如RabbitMQ即是通过AMQP协议实现。
在这里并不能说基于AMQP实现的消息中间件性能就一定好于JMS，对于阿里基于JMS实现的RocketMQ网上能够查到的性能测试数据实际是好于RabbitMQ的。
具体的测试数据可以参考网上的一个对比图:

文章插图

高可用性集群搭建对于集群可以分为两类，一类是应用中间件集群，一类是涉及到持久化中间件集群。
应用中间件集群
对于应用中间件集群，比如常见的weblogic，Tomcat应用中间件和Web容器。这类要实现高可用性本身相对容易，因为本身不涉及到数据的持久化存储方面的问题。
应用集群高可用，唯一就是服务器节点之间的Session状态信息同步，当前也有很多的方案，类似Session同步复制，采用数据库，redis等共享库来保持Sesion会话信息等。再简单点，你完全可以在上层接入到负载均衡设备，通过负载均衡设备配置Session会话保持来保持会话信息。在这种情况下仅是需要容忍集群节点出现故障，当前在该节点的会话不可用。
其次就是集群节点的心跳检测，一种是最简单的方法就是心跳ping节点，如果出现异常则认为节点出现故障。而这种情况下无法判断集群节点是否假死或Hang住了。因此也有进一步的做法，即采用OpenRestry来实现集群负载和动态的心跳监控。
持久化中间件集群

文章插图

对于消息中间件，Redis缓存数据库等都可以看到，典型特点就是涉及到数据持久化的问题。而这些中间件本身的高可用集群思路基本完全一样。
集群节点配置问题
集群节点配置，可以看到有1主1从，多主，多（主+从）等多种模式来实现集群扩展。要看到主从的目的是实现Master宕机的时候消息还能够从Slave上获取，不影响消息实时性，Slave节点实际是实时在复制主节点数据，并不提供性能分担。
而多主的目的则是真正分散消息并发泄到集群时候的性能问题。即使是一个最简单的点对点消息模型，Producer也可以将消息分发到两个Master节点进行性能分担，以减轻单Master节点下的性能压力。
所以如果仅仅是高可靠，Master+Slave基本就能够满足。但是要满足高可靠+高性能，则必须搭建多个Master+多个Slave组成的集群。
管理或心跳监控节点
管理节点有很多方法，比如RocketMQ里面自己实现的Name Server集群，Redis集群实现的Sentinel哨兵集群，或者通用的Zookeeper集群来实现分布式协调等。
但是不论哪种方式都能看到管理节点往往是3台服务器配置模式。
首先Admin节点采用单点肯定不行，即存在单点故障。
因此你至少需要配置两台Server来作为Admin管理节点，但是配置2台服务器的时候又发现一个新问题，即如果2台服务器检测到的节点状态不一致那么听谁的？
正是这样原因引入了第3台服务器，即能够超过半数的投票机制来实现文档的集群管理节点。可以看到类似Kurbernetes集群同样也是需要3台服务器来实现多主的高可用配置。
持久化存储
前面已经谈到了持久化存储。对于消息中间件在集群下，实际每个集群节点都可能接收到大量的消息，消息是存储在本地磁盘还是共享文件存储是需要考虑的问题。
如果是本地磁盘，那么一般需考虑Master-Slave模式，实现消息的实时同步复制，以确保在Master宕机的情况下不影响到消息的实时获取。如果是共享存储模式，实际可以看到不一定必须配置Slave节点，即某个Master宕机后，另外一个节点可以从共享存储中重新装载消息，虽然稍微有一定延迟，但是基本不会影响到消息的实时性。
类似Weblogic JMS集群基本采用这种方式，即共享文件进行持久化存储，当节点出现故障的时候，请求信息会漂移到其它非故障节点完成高可用性。