云妹导读：

随着互联网的一直倒退，大数据高并发不再边远，是大部分我的项目都必须具备的能力。其中，音讯队列简直是必备技能。成熟的音讯队列工具有很多，本篇文章就来介绍一款京东智联云自研音讯队列工具——JCQ。

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

一、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年底上线。计算存储拆散对架构带来了比拟显著的益处，解决了日常遇到的许多痛点问题。

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

1，无效管制降级影响范畴

在JCQ2.0中计算模块与存储模块处于同一个过程，降级计算模块势必将存储模块一起降级。而存储模块重启是比拟重的动作，须要做的工作有：加载大量数据、进行音讯数据与音讯索引数据比对、脏数据截断等操作。往往修复计算模块一个小的Bug，就须要做上述十分重的存储模块重启。而在事实工作中，大部分降级工作都是因为计算模块性能更新或Bugfix引起的。

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

计算节点Broker只负责生产音讯、推送音讯、鉴权、认证、限流、拥塞管制、客户端负载平衡等业务逻辑，属于无状态服务。比拟轻量，降级速度快。

存储节点Store只负责数据写入、正本同步、数据读取。因为业务逻辑简略，性能稳固后，除优化外根本无需改变，也就无需降级。

2，独立部署，突破硬件限度

JCQ是共享消息中间件，用户申请的是不同规格TPS的Topic，并不感知CPU、Memory、Disk等硬件指标。所以，JCQ服务方须要思考如何正当应用这些硬件指标。

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

JCQ3.0后，计算节点Broker与存储节点Store独立部署，这两个组件能够各自抉择适宜本人业务的机型，部署在相应资源池中。这样 JCQ能够做到与其余产品混合部署，共用资源池水位，而不必单独承当资源水位线。

3，架构改良带来的老本升高

JCQ3.0中计算节点Broker是无状态服务，主从切换比拟轻量，能在秒级实现故障转移；且部署时思考了物理设施反亲和，如跨Rack、跨AZ部署。所以，能够在可用性、资源老本之间做肯定的衡量。如能够应用M:1形式做高可用冷备，而不用1：1的比例高可用冷备，进而达到节俭硬件资源的目标。

4，解决Raft性能问题

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数目并不会带来线程资源线性增长的问题。

5，疾速故障复原，轻量负载平衡

在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持续进行生产、生产。

6，高扇出需要

构想一个场景，有一个大规格的Topic，创立了n个生产组。生产总TPS是生产总TPS的n倍。减少生产组，会导致生产总TPS线性增长。达到肯定生产组规模后，单Broker因为网卡带宽的起因，无奈满足这种高扇出的场景。单服务器是无奈解决这个问题。

在JCQ 3.0 能够将这些不同的生产组对应的SubTask扩散到若干个Broker上，每个Broker负责一部分SubTask，单Broker从Store预读音讯，将数据推送给Consumer。这样 多个Broker共同完成所有生产组的音讯流量，合作一起提供高扇出的能力。

7，反对多种存储引擎

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

JCQ 计算节点设计了一层存储形象层Store Bridge 能够接入不同的存储引擎，能够接入Remote Raft Cluster，或者分布式文件系统WOS、或者S3。甚者能够将冷数据定期从低廉的本地盘卸载到便宜的存储引擎上。

8，带来的副作用

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

二、JCQ将来瞻望

JCQ将来会次要在多协定兼容，按需主动扩缩容、云原生等方面演进：

1，多协定兼容

目前JCQ协定为公有协定，在疏导用户迁徙方面有比拟大的阻碍。后续会抽离JCQ Kernel，内部提供不同的协定接入层。不便用户从其余MQ接入JCQ。

2，主动扩缩容

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

3，云原生

将来会反对在Kubernetes环境部署与交付，会提供原生的Operator，能疾速的部署在K8s环境中，更好的交付公有云、混合云我的项目。

举荐浏览：

  • 如何基于KAFKA打造高牢靠、高可用音讯平台？
  • 自主研发，京东智联云推出云架构外围产品分布式音讯队列
  • JCS大数据工程师专项认证

欢送点击【京东智联云】，理解开发者社区

更多精彩技术实际与独家干货解析

欢送关注【京东智联云开发者】公众号