前言
前段时间针对EQueue的完善终于告一段落了，实在值得庆祝，自己的付出和坚持总算有了成果。这次新版本主要为EQueue实现了集群功能，基本实现了Broker的高可用。另外还增加了很多实用的功能，对性能也做了很多优化。总之，EQueue越来越成熟了。
EQueue最新版本信息
版本发布说明
- 为Broker支持集群部署的功能，解决针对消息生产者的高可用；
- 支持显示无在线消费者的消费者分组，并支持删除这些消费者分组；
- 支持删除消息时配置是否需要判断消息已经消费过；
- 完善重置消费进度的功能，重置后可立即看到效果；
- 采用双缓冲队列，提高Broker的性能；优化后单台Broker的性能：单发10W TPS；单收10W TPS；同时收发 8.5W TPS；消息大小为1KB；Broker配置：8核16G，虚拟机；
- 管理控制台功能极大的完善；
- 可配置按时间删除消息，满足用户希望消息只保存最近1天的需求；
- 支持Pull模式，允许高级用户自己拉取消息，自己消费，自己提交消费进度；
为什么要做高可用
经过了一个多月的业余时间的努力，终于为EQueue增加了Broker的集群功能。作为一个分布式消息中间件，除了性能之外，我们还关注其高可用，高可用指的是Broker的高可用。要实现Broker的高可用，最基本的条件是Broker要支持集群部署的能力。假设一个集群内我们部署了5台Broker，然后挂掉几台，如果对Producer, Consumer都没有影响，则我们可以说Broker支持高可用。
这次发布的EQueue的版本，实现了Broker的集群部署，但是还没有实现Broker的主备。所以，在架构上来讲，支持了对Producer的高可用，但是对Consumer来说还没有实现高可用。因为如果有一台Broker挂了，则Producer可以将消息发送到Broker集群中的其他的Broker，所以对Producer没有影响。但是对Consumer是有影响的。因为此时挂掉的这台Broker上的消息在挂掉的这段时间内就无法被Consumer消费了。必须等到Broker重新起来后才能被消费。而如果实现了Broker的主备功能，则当Broker Master挂掉了，则因为Broker Slave还在，所以Consumer可以从Broker Slave上消费消息。从而可以做到对Consumer的高可用。Broker的主备功能，还能保证消息的可靠性。因为假设Broker Master的硬盘坏掉了，消息也不会丢失，因为Broker Slave上还有消息。
所以，总结一下就是：
- Broker集群功能解决的是针对Producer发送消息的高可用；
- Broker主备功能解决的是针对Consumer消费消息的高可用，以及消息的可靠性保证；
新版EQueue架构说明
下一个版本的EQueue将会实现Broker的主备功能。目前EQueue的高可用部署架构如下图所示：
架构说明：
- 总共有Producer, Consumer, Broker, Name Server四种服务器角色；
- Name Server的职责是负责管理所有的Broker，并为Producer，Consumer提供Broker信息以及所有Topic的路由信息；
- 从部署逻辑上看，Broker Master, Broker Slave是属于一个逻辑上的单元，一个Broker Master可以配置多个Broker Slave；所以，我设计了一个Broker Group的概念。同一个Broker Group中可以有一个Broker Master和多个Broker Slave；
- Broker启动时，
- 与配置的所有的Name Server建立TCP长连接；
- 定时（5s，可配置）向所有的Name Server注册自己的所有信息，主要包括：基本信息、队列信息、消费信息、生成者信息、消费者信息；
- Name Server之间无联系，数据无同步；Name Server也可以部署多台，由于每台Broker都会向所有的Name Server注册自己的信息，所以，理论上所有的Name Server里维护的信息最终都是完全一致的；Name Server不持久化任何东西，启动后只在内存中维护所有Broker上报上来的信息；Name Server不与其他任何服务器主动通信；
- Broker Slave会从Broker Master通过拉的方式同步消息，并存储到本地磁盘，消息同步为异步同步；
- Producer启动时，
- 与配置的所有Name Server服务器建立TCP长连接；
- 随机选择一台Name Server获取所有可用的Broker列表，对所有的Broker建立TCP长连接，并定时（5s，可配置）更新所有可用的Broker列表；
- 定时（1s，可配置）向所有当前连接的Broker发送心跳，将自己的信息注册到Broker；
- 定时（5s，可配置）从Name Server获取所有当前集群的所有Topic的队列信息；
- 发送Topic时，如果该Topic的队列信息在本地存在，则直接从本地获取队列信息；如果不存在，则尝试从Name Server获取，如果Name Server上获取不了，则认为该Topic下没有队列信息；如果没有获取到队列信息，则会重试这个步骤5次（可配置），以保证尽量能发送消息成功；
- Consumer启动时，
- 与配置的所有Name Server服务器建立TCP长连接；
- 随机选择一台Name Server获取所有可用的Broker列表，对所有的Broker建立TCP长连接，并定时（5s，可配置）更新所有可用的Broker列表；
- 定时（1s，可配置）向所有当前连接的Broker发送心跳，将自己的信息注册到Broker；
- 定时（5s，可配置）从Name Server获取所有当前集群的所有Topic的队列信息；
- 定时（每隔1s，可配置）进行消费者负载均衡，消费者负载均衡的逻辑是，针对当前消费者订阅的每个Topic，执行下面的逻辑：
- 从本地获取该Topic的所有队列信息；
- 从Broker集群中的第一台启动的并且可用的Broker获取所有当前在线的消费者；
- 根据获取到的队列和消费者信息，按队列个数平均的目的为算法，为消费者平均分配队列，完成消费者负载均衡的目的；
- Broker的Producer心跳超时时间默认为10s；Broker的Consumer心跳超时时间默认为10s；Name Server的Broker超时时间未10s；
EQueue管理控制台
因为支持了集群功能，所以管理控制台也需要增加相应的管理功能支持。主要是要支持以集群为单位查看集群下的所有Broker列表，以Topic为单位查看每个Topic在哪些Broker上存在，以Consumer Group为单位查看每个Consumer Group下有哪些消费者，每个消费者分别正在消费哪些队列等；总结起来，目前的EQueue管理控制台支持以下功能：
- 查看当前有哪些集群；
- 查看某个集群下有哪些Broker，每个Broker的发送TPS，消费TPS，总消息堆积数；
- 查看单个Broker的详细信息，如监听的端口，消息存储信息，总的发送和消费TPS，Topic数、队列数、消费者组个数、消费者个数、生产者个数、该Broker上的队列信息、消费信息、生产者列表、消费者列表，最近发送的100条消息，队列扩容、缩容、重置队列消费进度，etc；
- 查看某个集群下的队列信息、消费信息、生产者列表、消费者列表；
- 查看某个集群下的所有队列的发送TPS，消费TPS；
- 查看某个集群下根据消息ID查看某个消息的详情；
- 单个集群下支持的操作：
- 新增一个Topic，该Topic会自动在该集群下的所有Broker上创建；
- 删除一个Topic，该Topic会自动在该集群下的所有Broker上删除；
- Topic的队列扩容，自动在集群下的所有Broker上扩容；
- Topic的队列缩容，自动在集群下的所有Broker上缩容；
- 重置队列消费进度，自动在集群下的所有Broker上的该队列重置队列消费进度；
- 支持消息堆积报警，发送邮件；
下图为管理控制台的界面，供大家参考理解：
最后，大家对新版的EQueue的集群功能有兴趣的，可以进一步观看我之前在斗鱼上直播的视频：
