EQueue 2.3.2版本发布(支持高可用)
前言
前段时间针对EQueue的完善终于告一段落了,实在值得庆祝,自己的付出和坚持总算有了成果。这次新版本主要为EQueue实现了集群功能,基本实现了Broker的高可用。另外还增加了很多实用的功能,对性能也做了很多优化。总之,EQueue越来越成熟了。
EQueue最新版本信息
Nuget:https://www.nuget.org/packages/EQueue
github:https://github.com/tangxuehua/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启动时,
从本地获取该Topic的所有队列信息;
从Broker集群中的第一台启动的并且可用的Broker获取所有当前在线的消费者;
根据获取到的队列和消费者信息,按队列个数平均的目的为算法,为消费者平均分配队列,完成消费者负载均衡的目的;
与配置的所有Name Server服务器建立TCP长连接;
随机选择一台Name Server获取所有可用的Broker列表,对所有的Broker建立TCP长连接,并定时(5s,可配置)更新所有可用的Broker列表;
定时(1s,可配置)向所有当前连接的Broker发送心跳,将自己的信息注册到Broker;
定时(5s,可配置)从Name Server获取所有当前集群的所有Topic的队列信息;
定时(每隔1s,可配置)进行消费者负载均衡,消费者负载均衡的逻辑是,针对当前消费者订阅的每个Topic,执行下面的逻辑:
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的集群功能有兴趣的,可以进一步观看我之前在斗鱼上直播的视频(建议Wifi下看):
class="video_iframe" data-vidtype="1" style=" z-index:1; " height="375" width="500" frameborder="0" data-src="https://v.qq.com/iframe/preview.html?vid=w0334aqm27s&width=500&height=375&auto=0" allowfullscreen>
原文链接:http://www.cnblogs.com/netfocus/p/5911179.html
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注
EQueue 2.3.2版本发布(支持高可用)相关推荐
- CAP 2.3版本发布,支持 MongoDB
前言 经过2个月的调整及测试,CAP 2.3 版本终于发布了,这个版本最大的特性就是对于 MongoDB 的支持,感谢博客园团队的keke同学对于 MongoDB 支持所提供的 PR,相信随着博客园的 ...
- OpenStack JUNO版本发布——支持Spark和NFV
JUNO版本的重点更新内容: 包含了OpenStack Swift 2.0.0, 2.1.0, 2.2.0三个版本 存储策略 Keystone v3支持 服务器端账户到账户(account-to-ac ...
- OpenStack Juno 版本发布——支持Spark和NFV[转]
作者:郑晨,OpenStack中国社区,转载请注明出处 美国时间2014年10月16日,OpenStack Juno版本正式发布,这是OpenStack开源云计算项目自2010年创立以来的第10个版本 ...
- 深蓝词库转换1.2版本发布——支持紫光拼音和拼音加加
之前推出了深蓝词库转换工具,受到大家的欢迎,有朋友陆陆续续来信,希望增加一些实用的功能,于是乎今天深蓝词库转换1.2推出.该版本主要实现了3个新功能: 1.支持紫光拼音输入法的词库导入导出. 紫光拼音 ...
- 什么版本linux支持高通骁龙,高通也来刷版本号?骁龙712正式登场:性能提升10%...
当我们都在欢度春节假期的时候,高通却没有闲着,正式对外宣布新款处理器高通骁龙712芯片.从命名来看我们可知,这款芯片为高通骁龙710的升级版,官方表示骁龙712相比骁龙710,有着10%的性能提升. ...
- Nacos发布 v0.2 版本,无缝支持 Spring Cloud 微服务生态及高可用集群模式
2019独角兽企业重金招聘Python工程师标准>>> 近日,阿里巴巴新开源项目Nacos 发布了 v0.2 版本,该版本开始支持完整的Spring生态技术栈,这包括 Spring ...
- Windows版本redis高可用方案探究
文章目录 @[toc] 前言 搭建redis主从 配置主redis-28380 配置从redis-23381 配置从redis-23382 将redis部署为服务 启动redis 配置哨兵 启动哨兵 ...
- kubeadm部署k8s_(Ansible)三分钟部署一套高可用/可扩展的kubeadm集群
介绍 容器的兴起改变了我们开发,部署和维护软件的方式.容器使我们能够将构成应用程序的不同服务打包到单独的容器中,并在一组虚拟机和物理机上部署这些容器.这就产生了容器编排工具,可以自动执行基于容器的应用 ...
- .Net Core2.1 秒杀项目一步步实现CI/CD(Centos7)系列二:k8s高可用集群搭建总结以及部署API到k8s...
前言:本系列博客又更新了,是博主研究很长时间,亲自动手实践过后的心得,k8s集群是购买了5台阿里云服务器部署的,这个集群差不多搞了一周时间,关于k8s的知识点,我也是刚入门,这方面的知识建议参考博客园 ...
最新文章
- fn hotkeys and osd_潍坊实习生活(3)and 绊 最后的进化
- between and 效率_香港城市大学吕坚教授Adv. Funct. Mater.: 铁基金属玻璃在工业废水处理上再次突破,实现催化效率与稳定性双提升...
- Hulu 2013北京地区校招笔试题
- Silverlight:应用程序模型
- 我一哥们,在东莞和五名女孩被抓了.....
- 中挪动正请求第三方支出牌照竖立支出公司
- java 长链接转短链接_java长链接转短链接代码和如何跳转使用
- iOS数据持久化设计探讨(NSCache,PINCache,YYCache,CoreData,FMDB,WCDB,Realm)
- 初生牛犊不怕虎 造车新势力的硬核移动互联科技盘点
- 牵手华为云,云时通SRM助力企业采购数字化升级!
- 使用Java SE8 Streams 处理数据,Part 2
- 提取mdx字典文件中的数据
- 微服务-微服务为什么要用到 API 网关
- (转)Java学习书籍推荐
- Python 实现延时队列
- 初探微信小游戏(一)
- mysql可串行化读音,Oracle与MySQL中“可串行化”的对比测试
- 影建无不ProtaBIM 2016 sp5 for Revit 2015 1CD
- [附源码]计算机毕业设计JAVA党建工作信息管理系统
- 3D激光雷达SLAM算法学习01——3D激光SLAM整体框架