目录
3.4 基于Zookeeper + LevelDB的 Master-Slave 实现方式
1.RabbitMQ的高可用
RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，Rabbit部署有三种模式：单机模式、普通集群模式、镜像集群模式
1.1 单机模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式。
1.2 普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
1.3 镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
2.Kafka的高可用
kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。
实际上rabbitmq之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。
kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
实际上这块机制，讲深了，是可以非常之深入的，但是我还是回到我们这个课程的主题和定位，聚焦面试，至少你听到这里大致明白了kafka是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要遇上面试官确实是kafka高手，深挖了问，那你只能说不好意思，太深入的你没研究过。
但是大家一定要明白，这个事情是要权衡的，你现在是要快速突击常见面试题体系，而不是要深入学习kafka，要深入学习kafka，你是没那么多时间的。你只能确保，你之前也许压根儿不知道这块，但是现在你知道了，面试被问到，你大概可以说一说。然后很多其他的候选人，也许还不如你，没看过这个，被问到了压根儿答不出来，相比之下，你还能说点出来，大概就是这个意思了。
3.activeMQ的高可用
ActiveMQ的高可用性架构是基于Master/Slave 模型的。ActiveMQ总共提供了四种配置方案来配置HA，其中Shared Nothing Master/Slave 在5.8版本之后不再使用了，并在ActiveMQ5.9版本中引入了基于Zookeeper的Replicated LevelDB Store HA方案。
3.1 Shared Nothing Master/Slave
该架构最大的特点是：
1）Master 和 Slave各自都单独存储持久化的消息，它们不共享数据。
2）Master收到持久化消息时，需要先同步(sync)给Slave之后，才向Producer发送ACK确认。
3）只有Master负责Client的请求，Slave不接收Client请求。Slave连接到Master，负责备份消息。
4）Master出现故障，Slave有两种处理方式：❶自己成为Master；❷关闭（停服务）---根据具体配置而定。
5）Master 与 Slave之间可能会出现“Split Brain”现象。比如：Master本身是正常的，但是Master与Slave之间的网络出现故障，网络故障导致Slave认为Master已经宕机，因为它自己会成为Master(根据配置：shutdownOnMasterFailure)。此时，对Client而言，就会存在两个Master。
6）Slave 只能同步它连接到Master之后的消息。在Slave连接到Master之前Producer向Master发送的消息将不会同步给Slave，这可以通过配置（waitForSlave）参数，只有当Slave也启动之后，Master才开始初始化TransportConnector接受Client的请求(Producer的请求)
7）如果Master 或者 Slave其中之一宕机，它们之间不同步的消息 无法 自动进行同步，此时只能手动恢复不同步的消息了。也就是说：“ActiveMQ没有提供任何有效的手段，能够让master与slave在故障恢复期间，自动进行数据同步”
8）对于非持久化消息，并不会同步给Slave。因此，Master宕机，非持久化消息会丢失。
关于ShareNothing 高可用配置的一点理解：
❶由上面的第2)步可知：Producer向Master发消息之后，Master需要将消息同步给Slave之后，才向Producer返回确认ACK。因此，对Producer的响应有一定的延时。
如果为了保证快速响应，即Producer给Master发消息之后，Master收到了消息立即给Producer回复，然后再在后台把消息同步给Slave。这又会造成数据不一致性问题。
因为，如果Master收到了消息立即给Producer回复之后，Master还未来得及向Slave同步就宕机了，如果此条消息还在Master内存中，则Master宕机后消息就丢失了。如果Master收到Producer的消息，先写入磁盘，然后再向Producer返回确认ACK，然后再在后台与Slave同步，那么Master就需要标记每条消息是否已经成功同步到了Slave，若消息还未同步到Slave，则Master重启恢复后，需要立即同步Slave。只有当Slave成功同步了所有的Master上的消息之后，才能上线。这也无法实现 automatic failover。
关于一个很好的高可靠性解决方案：可参考 Hadoop HA中的QJM机制。其核心就是：1）采用集群，能容忍不超过大多数机器的失效；2）数据只写大多数机器就返回确认，保证Client快速的响应能力；3）数据在后台在异步同步到集群所有的机器，从而保证高可用。
❷这里的Master--Slave机制中，只有一台Slave，并不是Slave集群(见上面结构图)。Master宕机，或者Slave宕机后，都会给整个服务造成极大的风险，并没有像Hadoop HA中的那样能够容忍“不超过大多数机器失效”的保证，即没有做到真正的高可用性。
❸还可能出现“双主”问题。即上面提到的“Split Brian”现象。
3.2 Shared Database Master/Slave
这是很常用的一种架构。“共享存储”，意味着Master与Slave之间的数据是共享的。
那如何避免冲突呢？通过争夺数据库表的排他锁，只有Master有锁，未获得锁的自动成为Slave。
对于“共享存储”而言，只会“共享”持久化消息。对于非持久化消息，它们是在内存中保存的。可以通过配置（forcePersistencyModeBrokerPlugin persistenceFlag）属性强制所有的消息都持久化。
当Master宕机后，Slave可自动接管服务成为Master。由于数据是共享的，因此Master和Slave之间不需要进行数据的复制与同步。Slave之间通过竞争锁来决定谁是Master。
3.3 Shared File system Master/Slave
这种方式和共享数据库存储原理基本一样，（文件系统也有文件锁），故不详细介绍。
3.4 基于Zookeeper + LevelDB的 Master-Slave 实现方式
1）这种方式使用Zookeeper选举Master。要进行选举，则需要多数派的“参与者”。因为Replicated LevelDB Store中有多个Broker，从多个Broker中选举出一个成为Master，其他的则成为Slave。只有Master接收Client的连接，Slave负责连接到Master，并接收（同步方式、异步方式）Master上的数据。
2）Quorum机制的又一应用。假设有3个Broker，那么选举时至少需要两个Broker同意（大多数）之后，才能选出Master。此外，只需要当新消息复制到大多数Broker上时，就可以给Producer返回ACK。其他少数Broker则可以在后台以异步方式复制新的消息。
比如说：一共有3个Broker，一个Master，二个Slave。当新消息到达Master时，Master需要将消息同步到其中一台Slave之后，才能向Producer发送ACK确认此次消息成功发送。
而剩下的另一台Slave，则可以在后台以异步方式复制这个新消息。此外，还能容忍一台Slave宕机。（能容忍不超过大多数的Broker宕机）
这种设计要求，可以保证集群中消息的可靠性，只有当(replicas/2 + 1)个节点物理故障，才会有丢失消息的风险。另外，也提高了一定的响应性，因为它不需要将消息同步到所有的Slave上，而只需要同步到大多数Broker上。
3）以何种标准判断谁是Master，谁是Slave呢？
【选举将会根据“消息日志的版本戳”、“权重"的大小决定，即“版本戳”越大(数据最新)、权重越高的broker优先成为master，其他broker作为slave并跟随master。】
参考：
https://www.cnblogs.com/hapjin/p/5663024.html
https://huangxubo.me/blog/activemq/activemq-install/