作者|个推资深研发专家 微风
引⾔
马上就是元旦了，⾯对井喷的推送需求、百亿级推送下发压⼒，服务了数⼗万App的个推，是如何持续优化技术⽅案，保障⾼优先级消息实时下发的？本⽂将从业务场景、⽅案设计思路、⽅案阐述等⽅⾯讲述个推百亿级消息推送的优先级解决⽅案。 业务场景
在⽇常消息推送过程中，个推往往需要应对来⾃以下四⽅⾯的挑战。
· ⾼并发：单台服务器在每⽇⾼峰时段需要响应百万级并发量请求
· ⾼并发：
· 低延迟：需毫秒级响应推送请求，保障亿级消息秒级送达
三维激光扫描系统· 低延迟：
· 海量数据：需在每⽇百亿级推送下发请求中，实现消息的实时下发
· 海量数据：
· 海量⽤户：需要在个推业务层中对外标识的百亿⽤户⾥快速筛选出符合推送条件的⽬标体进⾏消息下发
· 海量⽤户：
手机背光源
当同时有多个App进⾏消息下发时，难免会出现资源竞争的情况, 因此就产⽣了优先级队列的需求：在下发资源固定的情况下, ⾼优先级的⽤户需要有更多的下发资源。
⽅案设计思路
为了应对上述四点挑战，我们采⽤了以下三项原则予以指导：
· 保证相对公平、避免饥饿问题
硝化纤维素膜· 避免互相⼲扰、阻塞
· 动态调整下发速度涡轮抽风机
业务⽅案
上⽂介绍了打包构建⽅案的流程，但是在实践中，我们会发现随着构建的任务越来越多，构建的环境会变得越来越繁杂，难以管理。
基于以上三点原则，结合具体业务场景，我们制定了如下两套解决⽅案。
⽅案概述
· 个推采⽤基于Kafka 的优先级队列⽅案，解决了消息下发场景中⾯临的任务⼤⼩不⼀、下发量⼤、时延低三⼤难题。
· 个推采⽤基于Pulsar 的优先级队列⽅案，解决了消息回执场景中⾯临的回执响应时间不⼀、优先级需实时调整这两⼤难题。 1、基于Kafka 的优先级队列⽅案
⼀般情况下，早上7 - 9点、中午12 - 13点、 晚上19 - 21点这三个时间段，个推收到的推送任务⽐较集中，其消息量占全天的七⼋成。在这些推送任务中，我们都会针对⼿机类型、区域分布、⽤户体特征等复杂条件筛选出需要送达的⽤户，⽽不同客户的⽤户量差距较⼤，范围在⼏百到上亿之间。⾯对这些客户同时发送的推送请求时，个推需要保障推送消息实时到达，避免客户之间下发速度互相影响。 发泡海绵业务逻辑
针对实际遇到的挑战与我们的⽅案规划思路，最终设计的落地⽅案如图所⽰：
当消息推送处于低峰期、机器资源处于低⽔位运⾏时，消息不进⼊队列，直接发送给App；
当消息推送并发量变⾼、机器资源处于中⽔位运⾏时，消息进⼊内部队列排队，待消息被消费后再发送给App；
当消息推送并发量继续增⼤、机器资源处于⾼⽔位运⾏时，消息需要削峰填⾕、降低资源竞争。它的具体实现⽅式是：
消息进⼊外部队列Kafka中排队，内部队列只接收从外部队列出来的消息，消息从内部队列被消费后发送给App；
当外部队列内的消息消费完，机器资源运⾏⽔位缓慢降低到中⽔位时，内部队列才开始接收其他渠道的推送消息。这样可以避免消息之间的资源竞争，还可以保持后续处理逻辑的统⼀性。
下⽂我们将以资源进⼊⾼⽔位运⾏时的场景来举例说明。
细节⽅案
由上图可知，推送消息会根据所属的App ID区分⾼中低优先级。在同优先级的情况下，Kafka⽣产者⾸先会给⼤中⼩任务发送不同的topic，由对应的Kafka消费者线程放⼊有界阻塞队列中；接着按照 6：
3：1的⽐例消费，⽐如⼀次取1000条推送消息，⾼中低优先级将分别获得600、300、100的推送消息量；
然后，调度线程将这批消息下发给⼿机；如果此时⾼优先级推送消息处于低峰期，配额没⽤完，假设只⽤了300，那么剩下的300配额会按 3:1
以此充分提⾼资源的利⽤率，且达到⼤中⼩任务不相互阻塞、不同优先级任务不相互⼲扰的⽬
的⽐例分配给中、低优先级的消费者线程，以此充分提⾼资源的利⽤率，且达到⼤中⼩任务不相互阻塞、不同优先级任务不相互⼲扰的⽬的。
2、基于Pulsar 的优先级队列⽅案
当消息下发后，⼤多数客户都希望及时了解这条推送消息是否已经到达App端，是否已经被系统展⽰以及是否被⽤户及时点击查看，故我们每天发给客户的回执量也是巨⼤的。此业务场景主要涉及到的
挑战有：
由于每个客户的⽹络情况、机器性能、业务处理逻辑等各不相同，因此个推发给客户的回执响应时间也不同，快的⼗⼏毫秒就可返回，慢的则需⼗⼏秒甚⾄更久，且有些客户的响应时间是在这个区间内不定期波动。
由于回执消息数量巨⼤，所以Pulsar也需要先进⼊队列排队再发送给客户服务端。有些客户为了提⾼回执发送速度，会申请调整优先级，我们服务端需要对此进⾏实时调整，提⾼回执速度。
结合挑战和上述提及的⽅案设计思路，我们的落地⽅案如图所⽰：
相⽐基于Kafka 的优先级队列⽅案，此⽅案的业务逻辑相对⽐较简单，所有的回执消息先进⼊外部队列中，再通过调度线程统⼀把回执消息发送给客户服务端。
由于我们需要实时调整优先级，且希望回执响应速度不同的客户之间不互相阻塞和影响，所以我们优先考虑了Pulsar组件。该组件的数据传输性能表现优秀且具备创建百万级topic的能⼒。
个推利⽤此特性为每个App都创建了不同的topic，为我们后续实时调整优先级和下发速度打下了强有⼒的基础，详情见细节⽅案。
细节⽅案
由上图可知，回执消息会被划分到不同组，组内则会按优先级程度发送给客户，具体步骤为：
⾸先，⼿机回执消息到达个推服务端后，消息会进⼊外部队列Pulsar中排队，接着不同的Pulsar消费者组会依据组内不同的优先级，按照6：3：1的⽐例获取⼀批回执消息，然后发送⾄客户的服务端。
App维度的回执消息所属的组是不固定的，每过⼀段时间，个推会根据不同的回执响应时间，通过K-means聚类算法动态调整App所属的组别，保证组内的发送速度相近，使回执响应速度不同的客户互不影响，且同组内⾼优先级⽤户能拥有较多的回执资源。
总结
以上是个推结合消息下发和回执场景整理出的两种解决⽅案。概括起来，重点为：
· 场景不同，⽅案不同
消息下发 -- ⾼峰期内消息下发量⼤、推送任务⼤⼩不⼀，消息需要被快速下发，为此个推选择了基于Kafka（内外部）优先级队列⽅案；
消息回执 -- 需要动态聚合回执响应时间不⼀的消息、动态调整优先级，为此个推选择了基于Pulsar（不同组别）优先级队列⽅案。
· ⽅案不同，MQ不同
内外部优先级队列⽅案 - - 需要满⾜短时间内传输⼤量消息数据，为此个推选择了Kafka组件；
不同组别优先级队列⽅案 -- 需要为每个App都创建各⾃的topic，为此个推选择了Pulsar组件。
建议开发者在选择⽅案的时候，多结合业务场景进⾏思考，从⽽到最为合适的落地⽅案。服务了数⼗万App的个推，还会在“消息推送”这个领域深⼊拓展，持续为开发者们分享前沿的理念与最新的实践⽅案。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议