消息-push系统架构

 

消息\推送架构图： 说明部分

        快讯推送逻辑：（见图最下面部分）

a.        CMS系统：  发布快讯后会往收集服务器队列（kestrel）中发送一条消息，消息内容为：  推送类型+消息id。

b.     收集collector工程  会从该队列取出消息，并启动相应的collector线程，收集需要推送的push消息并发送到相关队列（imq/wmq/搜狐微博队列/android服务器），所有队列都是本地队列。技术点说明：

收集工程中任务分工策略（iphone为例）：

        收集工程是按线程为单位来进行分工合作的，比如iphonepush信息单元收集，有180个线程，编号为1、2、3……180，编号为i的线程负责id=180*n*((i-1)*4000 ~i*4000)  {n=0 、1、2……}的iphone用户的收集工作。收集模块在收到订阅的termId时，会依次启动所有180个线程开始收集工作，每个线程会遍历它负责的用户，查询他是否订阅了termId的期刊，如果订阅了就组装一份推送的信息入队。

         收集工程中预加载用户和订阅信息（iphone为例）：

        收集工程时刻在内存中维护了一份系统用户的和用户的订阅信息，并且每隔一段时间（15分钟）要加载一次（保证用户和用户订阅逻辑的实时性），同时按{类型---线程---用户}的数据结构进行封装。一个线程只需要给出收集的类型、线程编号就可以获得它要负责的用户集合

 

c.      推送工程   相应消费者会消费相应队列的消息，并推送给不同的服务商server。技术点说明：

             

推送工程中第三方jar包使用（iphone为例）：

Ios推送到苹果服务器，使用三方推送包：javapns2.2。目前该jar包目前有bug，如果调用了他的stopConnection()\restartConnection()会导致重复push，具体bug代码见PushNotificationManager.processedFailedNotifications()方法。

Javapns会有发送失败的情况，但是pushedNotification.isSuccessful()方法不是同步的，需要过一段时间去判断是否成功，javaapns里面有失败重发的逻辑，调用stopConnection()\restartConnection()时候会触发失败重发的逻辑。所以业务代码一个与苹果服务器的push链接需要隔一段时间根据业务情况调用stopConnection()\restartConnection()，触发失败重发的逻辑