影响推送系统到达率的四个因素

决定推送系统实际效果的，不只是服务端架构，客户端SDK和网络策略的完善程度往往才是消息能不能真正送达的关键。一，SDK的完善程度：选路策略要足够灵活——简单地对用户做Hash分配固定IP在国内网络环境下不可行，因为同一地区不同用户对同一IDC内不同IP的连通性可能不一致，甚至同一IP不同端口的连通性都会不同，所以分配器最好返回一组散列的IP和端口，必要时客户端多组都连不上还能拿到不同IDC的服务器；客户端还要对不同网络环境（WiFi/2G/3G）下的长连接IP做缓存，网络切换时重新请求分配器。二，恰当的心跳和读写超时设置：心跳要能根据网络环境和客户端消息活跃程度自适应调整并和服务端协商，弱网络下多久没收到ping响应就判定网络异常、要不要重连是个需要权衡的问题，不同网络环境读取不同长度消息的容忍时间也不能一刀切——好的心跳/超时设置能让客户端最快检测到网络问题并重建链路，同时在网络抖动时依然完成大数据传输。三，结合服务端做的特殊策略：比如选路时尽量把同一用户映射到同一个Room Service实例上，断线时客户端优先重试上次连接成功的地址，这样服务端可以在闪断场景下暂存该实例上的用户信息，重连时只需要做单实例内的迁移，减少延时和加载开销。四，客户端保活策略：很多创业公司觉得自建push系统不难，协议完备的情况下服务端确实能保证消息不丢，但真正的问题是”消息有效期内到达率上不去”——原因往往是自家App的Push Service存活能力不够高，大厂或云平台的SDK之所以更有保障，是因为它们会做”多个使用同一SDK的App互相唤醒”这类保活策略，这也是push SDK普遍走”单连接、多App复用”模式的原因，但这种模式又给流量归属统计、多App间SDK版本不一致等问题带来了新的复杂度。综合看，选择推送平台时应该优先看客户端SDK的完善程度，服务端方面则更看重接入点（IDC）数量是否够多、配合精细选路策略。