消息队列

发表于 更新于 分类于

一、消息队列MQ基础

在服务化架构中，消息队列的作用时不可替代的。服务化架构的异步通信、流量消峰、跨语言调用、通知协调等等很多功能都会用到消息队列。
在选用MQ时，要考虑一下我们的需求和MQ自身功能是否匹配，超前的使用有时候并不能给我们带来相应的好处，反而可能会成为使用的障碍。
消息队列有点对点（point to point， queue）与发布订阅（publish/subscribe)等方式。

1、MQ核心组成

Sender（Producer App）——Message Queue——Receiver（Consumer App）

2、MQ vs SOA

消息队列的出现意于完成系统间的消息通信，协调系统调用间调用。这跟SOA类似。但不同于SOA面向服务的直接调用，消息队列的通信不是直接调用关系，系统间通信主要通过消息发送，接收方接收消息，进行处理，完成与发送方的调用处理。

3、消息队列的优势

（1）系统解耦
交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。

（2）提高系统响应时间
例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。

（3）为大数据处理架构提供服务
通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

二、消息队列需要注意事项

  • 是否保证消息顺序；
  • 消息拉取／推送模式有哪些；
  • 水平扩展能力；
  • 实时能力；
  • 消息堆积能力；
  • 监控功能是否完整／是否提供了完善的监控接口；
  • 是否有持久化能力；
  • down机重启后，是否可以继续消费；
  • 社区活跃度、更新频率；
  • 成功使用案例。

三、分布式事务

分布式事务经常会涉及到的概念有两阶段提交、一阶段提交、事务补偿等等，可参考相关文档说明了解详细内容。
这里我们要分析一下，使用事务的最终目的是什么？首先想到的是同时成功或失败，再深入分析一下，我们终于明白要的是什么了：数据的一致性，一致性又分为 最终一致、强一致和弱一致三种。那么是不是所有的场景都要求必须要达到数据的强一致呢？显然不是，这需要我们根据实际情况分析（鱼与熊掌不可兼得，这是一 个不使用任何程序控制事务的场景，一个操作先插入从属信息再插入主信息，即便主信息插入失败也不会给用户带来影响，类似这样以空间换时间的方式也未尝不 可）。
数据的最终一致性业界有了很多的解决方案（非事务方式）。
1）使用MQ、Redis进行协调控制从而达到数据最终一致；
2）通过分析MySQL的Binlog达到数据最终一致；
3）根据行业、业务特点自己实现的数据最终一致。