遇到的一些问题

  • 交换器队列绑定有问题
  • 客户端代码编写问题
  • 没有选择合适的交换器类型
  • 客户端与MQ连接阻塞
  • 网络分区的发生与恢复方案
  • 非持久化镜像队列同步异常

性能优化

  • 优化网络配置（禁用Nagle算法，增加TCP缓存区大小）
  • 客户端代码优化（事务，普通confirm，批量confirm和异步confirm）
  • publisher confirm和comsumer ack，prefetchCount数值
  • 镜像队列的使用拉低整体性能
  • Erlang Hipe compile
  • 避免触发流控机制影响性能

消息传输保障

  • 生产者publisher confirm机制确保消息可靠传输到MQ中

  • 生产者配合使用mandatory或者备份交换器确保消息能够从交换器路由到队列中，进而能够保存下来而不会被丢弃

  • 交换器、消息、队列需要进行持久化处理

  • 消费者在消费消息的同时需要将autoAck设置为false，手动确认消息已经被正确消费

RabbitMQ没有消息去重机制，需要业务方根据自身的业务特性进行去重

运维监控

集群搭建

节点故障恢复

集群监控

  • 通过HTTP API接口提供监控数据
  • 通过客户端提供监控数据
  • 元数据管理与监控

跨级群和WAN部署

使用Federation和shovel可跨越集群（网络状态良好的LAN）界限，实现WAN部署

项目中待改善的细节

  • 使用rabbitmq达到一定规模后，可根据业务功能和场景进行归类拆分，为之分配不同vhost
  • 用户是访问控制的基本单元，单用户可跨多个vhost进行授权，需合理配置用户权限
  • 使用aliveness-test程序配合AMQPPing一起全面监控RabbitMQ服务
  • 加强元数据管理与监控，提供给业务方使用的用户只有可读可写权限，不能够变更元数据信息

  • 目前MQ程序异常是单纯通过守护脚本拉起，这其中逻辑需要完善，确保在启动时最后关闭的节点是第一个启动的

  • 没有对重要业务加以区分，制作备份交换器
  • 没有监控队列中可能存在的消息积压的情况，运维部分薄弱
  • 可考虑预先分配创建元数据资源，避免人为因素，代码缺陷导致的MQ使用问题
  • 格式化使用reset操作而非删除menisa数据

消息追踪和问题定位

  • 使用firehose和tracing插件追踪消息的处理过程
  • 在开启web管理插件的前提下，登陆操作界面查看问题
  • 合理利用amq.rabbitmq.log交换器，过滤不同级别日志信息
  • 查看日志文件分析定位问题
  • 使用操作管理命令（rabbitmqctl）和HTTP API接口