Replicated LevelDB Store with zookeeper

当Broker启动时，它首先向zookeeper注册自己的信息(brokerName，消息日志的版本戳等)，如果此时group中没有其他broker实例，并阻塞初始化过程，等到足够多的broker加入group；

当brokers的数量达到“replicas的多数派"时，开始选举，选举将会根据“消息日志的版本戳”、“权重"的大小决定，即“版本戳”越大(数据最新)、权重越高的broker优先成为master，其他broker作为slave并跟随master。

当一个broker成为master时，它会向zookeepr注册自己的sync地址信息；

此后slaves首先根据sync地址与master建立链接，并同步消息文件(download)。

当足够多的slave数据同步结束后，master将初始化transportConnector，此后Client将可以与master进行数据交互。

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="mq-group" brokerId="mq-group-0" dataDirectory="${activemq.data}">  
  
    <persistenceAdapter>  
        <replicatedLevelDB directory="${activemq.data}"  
          replicas="3"  
          bind="tcp://127.0.0.1:0"  
          zkAddress="127.0.0.1:2181"  
          zkSessionTmeout="30s"  
          zkPath="/activemq/leveldb-stores"  
          hostname="broker0" />  
     </persistenceAdapter>  
           
</broker>  

 

    Master-slaves集群中，所有的broker必须具有相同的brokerName，它作为group域来限定集群的成员，brokerId可以不同，它仅作为描述信息。

“replicas”参数非常重要，默认为3，表示消息最多可以备份在几个broker实例上，同是只有当“replicas/2 + 1”个broker存活时(包含master)，集群才有效，才会选举master和备份消息，此值必须>=2。

Client发送给Master的持久化消息(包括ACK和事务)，master首先在本地保存，然后立即同步(sync)给选定的(replicas/2)个slaves，只有当这些节点也同步成功后，此消息的交互才算结束；对于剩下的replicas个节点，master采用异步的方式(async)转发。

这种设计要求，可以保证集群中消息的可靠性，只有当(replicas/2 + 1)个节点物理故障，才会有丢失消息的风险。通常replicas为3，这要求开发者需要至少部署3个broker实例。

如果replicas过大，会严重影响master的吞吐能力，因为它在sync消息的过程中会消耗太多的时间。

  

 

    如果集群故障，在重启broker实例时，建议首先查看每个broker中查看LevelDB日志文件的版本戳(文件名为16进制数字)，并优先启动版本戳较大的实例。(因为replicas多数派的约束，随机重启也不会有太大的问题)。但是不得随意调小replicas的值，如果你确实需要修改，那就首先关闭集群，一定优先启动版本戳最大的broker。

 

    尽管集群对zookeeper的操作并不是很多，但是我们还是希望不要接入负载过高的zookeeper集群，以免给消息服务引入不稳定因素。通常zookeeper集群至少需要3个实例，才能保证zookeeper本身的高可用性。

 

    其中bind属性表示当此broker实例成为master时，开启一个socket地址，此后slave可以通过此地址与其同步数据。

 

    我们还需要为Replicated LevelDB配置zookeeper的地址和path，其中path下用来存储group中所有broker的注册信息，此值在group中所有的broker上都要一样。“hostname”用来描述当前机器的核心信息，通常为机器IP。如果你在本机构建伪分布式，那么需要在系统hosts文件中使用转义。

 

127.0.0.1   broker0  
127.0.0.1   broker1  
127.0.0.1   broker2  

    对于Client端而言，仍然需要使用failover协议，而且协议中需要包含group中所有broker的链接地址。

 

failover://(tcp://localhost:61616,tcp://localhost:51616,tcp://localhost:41616)?randomize=false  

    和其他模式一样，对于非持久化消息仍然只会保存在master上，当master失效后，消息将会丢失。

 

1）这种方式使用Zookeeper选举Master。要进行选举，则需要多数派的“参与者”。因为Replicated LevelDB Store中有多个Broker，从多个Broker中选举出一个成为Master，其他的则成为Slave。只有Master接收Client的连接，Slave负责连接到Master，并接收（同步方式、异步方式）Master上的数据。

The elected master broker node starts and accepts client connections. 
The other nodes go into slave mode and connect the the master and synchronize their persistent state /w it.

以上也表明：每个Broker都是单独存储数据的。因为Master要把新的数据复制到Slave上。从这个角度看：称这种方式为“Share Storage”有点不合适。

 

2）Quorum机制的又一应用

假设有3个Broker，那么选举时至少需要两个Broker同意（大多数）之后，才能选出Master。此外，只需要当新消息复制到大多数Broker上时，就可以给Producer返回ACK。其他少数Broker则可以在后台以异步方式复制新的消息。

All messaging operations which require a sync to disk will wait for the update to be replicated to a quorum of the nodes before completing. 
So if you configure the store with replicas="3" then the quorum size is (3/2+1)=2. 
The master will store the update locally and wait for 1 other slave to store the update before reporting success.

比如说：一共有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。】