使用apns构建push服务开发思路

      上一次折腾PUSH服务已经好几个月了，终于抽空重构了（APNS：Apple Push Notification Service,我谈的其实只是构建一个中间平台去调用apns服务）。       

      先介绍下之前所做的push服务的设计模型

 

当初的设计比较简单，将压力全部放在了推送消息处理线程上，线程不仅需要建立apns服务器的通信，也需要对广播消息进行转换。对于单播消息而言性能似乎还可以接受，然而对广播消息处理，线程的处理性能明显降低。因为apns服务是不支持广播消息的，进行广播必须要获取到所有广播对象的devicetoken，这就需要线程去批量获取推送对象列表，并将这个列表组成单播message，而后批量发送。这样的设计将消息处理和发送耦合在了一起，无法并行处理。虽然通过异步通信的方式实现了批量发送，但是总体而言性能还是很低的。

       之前设计最根本的的问题是耦合了广播消息本身的处理和发送的处理，发挥不了多线程处理的性能。这次重构，主要的性能优化就是，区分了推送请求队列和推送消息队列，请求处理线程只专注对推送请求的处理，生成可用于直接发送的推送报文，并均衡负载到推送消息队列上。推送线程则专注于推送本身，每个线程hold一个与apns的连接，发送推送报文。

将push请求处理和push发送处理分开，也给系统扩展提供了更多的可能性。单服务器可以设置多个请求队列、多个发送队列，每个队列允许多个线程进行监听处理。也可以将推送请求处理和发送处理分开部署，并进行均衡负载。

       废话了这么多，最后再戳下漏洞：由于没有区分消息级别，即时消息可能会淹没在队列中。对于实时性要求不是非常高的一般应用上面的模型还能凑合使用。大家有什么好的设计思路欢迎讨论。

 

欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。