消息队列：解决蜘蛛网式异步通知问题，带来的五个好处

互联网业务讲究”快”，很多业务处理必须走异步——比如大V发一条微博后，系统要通知所有关注他的用户，不可能等所有通知都发完才告诉大V”发布成功”，只能先让大V发布成功、再异步通知关注者。传统的异步通知方式是消息生产者直接调用消息消费者提供的接口，业务规模变大、子系统一多，这种点对点通知会让系统间交互变得极其复杂——各系统互相依赖调用，整个系统结构变成一张蜘蛛网。消息队列正是为了实现这种跨系统异步通知的中间件，既能”一对一”通知，也能”一对多”广播（还是以微博为例，一条微博发布事件可以广播给成千上万个关注者）。引入消息队列后相比蜘蛛网式的直接调用，能带来五个明显好处：整体结构从网状变成线性结构，架构一目了然；消息生产和消息消费彻底解耦，双方实现都变简单；新增一个消息消费者时，消息生产者完全不需要任何改动，扩展起来很方便；消息队列系统本身可以统一做高可用、高性能，避免每个业务子系统各自重复造一套异步通知机制、白白浪费工作量；业务子系统因此可以只聚焦在自己的业务逻辑上，实现更简单。消息队列的基本功能（发消息、收消息）实现起来不算难，但真要做到高性能、高可用，同时还要保证消息时序性、消息事务性，就比较有挑战了。业界已经有很多成熟的开源实现（RocketMQ、Kafka、ActiveMQ等），如果对消息可靠性、时序、事务性要求不高，直接拿开源方案用就行；但如果业务对这几点要求很高，就必须深入研究这些开源方案的实现细节，否则很容易踩坑。开源方案用起来方便，但真要改动它就比较麻烦了，因此不少公司也会花人力时间重复造一个消息队列的轮子——这种”重复造轮子”未必是坏事，好处在于自己造的轮子可以根据自身业务特点快速做定制化适配。

结构图：

flowchart TB
  A["传统直接调用：消息生产者直连消费者"]
  A --> A1["子系统多了后变成蜘蛛网结构<br/>系统间互相依赖，交互极其复杂"]
  A1 --> B["引入消息队列(可一对一/一对多广播)"]
  B --> C["好处①网状→线性结构，架构清晰"]
  B --> D["好处②生产消费解耦，实现简单"]
  B --> E["好处③新增消费者，生产者零改动"]
  B --> F["好处④高可用高性能集中实现<br/>避免各子系统重复造轮子"]
  B --> G["好处⑤业务子系统只需聚焦业务逻辑"]