计算存储分离在消息队列上的应用

京东科技开发者

共 3321字,需浏览 7分钟

 ·

2020-12-26 02:31

云妹导读:

随着互联网的不断发展,大数据高并发不再遥远,是大部分项目都必须具备的能力。其中,消息队列几乎是必备技能。成熟的消息队列工具有很多,本篇文章就来介绍一款京东智联云自研消息队列工具——JCQ。


JCQ全名JD Cloud Message Queue,是京东智联云自研,具有CloudNative特性的分布式消息中间件。 JCQ设计初衷即为适应云特性的消息中间件,具有高可用、数据可靠性、副本物理隔离、服务自治、健康状态汇报、少运维或无运维、容器部署、弹性伸缩、租户隔离、按量付费、云账户体系、授权等特性。


JCQ早在2017年中开始开发1.0版本,2018年11月正式GA上线对外售卖。但1.0版本中Topic受限于单台服务器限制,满足不了用户超大规格Topic需求。


因此,我们在2.0 版本中着重解决扩缩容问题。2019年4月 JCQ 2.0 正式上线,主要新增特性就是Topic 扩缩容能力、热点Topic在Broker间的负载均衡、热点Broker的流量转移。


2019年7月,JCQ又做了一次大的架构演进——计算存储分离,大版本号为JCQ 3.0, 于2019年底上线。计算存储分离对架构带来了比较明显的好处,解决了日常遇到的许多痛点问题。


下文将详细介绍此次演进带来的优势以及解决了哪些痛点问题:


在JCQ2.0中计算模块与存储模块处于同一个进程,升级计算模块势必将存储模块一起升级。而存储模块重启是比较重的动作,需要做的工作有:加载大量数据、进行消息数据与消息索引数据比对、脏数据截断等操作。往往修复计算模块一个小的Bug,就需要做上述非常重的存储模块重启。而在现实工作中,大部分升级工作都是由于计算模块功能更新或Bugfix引起的。


为了解决这个问题, JCQ3.0将计算模块、存储模块独立部署,之间通过RPC调用。各自升级互不影响。如下图所示:



计算节点Broker只负责生产消息、推送消息、鉴权、认证、限流、拥塞控制、客户端负载均衡等业务逻辑,属于无状态服务。比较轻量,升级速度快。


存储节点Store只负责数据写入、副本同步、数据读取。因为业务逻辑简单,功能稳定后,除优化外基本无需改动,也就无需升级。


JCQ是共享消息中间件,用户申请的是不同规格TPS的Topic,并不感知CPU、Memory、Disk等硬件指标。所以,JCQ服务方需要考虑如何合理使用这些硬件指标。


JCQ通过容器部署,有多种类型的组件,这些组件对硬件的需求也是多样化的,其中对资源消耗最多的是计算模块和存储模块。在JCQ2.0版本中,计算模块和存储模块部署在一起,选择机型时要兼顾CPU、Memory、Disk等指标,机型要求单一,很难与其他产品线混合部署。即使是同一资源池,也存在因为调度顺序,造成调度失败的情况。如一台机器剩余资源恰好能调度一个需要大规格磁盘的A容器,但是因为B容器先被调度到这台机器上,剩余资源就不够创建一个A容器,那这台机器上的磁盘就浪费了。


JCQ3.0后,计算节点Broker与存储节点Store独立部署,这两个组件可以各自选择适合自己业务的机型,部署在相应资源池中。这样JCQ可以做到与其他产品混合部署,共用资源池水位,而不用独自承担资源水位线。



JCQ3.0中计算节点Broker是无状态服务,主从切换比较轻量,能在秒级完成故障转移;且部署时考虑了物理设备反亲和,如跨Rack、跨AZ部署。所以,可以在可用性、资源成本之间做一定的权衡。如可以使用M:1方式做高可用冷备,而不必1:1的比例高可用冷备,进而达到节省硬件资源的目的。



JCQ 1.0 设计之初就采用Raft算法,来解决服务高可用、数据一致性的问题。Message Log与Raft Log 有很多共同的特性,如顺序写、随机读、末端热数据。所以,直接用Raft Log当成Message Log是非常合适的。


在JCQ演进中我们也发现了Raft本身的一些性能问题,如顺序复制、顺序commit、有的流程只能用单线程处理等限制。针对这些问题,最直接有效的办法就是扩展Raft的数目、扩展单线程流程数目,在一定数量级内,并发能力随着Raft Group数目的增长,呈线性增长关系,称之MultiRaft,如下图所示:



上图中,每个StoreNode节点是一个独立进程,内部有四组逻辑RaftGroup(橙色的节点为RaftGroup的Leader),各组RaftGroup之间是并行关系,可以做到Group间并行复制、并行commit。


由于大量使用了NIO,这些RaftGroup之间可以共享通信线程池,扩充RaftGroup数目并不会带来线程资源线性增长的问题。


在JCQ3.0中,Broker为轻量的无状态服务,在主从切换、故障恢复方面相对2.0更为轻量,本身能更快地恢复对外服务能力


同时,Broker将Producer、Consumer的连接请求,抽象为PubTask和SubTask,后文统称为Task。Task的概念非常轻量,仅描述Client与Broker的对应关系,由元数据管理器Manager统一调度、管理。转移Task只需要修改Task的内容,客户端重新连接新Broker即可。


一般来说,Broker的主要瓶颈在于网络带宽。Broker定期统计网络入口流量与出口流量,并上报给管理节点Manager。Manager根据入口流量、出口流量与带宽阈值进行裁决,发现超过阈值后,通过一定策略将相应的Task转移到较小负载的Broker上,并通知相应的Producer与Consumer;Producer与Consumer收到通知后,重新获取Task的路由信息,自动重连到新的Broker继续进行生产、消费。




设想一个场景,有一个大规格的Topic,创建了n个消费组。消费总TPS是生产总TPS的n倍。增加消费组,会导致消费总TPS线性增长。到达一定消费组规模后,单Broker由于网卡带宽的原因,无法满足这种高扇出的场景。单服务器是无法解决这个问题。


在JCQ 3.0 可以将这些不同的消费组对应的SubTask分散到若干个Broker上,每个Broker负责一部分SubTask,单Broker从Store预读消息,将数据推送给Consumer。这样多个Broker共同完成所有消费组的消息流量,协作一起提供高扇出的能力。



消息中间件很大的特点是:大部分场景下,热数据都在末端,而回溯几天之前的消息这个功能是不常用的。所以,就有冷热数据之分。


JCQ 计算节点设计了一层存储抽象层Store Bridge 可以接入不同的存储引擎,可以接入Remote Raft Cluster,或者分布式文件系统WOS、或者S3。甚者可以将冷数据定期从昂贵的本地盘卸载到廉价的存储引擎上。



相对于JCQ2.0,计算节点与存储节点之间的通信方式,由接口调用变为RPC调用,在延迟方面会有一定损失。经过测试,绝大部分延迟都在1ms左右,在大多数场景下牺牲1ms左右的延迟并不会给业务带来太大的影响。


JCQ未来会主要在多协议兼容,按需自动扩缩容、云原生等方面演进:


前JCQ协议为私有协议,在引导用户迁移方面有比较大的障碍。后续会抽离JCQ Kernel,外部提供不同的协议接入层。方便用户从其他MQ接入JCQ。


JCQ是共享消息中间件,但缺少Serverless自动扩缩容的特性。每逢大促,如618,11.11,服贸会等重要活动。业务方很难预估自己的业务量峰值,或者估计不足,会造成topic限流等问题。如在保证JCQ服务本身能力情况下,能做到Topic灵活地自动扩缩容,将对用户有极大的帮助,起到真正的削峰填谷作用。


未来会支持在Kubernetes环境部署与交付,会提供原生的Operator,能快速的部署在K8s环境中,更好的交付私有云、混合云项目。


浏览 22
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报