RabbitMQ 入门系列（5）— RabbitMQ 使用场景优缺点

1. 为什么要使用 MQ

1.1 异步

怎么理解异步这个概念呢？ 举个简单的例子，假设有个业务需要写数据库，但是呢写数据库需要一定的网络开销，可能是几毫秒或者几十毫秒，这对于延时要求很高的业务来说是不可接受的，在写数据库的同时会严重阻塞后面的任务。要解决这种场景的问题，就需要采用异步的设计。

而 MQ 的出现为这种异步的设计提供了很好的支持， 我们可以把要写数据库的 SQL 存储在 MQ 中，而由另外的进程从 MQ 中读取并写进数据库， 这样就可以避免主业务在写数据库延迟操作。

1.2 解耦

解耦， 从字面意思来看就是解除耦合。以上面的例子继续来讲，假如 A 功能用于生成写数据库的 SQL， 而 B 功能用于将 SQL 执行写到数据库， 那么假如业务需求发生变更，需要写多张表或者修改生成的 SQL，那么我们只需要修改功能 A 就可以。

而假如没有解耦的话，那么就必须修改整个业务逻辑，肯能会引发其它的问题。

1.3 高并发缓冲

假如瞬时间有 1 万个任务同时触发， 但是系统最大能同时负载 1000 个任务，如果在同一时刻处理这 1 万个任务，系统可能会崩溃，那么就可以把这 1 万个任务发送给 MQ，让 MQ 先缓存下来，然后系统在每秒从 MQ 中获取 1000 个任务来处理。这样就可以避免瞬时间给系统造成的压力。

1.4 顺序调度

先进先出,按顺序处理。

2. MQ 可能带来的问题

2.1 系统可用性降低

增加 MQ 之后在一定程度上方便了我们专注于业务开发，但是如果 MQ 使用不当或者 MQ 突然挂掉，那么就会对我们的业务造成很大的影响。所以从这个角度来看增加 MQ 会使我们系统的可用性降低。

2.2 系统复杂度提高

本来系统通过调用接口就能完事的，但是加入一个 MQ 之后，需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题，为了解决这些问题，有需要引入很多复杂的机制，这样一来系统的复杂度提高了很多。

2.3 数据一致性问题

当 A 功能生成 SQL 之后，A 就认为当前系统中某个属性已经发生变更，但是假如 B 功能没有将 SQL 写进数据库那么就会造成系统某个属性的实际值和预期值不一致问题。