RabbitMQ如何解决消息积压问题
消费者消费消息的速度赶不上生产速度，这总问题主要是业务逻辑没设计好消费者和生产者之间的平衡，需要改业务流程或逻辑已保证消费度跟上生产消息的速，譬如增加消费者的数量等。
消费者出现异常，导致一直无法接收新的消息，这种问题需要排查消费的逻辑是不是又问题，需要优化程序。
除了上面的者两种问题，还有一些其他情况会导致消息积压，譬如一些系统是无法预计成产消息的速度和频率，又或者消费者的速度已经被限制，不能通过加新的消费者来解决，譬如不同的系统间的API对接，对接那一方就做了请求频率的限制，或者对方系统承受不了太大的并发，还有一些系统如果是面对企业客户，譬如电商，物流，仓储等类似平台系统的客户的下单是没有规律的或者集中某一个时间段下单的，这种就不能简单的通过加消费者来解决，就需要分析具体业务来避免消息积压。
解决方法：
拆分MQ,生产者一个MQ，消费者一个MQ，写一个程序监听生产者的MQ模拟消费速度(譬如线程休眠)，然后发送到消费者的MQ，如果消息积压则只需要处理生产者的MQ的积压消息，不影响消费者MQ拆分MQ,生产者一个MQ，消费者一个MQ，写一个程序监听生产者的MQ，定义一个全局静态变量记录上一次消费的时间，如果上一次时间和当前时间只差小于消费者的处理时间，则发送到一个延迟队列(可以使用死信队列实现)发送到消费者的MQ，如果消息积压则只需要处理生产者的MQ的积压消息，不影响消费者MQ
使用Redis的List或ZSET做接收消息缓存，写一个程序按照消费者处理时间定时从Redis取消息发送到MQ
设置消息过期时间，过期后转入死信队列，写一个程序处理死信消息(重新如队列或者即使处理或记录到数据库延后处理)
ZooKeeper 是什么？
ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。
ZooKeeper致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务五大特性：
1.顺序一致性，2.原子性，3.单一性，4.可靠性，5.实时性。
Zookeeper 怎么保证主从节点的状态同步？
Zookeeper 的核心是原子广播机制，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab
协议有两种模式，它们分别是恢复模式和广播模式。恢复模式 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader
的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。广播模式 一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息了，即进入广播状态。这时候当一个
server 加入 ZooKeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader
进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者
leader 失去了大部分的 followers 支持。
