Docker搭建高可用消息中间件的核心是构建具备容错、自动恢复和横向扩展能力的消息链路，关键在于集群设计、状态分离、健康保障与故障切换机制。
用Docker搭建高可用消息中间件，核心不是单个容器跑起来，而是让整个消息链路具备容错、自动恢复和横向扩展能力。关键在于集群设计、状态分离、健康保障和故障切换机制。
选型与集群结构要匹配业务可靠性要求
不同消息中间件的高可用实现方式差异较大，需按实际需求选择：
- RocketMQ：必须部署NameServer集群（≥2节点）+ Broker主从对（Master/Slave），NameServer无状态可水平扩展，Broker通过同步刷盘+异步复制保障数据不丢
- RabbitMQ：推荐镜像队列（Mirrored Queues）模式，所有节点保存完整队列副本，配合HA策略自动选主；或使用Quorum Queue（3.8+版本），基于Raft协议保证强一致性
- Pulsar：天然分层架构（Broker + BookKeeper + ZooKeeper），三者均可独立扩缩容；BookKeeper负责持久化，即使Broker宕机也不影响消息写入
- 避免单点：绝不只起一个NameServer、一个ZooKeeper或一个Broker；最小可用集群至少含2个协调节点+2个处理节点
用Docker Compose或K8s编排服务依赖关系
容器间网络、启动顺序和配置注入必须显式声明，不能靠人工连通：
- 定义统一自定义网络（如rmq-net），让namesrv、broker、console等服务通过服务名互通，不依赖IP
- 用depends_on配合healthcheck确保Broker启动前NameServer已就绪（仅Compose v2.3+支持条件等待）
- 环境变量集中管理：如NAMESRV_ADDR=nameserver:9876、PULSAR_SERVICE_URL=pulsar://broker:6650，避免硬编码
- 挂载外部配置文件（如broker.conf）和数据卷（logs/store），保证容器重建后配置不丢失、消息可恢复
内置健康检查与自动恢复策略
容器“活着”不等于服务可用，必须探测真实业务端点：
- 为每个服务配置healthcheck：RocketMQ用curl -f http://localhost:8080/status，RabbitMQ查/api/health，Pulsar调/admin/v2/brokers
- 设置restart: unless-stopped，防止进程崩溃后服务中断
- 在负载均衡层（如Nginx或HAProxy）启用主动健康探测，自动摘除异常Broker或Pulsar Broker实例
- 对有状态组件（如BookKeeper Ledger、RocketMQ Store）启用readinessProbe和livenessProbe，K8s中区分就绪与存活状态
配套可观测性与运维闭环
高可用不只是“不挂”，更是“挂了能快速定位、快速切流、快速修复”：
- 所有组件日志统一输出到stdout/stderr，用docker logs -f或ELK采集，禁用本地文件日志分散排查
- 集成Prometheus Exporter：RocketMQ有rocketmq-exporter，RabbitMQ自带/metrics端点，Pulsar通过pulsar-perf暴露指标
- 部署可视化控制台（如RocketMQ Console、RabbitMQ Management Plugin、Pulsar Manager），实时查看队列堆积、消费延迟、Broker状态
- 配置告警规则：如消息积压超1万条、消费者延迟超60秒、磁盘使用率＞90%，触发企业微信或邮件通知
