消息中间件学习

定义：消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

三个角色：

生产者（Producer）：消息的产生者

消息（Message）：各个业务之间通信的“内容”

消费者（Consumer）：对消息的处理（服务进程）

消息路由：消息如何经过消息中间件到达消费者，在一定程度上决定了消息中间件的灵活性

消息可靠性：部分场景下消息是容忍丢失的，或者说对性能的渴求大于可靠性，比如异步发短信，异步发邮件，概数数据统计，日志等。有的场景是不允许消息丢失的，消息的丢失会带来数据的不一致，不一致的数据很多时候是灾难的开始，比如异步写数据，下单后减库存，转账等。可靠性基本都依赖于持久化。

消息重放： 这个说的是即使是消费过的消息也能设定offset（一般是时间点）重新消费。这个功能在消息下游数据丢失，新系统导入旧数据的时候非常有用，不用再去理繁杂的数据对应关系，按照正常的业务逻辑处理消息就OK了，非常好用！非常好用！非常好用！

消息堆积 抗流量神技。像双十一这种超高峰流量都会用到这个功能，这时候一方面会把消息中间件下游业务（Consumer端）的机器挪到核心业务，另一方面消息中间件在高并发投递消息的时候可能出问题，所以把消息暂存在中间件，等流量高峰过去了再投递到下游业务

分布式集群支持 高可用的需求，解决单点问题。

消息顺序： 有的业务要求消息投递顺序和消费顺序一致，或者至少要求对于单个用户顺序一致，比如用户的赞/取消操作，顺序反了数据就会错乱

性能和扩展： 这里指的扩展是能否通过增加Consumer来提高消息的消费速率以及消息中间件的容量是否有理论的上线；性能主要指tps、qps以及并发连接数。

ACK 消息确认：在下游业务确认后才将消息标记为已消费，处理超时则重新投递消息，这里要求下游业务自己做可重入（幂等）

消息协议： 优先考虑标准协议或者使用广泛的协议，有利于后期的维护和扩展

消息中间件一下几种：

redis
activeMQ    
kafka
Zmeromq
RabbitMQ
asio   ace
opendds

各个中间件的好处与缺点，自行比较吧，使用哪个中间件还是要看具体的使用场景。这里只给出关键词，剩下的自己摸索吧。

根据我的使用场景，我打算使用Zmeromq，过段时间，再来总结zmeromq的使用方法以及特性总结。

参考自：http://www.jianshu.com/p/477618203a97