前言：App推送在日常运营场景中经常用到，如：资讯类的新闻及时下发、生活服务类优惠券精准推送、 电商类的货品状态或是促销优惠等，通常开发者会根据运营的需求通过自建消息推送通道或使用第三方消息推送平台实现，但自建消息推送的开发成本和人力成本非常高， 很多App开发者选择第三方消息推送。今天就以友盟+消息推送U-Push，详细解读在海量业务背景下如何保证服务的稳定性以及功能丰富的触达服务。
1. 业务背景友盟+消息推送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功能清单
2. 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筛选的应用场景更加苛刻。
1. 不俗的在线任务并发能力