一种基于Netty框架应用Raft算法实现MQTT Broker服务器的方法

技术领域

本发明属于物联网技术领域，尤其涉及一种基于Netty框架应用Raft算法实现MQTT Broker服务器的方法。

背景技术

消息队列遥测传输是ISO标准(ISO/IEC PRF 20922)下基于发布(Publish)/订阅(Subscribe)范式的消息协议，可视为“资料传递的桥梁”它工作在TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个消息中间件，以解决当前繁重的资料传输协议。

MQTT协议定义了两种网络实体：消息代理(message broker)与客户端(client)。其中，消息代理用于接收来自客户端的消息并转发至目标客户端。MQTT客户端可以是任何运行有MQTT库并通过网络连接至消息代理的设备，例如微型控制器或大型服务器。

信息的传输是通过主题(topic)管理的。发布者有需要分发的数据时，其向连接的消息代理发送携带有数据的控制消息。代理会向订阅此主题的客户端分发此数据。发布者不需要知道订阅者的数据和具体位置；同样，订阅者不需要配置发布者的相关信息。如果消息代理接受到某个主题上的消息，且这个主题没有任何订阅，那么代理就会丢弃之，除非发布者将其标记为保留消息。

而现有MQTT代理：

1).Mosquitto

mosquitto是Eclipse开源社区推出的，一款实现了消息推送协议MQTT v3.1的开源消息代理软件，提供了轻量级、发布/订阅的的消息推送模式，方便设备之间的短消息通信，使用C语言开发，适用于轻量级的MQTT接入应用情景；

2).EMQX

EMQX是杭州映云科技有限公司推出的分布式物联网MQTT服务器，提供开源版和商业版，使用Erlang语言开发，支持海量物联网设备链接。

但是，现有技术存在以下缺点：

1).Mosquitto

(1).不支持安全认证；

(2).不支持集群模式；

(3).不支持数据持久化；

(4).无业务管理接口开放；

2).EMQX

(1).开源版本功能有限，需通过前置负载实现伪集群模式；

(2).商业版本功能齐全，按流量或设备接入数计费，需授权后才能私有化部署；

(3).仅商业版支持数据持久化，开源版宕机则数据丢失；

(4).使用Erlang开发，扩展方式较多，扩展实现门槛高。

因此，有必要提供一种新的基于Netty框架应用Raft算法实现MQTT Broker服务器的方法解决上述技术问题。

发明内容

本发明解决的技术问题是提供一种可以避免商业授权的负面影响，不断迭代升级，可以为Broker运行和决策提供数据支撑，可以保证集群内数据的强制一致性，即使节点故障，节点恢复后仍然能正常提供数据，同时还可以解决现有技术的缺点的基于Netty框架应用Raft算法实现MQTT Broker服务器的方法。

为解决上述技术问题，本发明提供的基于Netty框架应用Raft算法实现MQTTBroker服务器的方法包括以下步骤：S1.Netty

所述Netty是一款异步的事件驱动的网络应用程序框架，支持快速地开发可维护的高性能的面向协议的服务器和客户端；

S2.Reactor模型

所述Netty架构是按照Reactor模式设计和实现的，所述Netty的Reactor并发模型：

Netty实现并扩展了Reactor模型，具体如下：

1).Acceptor主线程池是一个独立的NIO线程池，它用NIO的形式扮演网络链路中的Acceptor角色，又名AcceptorReactor；

2).程序启动后，会在Acceptor主线程池中随机选择一个线程作为Acceptor线程，用于绑定端口，接收客户端连接；

3).Acceptor线程接收到连接请求，会将请求交给AcceptorReactor的其他线程，以处理客户端的登录、握手和安全认证；

4).在业务层链路正式建立后，会将请求转到IO子线程池的某个线程，由其处理IO读写、编码操作；

5).最后根据请求类型的不同，将请求转到特定类型WorkThreadsPools，做具体的业务处理在Netty并发模型中，客户端的并发接入、底层Socket的读写、以及业务请求的处理，都是多线程化的异步操作，因此，Netty赋予了应用程序一项核心能力，可以以任意的顺序响应任意时间点产生的网络事件，可以在确定的资源里，不断复用计算机的线程资源，适应更高的吞吐量和可扩展性要求；

S3.Raft

所述Raft集群由若干节点组成，每个节点有三个状态：Leader、Follower和Candidate，Raft会先选举Leader，并且只会有一个节点是Leader，其他节点都是Follower，Leader节点处理所有客户端请求，复制Replicated Log到Follower节点，如果Leader故障，选举倒计时过期后，Leader心跳检测依然异常，Follower会重新选举出新的Leader；

S4.基于Netty和Raft实现MQTT Broker：

所述MQTT Broker是直接接受并发客户端网络连接的服务器，使用Netty处理网络通信部分，可以最大限度地利用服务器资源处理更多的客户端连接、处理更多的业务，Netty自带MQTT的编解码模块，可以直接使用以完成MQTT协议通信的编解码；

S5.Broker服务通过Raft集群保持数据一致性：

MQTT Broker服务通过实现Raft算法，赋予MQTT Broker之间数据复制特性，基于强一致性的数据同步组成集群，从而降低系统单点故障的风险；

S6.通过Raft算法赋予系统以下特性：

1).持久会话：当会话标识“Clean Session”置为0时，表示创建一个持久会话，在客户端断开连接时，会话仍然保持并保存离线消息，直到会话超时注销，持久会话信息、离线MQTT信息保存本地后，通过Raft算法复制到集群其他Broker,客户端重新上线后，即可及时获得全部离线信息，减少等待；

2).订阅数据：客户端订阅成功后，将订阅关系数据复制到其他Broker，需要广播、下发指令、或客户端更换了Broker接入，即可及时获得客户端当前全部的订阅主题数据，取消订阅时则本地删除后集群内删除；

3).消息服务质量保证(QoS)的消息重传：MQTT协议规定作为通信双方服务端和客户端对于自己发送到对端的消息都应该满足其服务质量的要求，即，MQTT报文发送后，对端在规定时间内未收到应答，则客户端会重发该报文，同时，若在保持会话的情况下，客户端发成重连，Broker会自动为重连的客户端重发应答的消息，以确保QoS流程的正确，针对上述场景，将客户端发送而未确认消息保存本地，再复制同步到其他Broker，无论是重试消息、或是发布者重连，仍然可以在其他Broker中找到该消息报文，并按QoS的语义要求，对相应消息报文做出维护。

作为本发明的进一步方案，所述MQTT Broker服务包括如下：

(1).Broker服务由网络服务层、MQTT协议服务层、业务服务层、存储模块和桥接模块组成，将网络通信和业务处理分离，存储模块由Raft节点和本地存储组成，存储模块定义有若干存储器；

(2).网络服务层处理客户端连接，并转发客户端上报数据到协议层解码，同时，将协议层已编码的业务数据下发到对应客户端；

(3).协议层应用Netty已实现的MQTT协议编解码模块，处理客户端和Broker之间通信所需的MQTT协议报文，定义对应报文的处理流程，实现协议业务的触发处理，如登录、鉴权等和消息分发；

(4).业务服务由消息下发模块和数据分发模块组成；

(5).Raft服务实现网络通信，为Raft集群提供节点间的通信功能，支持Raft集群的运作：选举、日志复制、安全检查和心跳探活；

(6).Raft节点由实现Raft协议的存储器与Raft通信服务组成，业务链路内的过程数据和结果数据，按需可以将数据变更提交到Raft Leader，将作为Raft Log存入本地特定存储引擎，利用Raft算法的日志复制和强一致性检查，完成集群内节点之间的数据复制；

(7).本地存储用于存储包括但不限于以下数据：客户端会话记录、未确认的消息(QoS1、QoS2)、指标度量数值和程序运行所需的配置数据；

(8).无状态的桥接服务向外暴露REST API，通过低侵入性的方式提供包括但不限于以下业务功能管理操作：获取Broker状态信息、进行消息发布和查看客户端列表。

作为本发明的进一步方案，所述消息下发负责捕获用户操作，抽象成MQTT消息体后，转入协议层处理，所述数据分发负责捕获协议层已解码的消息体，所述数据分发负责处理包括但不限于：消息持久化、设备间通信、消息重放、共享订阅等，通过对接持久化中间件和特定服务接口完成上报数据的分发。

作为本发明的进一步方案，所述数据复制流程具体如下：

(1).Leader负责接收客户端的请求，Leader把请求作为Raft日志条目存入本地储存，存入成功后，并行向其他服务器发起复制动作，以便复制日志条目；

(2).当日志从Leader被复制到大多数Follower，Leader将这条日志条目公开到它的状态机并向客户端返回执行结果，即全局提交复制结果；

(3).数据块(Block)是Raft集群数据管理和移动的最小单元，对应本地存储中实际的一块数据区间，每个Block包含多条数据，Block存在多个副本，每个副本位于不同的Node，不同节点上的多个Block构成一个抽象的Raft集群，互为副本；

(4).基于Raft算法的日志一致性检查，某些Followers可能没有成功完成日志复制，Leader便会无限重试复制直到所有的Followers最终存储了所有的日志条目。

作为本发明的进一步方案，所述MQTT运行时为单独实例，对外暴露TCP端点，依据Raft特性，需运行至少3个实例才能组成Raft集群，具体如下：

(1).Netty服务仅可获取实现MQTT协议的客户端的接入，只处理满足MQTT协议规范的请求，Broker服务启动时暴露固定的{ip:port}，并暴露Raft节点的通信端点{ip:port}；

(2).客户端依据预定义配置，使用用户名、密码请求接入Broker服务，获准后两端建立通信长链接，在报文“CONNECT”监听处理中，网络服务会将该链接，以ClientID为key，存入客户端会话列表和客户端链接列表，并更新路由表；

(3).Raft节点在Broker启动时，以配置中的节点列表启动，并初创集群，初创时所有节点均为Follower，则发起新的Leader选举；

(4).Netty服务开始处理与客户端的MQTT通信消息，消息类型包括但不限于：订阅主题、发送消息和心跳探活，客户端订阅主题、发送消息受管理人员的授权限制，需要在管理后台编辑维护；

(5).若客户端允许订阅主题，在建立长链接后，即可发起“SUBSCRIBE”报文，Broker服务在返回“SUBACK”报文前，通过解码，将该客户端与多个主题的关系以{ClientID,Subscription}存入本地存储，同时，使用Raft算法复制到其他节点；

(6).若客户端允许发送消息，在建立长链接后，即可发起“PUBLISH”报文，Broker收到后在报文处理器中，按消息类型处理信息，若是一般信息，则直接转发；若是保留信息，则存入保留信息的本地存储，等待重发到客户端，若是QoS 1、QoS 2消息，则依次按MQTT规范要求发起多个报文互传流程，期间将未确认消息，存入对应本地存储，待收到“PUBCOMP”报文后，删除未确认消息；

(7).无论是客户端、或是通过桥接服务发布的消息，都必须经过Broker服务的协议层报文处理器的解码，经过处理器解码后的消息转入消息分发模块，依据消息MessageType、MessageHeader、QoS等数据特征(如图.4)，决定消息的去向，已知主题，则可通过主题订阅，反向确定客户端范围后便可开始转发消息，根据消息的MessageType、MessageHeader、QoS等数据特征，采用不同的编码器对消息编码，并启用不同的消息发送流程处理，如需延迟发送，则将消息存入延迟存储器；如需达成QoS 2语义，则将消息存入待确认消息存储器，并在后续的QoS2流程节点中配合数据处理，如需持久化消息，则通过桥接服务依照当前的持久策略，存入相应的存储引擎；

(8).管理人员可通过web平台的操作直接发送请求，web平台对接桥接服务，外部应用通过适配桥接服务，完成对Broker服务的通信，如，调整设置、获取Broker状态信息、进行消息发布、代理订阅与取消订阅、断开指定客户端和查看客户端列表。

作为本发明的进一步方案，所述Raft算法是将一致性问题分解成了三个子问题，分别为选举、日志复制和安全性，具体如下：

(1).选举：当Leader宕机或者集群初创时，Followers会选举新的Leader；

(2).日志复制：Leader统一处理所有客户端的请求，当接收到来自客户端的数据后，Leader会将数据以日志条目的形式复制到集群中的其它节点，并且强制要求其它节点的日志和自己保持一致；

(3).安全性：每个节点都有明确的日志存储在状态机中，节点的日志索引位置不能跟Leader的日志索引不一致，Leader会强制节点的索引位置跟自己保持一致。

作为本发明的进一步方案，所述Raft算法为增强集群可用性、保证数据强一致性，增加了两个限制：分别为选举限制和日志一致性检查，具体如下：

(1).选举限制：Candidate状态节点在发起选举后会访问大部分节点，将自己的日志和每一个节点的日志做对比，通过比较两份日志中，最后一条日志的索引值和任期号，来确定哪个节点的日志比较新，如果两份日志最后的条目的任期号不同，那么任期号大的日志更加新，如果两份日志最后的条目任期号相同，那么日志比较长的那个就更加新，只有日志索引值最大、任期号最新的节点才能赢得选举；

(2).日志一致性检查：正常情况下，Leader和Follower的日志会保持一致，生产运行环境下，Leader和Follower都会发生各种异常情况，导致各节点的日志不一致，Raft算法约定，Leader必须保存每一个Follower的nextIndex，刚当选的Leader会初始化nextIndex为当前Leader的日志索引值+1，如果一个Follower的日志和Leader不一致，Leader在下一个心跳同步日志时，一致性检查就会失败，当nextIndex与目标Follower的currentIndex不匹配时，Leader减少nextIndex的值，并重试，nextIndex与Follower的currentIndex最终会在某一个位置一致，由于选举限制，Leader保存着集群最新最全的Log数据，Leader在确定nextIndex之后，会将nextIndex之后数据同步到Follower。

与相关技术相比较，本发明提供的基于Netty框架应用Raft算法实现MQTT Broker服务器的方法具有如下有益效果：

1、本发明通过使用Java工业级计算机语言设计实现，通用高，二次开发门槛降低；

2、本发明可以避免商业授权的负面影响，不断迭代升级；

3、本发明通过使用Netty实现网络接入，单机4CoreCPU、16GRAM可以支持50万链接；

4、本发明通过接入MQTT Broker的角色，除了经典的客户端形式，还可以是应用服务形式，不再强制作为Client接入；

5、本发明系统通过桥接服务与外部服务关联，通过对接现有配置系统、或自定义配置系统，可以为Broker运行和决策提供数据支撑；

6、本发明通过使用Raft算法实现轻量级的Broker集群，可以保证集群内数据的强制一致性，即使节点故障，节点恢复后仍然能正常提供数据；

7、本发明通过不断升级扩展桥接服务、协议层、Raft节点，理论上可以满足分布式集群运行所需的特性。

附图说明

为了便于本领域技术人员理解，下面结合附图对本发明作进一步的说明。

图1为本发明中Netty并发模型的示意图；

图2为本发明中Raft节点状态转换的示意图；

图3为本发明中MQTT Broker服务整体架构的示意图；

图4为本发明中消息体结构的示意图；

图5为本发明中Raft集群结构的示意图。

具体实施方式

请结合参阅图1、图2、图3、图4和图5，其中，图1为本发明中Netty并发模型的示意图；图2为本发明中Raft节点状态转换的示意图；图3为本发明中MQTT Broker服务整体架构的示意图；图4为本发明中消息体结构的示意图；图5为本发明中Raft集群结构的示意图。基于Netty框架应用Raft算法实现MQTT Broker服务器的方法包括以下步骤：S1.Netty

所述Netty是一款异步的事件驱动的网络应用程序框架，支持快速地开发可维护的高性能的面向协议的服务器和客户端；

S2.Reactor模型

所述Netty架构是按照Reactor模式设计和实现的，所述Netty的Reactor并发模型：

如图1所示，Netty实现并扩展了Reactor模型，具体如下：

1).Acceptor主线程池是一个独立的NIO线程池，它用NIO的形式扮演网络链路中的Acceptor角色，又名AcceptorReactor；

2).程序启动后，会在Acceptor主线程池中随机选择一个线程作为Acceptor线程，用于绑定端口，接收客户端连接；

3).Acceptor线程接收到连接请求，会将请求交给AcceptorReactor的其他线程，以处理客户端的登录、握手和安全认证；

4).在业务层链路正式建立后，会将请求转到IO子线程池的某个线程，由其处理IO读写、编码操作；

5).最后根据请求类型的不同，将请求转到特定类型WorkThreadsPools，做具体的业务处理在Netty并发模型中，客户端的并发接入、底层Socket的读写、以及业务请求的处理，都是多线程化的异步操作，因此，Netty赋予了应用程序一项核心能力，可以以任意的顺序响应任意时间点产生的网络事件，可以在确定的资源里，不断复用计算机的线程资源，适应更高的吞吐量和可扩展性要求；

S3.Raft

所述Raft集群由若干节点组成，每个节点有三个状态：Leader、Follower和Candidate(如图2所示)，Raft会先选举Leader，并且只会有一个节点是Leader，其他节点都是Follower，Leader节点处理所有客户端请求，复制Replicated Log到Follower节点，如果Leader故障，选举倒计时过期后，Leader心跳检测依然异常，Follower会重新选举出新的Leader；

S4.基于Netty和Raft实现MQTT Broker：

如图3所示，所述MQTT Broker是直接接受并发客户端网络连接的服务器，使用Netty处理网络通信部分，可以最大限度地利用服务器资源处理更多的客户端连接、处理更多的业务，Netty自带MQTT的编解码模块，可以直接使用以完成MQTT协议通信的编解码；

S5.Broker服务通过Raft集群保持数据一致性：

如图5所示，MQTT Broker服务通过实现Raft算法，赋予MQTT Broker之间数据复制特性，基于强一致性的数据同步组成集群，从而降低系统单点故障的风险；

S6.通过Raft算法赋予系统以下特性：

1).持久会话：当会话标识“Clean Session”置为0时，表示创建一个持久会话，在客户端断开连接时，会话仍然保持并保存离线消息，直到会话超时注销，持久会话信息、离线MQTT信息保存本地后，通过Raft算法复制到集群其他Broker,客户端重新上线后，即可及时获得全部离线信息，减少等待；

2).订阅数据：客户端订阅成功后，将订阅关系数据复制到其他Broker，需要广播、下发指令、或客户端更换了Broker接入，即可及时获得客户端当前全部的订阅主题数据，取消订阅时则本地删除后集群内删除；

3).消息服务质量保证(QoS)的消息重传：MQTT协议规定作为通信双方服务端和客户端对于自己发送到对端的消息都应该满足其服务质量的要求，即，MQTT报文发送后，对端在规定时间内未收到应答，则客户端会重发该报文，同时，若在保持会话的情况下，客户端发成重连，Broker会自动为重连的客户端重发应答的消息，以确保QoS流程的正确，针对上述场景，将客户端发送而未确认消息保存本地，再复制同步到其他Broker，无论是重试消息、或是发布者重连，仍然可以在其他Broker中找到该消息报文，并按QoS的语义要求，对相应消息报文做出维护。

所述MQTT Broker服务包括如下：

(1).Broker服务由网络服务层、MQTT协议服务层、业务服务层、存储模块和桥接模块组成，将网络通信和业务处理分离，存储模块由Raft节点和本地存储组成，存储模块定义有若干存储器；

(2).网络服务层处理客户端连接，并转发客户端上报数据到协议层解码，同时，将协议层已编码的业务数据下发到对应客户端；

(3).协议层应用Netty已实现的MQTT协议编解码模块，处理客户端和Broker之间通信所需的MQTT协议报文，定义对应报文的处理流程，实现协议业务的触发处理，如登录、鉴权等和消息分发；

(4).业务服务由消息下发模块和数据分发模块组成；

(5).Raft服务实现网络通信，为Raft集群提供节点间的通信功能，支持Raft集群的运作：选举、日志复制、安全检查和心跳探活；

(6).Raft节点由实现Raft协议的存储器与Raft通信服务组成，业务链路内的过程数据和结果数据，按需可以将数据变更提交到Raft Leader，将作为Raft Log存入本地特定存储引擎，利用Raft算法的日志复制和强一致性检查，完成集群内节点之间的数据复制；

(7).本地存储用于存储包括但不限于以下数据：客户端会话记录、未确认的消息(QoS1、QoS2)、指标度量数值和程序运行所需的配置数据；

(8).无状态的桥接服务向外暴露REST API，通过低侵入性的方式提供包括但不限于以下业务功能管理操作：获取Broker状态信息、进行消息发布和查看客户端列表。

所述消息下发负责捕获用户操作，抽象成MQTT消息体后，转入协议层处理，所述数据分发负责捕获协议层已解码的消息体，所述数据分发负责处理包括但不限于：消息持久化、设备间通信、消息重放、共享订阅等，通过对接持久化中间件和特定服务接口完成上报数据的分发。

所述数据复制流程具体如下：

(1).Leader负责接收客户端的请求，Leader把请求作为Raft日志条目存入本地储存，存入成功后，并行向其他服务器发起复制动作，以便复制日志条目；

(2).当日志从Leader被复制到大多数Follower，Leader将这条日志条目公开到它的状态机并向客户端返回执行结果，即全局提交复制结果；

(3).数据块(Block)是Raft集群数据管理和移动的最小单元，对应本地存储中实际的一块数据区间，每个Block包含多条数据，Block存在多个副本，每个副本位于不同的Node，不同节点上的多个Block构成一个抽象的Raft集群，互为副本；

(4).基于Raft算法的日志一致性检查，某些Followers可能没有成功完成日志复制，Leader便会无限重试复制直到所有的Followers最终存储了所有的日志条目。

如图3所示，所述MQTT运行时为单独实例，对外暴露TCP端点，依据Raft特性，需运行至少3个实例才能组成Raft集群，具体如下：

(1).Netty服务仅可获取实现MQTT协议的客户端的接入，只处理满足MQTT协议规范的请求，Broker服务启动时暴露固定的{ip:port}，并暴露Raft节点的通信端点{ip:port}；

(2).客户端依据预定义配置，使用用户名、密码请求接入Broker服务，获准后两端建立通信长链接，在报文“CONNECT”监听处理中，网络服务会将该链接，以ClientID为key，存入客户端会话列表和客户端链接列表，并更新路由表；

(3).Raft节点在Broker启动时，以配置中的节点列表启动，并初创集群，初创时所有节点均为Follower，则发起新的Leader选举；

(4).Netty服务开始处理与客户端的MQTT通信消息，消息类型包括但不限于：订阅主题、发送消息和心跳探活，客户端订阅主题、发送消息受管理人员的授权限制，需要在管理后台编辑维护；

(5).若客户端允许订阅主题，在建立长链接后，即可发起“SUBSCRIBE”报文，Broker服务在返回“SUBACK”报文前，通过解码，将该客户端与多个主题的关系以{ClientID,Subscription}存入本地存储，同时，使用Raft算法复制到其他节点；

(6).若客户端允许发送消息，在建立长链接后，即可发起“PUBLISH”报文，Broker收到后在报文处理器中，按消息类型处理信息，若是一般信息，则直接转发；若是保留信息，则存入保留信息的本地存储，等待重发到客户端，若是QoS 1、QoS 2消息，则依次按MQTT规范要求发起多个报文互传流程，期间将未确认消息，存入对应本地存储，待收到“PUBCOMP”报文后，删除未确认消息；

(7).无论是客户端、或是通过桥接服务发布的消息，都必须经过Broker服务的协议层报文处理器的解码，经过处理器解码后的消息转入消息分发模块，依据消息MessageType、MessageHeader、QoS等数据特征(如图.4)，决定消息的去向，已知主题，则可通过主题订阅，反向确定客户端范围后便可开始转发消息，根据消息的MessageType、MessageHeader、QoS等数据特征，采用不同的编码器对消息编码，并启用不同的消息发送流程处理，如需延迟发送，则将消息存入延迟存储器；如需达成QoS 2语义，则将消息存入待确认消息存储器，并在后续的QoS2流程节点中配合数据处理，如需持久化消息，则通过桥接服务依照当前的持久策略，存入相应的存储引擎；

(8).管理人员可通过web平台的操作直接发送请求，web平台对接桥接服务，外部应用通过适配桥接服务，完成对Broker服务的通信，如，调整设置、获取Broker状态信息、进行消息发布、代理订阅与取消订阅、断开指定客户端和查看客户端列表。

所述Raft算法是将一致性问题分解成了三个子问题，分别为选举、日志复制和安全性，具体如下：

(1).选举：当Leader宕机或者集群初创时，Followers会选举新的Leader；

(2).日志复制：Leader统一处理所有客户端的请求，当接收到来自客户端的数据后，Leader会将数据以日志条目的形式复制到集群中的其它节点，并且强制要求其它节点的日志和自己保持一致；

(3).安全性：每个节点都有明确的日志存储在状态机中，节点的日志索引位置不能跟Leader的日志索引不一致，Leader会强制节点的索引位置跟自己保持一致。

所述Raft算法为增强集群可用性、保证数据强一致性，增加了两个限制：分别为选举限制和日志一致性检查，具体如下：

(1).选举限制：Candidate状态节点在发起选举后会访问大部分节点，将自己的日志和每一个节点的日志做对比，通过比较两份日志中，最后一条日志的索引值和任期号，来确定哪个节点的日志比较新，如果两份日志最后的条目的任期号不同，那么任期号大的日志更加新，如果两份日志最后的条目任期号相同，那么日志比较长的那个就更加新，只有日志索引值最大、任期号最新的节点才能赢得选举；

(2).日志一致性检查：正常情况下，Leader和Follower的日志会保持一致，生产运行环境下，Leader和Follower都会发生各种异常情况，导致各节点的日志不一致，Raft算法约定，Leader必须保存每一个Follower的nextIndex，刚当选的Leader会初始化nextIndex为当前Leader的日志索引值+1，如果一个Follower的日志和Leader不一致，Leader在下一个心跳同步日志时，一致性检查就会失败，当nextIndex与目标Follower的currentIndex不匹配时，Leader减少nextIndex的值，并重试，nextIndex与Follower的currentIndex最终会在某一个位置一致，由于选举限制，Leader保存着集群最新最全的Log数据，Leader在确定nextIndex之后，会将nextIndex之后数据同步到Follower。

本发明相对现有技术而言，所具有的优点和效果具体如下：

(1).使用Java工业级计算机语言设计实现，通用高，二次开发门槛降低；

(2).可以避免商业授权的负面影响，不断迭代升级；

(3).使用Netty实现网络接入，单机4CoreCPU、16GRAM可以支持50万链接；

(4).接入MQTT Broker的角色，除了经典的客户端形式，还可以是应用服务形式，不再强制作为Client接入；

(5).系统通过桥接服务与外部服务关联，通过对接现有配置系统、或自定义配置系统，可以为Broker运行和决策提供数据支撑；

(6).使用Raft算法实现轻量级的Broker集群，可以保证集群内数据的强制一致性，即使节点故障，节点恢复后仍然能正常提供数据；

(7).通过不断升级扩展桥接服务、协议层、Raft节点，理论上可以满足分布式集群运行所需的特性。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,根据本发明的技术方案及其发明构思加以等同替换或改变,都应涵盖在本发明的保护范围之内。