消息中心架构浅析
在开发消息中心时，需要将各个端产生的消息进行聚合，并调用其他的接口获取额外的信息之后，再在消息获取接口提供。
消息产生Producer
这部分主要是放在各个端中，各个端写入消息到MQ中
消息消费BaseConsumer
当从MQ中订阅得到的消息之后，会有BaseConsumer分发给各个事件的消费者。这一步这要是负责把消息读取并写入redis的过程。写入redis的时候，需要产生相应的key。
key应该由几个部分组成：事件名+消息用户id+时间段时间戳。
时间段时间戳是指：比如需要在聚合5分钟内的消息，现在是15:02获取到了某一条消息，那么写入这个消息的时候，『时间段时间戳』就应该是15:05的时间戳，并且在15:05之前到达的事件都应该是这个值，这样就起到了聚合的作用。
写入消息的时候需要往两个地方写：
- redis zset 结构的 『key』集合: 用于存放key
- redis list 结构的 『key-value』: 用于存放key对应的消息的列表，在某一个短时间内的相同事件的相同用户得到的消息应该被追加到同一个key里面。
消息聚合处理BaseProcesser
这部分会由一个BaseProcesser周期性的读取 zset 中的key，并把这个key中redis list中获取键值对，再将消息取出来进行进一步的处理，比如调用其他接口、拼接内容等等。
在这里只有一个zset key 应该可能还不行，读取完zset key之后在处理的过程中可能还出现异常，还需要另一个zset key来临时存放，当正确处理完成之后再删除。
zset 是为了并发读取的时候 能够不会被多台机器读取。
消息存储Saver
消息聚合处理之后会放入存储接口。通常情况下会把消息放入持久库和缓存库用于提供更快的消息查询时间。