需求描述
为什么要尽快到达用户端呢？
因为消息具有时效性，在一个不恰当的时间给用户消息，不仅容易被忽略，而且会骚扰到用户。
我们需要解决几个问题：
1、用户按活跃日期由新到旧顺序排序。
2、推送过程中途停止后，可以重新推送新消息。那么就需要一个可以重复消费的高性能消息队列。
3、消息推送过程，用户可能网络在那时间点没连接上，所以需要存储起来，等用户连接上来的时候同步消息。于是，需要一个高性能的存储。
4、用户可以按条件筛选出指定的一部分用户。（男/女）（主播/用户）（商家/用户）
存量用户量级，我们以5000W做为目标。
以下为架构图：
用户活跃排序
首先，从点击“消息推送”按钮开始，需要尽快发送用户。于是，用户活跃排序不能是临时排序，必须提前排好序。我们采用每天凌晨4点，导出一份用户活跃排序的数据。
其次，活跃用户有一定量级，会产生大量的网络连接/断开连接（长连接架构）。如果是短连接架构可能会更多。每次用户连接活跃就会记录下这个用户的活跃时间点，那么也需要一个高写入性能可扩展的存储。
最后，排序导出的用户活跃的过程，不能产生重复的用户数据（快照），否则就会有用户重复收到相同的消息。
这里采用了mongodb的wiredtiger引擎来处理记录用户的活跃时间以及ios token等信息。高写入性能，并且可以支持按任意索引来排序导出快照。这里存储的用户信息，除了提供给推送系统外，还会提供给其它系统使用。例如用来查询userID与DeviceID之间的关系。
（mongodb分片按照用户来区分）
导出了用户活跃数据，就可以把这个预先插入到消息队列里，等待随时被消费。
消息队列
消息可随时终止推送，并且重新发送新消息。那么就要求消息队列里的用户数据在消费后不能马上就删除了，要可重用。
这里采用Kafka作为消息队列，消息消费相当于游标移动。当需要终止推送时，游标重新回归初始值即可重新消费。不存在重新导出用户活跃排序和重新加载进队列的过程。
消息存储
消息的特性是：
1、有时效性，所以需要有数据过期功能。
2、数据量很大，高写入，高删除，无更新。需要尽量避免磁盘碎片。
3、基本都是冷数据，消息读取一次，就不会再读了。缓存无作用。
采用cassandra的一大原因：
1、相比mongodb节约资源。cassandra采用DateTieredCompactionStrategy存储策略，非常适合临时性数据的删除和回收。避免压缩数据时，还需要预留一倍的内存来做压缩操作。
2、架构相对mongodb层级要少，性能消耗更少，更容易管理。
（cassandra分片按照用户来区分）
消息的重要性：
1、不仅仅应用于消息推送，用户之间的IM私信、订阅的内容提醒等等。所以必须要可容灾的。
2、当推送的速度很快，占满了消息存储的资源怎么办？这是需要推送服务控制好速度的。
按条件筛选出用户
这种情况如果要做出一个理想的方法比较难。我们假设分为两种情况：
1、条件比较少，筛选出来的用户比较多。（商家/用户）
2、条件比较多，筛选出来的用户比较少。（广州天河区的男性用户）
第一种情况，我们依旧采取预处理的方法。与全局用户的处理方法一样，只是分了不同的队列名。
第二种情况，由于数据量比较少了。我们可以动态筛选用户，这需要耗费一定时间在筛选用户上面，不能立即推送。但由于用户量少了，最终的完成时间也会在可控范围内。
回顾
从效果上看，当运营操作人员点击“推送消息”按钮开始，最近活跃用户就立刻陆续收到了消息推送。每个环节都是可扩展的，以普通服务器为评估，Kafka消费每秒6W+不成问题，cassandra写入每秒4W+，推送服务每秒2W+（json解析格式比较耗时）（部署两个实例）。比较容易就达到了4~5W的速度。1分钟300W用户；5000W用户大约16分钟可以处理完成。当然，这是把资源耗光的计算方法了，实际上还是需要预留资源的，而且也会扩展多个节点来扩展性能。
原创博客，转帖请注明原出处：http://my.oschina.net/u/223522/blog/726417
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
