分布式架构和分布式系统存储研发的区别是什么？

《开源精选》是我们分享Github、Gitee等开源社区中优质项目的栏目，包括技术、学习、实用与各种有趣的内容。本期推荐的IPFS 是一个分布式系统，用于存储和访问文件、网站、应用程序和数据。

而且，当您使用 IPFS 时，您不只是从其他人那里下载文件——您的计算机也有助于分发它们。当您在几个街区外的朋友需要相同的 Wikipedia 页面时，他们可能会像从您的邻居或任何使用 IPFS 的人那里一样从您那里获得它。

IPFS 不仅可以用于网页，还可以用于计算机可能存储的任何类型的文件，无论是文档、电子邮件，甚至是数据库记录。

可以从不由一个组织管理的多个位置下载文件：

最后一点实际上是 IPFS 的全名： InterPlanetary File System 。我们正在努力建立一个系统，该系统可以在不连贯或相隔很远的地方工作，就像行星一样。虽然这是一个理想主义的目标，但它让我们努力工作和思考，几乎我们为实现这一目标而创造的一切在家里也很有用。

IPFS 是一个点对点 (p2p) 存储网络。可以通过位于世界任何地方的对等点访问内容，这些对等点可能会传递信息、存储信息或两者兼而有之。IPFS 知道如何使用其内容地址而不是其位置来查找您要求的内容。

理解 IPFS 的三个基本原则：

这三个原则相互依赖，以启用 IPFS 生态系统。让我们从 内容寻址 和内容的唯一标识开始。

互联网和您的计算机上都存在这个问题！现在，内容是按位置查找的，例如：

相比之下，每条使用 IPFS 协议的内容都有一个 内容标识符 ，即 CID，即其 哈希值 。散列对于它所来自的内容来说是唯一的，即使它与原始内容相比可能看起来很短。

有向无环图 (DAG)

IPFS 和许多其他分布式系统利用称为有向无环图的数据结构 （打开新窗口），或 DAG。具体来说，他们使用 Merkle DAG ，其中每个节点都有一个唯一标识符，该标识符是节点内容的哈希。
IPFS 使用针对表示目录和文件进行了优化的 Merkle DAG，但您可以通过多种不同的方式构建 Merkle DAG。例如，Git 使用 Merkle DAG，其中包含许多版本的存储库。

为了构建内容的 Merkle DAG 表示，IPFS 通常首先将其拆分为 块 。将其拆分为块意味着文件的不同部分可以来自不同的来源并可以快速进行身份验证。

分布式哈希表 (DHT)

要查找哪些对等方正在托管您所追求的内容（ 发现 ），IPFS 使用分布式哈希表或 DHT。哈希表是值键的数据库。 分布式 哈希表是一种表在分布式网络中的所有对等方之间拆分的表。要查找内容，您需要询问这些同行。

libp2p项目 （打开新窗口）是 IPFS 生态系统的一部分，它提供 DHT 并处理对等点之间的连接和交谈。

一旦你知道你的内容在哪里（或者更准确地说，哪些对等点正在存储构成你所追求的内容的每个块），你就可以再次使用 DHT 来查找这些对等点的当前位置（ 路由 ）。因此，要获取内容，请使用 libp2p 查询 DHT 两次。

然而，这确实意味着 IPFS 本身并没有明确保护 有关 CID 和提供或检索它们的节点的知识。这不是分布式网络所独有的。在 d-web 和 legacy web 上，流量和其他元数据都可以通过可以推断出很多关于网络及其用户的方式进行监控。下面概述了这方面的一些关键细节，但简而言之：虽然 节点之间 的 IPFS 流量是加密的，但这些节点发布到 DHT 的元数据是公开的。节点宣布对 DHT 功能至关重要的各种信息——包括它们的唯一节点标识符 (PeerID) 和它们提供的数据的 CID——因此，关于哪些节点正在检索和/或重新提供哪些 CID 的信息是公开的可用的。

加密

网络中有两种类型的加密： 传输加密 和 内容加密 。

在两方之间发送数据时使用传输加密。阿尔伯特加密文件并将其发送给莱卡，莱卡在收到文件后对其进行解密。这会阻止第三方在数据从一个地方移动到另一个地方时查看数据。

内容加密用于保护数据，直到有人需要访问它。Albert 为他的每月预算创建了一个电子表格，并用密码保存它。当 Albert 需要再次访问它时，他必须输入密码才能解密文件。没有密码，Laika 无法查看该文件。

IPFS 使用传输加密，但不使用内容加密。这意味着您的数据在从一个 IPFS 节点发送到另一个节点时是安全的。但是，如果拥有 CID，任何人都可以下载和查看该数据。缺乏内容加密是一个有意的决定。您可以自由选择最适合您的项目的方法，而不是强迫您使用特定的加密协议。

如果您精通命令行并且只想立即启动并运行 IPFS，请遵循此快速入门指南。请注意，本指南假定您将安装 go-ipfs，这是用 Go 编写的参考实现。

ipfs将其所有设置和内部数据存储在称为 存储库的目录中。 在第一次使用 IPFS 之前，您需要使用以下ipfs init命令初始化存储库：

如果您在数据中心的服务器上运行，则应使用server配置文件初始化 IPFS。这样做会阻止 IPFS 创建大量数据中心内部流量来尝试发现本地节点：

您可能需要设置大量其他配置选项 — 查看完整参考 （打开新窗口）更多。

后面的散列peer identity:是您节点的 ID，与上面输出中显示的不同。网络上的其他节点使用它来查找并连接到您。如果需要，您可以随时运行ipfs id以再次获取它。

现在，尝试运行在ipfs init 那个样子ipfs cat /ipfs/ /readme。

您应该看到如下内容：

您可以 探索 存储库中的其他对象。特别是quick-start显示示例命令尝试的目录：

准备好将节点加入公共网络后，在另一个终端中运行 ipfs 守护程序，并等待以下所有三行显示您的节点已准备好：

记下您收到的 TCP 端口。如果它们不同，请在下面的命令中使用您的。

现在，切换回原来的终端。如果您已连接到网络，您应该能够在运行时看到对等方的 IPFS 地址：

这些是 /p2p/

现在，您应该能够从网络中获取对象了。尝试：

使用上述命令，IPFS 在网络中搜索 CIDQmSgv并将数据写入spaceship-launchjpg桌面上调用的文件中。

接下来，尝试将对象发送到网络，然后在您喜欢的浏览器中查看它。以下示例curl用作浏览器，但您也可以在其他浏览器中打开 IPFS URL：

您可以通过转到 来查看本地节点上的 Web 控制台localhost:5001/webui。这应该会d出一个这样的控制台：

Web 控制台显示可变文件系统 (MFS)中的文件。MFS 是内置于 Web 控制台的工具，可帮助您以与基于名称的文件系统相同的方式导航 IPFS 文件。

当您使用CLI 命令ipfs add 添加文件时，这些文件不会自动在 MFS 中可用。要查看您使用 CLI 添加的 IPFS 桌面中的文件，您必须将文件复制到 MFS：

—END—

开源协议：MIT License

开源地址：>

如果大家了解微服务和分布式服务器架构等技术的话，那么对于如何解决系统运行中出现的BUG造成的破坏和损失这些问题也应该有自己独到的见解吧。今天，电脑培训就一起来了解一下，在服务器运行过程中出现的问题都有哪些解决方法。

随着微服务和分布式云架构的崛起，Web变得日趋复杂，“随机性”的故障因此变得越来越难以预测，而我们对这些系统的依赖却与日俱增。

这些故障给公司造成巨大损失，也给用户带来很大的麻烦，影响他们进行在线购物、交易或打断他们的工作。即使是一些简单的故障也会触及公司的底线，因此，宕机时间就成为很多工程团队的KPI。2017年，有98%的企业表示，一小时的宕机时间将给他们带来超过10万美元的损失。一次服务中断有可能让一个公司损失数百万美元。近，英国航空的CEO透露，2017年5月发生的一次技术故障造成数千名乘客滞留机场，给公司造成8000千万英镑的损失。

企业需要想办法解决这些问题，因为等到下一次事故发生就为时已晚。为此，混沌工程应运而生。

混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

混沌工程将预想的事情与实际发生的事情进行对比，通过“有意识地搞破坏”来提升系统的d性。

混沌工程简史

混沌工程先出现在互联网巨头公司中，这些公司拥有大规模的分布式系统，因为这些系统太过复杂，他们需要一些新的手段来测试它们。

2010年

NetflixEngTools团队开发出了ChaosMonkey。当时，Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。

2011年

SimianArmy诞生，在ChaosMonkey的基础上增加了故障注入模式，可以测试更多的故障场景。Netflix认为，云的特点是冗余和容错，但没有哪个组件能够保证100%的可用性，所以他们必须设计出一种云架构，在这种架构里，个体组件的故障不会影响到整个系统。

2012年

Netflix在GitHub上开源了ChaosMonkey，并声称他们“已经找到了应对主要非预期故障的解决方案。通过经常性地制造故障，我们的服务因此变得更有d性。”

2014年

Netflix团队创建了一种新的角色，叫作混沌工程师。BruceWong发明了这个角色，并由DanWoods在Twitter上向广大的工程社区推广。DanWoods解释说，“我从KoltonAndrus那里学到了更多有关混沌工程的知识，他把它叫作故障注入测试”。

2014年10月，当时Gremlin的联合创始人KoltonAndrus还在Netflix，他们在SimianArmy的基础上提出了故障注入测试(FIT)概念，开发者可以更灵活地控制注入故障的“杀伤力范围”。因为SimianArmy有时候会造成非常严重的故障，所以Netflix的开发者对它抱有疑虑，而FIT可以更好地控制故障粒度，于是他们就由此想出了混沌工程这个概念。

在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？

对于测试结果的分析，我们通常观察下面几种情况。

观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行 *** 作，观察返回结果是否符合业务方的需求预期；第二， *** 作后端的服务器（通常是重启、宕机、断网等 *** 作），观察前端应用的返回结果是否符合系统的设计需求。

分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定义为Debug级别（最低级别）。这样做的主要目的是为了能便于测试工程师来分析日志和定位问题。为了能更好地定位问题，常常需要在服务器程序代码中进行日志打桩，把程序中的一些重要数据通过日志的方式展现出来。通常情况下，我们需要对日志的格式进行约定，在日志行中增加一些关键字来进行分类，这将便于测试工程师进行日志分析，也有利于开展分布式系统的自动化测试。另外，值得注意的是，我们尽可能地将打桩代码放在Debug代码中，避免影响系统代码，引入新问题。

分析 *** 作系统的一些重要信息。我们测试的分布式系统绝大多数是基于Linux *** 作系统开发的，在测试的过程中，除了详细分析程序日志以外，还需要对 *** 作系统的一些重要数据信息进行分析，从而来诊断服务器程序是否存在异常。以Linux *** 作系统为例，我们常常会使用top命令、netstat命令及sar命令来查看 *** 作系统的一些数据信息。例如，可以通过netstat命令检查服务器程序是否正确地监听了指定的端口等。

借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于内存检测工具来进行分析。在Linux环境下，我们常用Valgrind来进行内存检测。这是一款非常好用、功能强大的分析工具，可以帮助测试或者开发工程师快速发现很多隐藏的程序Bug，尤其是在内存检测方面（同时它还具有很多其他优秀的功能，读者可以自己查看官网中的使用手册）。对于分布式系统而言，压力测试和性能测试非常重要。在进行压力测试和性能测试的时候，可能会碰到下面一些难点。

数据准备。如何准备海量的测试数据并保证模拟数据的真实性？以一个分布式的文件系统为例，预先存入100GB的数据还是存入100TB的数据、存入的文件是大小基本一致差别不大还是各不相同甚至差异很大（例如，从几十字节至几十兆字节不等），这些因素对于分布式系统的性能影响是有很大差异的。另外，如果需要预先存入100TB的数据，若按每秒写入100MB数据来计算，写入100TB数据需要100×1024×1024/100=1048576秒=29127小时=12天。我们是否能忍受这么长时间的数据准备工作？为了解决这样的问题，我们需要对系统架构设计进行深入分析，设计好测试场景，并提前进行测试用例的设计，以尽早开始准备测试数据。

性能或压力测试工具。通常来说，分布式系统的测试需要开发一些测试工具来满足性能测试的需求。如果可以的话，建议这样的测试工具最好由测试工程师自己来实现，因为测试工程师更清楚自己的测试需求。当需要自己开发测试工具的时候，有两个关键问题需要重点关注：第一，一些关键数据的收集方式与计算将成为性能测试工具的关键，例如，TPS（每秒请求数）、Throughput（吞吐量）计算的准确性；第二，要保证性能测试工具的性能，如果工具本身的性能不好，将无法给予分布式系统足够强大的压力来进行测试。另外，当考虑到多并发（例如有10万客户端同时并发连接）时，如果性能测试工具在一台测试机器上只能运行50个或者更少的话，那么需要的测试机器数量也将会很庞大（例如2000台测试机），这个成本或许是许多公司不能承受的。因此，性能测试工具本身的性能必须要足够好才能满足需求、降低测试成本。自动化测试是测试行业发展的必然趋势，对于分布式系统测试而言也不例外。在实施分布式系统自动化测试的过程中，我们可能会碰到下面两个难点问题。

涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需要控制的 *** 作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网络设备。因此，选择一个优秀的自动化测试框架成为了非常重要的工作之一。以我们的实践经验来看，STAF是一个不错的选择，它的平台（Windows及Linux各版本）支持及开发语言的支持都很全面。

测试结果验证复杂。对于分布式系统的自动化测试来说，我们需要通过测试脚本来收集各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。例如，我们会设计一个日志分析模块，主要负责从服务器应用程序的日志中收集相应数据进行对比验证（本文前面提到的在打桩日志中增加关键字部分就显得格外重要）。

随着互联网的发展，大型分布式系统也越来越多、越来越复杂、越来越重要。如何有效地保证大型分布式系统7×24小时全天候持续稳定地运行也就成为了一个重要课题。

本文基于对redis、zookpeer、rocketmq、elasticsearch学习总结，对于分布式系统学习，一定绕不开一个点，那就是CAP定理。什么是CAP定理，我这里简单的复制摘抄一下百度上的文案。

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

说明一下上面的三个要素各代表的含义：

CAP定理说明上述的三个要素不能兼顾，最多只能满足其中的两个要素，在分布式系统中，一般都是保证分区容错性，而在一致性和可用性之间做取舍。因此存在CP、AP两种分布式集群的实现。

CP集群，即满足一致性和分区容错性，如zookpeer

AP集群，即满足可用性和分区容错性，如redis-cluster

下面，针对与上述的CP和AP问题，我们展开话题。

对于分布式系统，学习了解多了之后，发现其内在的解决方案基本上都是一样的，所谓万变不离其中。总结一下大体在于以下几步：

数据分片，很多分布式系统尤其是中间件服务，一般都会涉及高并发，数据量大的问题，如redis-cluster、recketmq，以及被大家熟知的Elasticsearch。针对于大数据量高并发的问题，若不做处理，服务器的性能将会成为服务的瓶颈，解决的方案之一便是数据分片，将大数据量在集群中按照一定的规则分片，使数据按照一定的规则分布集群的不同服务器上，以减轻单个服务器的压力，保证服务集群的可用性。

redis-cluster的数据分片是通过redis-cluster的哈希槽来实现的，redis-cluster有16384个哈希槽，这个数量是固定的，根据集群中服务器的数量可以手动的调配每个服务上存放的hash槽的数量，哈希槽之间是相互独立的，因此对集群的扩展提供了便利。

rocketmq的分片和topic紧密相关，在使用rocketmq中，无论是消息的生产者还是消费者都需要注册订阅一个topic。在rocketmq集群中，集群中的broker保存这个topic下数据的一部分，也就是topic的其中一个数据分片。当然，rocketmq不仅将一个topic下的数据分片到多个broker上，而且，一个broker上的topic数据还可以被分为多个queue，这是因为rocketmq中，一个queue只能被一个consumer消费，若是consumer的数量多于queue的数量，没有绑定queue的consumer将不能消费数据。

elasticsearch的数据分片在我看来和mysql的分库分表原理是一样的，elasticsearch中，每一个索引都相当于mysql的一个表，将一个索引分成多个shard放在不同的节点上，每个shard存储一部分数据。elasticsearch将数据进行分片，这样可以支持集群的横向扩展，同时，多个节点提供服务可以提高系统的效率和吞吐量。

综上所述，数据分片的一般都有两个好处，一个是支持集群的横向扩展，而是提升服务的吞吐量和性能。数据分片解决了以上两个问题，但是若是集群中一个节点发生宕机，或者因为网络原因和集群断开链接，那么这部分的数据分片甚至整个集群都会不可用，如何解决这个问题，就需要用到数据备份和主备切换。

数据分片的策略 了解了数据分片之后，需要了解以下数据分片的策略，根据集群提供服务的性质不同，可以采用的数据分片策略也各有不同，下面是我学习后的总结：

说到这里，会发现其实这种分片策略和负载均衡的策略还是挺相似的。

数据备份，举个例子来说，我有两台电脑A、电脑B，A用于工作，B用于游戏，我写了一篇文章，保存在电脑上电脑上，若是某一天我的电脑A磁盘坏了，那我这篇文章就找不到了，即便我现在还有电脑B，我也没有办法在对文章进行编辑。但是若是我在之前，就将文章拷贝了一份放在电脑B上，那么现在，我用电脑B就可以对文件进行编辑修改。

举这个例子，我的目的就是为了说明数据备份对于集群可用性的意义，例子中，我的两台电脑可以认为是集群中两台服务器，两台服务器一开始提供的服务可能不相同，A电脑提供的就是编辑文章的服务，数据备份的意义就在于，当原本提供服务的服务器宕机损坏，集群中另外的服务器仍然可以根据已经备份的数据提供相同的服务，而不会影响到用户的工作。

数据备份的目的就是不发生单点问题的措施之一，但是若是数据备份的策略不合适，备份的时机不对，那么备份的数据时效性也是问题。还是从例子出发，这里的文章每次都是我手动从A电脑拷贝到B电脑，这是我的备份策略，若是我选择每天晚上才拷贝一次，那么若是A电脑在我拷贝之前坏了，当天的文章编辑数据就丢失了，采用手动的方式备份，这种备份方式耗时耗力且不可控，而在分布式集群中，不同的系统采用了不同的备份策略，下面一一来说明。

首先明确一点，在分布式集群中，不可能采用人工手动备份，一定是系统程序按照一定的规则自动备份，就好像我将AB连在一起，写个程序，让A电脑自动把文章同步到B电脑。数据备份的方式分为两种：

这里以redis-cluster和zookeeper举例。

在redis-cluster中，当一台新的slave节点加入时，会出发数据同步，需要将主节点的数据同步到从节点。这时根据从节点的状态有两种同步方案：完整重同步 和 部分重同步

完整重同步既是将主节点的全部数据都复制给新的slave节点。大致流程为，当一个新的节点加入进来时，发送PSYNC命令给主节点并携带slave节点自身的信息（重点是复制偏移量），主节点会根据slave传过来的信息判断是完整重同步还是部分重同步，如何判断与数据同步时的复制缓冲区有关，更细节不展开介绍。

相对于redis-cluster，zookeeper中的数据同步有四种方式，和redis-cluster完整重同步和部分重同步相似的SNAP（全量同步）和DIFF（增量同步），以及zk事务处理相关的TRUNC（仅回滚同步）、TRUNC+DIFF（回滚+增量同步）

当节点已经加入集群，成为集群中的从节点，只要不断开连接，一般都只需要进行增量同步，不过系统同步的范围和方式有所差异，大致分为下面六种：

下面还是以具体服务来举例： redis-cluster中，主从复制采用的是异步复制的方式，master节点在做数据变更之后，会由一个异步线程将数据变更同步给slave节点，这是通过push的方式。当redis28之后，slave会周期的获取最新的数据，加入了pull方式。无论是master还是slave，在进行数据同步时，不会阻塞正常的应用请求。所以redis-cluster的主从复制，是异步备份+最终一致性的备份。

elasticsearch的主从复制可以手动设置同步备份或者异步备份，数据备份时不要求强一致性，而是主分片（primary shard）会维护一份需要同步的（replica shard）分片列表，这个分片列表同步完成，则认为数据备份完成，需要注意的是，这里的主从复制不是节点的更新数据，而是分片的更新数据。

rocketmq的主从复制和elasticsearch类似，也可以分为同步备份和异步备份，不同的是rocketetmq的数据备份采用的是pull的方式，从节点会通过HAConnection链接主动向主节点发送待拉取数据偏移量，待主节点返回节点更新数据信息，更新从节点数据偏移量，如此重复。

zookeeper的数据备份则是通过ZAB协议，通过消息广播的方式同步数据到从节点。

当数据备份后，主从节点上就有了相同的数据，为了提升服务的性能，那么可以采用读写分离的方式。主节点提供数据写服务，从节点提供读服务，可以有效的分担主节点的服务器压力。可以进行数据分片的系统，如：redis、rocketmq、elasticsearch，一般都可以配置一主多从、多主多从的集群架构。

读写分离之后，主节点提供写服务，从节点只提供读服务，因此若是主节点发生宕机，从节点依然可以提供读服务，但是服务无法更新数据，这时候就要进行主从切换。早起，主从切换可以由人工手动完成，不过随着技术发展，主从切换已经成为集群的必备功能。想要实现主从切换，必须要解决两个问题：

解决这个问题，需要额外再引入一个角色，相当于是一个监视者的角色，能够长期的对主节点进行监视，若是只有一个监视者，可能会发生误判，所以还需要一套机制去保证当监视者说主节点宕机，那么主节点是真的宕机，否则集群会出现脑裂问题。

以redis为例，在redis的哨兵模式中，这个监视者的角色是一个个哨兵实例，而在redis-cluster架构中，这个监视者的角色是redis实例自己。

在redis哨兵模式中，哨兵集群中的哨兵实例会定期和redis实例进行通信（ping），监视redis实例的在线情况，若是其中一台哨兵发现redis实例master故障，那么该哨兵会将该master状态改为主观下线，并通知其他哨兵，当哨兵集群中达到配置数量的哨兵实例认为该master都为主观下线状态，这时会将master修改为客观下线状态，并开始触发后续的故障转移。

在redis-cluster模式中，集群中的每一个节点都可以和其他节点通讯（ping），当某一个节点A发现主节点B下线了，A会将该主节点B设为疑似下线状态。集群中的节点会通过互发消息维护信息，当另一个节点C收到A的消息时，会将A对B节点的判断记录在C节点的维护信息下，这个信息可以理解为A说C疑似下线了。若是有其他节点发送C的状态信息，A同样也会记录。当某一个节点如C发现记录的B节点信息中，超过半数的主节点都认为B下线了，那么C就会将B节点状态修改为已下线状态，并广播消息给集群的其他节点，开始后续的故障转移。

上面就是redis的两种分布式模式故障检测的方案。大致可以归结为，监视节点会和被监视节点进行通讯，感知被监视节点的状态；监视节点之间也会进行通讯，同步信息。为了防止集群出现脑裂，对于某个主节点的故障判断会十分的谨慎，需要达到一定数量的监视节点都认为主节点故障时，才会认为主节点真的故障，从而触发故障转移。

在rocketmq集群模式中，nameserver扮演着监视者的角色（不同于其他系统，nameserver并不负责集群的主从切换，rocketmq 45之前不支持自动主从切换，45之后，通过dledger实现自动的故障转移）。在elasticsearch集群中，elasticsearch实例本身在扮演监视者角色。zookeeper也是实例本身扮演监视者的角色。

故障转移就是当集群发现集群中的主节点/从节点发生故障之后的处理，从节点比较简单，直接将从节点下线即可，主节点的故障转移流程比较复杂，各个系统根据系统的功能和架构有不同的实现方式，共同点是选举出的主节点一定是集群中数据最新的最完善的节点。

选举过程大致如下：

首先选举成功的条件时集群中具有投票权限的超过半数的节点投票一致，通过某一个节点成为主节点。

开始一轮选举时，定义为一个纪元，用一个自增的id表示。

候选节点将带着纪元id，以及自身信息作为投票申请广播给集群给可投票的节点。

具有投票权限的节点投票只要满足两个条件：1自身在最新纪元没有给投过票 2节点发送过来的投票申请时最新纪元的（如何判断时最新纪元，则是判断一下节点之前通过申请的纪元id是否小于当前申请的纪元id）。

半数以上的投票节点通过某一个候选节点成为leader节点，则leader产生。

若是一个纪元没有产生主节点，则候选节点进入随机的休眠，并且开启下一个纪元，知道产生leader节点。

在zk集群经过崩溃恢复模式之后，需要保证：1已经提交的事务不能丢失 2未被提交的事务不能出现。如何保证以上两点，zk服务集群中维护了zxid，zxid也可以看作是一个自增的id，集群中每产生一个新事物，zxid就会增加。zxid有64位，前32位维护了集群主节点变更情况，每重新选举出一个新的主节点则增加，后32位维护在新的主节点集群下事务的id，产生一个新事物则增加。

ZAB的选举模式有很多种，我主要了解了默认，也是推荐的FastLeaderElection模式，在这个模式下，我会以集群中一台参与选举的服务器的视角来模拟选主的过程；

我是一台zk服务器，我现在很慌，因为我的leader服务器不见了，作为一个有梦想的follower，我也要参加leader的选举，为了这次选举我要准备：myid(在集群中标识是这台服务器的id)，zxid(本台服务器保存的最新事务id)，logicClock(本台服务器发起的第几轮投票)

首先我会自己选自己，这得自信。于是我将自身的选举信息[myid, zxid]放到自己的收票箱，然后将我的选举信息还有我的选举轮次logicClock广播给其他服务器进行PK

作为一个有原则的服务器，我们的选举也是有原则的，当我收到别人的选举信息时，我也会将他和我自己的选举信息进行PK，PK的原则如下：

经过这一系列的PK，终于选出了我心中的leader服务器，要广播给其他服务器。

超过半数的服务器都同意某一台服务器成为leader，选举结束了。

---