消息队列
解耦 异步 削峰
异步化解耦合
缺点：
系统可用性降低 mq 挂掉 系统挂掉
系统复杂性提高 需要考虑消息的重复消费 消息丢失 消息传递的顺序性
一致性问题
可能导致数据的不一致
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量 万级 万级 十万级 十万级 一般配合大数据类的系统作实时数据计算 日志采集等场景
topic 数量 可以支撑大量的topic topic 从几十到几百个时候，吞吐量会大幅度下降
对吞吐量的影响
时效性 毫秒 微秒，延迟最低 ms ms以内
可用性 高， 高， 非常高 分布式
基于主从架构 基于主从架构 分布式架构 少数机器宕机 不会导致不可用
消息可靠性 较低 基本不低 可以0丢失 可以0丢失
功能支持 MQ领域功能完备 基于erlang开发， MQ功能完善，分布式。 功能较为简单，主要支持简单的 MQ 功能
并发能力强 性能好 拓展性好 在大数据领域的实时计算以及日志采集被大规模使用
如何保证消息队列的高可用？
RabbitMQ的高可用性 非分布式
单机模式 普通集群模式 镜像集群模式
普通集群模式（无高可用性）只能提高吞吐量
多台机器上启动多个rabbitmq 消息队列只会放在1个rabbitmq上 但是每个实例都同步 queue 的元数据
镜像集群模式（高可用性）
在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。
然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。
RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，
指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
无拓展性
kafka的高可用性
分布式消息队列 HA机制 副本机制，
写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，
leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。