如何保证推送消息能够准确推送到客户端。

手机端：

• 轮询方式获取消息。
• 短信拦截模式。 发送短信通知消息，应用中的短信拦截模块拦截短信，并解析成数据。成本高。

• 持久连接。

  监听电量变化，网络变化，开关屏幕等等时候注册BroadCastReceiver来接收通知，接手后进行消息获取。
  有些ROM一旦用户kill掉主线程，就不会再投送广播消息给应用，导致应用无法启动，这是可以Fork一个进程,一旦发现主线程被杀，立即调用shell启动该Service（应用保活）

微服务间如何选择推送和拉取数据

在消息系统中，一般有两种消费模式：生产端推送消息，消费主动拉取消息。

数据是动态的，且实时性较强，宜采用生产端推送。

例如家长手机控制孩子手机使用，希望设置立即生效，家长端设置后由立即由中间系统进行通知。如果让消费端轮询查消息，不仅不能保证消息的实时性和准确性，而且系统也会造成一定的损耗，供应链系统也会被迫处理重复订单问题。
如果把消息设置成实时推送也是不合适的，推送成不成功不应该作为设置成功的条件。设置功能和推送功能不应该是强关联的，就像发送验证码，服务器收到了发送验证码的功能请求后，异步交给验证码发送功能，返回给客户200成功，随后验证码发送功能进行异步通知，确保通知成功即可。

客户端长时间离线状态

客户端长时间离线状态（断网，没电等等），没办法推送过去，会暂存在一个暂存表中，等待客户端联网等监听广播事件进行主动获取，消息获取成功，就会把离线消息表里的消息转移到已发送的消息表中。（不在本表中将已发送的消息的字段置为已读，会影响查询速度。）

推送的优点

• 时效性高。
• 服务器压力小。 相对比轮询拉取模式，每次推送都会有数据，有效避免了空轮询
• 交互简单。 只需要提供推送接口就好了，不需要额外开销。

推送的缺点

• 不能保证一定能推送成功。
• 缺乏数据多样性，推送的消息一般都有固定的模板

  极光推送

• 活跃用户的到达率在90%以上。轮询获取99%以上。
• 并发情况下第三方服务的实时性不太理想。

自主研发的推送系统

• 对客户端的海量长连接的维护管理消耗太大。
• App端Service稳定性，保活。
• 有些厂商不允许有push service存在。

自主研发的推送架构

架构方案类似：

（图片来自架构之美公众号，侵删）

• 通过动态组合和扩展方式，结合移动Push推送数据分析，不同的手机使用不同的方案，针对性的优化，android平台中，融合多种不同的第三方推送PUSH平台，提高转化率。