大规划行列的中心诉求，不只需求「快」，还需求兼顾「公正」。

01 导言

HTTP是一种常用的通信协议，除了常见网站拜访、上传下载，HTTP协议还经常被用在音讯推送场景上。

设想你搭建了一个电商渠道，有许多大型商家入驻了该电商渠道并售卖各类产品，在顾客购买某个产品后，渠道会经过HTTP协议将顾客购买产品的信息告诉商家，商家则会在后台接纳渠道推送过来的音讯。

一般状况下，一切的体系都正常作业。但突然有一天，A商家呈现了爆款产品，使得销售量敏捷上升，由于A商家的后台服务处理才能是有限的，便会呈现渠道一向在给A商家推送产品售卖信息，而将其他商家的音讯都排在后边，这便导致很多其他商家不能及时知道产品的售卖状况。

这种状况也会产生在某个大客户体系反常、响应急剧变慢，导致渠道推送才能下降影响其他客户。因而，完结不同客户音讯推送的阻隔与操控就显得十分重要。

除了音讯推送场景，类似的需求也产生在渠道型的使命处理场景和资源调度场景。

在使命处理场景，许多客户会使用渠道来处理使命，比方：经过通信渠道发送语音告诉，每个客户都有很多的语音告诉事务恳求需求处理。

由于资源是有限的，所以需求给每个客户配额必定的处理才能，当客户提交的恳求大于配额的时分，渠道会按最高配额的处理速度来处理客户的恳求，并将超越配额的部分积压延后处理，这样会避免由于某些头部客户的恳求量过大导致其他客户的恳求长期无法处理的状况。

在资源调度场景，假定渠道有许多资源用于处理客户的恳求，虽然每个资源都能处理某些类型的使命，可是资源的实时处理才能是受限的。

比方：资源只能实时处理100QPS的恳求，这时需求树立一套机制，将对应资源能处理的使命挑选出来，并按资源的实际处理才能提交给对应的资源进行处理，确保一切资源都能满负荷运转。

02 问题剖析

上面三个场景看似不同，但背后其实隐藏的是相同的问题模型：

| 体系处理才能受限，或许体系能许诺处理才能受限。

| 实际的恳求量或许在某个时间点远大于体系的处理才能。

| 个别与个别之间是独立且存在差异的，渠道上有不同的客户，不同客户对时效的要求是不一样的，不同客户的使命规划也是不一样的。

| 超高的并发，比方十万甚至百万QPS的HTTP音讯推送恳求。

关于这种类型的问题，咱们怎么处理呢？

其实，不管是资源仍是客户，都可以抽象为一个实时处理才能受限的行列。

关于音讯推送场景，可认为每个客户树立一个行列，把需求推送的音讯放到对应的客户行列里，并按客户最大装备流量轮流进行推送。

关于使命接纳场景，每个客户都可以被当作是一个行列，只需能操控每个行列的最大消费速度，就能确保不会由于头部客户的突发流量导致其他客户被影响。

关于资源调度场景，可认为每个资源树立一个行列，然后将对应资源能处理的使命放在行列里边，再按照行列的实时处理才能，消费里边的数据。

此外，即使同个客户或许同个资源里，事务内部也是有优先级的，所以行列内部也需求支撑事务的优先级。

因而，这类行列模型于普通的出产顾客模型存在显著的区别：

行列数量十分多，行列的消费速度需求满意上限，支撑优先级。

怎么构建这类面向百万并发、支撑优先级的大规划行列的出产消费体系？

03 技术选型

说到出产消费模型，很自然会想到一些老练的音讯中间件，如METAQ，KAFKA等。可是经过调研发现：当行列数量的量级十分大，抵达千级甚至万级的时分，这些中间件仍是存在较大瓶颈的。

以METAQ为例，由于METAQ是一个线程池形式，一个TOPIC就有一个线程池，所以当TOPIC十分多的时分，机器上需求开十分多的线程，这显然是不或许的。经过剖析发现，METAQ的问题首要是完结机制的问题，所以另一个思路是：根据开源的METAQ源代码，对其消费端进行二次开发。

但这也会存在一系列的问题……

首要，METAQ的代码本身十分巨大，了解里边的细节就需求投入十分大的本钱。此外，METAQ的规划思路与面向大规划行列的场景有着本质区别，METAQ中心规划思路是“快” 。

然而，大规划行列的中心诉求不只需求“快”，还需求兼顾”公正”，即确保一切的行列都能抵达自己的功用方针。

这就导致METAQ里边有很多的逻辑其实并不匹配大规划行列的出产消费模型。一起，考虑到后续METAQ的版别迭代等的稳定性危险也是十分难以操控的。

不管是METAQ仍是KAFFA，在行列优先级的支撑上比较弱，这些中间件在规划的时分，并非首要面向多优先级的音讯。因而，支撑这个特性也十分难，改造的本钱也十分高。

经过综合评价，根据分布式根底行列进行自建会更稳定、牢靠、可落地。经过体系调研发现阿里云的LINDORM和REDIS都供给根底的行列操作，LINDORM供给的STRONG CONSISTENCY（SC）等级的数据一致性才能，可以支撑数据写入后100%被立即读出。而REDIS首要选用的是一种异步备份的机制，所以从数据的高牢靠考虑，挑选LINDORM是更牢靠的计划。

LINDORM是一个支撑多模型的NOSQL体系，兼容HBASE/CASSANDRA、OPENTSDB、SOLR、SQL、HDFS等多种开源标准接口，支撑的模型包括：KV，WIDECOLUMN，TABULAR和行列模型等，这儿使用的便是它的行列模型。

虽然LINDORM也叫行列模型，可是它跟METAQ音讯行列不一样，他中心的首要只有两个操作接口: 一个是PUT，把数据放入到某个行列的队尾，成功后会返回音讯对应的偏移，另一个是GET(I)，从某个偏移地址获取对应的数据，且单行列最大只支撑150QPS。

到这儿便可以发现理想与现实的巨大距离，咱们出产消费体系的方针是要支撑十万、百万并发，而且期望能主动处理消费进展办理、反常的恢复等问题，以LINDORM现在的状况来看都是没有的。

04 大规划行列出产消费体系总体规划

经过前文剖析发现LINDORM只供给了插入数据及获取数据两个根底操作，单行列只支撑150QPS，而且没有消费进展办理和反常灰度机制，这些问题该怎么处理？

这儿将构建百万并发、支撑多优先级的大规划行列出产消费体系称为EMQ(ENORMOUSE SCALE MESSAGE QUEUE )。EMQ体系首要分为6个模块：行列拆分、行列分配、行列消费、容量操控、消费进展办理、容错机制。

• 行列拆分

为了便于了解，将之前说到的客户对应的行列及资源对应的行列一致称之为逻辑行列，将LINDORM的行列称之为物理行列。

LINDORM单行列只支撑150QPS，且任何物理行列都存在容量约束。可是，咱们体系规划的方针是一百万QPS（虽然这个一百万QPS是一切逻辑行列的总和）。

单个逻辑行列超越1000QPS在实际状况中十分常见，且从规划视点来讲，逻辑行列的QPS也十分难操控。因而，有必要把逻辑行列拆分成一个个150QPS以内的物理行列。

• 行列分配

在行列拆分完后，体系需求消费这些物理行列，因而需求把行列合理的分配到使用集群的机器上。

每台机器上需求启动对应的客户端去消费各行列里边的数据，由于把一个支撑1000QPS的行列拆分成了20个小的物理行列，所以每个行列支撑50QPS。

这儿经过单行列容量50QPS乘以总的物理行列数等于1000QPS来完结逻辑行列支撑1000QPS的方针，可是从逻辑上假如存在数据倾斜的时分，会存在总容量不满1000PQS的状况。

考虑到该体系首要面向的是一个海量数据场景，因而从概率上来讲，这是可以接受的。

• 行列消费

行列分配完后，还需求构建一个支撑高功用的消费客户端。该客户端的高功用首要表现在：完结避免网络IO拜访导致的功用下降；能快速处理本台机器上的一切行列，确保既不会轮不到，又能满负荷处理；一起，在消费完音讯后能快速的履行事务体系的使命。

• 容量操控

当完结行列消费后，仍需求构建一个消费进展的办理模块，即办理当时行列出产的点位和现已消费的数据的点位，这姿态才能清楚地知道下一个需求消费的数据以及行列的积压量。

• 容错机制

体系的容错机制首要包括三个方面：首要，假如某个偏移量没有数据的时分，需求能发现并越过对应的偏移；其次，由于消费完的数据需求提交各事务层进行处理，假如事务层处理失利后咱们应该有必定的反常恢复机制，假如事务层持续失利的时分咱们需求有必定的兜底机制；此外，当机器由于反常宕机的时分，在原来机器上消费的行列需求平滑迁移到其他机器，然后完结无损恢复。

05 EMQ集群模型

• 行列模型

如下图为EMQ的行列模型：

ROOT节点下分两个节点：一是ONLINE节点，首要是面向出产环境，二是SANBOX，首要面向出产前的测验，这能确保体系在更新某个功用的时分可以先进行充分的测验然后再同步到出产环境。

在ONLINE节点下面是一个个TOPIC，这儿的TOPIC便是咱们之前说的逻辑行列，也便是分配给客户的行列或许为每个资源分配的行列（后文使用TOPIC代指逻辑行列）。每个TOPIC有必定的容量，也便是咱们说的QPS。

每个TOPIC下有若干个GROUP，每个GROUP有独立的容量，其值为TOPIC的容量除以总的GROUP数，而且要求这个值需求小于LINDORM物理行列支撑的最大QPS。

每个TOPIC下面有分优先级的QUEUE，该规划首要是为了支撑优先级才能规划的。本文为了描述方便，会以高中低三个优先级为例介绍。这三个优先级的QUEUE是同享GROUP的容量，也便是说假如GROUP支撑50QPS，那么三个QUEUE的总QPS是50。这儿QUEUE才是真实对应LINDORM的物理行列，这也是为什么要求GROUP的容量需求小于LINDROM物理行列支撑的最大QPS。

关于资源调度场景，假定有一个资源的QPS是500QPS。那么，他会对应一个TOPIC，这个TOPIC下面有10个GROUP，每个GROUP有3个优先级，也便是它会出产3*10 = 30个LINDORM行列。

• 行列分配模型

假定每个GROUP的QPS为50，那么关于100万并发的体系将有约6万个物理行列，怎么将这么大数量级的行列分配到机器上去？行列分配应该满意哪些准则?

首要，尽或许将行列均匀分配到每台机器上，避免呈现某个机器消费行列数据量太多产生功用问题；其次，当机器下线、宕机或置换的时分，机器上消费的行列尽或许不要产生大面积的迁移；最终，当行列新增或许删去的时分，机器上消费的行列也尽或许得不要产生大面积的迁移。

根据这些准则，规划了如下图所示的行列分配模型。

首要，引进一个ZOOKEEPER集群，在主节点下面树立两个节点，一个是RUNNING节点，用于保存机器的心跳信息，在机器上线的时分会创立一个以机器IP为姓名的临时节点，在机器下线的时分会销毁对应节点。二是SERVERLIST节点，该节点保存的是一切消费的机器IP为姓名的子节点，而在子节点里保存的是机器消费的一切行列。

现在有一个行列结调集和有一个机器列表调集，需求把行列尽或许均匀的分配到机器上。一个简略的办法便是取一切的行列除以机器总数，均匀分配到一切机器。这看似简略又完美的办法其实存在一些问题，当机器下线的时分，这个核算的过程就要从头来一把，或许导致很多的机器消费的行列迁移。

假如不从头核算而是在第一次取均匀，即在机器下线的时分把这个机器上的行列均匀分配到其他机器，机器上线的时分把其他机器上行列抽取一部分过来，这种计划在逻辑上是可行的。

可是，假如有行列新增的时分要履行行列的装备，在行列删去的时分要从头平衡机器的消费行列，这个无疑是十分杂乱的。最为重要的是，这种增量变更的办法假如在其中某次分配存在问题，那么后边或许一向无法挽回。

综合考虑下，选用了一致性HASH的计划，考虑到一致性HASH的平衡性，能确保一切机器分配的行列数较为接近，一起，由于一致性HASH的单调性，不管是机器变更或许行列变更，不会导致很多的行列机器关系产生变化。

在引进一个中心核算使命后，当机器产生变化或消费的行列产生变化时，都会全量的从头核算每台机器消费的行列。假如机器消费的行列有新增，那么它会新增消费对应的行列，假如有减少，就会撤销对应行列的消费。

06 EMQ单机模型

经过前面的一系列规划，现已完结了行列的拆分，而且将行列分配到集群机器上。那还有最重要的一件事情，便是构建一个高效牢靠消费客户端。

确保能准确无误高功用地消费行列的里边的数据，确保在行列有数据的状况下按行列配额的最大容量进行消费，以及当行列里的数据比较少的时分一切数据都快速被消费。

在原型机验证环节，规划方针按照在8核16G的机器上，单机3000行列的时分支撑1000QPS并发的处理。如下图，是EMQ的单机模型图，首要包括分布式物理行列、长途数据拉取模块、本地缓冲处理模块、缓冲行列分发&速度操控模块、音讯使命处理模块以及消费进展办理模块。

• 分布式物理行列

分布式物理队使用的是LINDORM的行列模型，考虑到后续的扩展，经过对LINDORM的操作做了一层抽象，只需完结适配层的办法，便可以快速支撑其他根底行列模型，比方：SWIFT，REDIS等。

• 长途数据拉取模块

长途数据拉取模块首要包括IO使命孵化器，中心是一个线程池会周期性地孵化一些使命，将远端行列里边的数据拉取到本地，确保本地行列缓冲区里边的数据抵达必定阈值。它的结束条件是本地缓冲区里的数据满意未来一段时间内的处理要求，或许一切远端的数据都现已拉取到本地缓冲区。

• 本地缓冲区

本地缓冲区是一系列的本地行列，与这台机器上消费的LINDORM上物理行列是一一对应的。也便是说：在远端这台机器有多少要消费的LINDORM行列，本地就有多少个对应的行列。

• 缓冲行列分发&速度操控

缓冲行列分发与速度操控首要包括一个缓冲使命孵化器，它的中心职责是孵化一些行列使命以及消费本地缓冲区里边的数据，直到抵达当时行列的QPS上限设置，或许缓冲区的数据空了。

• 消费进展办理

当消费完结一个新的数据之后，会更新对应通道的消费进展的点位，下次再消费的时分重新的点位开端消费，这样确保消费进展不断向前推移。一起，还会将消费进展的信息周期性的实例化到数据库，确保假如机器产生反常或许迁移的时分，能从头恢复之前的消费点位开端消费，由于这个备份是异步且有延时的，这便于一切的音讯中间件一样，一个音讯是或许重推的，需求事务处理的时分支撑幂等操作。

这儿再要点介绍一下，消费速度操控，要单机消费几千个行列，可是每台机器的线程是有限的，所以必定选用的是线程池的计划，如下图:

每个行列都有一个独立的消费计数器，每秒钟会履行若干个LOOP，每个LOOP会为每个行列生成一个消费的使命，这个使命包括方针行列和消费的最大的使命数。

每次履行拉取的时分会先对当时行列的消费计数器加一，提前预占，然后去消费行列里边的数据，假如成功了，那么流程结束，假如失利了会将计数器减一，完结回滚的操作。当越到后边的时分，有些行列的当时秒需求拉取的数据现已足够了，就无需再持续拉取了。

07 优先级操控

在完结EMQ集群模型和单机模型的规划之后，现已可以完结面向大规划行列百万并发的出产消费体系才能，可是在许多事务场景下咱们的使命都是存在必定优先级的。

比方以短信发送场景为例，短信分为告诉事务、营销事务、验证码事务，一个资源假如既能处理告诉事务，也能处理营销和验证码事务，在正常状况咱们肯定是期望验证码的使命能优先被处理，然后再处理告诉事务，最终才去向理去向理营销事务。

也便是在资源调度场景，咱们为每个资源树立了一个逻辑行列，在EMQ里边也便是一个TOPIC，这个行列是需求能支撑优先级调度的，假如验证码的使命最终进入到行列，它里边现已堆积了很多的营销事务恳求，咱们也期望这个验证码的恳求能优先于其他营销类型的恳求被处理。

假如对应通用的行列机制是不现实的，通用的行列中心的逻辑便是先进先出。

那咱们现在要完结优先级抢占，有必要要在行列规划上做文章，如下图:

咱们需求将一个行列拆分成N个行列，N是需求支撑的优先级个数。以三个优先级为例，咱们会构建高，中，低三个优先级的行列，这个三个优先级行列组成一个GROUP，同享这个GROUP的容量。也便是说假如这个GROUP的QPS是50，那么在一秒钟消费高中低三个优先级行列的总QPS不能超越50。

在消费行列音讯的时分，会先消费高优先级的行列里边的数据，然后再消费中优先级行列里边的数据，最终才消费低优先级行列里边的数据。这姿态就确保，高优先级里边的数据必定会先于中优先级里边的数据被处理。中优先级里边行列的数据也会先于低优先级里边的数据被处理。

本文要点介绍了怎么快速、低本钱地构建面向百万并发多优先级的大规划行列出产消费体系。在拥有根底才能今后，在上面做各种杂乱的事务才能规划便十分简单。比方：文章最开端说到的HTTP推送场景，那么假定某个客户突然有超10万QPS的音讯需求推送，体系只支撑10万QPS推送才能，假如按先进先出，那么或许其他客户的音讯都无法推送了。可是，假如根据EMQ构建出产者顾客模型，为每个客户（或客户组）树立一个行列，而且装备这个行列支撑的上限推送的QPS，音讯在发送前先推送到EMQ行列，按装备的限额消费。那么，即使客户瞬间有很大的信息推送恳求，也不会影响到其他客户的正常事务处理。