Push：有主动推的意思，实际上就是一个服务端主动推送消息到用户App的一个系统。“苹果之父”乔布斯曾说：“根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。”我感觉这句话用在推送上也是可行的。
今天主要从新闻app产品类型来介绍push系统的搭建与实践。
- 静态全量库，非实时更新，分布式提取
- 优先级排序（用户活跃度），保证用户体验
- 常备部分资源，保证及时响应
- 动态扩容，减少闲置资源
系统整体架构
采用阿里云产品的存储方案
机器复用和阿里云ecs的动态扩容
多播或群发
由兴趣，关系，LBS等部门针对不同人群做的群发push
难点 计算慢：特征工程（小时），特征匹配（分钟），用户设备更新
大批量：任务多，互相挤压，高低优先
频繁：下发条数太多，影响用户体验（push太多）
厂商通道限额
应对
数据架构：上面已经提到过的，hbase+spark
动态扩容：关键指标监控，自动触发扩缩容
混排：特征匹配混排，CTR试投，控制单个用户下发条数
限流器：厂商通道限制
物理隔离：分为重要通道和普通通道
混排与试投
厂商通道限额问题
总配额限制：额度熔断
QPS限制：限流器
单设备配额限制
偶发rt抖动：自动扩容，熔断
三种分布式限流器
短对点/长链接
与APP端的TCP长连接
用于push，IM，配置下发等多类功能
难点 ：
高并发连接数（千万级）
低延时需求（消息下发时间短）
大消息量（X十亿级消息数）
高到达率要求：连接稳定，分运营商机房，动态均衡算法
增加在线时长：心跳算法
长连接服务端基本逻辑
批量发送
连接和断开
