EQueue 2.3.2版本发布(支持高可用)

时间:2023-12-12 10:31:26

前言

前段时间针对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的高可用部署架构如下图所示:

EQueue 2.3.2版本发布(支持高可用)

架构说明:

  1. 总共有Producer, Consumer, Broker, Name Server四种服务器角色;
  2. Name Server的职责是负责管理所有的Broker,并为Producer,Consumer提供Broker信息以及所有Topic的路由信息;
  3. 从部署逻辑上看,Broker Master, Broker Slave是属于一个逻辑上的单元,一个Broker Master可以配置多个Broker Slave;所以,我设计了一个Broker Group的概念。同一个Broker Group中可以有一个Broker Master和多个Broker Slave;
  4. Broker启动时,
    • 与配置的所有的Name Server建立TCP长连接;
    • 定时(5s,可配置)向所有的Name Server注册自己的所有信息,主要包括:基本信息、队列信息、消费信息、生成者信息、消费者信息;
  5. Name Server之间无联系,数据无同步;Name Server也可以部署多台,由于每台Broker都会向所有的Name Server注册自己的信息,所以,理论上所有的Name Server里维护的信息最终都是完全一致的;Name Server不持久化任何东西,启动后只在内存中维护所有Broker上报上来的信息;Name Server不与其他任何服务器主动通信;
  6. Broker Slave会从Broker Master通过拉的方式同步消息,并存储到本地磁盘,消息同步为异步同步;
  7. 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次(可配置),以保证尽量能发送消息成功;
  8. Consumer启动时,
    • 与配置的所有Name Server服务器建立TCP长连接;
    • 随机选择一台Name Server获取所有可用的Broker列表,对所有的Broker建立TCP长连接,并定时(5s,可配置)更新所有可用的Broker列表;
    • 定时(1s,可配置)向所有当前连接的Broker发送心跳,将自己的信息注册到Broker;
    • 定时(5s,可配置)从Name Server获取所有当前集群的所有Topic的队列信息;
    • 定时(每隔1s,可配置)进行消费者负载均衡,消费者负载均衡的逻辑是,针对当前消费者订阅的每个Topic,执行下面的逻辑:
      • 从本地获取该Topic的所有队列信息;
      • 从Broker集群中的第一台启动的并且可用的Broker获取所有当前在线的消费者;
      • 根据获取到的队列和消费者信息,按队列个数平均的目的为算法,为消费者平均分配队列,完成消费者负载均衡的目的;
  9. Broker的Producer心跳超时时间默认为10s;Broker的Consumer心跳超时时间默认为10s;Name Server的Broker超时时间未10s;

EQueue管理控制台

因为支持了集群功能,所以管理控制台也需要增加相应的管理功能支持。主要是要支持以集群为单位查看集群下的所有Broker列表,以Topic为单位查看每个Topic在哪些Broker上存在,以Consumer Group为单位查看每个Consumer Group下有哪些消费者,每个消费者分别正在消费哪些队列等;总结起来,目前的EQueue管理控制台支持以下功能:

  1. 查看当前有哪些集群;
  2. 查看某个集群下有哪些Broker,每个Broker的发送TPS,消费TPS,总消息堆积数;
  3. 查看单个Broker的详细信息,如监听的端口,消息存储信息,总的发送和消费TPS,Topic数、队列数、消费者组个数、消费者个数、生产者个数、该Broker上的队列信息、消费信息、生产者列表、消费者列表,最近发送的100条消息,队列扩容、缩容、重置队列消费进度,etc;
  4. 查看某个集群下的队列信息、消费信息、生产者列表、消费者列表;
  5. 查看某个集群下的所有队列的发送TPS,消费TPS;
  6. 查看某个集群下根据消息ID查看某个消息的详情;
  7. 单个集群下支持的操作:
    • 新增一个Topic,该Topic会自动在该集群下的所有Broker上创建;
    • 删除一个Topic,该Topic会自动在该集群下的所有Broker上删除;
    • Topic的队列扩容,自动在集群下的所有Broker上扩容;
    • Topic的队列缩容,自动在集群下的所有Broker上缩容;
    • 重置队列消费进度,自动在集群下的所有Broker上的该队列重置队列消费进度;
  8. 支持消息堆积报警,发送邮件;

下图为管理控制台的界面,供大家参考理解:

EQueue 2.3.2版本发布(支持高可用)

EQueue 2.3.2版本发布(支持高可用)

EQueue 2.3.2版本发布(支持高可用)

EQueue 2.3.2版本发布(支持高可用)

最后,大家对新版的EQueue的集群功能有兴趣的,可以进一步观看我之前在斗鱼上直播的视频:

https://pan.baidu.com/s/1pLlf7j9