如何保证消息队列的高可用性
RabbitMQ的高可用性
RabbitMQ是比较有代表性的，因为是基于主从做高可用性，RabbitMQ有三种模式，单机，普通集群，镜像集群模式
单机模式
就是Demo级别
普通集群模式
多台器上启动多个RabbitMQ实例，每个机器启动一个，但是创建的Queue只会放在一个RabbitMQ实例上，但是每个实例都同步queue的元数据，消费的时候如果连接到了另外一个实例，那么这个实例就会从queue所在的实例上拉取数据过来
这种方式确实很麻烦，也不好，没有做所谓的分布式，就是个普通集群，因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在的实例消费数据，前者有数据拉取的开销，后者导致单实力性能瓶颈
而且如果那个放queue的实例当寄了，会导致接下来其他的实例就无法从那个实例拉取，如果开启了消息持久化，，让RabbitMq落地存储消息的话，消息不一定会丢，得等这个实例恢复后，才能继续从这个queue中拉取数据
所以这个方案就没有什么高可用性而言，主要就是让急群众多个节点来服务某个queue的读写操作
镜像集群模式
这种模式才是所谓的RabbitMQ的高可用模式，跟普通集群模式不一样的是，你创建的queue无论元数据还是queue里的消息都会存在于多个实例上，然后每次写消息到queue的时候就会主动把消息到多个实例的queue里的消息进行同步
好处就是如果一个机器宕机了，其他的机器一样可以使用，坏处在于，性能开销太大，消息同步所有的机器，导致网络的带宽压力和消耗很重，第二，没有拓展性可言，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，没有办法线性拓展你的queue
镜像集群开启方式
RabbitMQ有一个管理控制台，可以再后台新增一个策略，这个策略是惊喜那个集群模式的策略，指定的时候可以要求数据同步到所有的节点，也可以要求哦同步到指定数量的节点上，然后在创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了
kafka的高可用性
kafka是一个基本的架构认识，多个broker组成，每个broker是一个节点，你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据
这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据
实际上rabbitMQ之类的，并不是分布式消息队列，也就是传统的消息队列，只不过提供了一些集群，HA的机制而已，因为无论怎么玩，RabbitMQ一个Queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个Queue的完整数据
kafka0.8以前，是没有HA机制的，就是任何一个broker当寄了，那个broker上的patition
Topic,Partition,Replication
topic
KafKa与其他的MQ的区别是在于，其他的MQ同时拥有Queue(点对点)和Topic(订阅/发布)两种模式，而KafKa只有Topic一种模式，topic可以理解为消息存储的虚拟空间，也就是一个集合
Partition
KafKa是一个标准的分布式MQ，其在每台设备上都会运行一个Broker进程，如果我们定义一个Topic有三个Partition,则这三个Partition就会在设备上创建三个Partition文件，再机器上物理保存，也就是说，Partition就是消息的物理存储，我们可以再KafKa的数据目录(/tmp/KafKa-log)下面找到，命名规则为：topic_name-partition_id 此目录可以自行配置
Replication
Replication是保证KafKa消息高可用且系统稳定的一个策略，也就是HA机制，及，每个partitation都会有至少一个对应的Replication,而KafKa会通过一取模算法保证每个broker的partition和对应的Replication再不同的机器上，具体的算法是第i个Partitation存放的Broker为 i mod n ,而第i个Partition的j个 Replication存放的位置为 (i + j) mod n
