该用哪一个消息队列呢？

业务系统中的核心业务数据变化比较少，但是读取量却巨大无比，目前不超过30W条数据，但是每日的读取量都在3000W+以上，整个业务数据直接使用Java序列化缓存起来占用的内存总量不超过175MB，如果采用Redis/memcache等集中式缓存的话，对存储空间和并发量来讲都可以接受，只是需要实现非常可靠的高可用性，至少要双机（主备、双写等方式都可以接受），并且要有良好的单点失败处理机制（如果Cache挂5秒，连接Cache使用1秒超时的话估计系统整个会被拖垮）。

鉴于这样的特征，我考虑使用本地缓存的方式来存储这些最核心的数据，给WEB前端系统提供最可靠、最高效的支持。缓存直接分散到各WEB机器上去了，可靠性立马就上来了，由于是本地JVM内的数据，用Hash存储的话，性能那也是Redis/memcache之流没法比了。

接下来需要决绝的问题就是如果同步更新缓存这个问题了。

有好些可以选择的方案：

（1）采用OSCache之类的JGroup方式来组播方式更新；

（2）定时加载DB中有变化的那一部分数据；

（3）使用支持发布/订阅机制的消息队列等；

（4）采用Linkedin的Databus的方式，来直接解析DB的binlog来更新；

个人倾向于使用方案（3），不光是为了处理这个业务，对于我等互联网业务来讲，要使用异步解耦合的地方实在是多，有了消息队列这个大刀，很多地方都可以砍一砍了。只是，消息队列也实在是多，比如RabbitMq、ActiveMq、Memcacheq、ZeroMq、MSMQ、Redis、Kafka等等，对于Kafka我是情有独钟的，一直也想使用它做实时的日志分析的队列，只是很遗憾，业务系统中采用的消息队列要求是不能丢数据、最好有顺序、支持持久化存储消息、可用性要很好，它有点不满足这个要求（最新的0.8版本支持这些特性），其中Redis、ZeroMQ也被淘汰了，只剩下RabbitMq、ActiveMq这个2个重量级产品和相对较为轻量的Memcacheq、MSMQ了。

看来要把这几款产品拉出来溜一溜了！