[TOC] #### 1. 前言 --- 凌晨三点，你被电话吵醒，运维告诉你：RabbitMQ 所在的服务器宕机了 你打开监控一看： + 所有 Producer 发消息失败 + 所有 Consumer 消费停止 + 订单消息积压了几千条 + 短信停发，邮件停发，物流通知停发 整个系统的消息收发全部停止，你只能等服务器恢复，或者紧急在另一台机器上重新部署 RabbitMQ 这就是单机部署的风险 #### 2. 单机有什么问题 --- 问题一：单点故障 RabbitMQ 部署在一台机器上，这台机器就是唯一的依赖，机器挂了，RabbitMQ 就没了 不管是硬件故障、系统崩溃、还是误操作，只要这台机器出问题，整个消息系统就停摆 问题二：容量瓶颈 一台机器的 CPU、内存、磁盘都是有限的，消息量小的时候没问题 但随着业务增长，一台机器可能扛不住了： + 连接数达到上限 + 内存不够用 + 磁盘 IO 成为瓶颈 单机垂直升级（加 CPU、加内存）有上限，而且升级的时候需要停机 问题三：无法应对流量洪峰 双十一、大促、秒杀，流量瞬间暴涨，单机的处理能力是固定的，扛不住就是扛不住 #### 3. 集群能解决什么 --- 把 RabbitMQ 部署到多台机器上，组成一个集群，多台机器分担压力 + Producer 可以连接不同的节点，分散连接压力 + 消息可以分布在多个节点上，分散存储压力 + 某个节点挂了，其它节点还能继续工作 这就是集群的核心价值：高可用 + 可扩展 但集群不是万能的 在你兴奋地准备搭集群之前，先了解一个事实：RabbitMQ 的普通集群模式，并不能解决所有问题 普通集群下，队列的数据仍然只在一个节点上，如果那个节点挂了，队列就不可用了 这就像你把快递柜从一个城市搬到了三个城市，但你的包裹还是只放在其中一个柜子里，那个柜子坏了，你的包裹还是拿不到 想要真正的高可用，还需要更进一步的方案，这个我们后面会讲 #### 4. 本文小结 --- 单机部署的风险： + 单点故障：机器挂了，消息系统全停 + 容量瓶颈：单机性能有上限 + 流量洪峰：扛不住瞬间暴涨 集群能解决： + 分散连接和存储压力 + 某个节点挂了，其它节点还能工作 但普通集群有局限： + 队列数据仍然只在一个节点上 + 节点挂了，队列不可用 下一讲我们来详细看看：普通集群到底是怎么回事，它解决了什么，又没解决什么