11OSSEC HIDS
OSSEC HIDS是一种基于主机的入侵检测系统(HIDS)，用于安全检测、可见性和遵从性监控。它基于一个多平台代理，将系统数据(如：日志消息、文件散列和检测到的异常)转发给一个中央管理器，并在其中对其进行进一步分析和处理，从而产生安全警报。代理将事件数据通过安全且经过身份验证的通道传递给中央管理器，以便进行分析。
此外，OSSEC HIDS提供了一个集中的syslog服务器和一个无代理的配置监视系统，该系统提供了对防火墙、交换机、路由器、接入点、网络设备等无代理设备上的事件和更改的安全洞察。
12OpenSCAP
OpenSCAP是一种OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)解释器，用于检查系统配置和检测脆弱应用程序。
这是一种众所周知的工具，用于检查安全合规性和使用工业标准安全基线对企业环境的加固。
13Elastic Stack
Elastic Stack是一个软件套件(Filebeat、Logstash、Elasticsearch、Kibana)，用于收集、解析、索引、存储、搜索和显示日志数据。它提供了一个web前端，该前端提供事件的高级仪表板视图，支持深入到事件数据存储的高级分析和数据挖掘。
二、组件
Wazuh的主要组件是运行在每个受监控主机上的代理，以及分析从代理和syslog等无代理源接收到的数据的服务器。此外，服务器将事件数据转发到一个Elasticsearch集群，在这里对信息进行索引和存储。
21Wazuh agent
Wazuh代理运行在Windows、Linux、Solaris、BSD和Mac *** 作系统上。它用于收集不同类型的系统和应用程序数据，这些数据通过加密和经过身份验证的通道转发给Wazuh服务器。为了建立这个安全通道，使用了一个包含唯一预共享密钥的注册过程。
代理可以用来监视物理服务器、虚拟机和云实例(例如Amazon AWS、Azure或谷歌云)。预编译的代理安装包可用于Linux、HP-UX、AIX、Solaris、Windows和Darwin (Mac OS X)。
在基于Unix的 *** 作系统上，代理运行多个进程，这些进程通过本地Unix域套接字相互通信。其中一个进程负责向Wazuh服务器发送通信和数据。在Windows系统上，只有一个代理进程使用互斥对象运行多个任务。
不同的代理任务或过程以不同的方式监视系统(例如，监视文件完整性、读取系统日志消息和扫描系统配置)。
下图表示在代理级别上发生的内部任务和流程:
所有代理进程都有不同的目的和设置。以下是他们的简要说明:
Rootcheck:这个过程执行多个与检测rootkit、恶意软件和系统异常相关的任务。它还对系统配置文件运行某些基本的安全检查。
日志收集器 Log Collector :此代理组件用于读取 *** 作系统和应用程序日志消息，包括平面日志文件、标准Windows事件日志甚至Windows事件通道。还可以将其配置为定期运行并捕获特定命令的输出。
Syscheck:这个过程执行文件完整性监视(FIM)，也可以监视Windows系统上的注册表项。它能够检测文件的内容、所有权和其他属性的变化，以及记录文件的创建和删除。虽然它在默认情况下执行定期的FIM扫描，但它也可以配置为与 *** 作系统内核通信，以便实时检测文件更改并生成文本文件的详细更改报告(diffs)。
OpenSCAP:该模块使用已发布的OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)基线安全概要。通过定期扫描系统，它可以找到不符合众所周知的标准的脆弱的应用程序或配置，例如在CIS(互联网安全中心)基准测试中定义的那些。
代理守护进程 Agent Daemon :这个进程接收所有其他代理组件生成或收集的数据。它通过经过身份验证的通道将数据压缩、加密并交付给服务器。这个进程运行在一个独立的“chroot”(更改根)环境中，这意味着它对被监视系统的访问是有限的。这提高了代理的整体安全性，因为它是连接到网络的唯一进程。
22Wazuh server
服务器组件负责分析从代理接收的数据，并在事件匹配规则时触发警报(例如检测到入侵、文件更改、配置不符合策略、可能的rootkit等)。
服务器通常运行在独立的物理机器、虚拟机或云实例上，并运行代理组件，其目的是监视服务器本身。以下是主要服务器组件列表:
注册服务 Registration service :通过提供和分发每个代理特有的预共享身份验证密钥来注册新代理。此流程作为网络服务运行，支持通过TLS/SSL和/或通过固定密码进行身份验证。
远程守护进程服务 Remote daemon service :这是从代理接收数据的服务。它使用预共享密钥来验证每个代理的身份，并加密代理和管理器之间的通信。
分析守护进程 Analysis daemon :这是执行数据分析的进程。它利用解码器识别正在处理的信息类型(如Windows事件、SSHD日志、web服务器日志等)，然后从日志消息(如源ip、事件id、用户等)中提取相关数据元素。接下来，通过使用规则，它可以识别解码后的日志记录中的特定模式，这些模式可能触发警报，甚至可能调用自动对策(主动响应)，比如防火墙上的IP禁令。
RESTful API RESTful API :这提供了一个接口来管理和监视代理的配置和部署状态。它也被一个Kibana应用程序Wazuh web界面所使用。
23Elastic Stack
Elastic Stack是一个流行的用于日志管理的开源项目的统一套件，包括Elasticsearch、Logstash、Kibana、Filebeat等。与Wazuh解决方案特别相关的项目有:
Elasticsearch :一个高度可伸缩，全文搜索和分析引擎。d性搜索被分配，意味着数据(索引)被分成shard，并且每个shard可以具有零个或更多个副本。
Logstash:收集和解析要保存到存储系统中的日志的工具(例如，Elasticsearch)。收集到的事件还可以使用输入、过滤和输出插件进行丰富和转换。
Kibana:一个灵活和直观的web界面，用于挖掘、分析和可视化数据。它运行在一个Elasticsearch集群上索引的内容之上。
Filebeat:一种轻量级转发器，用于在网络中传送日志，通常用于Logstash或Elasticsearch。
Wazuh与Elastic Stack集成，提供已解码的日志消息提要，这些日志消息将由Elasticsearch索引，以及用于警报和日志数据分析的实时web控制台。此外，Wazuh用户界面(运行在Kibana之上)可用于管理和监视您的Wazuh基础设施。
Elasticsearch索引是具有某些相似特征(如某些公共字段和共享数据保留需求)的文档集合。Wazuh每天使用多达三种不同的索引来存储不同的事件类型:
Wazuh -alerts:每当事件触发规则时，Wazuh服务器生成警报的索引。
wazuh-events:从代理接收的所有事件(归档数据)的索引，无论它们是否触发规则。
wazuh-monitoring:索引与代理状态相关的数据。web接口使用它表示单个代理处于或已经处于“活动”、“断开”或“从未连接”的情况。
索引是由文档组成的。对于上面的索引，文档是单个警报、归档事件或状态事件。
将Elasticsearch索引分成一个或多个shard，并且每个shard可以选择性地具有一个或多个副本。每一主和副本shard是单个的Lucene索引。因此，一个Elasticsearch索引是由许多Lucene索引组成的。当搜索在Elasticsearch索引上运行时，将并行地对所有shard执行搜索，并合并结果。将Elasticsearch索引分成多个shard和复制品用于多节点的d性搜索集群，目的是缩小搜索和获得高可用性。单节点Elasticsearch集群通常每个索引只有一个shard，没有副本。
三、体系结构
Wazuh架构基于运行在受监视主机上的代理，这些主机将日志数据转发到中央服务器。此外，还支持无代理设备(如防火墙、交换机、路由器、接入点等)，并可以通过syslog和/或其配置更改的定期探针主动提交日志数据，以便稍后将数据转发到中央服务器。中央服务器对输入的信息进行解码和分析，并将结果传递给一个Elasticsearch集群进行索引和存储。
一个Elasticsearch集群是一个或多个节点(服务器)的集合，这些节点(服务器)相互通信，对索引执行读写 *** 作。小型Wazuh部署(<50个代理)可以由单节点集群轻松处理。当存在大量受监控系统、预期会有大量数据和/或需要高可用性时，建议使用多节点集群。
当Wazuh服务器和Elasticsearch集群在不同的主机上时，Filebeat可使用TLS加密将Wazuh警报和/或存档事件安全地转发到Elasticsearch服务器。
下图说明了Wazuh服务器和Elasticsearch集群在不同主机上运行时组件是如何分布的。注意，对于多节点集群，将有多个Elastic堆栈服务器，Filebeat可以将数据转发到这些服务器:
在较小的Wazuh部署中，使用单节点Elasticsearch实例的Wazuh和Elastic堆栈都可以部署在单个服务器上。在这个场景中，Logstash可以直接从本地文件系统读取Wazuh警报和/或归档事件，并将它们提供给本地Elasticsearch实例。
四、通信与数据流
41代理-服务器通信
Wazuh代理使用OSSEC消息协议通过端口1514 (UDP或TCP)将收集到的事件发送到Wazuh服务器。然后，Wazuh服务器解码并使用分析引擎对接收到的事件进行规则检查。触发规则的事件会被添加警告数据，如规则id和规则名称。根据规则是否触发，可以将事件存储到以下一个或两个文件:
文件/var/ossec/logs/archives/archivesjson包含所有事件，不管它们是否触发了规则。
文件/var/ossec/logs/alerts/alertsjson只包含触发规则的事件。
Wazuh消息协议使用的是192位Blowfish加密，完全实现了16轮，或者AES加密，每块128位，密钥256位。
42Wazuh-Elastic通信
在大型部署中，Wazuh服务器使用Filebeat使用TLS加密将警报和事件数据发送到d性堆栈服务器上的loghide (5000/TCP)。对于单主机架构，Logstash可以直接从本地文件系统读取事件/警报，而无需使用Filebeat。
Logstash对输入的数据进行格式化，并可选择在将数据发送到Elasticsearch(端口9200/TCP)之前丰富GeoIP信息。一旦数据被索引到Elasticsearch，就会使用Kibana(端口5601/TCP)来挖掘和可视化信息。
Wazuh APP运行在Kibana内部，不断查询RESTful API (Wazuh管理器上的端口55000/TCP)，以便显示服务器和代理的配置和状态相关信息，并在需要时重新启动代理。此通信使用TLS加密，并使用用户名和密码进行身份验证。
五、所需端口
对于安装Wazuh和Elastic堆栈，必须有几个网络端口可用并打开，以便不同组件之间能够正确通信。
六、档案数据存储
除了发送到Elasticsearch之外，警报和非警报事件都存储在Wazuh服务器上的文件中。这些文件可以是JSON格式( JSON)和/或纯文本格式(日志-没有解码字段，但更紧凑)。这些文件每天使用MD5和SHA1校验和进行压缩和签名。目录和文件名结构如下:
建议根据Wazuh Manager服务器的存储容量对归档文件进行轮换和备份。通过使用cron作业，您可以很容易地安排只在管理器上保留一个特定的存档文件时间窗口(例如，去年或过去三个月)。
另一方面，您可以选择完全不存储归档文件，而仅仅依赖于Elasticsearch来存储归档文件，特别是在运行定期的Elasticsearch快照备份和/或具有碎片副本的多节点Elasticsearch集群以获得高可用性时。您甚至可以使用cron作业将快照索引移动到最终的数据存储服务器，并使用MD5和SHA1算法对其进行签名。
Windows系统之间的文件共享用的是NetBIOS，但NetBIOS不是协议，是接口。
服务器信息块（SMB）协议是一种IBM协议，用于在计算机间共享文件、打印机、串口等。SMB 协议可以用在因特网的TCP/IP协议之上，也可以用在其它网络协议如IPX和NetBEUI 之上。
在一个网络环境中，服务器可以给客户端提供文件系统和文件资源的服务。客户端在访问服务器端的文件资源时，必须先想服务器端发送请求，并得到服务器的许可。
但是由于设计上的原因，Windows 系统无法正确处理畸形SMB请求，本地/远程攻击者可利用此缺陷进行拒绝服务攻击，甚至能够以系统权限在目标系统上执行任意指令。
扩展资料：
在网络环境下，通过FTP实现了在不同 *** 作系统的主机之间相互传输文件，从使用角度看，共享文件系统几乎不用你考虑网络传输和访问的细节，完全可以像访问本地文件一样访问网络上其它服务器文件系统上的文件。这可以在一定程度上解决开始提的问题，即为集群中的多台实际服务器共享同一台物理存储设备。
刚才提到的同一台物理存储设备可以是独立的一台服务器如服务器，也可以是集群中某台实际服务器的磁盘。
参考资料来源：百度百科-共享文件系统
最近在学习ZooKeeper，一直想写篇相关博文记录下学习内容，碍于自己是个拖延症重度患者总是停留在准备阶段，直到今天心血来潮突然想干点什么，于是便一不做二不休，通过对《从Paxos到Zookeeper 分布式一致性原理与实践》一书中ZAB相关内容的总结，以及对一些优秀博文的整理码出来这篇简文。本文首先对ZooKeeper进行一个简单的介绍，然后重点介绍ZooKeeper采用的ZAB（ZooKeeper Atomic Broadcast）一致性协议算法，加深自己对ZAB协议的理解的同时也希望与简友们一起分享讨论。ZooKeeper是一个具有高效且可靠的分布式协调服务， 由Yahoo创建的基于Google的Chubby开源实现，并于2010年11月正式成为Apache软件基金会的顶级项目。
ZooKeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
保证如下分布式一致性特性
顺序一致性
从同一个客户端发起的事务请求，最终将会严格地按照其发生顺序被应用到ZooKeeper中。
原子一致性
所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
单一视图
无论客户端连接的是哪个ZK服务器，其看到的服务端数据模型都是一致的。
可靠性
一旦服务端成功地应用了一个事务并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非另外一个事务又对其进行了变更。
实时性
通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。但这个需要注意的是， ZooKeeper仅仅保证在一定时间段内 ， 客户端最终一定能够从服务端上读取到最新的数据状态 。
Leader 一个ZooKeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写 *** 作必须要通过Leader完成再由Leader将写 *** 作广播给其它服务器。
Follower 一个ZooKeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
Observer 角色与Follower类似，但是无投票权。
ZooKeeper Atomic Broadcast (ZAB, ZooKeeper原子消息广播协议)是ZooKeeper实现分布式数据一致性的核心算法，ZAB借鉴Paxos算法，但又不像Paxos算法那样，是一种通用的分布式一致性算法， 它是一种特别为ZooKeeper专门设计的支持崩溃恢复的原子广播协议 。
ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事务请求处理方式，即：
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器称为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有的Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进提交。
ZAB协议整体可划分为两个基本的模式： 消息广播和崩溃恢复
按协议原理可细分为四个阶段： 选举（Leader Election）、发现（Discovery）、同步（Synchronization）和广播(Broadcast)
按协议实现分为三个时期： 选举（Fast Leader Election）、恢复(Recovery Phase)和广播(Broadcast Phase)
ZAB协议的消息广播过程使用的是一个原子广播协议，类似于一个二阶段提交过程。针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后在分别收集各自的选票，最后进行事务提交，此处与二阶段提交过程略有不同，ZAB协议的二阶段提交过程中， 移除了中断逻辑 ，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器。同时，ZAB协议将二阶段提交中的中断逻辑移除意味着 我们可以在过半的Follower服务器已经反馈Ack之后就开始提交事务Proposal了，而不需求等待集群中所有的Follower服务器都反馈响应 。
然而，在这种简化的二阶段提交模型下，无法处理Leader服务器崩溃退出而带来的数据不一致问题，因此ZAB协议添加了 崩溃恢复 模式来解决这个问题，另外，整个消息广播协议是基于有FIFO特性的TCP协议来进行网络通信的，因此很容易地保证消息广播过程中消息接收和发送的顺序性。
在整个消息广播过程中，Leader服务器会为每个事务请求生成对应的Proposal来进行广播，并且在广播事务Proposal之前，Leader服务器会首先为这个事务Proposal分配一个全局单调递增的唯一ID，我们称之为事务ID(即ZXID)。由于ZAB协议需要保证每一个消息严格的因果关系，因此必须将每一个事务Proposal按照其ZXID的先后顺序进行排序和处理。
具体的，在消息广播过程中，Leader服务器会为每个Follower服务器都各自分配一个单独的队列，然后将需要广播的事务Proposal依次放入这些队列中取，并且根据FIFO策略进行消息发送。每一个Follower服务器在接收到这个事务Proposal之后，都会首先将其以事务日志的形式写入本地磁盘中，并且成功写入后反馈给Leader服务器一个Ack相应。当Leader服务器接收到过半数Follower的Ack响应后，就会广播一个Commit消息给所有的Follower服务器以通知其进行事务提交，同时Leader自身也会完成对事务的提交，而每个Follower服务器在接收到Commit消息后，也会完成对事务的提交。
上面讲解的ZAB协议的这个基于原子广播协议的消息广播过程，在正常运行情况下运行非常良好，但是一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式。在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader服务器。因此，ZAB协议需要一个高效且可靠的Leader选举算法，从而确保能够快速选举出新的Leader。同时，Leader选举算法不仅仅需要让Leader自己知道其自身已经被选举为Leader，同时还需要让集群中的所有其他服务器也快速地感知到选举产生的新的Leader服务器。崩溃恢复主要包括Leader选举和数据恢复两部分，下面将详细讲解 Leader选举和数据恢复流程 。
现有的选举算法有一下四种： 基于UDP的LeaderElection 、 基于UDP的FastLeaderElection 、 基于UDP和认证的FastLeaderElection 和 基于TCP的FastLeaderElection ，在3410版本中弃用其他三种算法
myid —— zk服务器唯一ID
zxid —— 最新事务ID
高32位 是Leader的 epoch ，从1开始，每次选出新的Leader，epoch加一；
低32位 为该epoch 内的序号 ，每次epoch变化，都将低32位的序号重置；
保证了zkid的 全局递增性 。
logicClock 表示这是该服务器发起的第多少轮投票，从1开始计数
state 当前服务器的状态
self_id 当前服务器的 唯一ID
self_zxid 当前服务器上所保存的数据的 最大事务ID ，从0开始计数
vote_id 被推举的服务器的 唯一ID
vote_zxid 被推举的服务器上所保存的数据的 最大事务ID ，从0开始计数
LOOKING 不确定Leader状态。该状态下的服务器认为当前集群中没有Leader，会发起Leader选举。
FOLLOWING 跟随者状态。表明当前服务器角色是Follower，并且它知道Leader是谁。
LEADING 领导者状态。表明当前服务器角色是Leader。
OBSERVING 观察者状态， 不参与选举 ，也不参与集群写 *** 作时的投票。
能够确保提交已经被Leader提交的事务Proposal，同时丢弃已经被跳过的事务Proposal。针对这个要求，如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号(即ZXID最大)的事务Proposal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。更为重要的是，如果让具有最高编号事务Proposal的机器成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步 *** 作了。
ZooKeeper规定所有有效的投票都必须在同一轮次中。每个服务器在开始新一轮投票时，会先对自己维护的logicClock进行自增 *** 作。
每个服务器在广播自己的选票前，会将自己的投票箱清空。该投票箱记录了所收到的选票。例：服务器2投票给服务器3，服务器3投票给服务器1，则服务器1的投票箱为(2, 3), (3, 1), (1, 1)。 票箱中只会记录每一投票者的最后一票 ，如投票者更新自己的选票，则其它服务器收到该新选票后会在自己票箱中更新该服务器的选票。
每个服务器最开始都是通过广播把票投给自己。
服务器会尝试从其它服务器获取投票，并记入自己的投票箱内。如果无法获取任何外部投票，则会确认自己是否与集群中其它服务器保持着有效连接。如果是，则再次发送自己的投票；如果否，则马上与之建立连接。
根据选票logicClock -> vote_zxid -> vote_id依次判断
1 判断选举轮次
收到外部投票后，首先会根据投票信息中所包含的logicClock来进行不同处理：
外部投票的logicClock > 自己的logicClock: 说明该服务器的选举轮次落后于其它服务器的选举轮次，立即清空自己的投票箱并将自己的logicClock更新为收到的logicClock，然后再对比自己之前的投票与收到的投票以确定是否需要变更自己的投票，最终再次将自己的投票广播出去;
外部投票的logicClock < 自己的logicClock: 当前服务器直接忽略该投票，继续处理下一个投票;
外部投票的logickClock = 自己的: 当时进行选票PK。
2 选票PK
选票PK是基于(self_id, self_zxid)与(vote_id, vote_zxid)的对比：
若logicClock一致，则对比二者的vote_zxid，若外部投票的vote_zxid比较大，则将自己的票中的vote_zxid与vote_myid更新为收到的票中的vote_zxid与vote_myid并广播出去，另外将收到的票及自己更新后的票放入自己的票箱。如果票箱内已存在(self_myid, self_zxid)相同的选票，则直接覆盖
若二者vote_zxid一致，则比较二者的vote_myid，若外部投票的vote_myid比较大，则将自己的票中的vote_myid更新为收到的票中的vote_myid并广播出去，另外将收到的票及自己更新后的票放入自己的票箱
如果已经确定有过半服务器认可了自己的投票（可能是更新后的投票），则终止投票。否则继续接收其它服务器的投票。
投票终止后，服务器开始更新自身状态。若过半的票投给了自己，则将自己的服务器状态更新为LEADING，否则将自己的状态更新为FOLLOWING。
注： 图中箭头上的(1,1,0) 三个数一次代表该选票的服务器的 LogicClock 、被推荐的服务器的myid (即 vote_myid ) 以及被推荐的服务器的最大事务ID(即 vote_zxid )；
(1, 1) 2个数分别代表投票服务器myid(即 self_myid )和被推荐的服务器的myid (即 vote_myid )
选举流程如下:
自增选票轮次&初始化选票&发送初始化选票
首先，三台服务器自增选举轮次将LogicClock=1；然后初始化选票，清空票箱；最后发起初始化投票给自己将各自的票通过广播的形式投个自己并保存在自己的票箱里。
接受外部投票&更新选票
以Server 1 为例，分别经历 Server 1 PK Server 2 和 Server 1 PK Server 3 过程
Server 1 PK Server 2
Server 1 接收到Server 2的选票(1,2,0) 表示，投票轮次LogicClock为1，投给Server 2，并且Server 2的最大事务ID，ZXID 为0；
这时Server 1将自身的选票轮次和Server 2 的选票轮次比较，发现 LogicClock=1相等 ，接着Server 2比较比较最大事务ID，发现也 zxid=0也相等 ，最后比较各自的myid，发现Server 2的 myid=2 大于自己的myid=1 ；
根据选票PK规则，Server 1将自己的选票由 (1, 1) 更正为 (1, 2)，表示选举Server 2为Leader，然后将自己的新选票 (1, 2)广播给 Server 2 和 Server 3，同时更新票箱子中自己的选票并保存Server 2的选票，至此Server 1票箱中的选票为(1, 2) 和 (2, 2)；
Server 2收到Server 1的选票同样经过轮次比较和选票PK后确认自己的选票保持不变，并更新票箱中Server 1的选票由(1, 1)更新为(1, 2)，注意此次Server 2自己的选票并没有改变所有不用对外广播自己的选票。
Server 1 PK Server 3
更加Server 1 PK Server 2的流程类推，Server 1自己的选票由(1, 2)更新为(1, 3), 同样更新自己的票箱并广播给Server 2 和 Server 3；
Server 2再次接收到Server 1的选票(1, 3)时经过比较后根据规则也要将自己的选票从(1, 2)更新为(1, 3), 并更新票箱里自己的选票和Server 1的选票，同时向Server 1和 Server 3广播；
同理 Server 2 和 Server 3也会经历上述投票过程，依次类推，Server 1 、Server 2 和Server 3 在俩俩之间在经历多次 选举轮次比较 和 选票PK 后最终确定各自的选票。
选票确定后服务器根据自己票箱中的选票确定各自的角色和状态，票箱中超过半数的选票投给自己的则为Leader，更新自己的状态为LEADING，否则为Follower角色，状态为FOLLOWING，
成为Leader的服务器要主动向Follower发送心跳包，Follower做出ACK回应，以维持他们之间的长连接。
1《从Paxos到Zookeeper 分布式一致性原理与实践》 [倪超著]
2 《实例详解ZooKeeper ZAB协议、分布式锁与领导选举》
3《ZooKeeper’s atomic broadcast protocol:Theory and practice》[Andr ́e Medeiros]
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）