以友盟+U-Push为例,深度解读消息推送的筛选架构解决方案应用与实践

业务背景

友盟+消息推送U-Push日均消息下发量百亿级，其中筛选任务日均数十万，筛选设备每分钟峰值可达7亿+，本文将分享友盟+技术架构团队在长期生产实践中沉淀的筛选架构解决方案。

如何保证百亿级的下发量？

友盟+U-Push筛选是Push产品的核心功能，其中实时筛选是面向推送要求较高的付费Pro用户提供的核心能力之一，实现了用户实时打标、筛选、分发、触达的功能。友盟+U-Push的设备识别以device_token为基准，为保证尽可能的触达我们留存了近期所有可能触达客户的device_token，以10亿真实设备为例，每个设备安装10个集成友盟+SDK的应用可以产生10个device_token，牵扯到硬件环境变动导致的device_token漂移问题，可能产生更多device_token。

（ 图1.1.1 友盟+U-Push业务数据流简图）

图1.1.2 友盟+U-Push功能清单

U-Push筛选架构概览

2.1 上下行两个核心链路

U-Push服务由两个关键链路组成，下行链路保证客户消息的触达，上行链路承载终端采数和与客户服务端的数据同步。其中下行链路主要分为任务调度、筛选中心，上行链路主要服务是多种收数通道（为兼容历史问题）和设备中心，上行通过设备中心实现跟下行桥接。

图2.1.1 友盟+U-Push筛选业务场景

在U-Push服务中，依照业务场景不同定义了多种任务类型，其中除单播、列播直接下发外组播、广播、自定义播、自定义文件播均需要通过筛选服务处理后才可执行下发，下行链路中（如图2.1.2）优先级最高是的任务受理和任务发送流程（红色链路），即无论发生什么情况都要保证客户消息的正确下发，是U-Push服务稳定性的底线。出于融灾考虑，筛选服务在架构上与主链路解耦。

图2.1.2 筛选和核心链路隔离

2.2 数据架构目标和设计

提到筛选，其本质是通过建立合理的标签索引系统实现数据的快速定位。筛选的目标是U-Push核心设备库，但是为避免筛选请求影响到核心库稳定需要将待筛选集合分库冗余存储，与一般OLAP，OLTP场景不同，U-Push筛选的应用场景更加苛刻。

不俗的在线任务并发能力

筛选本质还是在线场景，具有一定的并发能力，并发压力主要在于压榨系统IO上，通过合理的中间件使用、严谨的服务调度、针对性场景的差异化设计降低单次筛选的执行时间，提高并发。