架构之路：消息队列(未完)

常用消息队列

• Apache
  ActiveMQ, RocketMQ, Kafka/Jafka
• iMati
  ZeroMQ
• Pivotal
  RabbitMQ
• Alibaba
  Notify：阿里baba的中间件必须列出来

消息队列主要应用场景

• 解耦
  解耦是指服务解耦。

实例：账户安全系统。很多应用当登陆成功后会发送短信提醒：“亲爱的用户xx，您的帐号于xx时间通过手机客户端登陆”等信息。如登录系统直接调用短信系统，那么登录系统与短信系统是强耦合。如果短信系统在这时down机（通过同步调用的方式），那我们是不是也就无法登录成功了？使用消息队列后，登录成功后只要向消息队列发送一条登陆成功的消息即可，谁关注这条消息对于登录系统并不重要。它也无需知道。

• 最终一致性
  对于事务实时性要求不高的场景下适合使用消息队列。

实例：在线购物应用包含用户下单系统与库存系统。用户下单成功后立刻通知用户下单成功，再发一条消息给库存系统。此时用户已经收到下单成功通知。但库存系统还没有减掉对应库存，此时两个系统存在不一致性。过一段时间（假设网络延迟或其它故障）库存系统收到消息，在库存量中减去对应的商品，此时系统再次回归一致性。

• 广播
  本系统拥有很多下游系统时非常适合使用广播机制（还可以使用发布订阅机制、事件监听机制）。

实例：在直播平台中有一主播开播，会发送一条开播消息。用户系统负责处理本条消息并通知所有关注该主播的用户主播已经开播。考勤系统开始记录主播的直播时长（签约主播每天要直播指定的时间）。

• 错峰流控
  不同系统间无法保证性能一致。前端服务很容易通过集群部署与负载均衡的方式进行扩容，但对于数据库来说就没那么容易了。

实例：我的前公司内部上线的考勤系统就经历过一段有趣的回忆。它以web型式发布，员工每天用自己的工号登录然后点击打卡（it公司这么搞考勤，必然被各种攻击，各种破解~~~）。它上线的第一天的down机了。因为没有考虑到上班高峰的并发。这时不要直接将考勤记录写入数据库，先将考勤信息发送给消息队列，再从消息队列已合理的速度写入数据库。这样既能保证考勤信息不丢失同时系统再也没有down机。

提供以上例子为了大家更好的理解消息队列应用场景，当然他们还有其它的解决方案。