‘壹’ redis集群添加节点怎么保证不丢失数据
执行在任意一个客户端下执行 cluster nodes 命令，可以看到7007 已经作为主节点添加到我们的集群中了，但是可以看到他没有分配哈希槽，没有分配哈希槽的话表示就没有存储数据的能力，所以我们需要将其他节点上的哈希槽分配到这个节点上。
‘贰’ ElasticSearch核心之——分布式特性
ES支持集群模式，是一个分布式系统，其好处主要有两个∶
es集群由多个ES 实例组成。不同集群通过集群名字来区分，可通过 cluster.name 进行修改，默认为elasticsearch。每个ES实例本质上是一个 JVM 进程，且有自己的名字，通过 node.name 进行修改
ES集群相关的数据称为 cluster state ，主要记录如下信息∶节点信息，比如节点名称、连接地址等；索引信息，比如索引名称、配置等
可以修改 cluster state 的节点称为master节点，一个集群只能有一个 cluster state 存储在每个节点上，master维护最新版本并同步给其他节点
master节点是通过集群中所有节点选举产生的，可以被选举的节点称为 master-eligible 节点 ，相关配置如下: node.master: true
处理请求的节点即为coordinating节点，该节点为所有节点的默认角色，不能取消。路由请求到正确的节点处理，比如创建索引的请求到master节点
存储数据的节点即为data节点，默认节点都是data类型，相关配置如下∶ node.data: true
谈及副本和分片两个概念之前，我们先说一下这两个概念存在的意义： 解决系统可用性和增大系统容量
我们想象这样一个场景，我们的数据只存放在一台ES服务器上，那么一旦这台ES出现宕机或者其他不可控因素影响的话，我们除了丧失了服务的可用性外，可能还存在着数据丢失的可能。同时，单机服务的存储容量也无法应对项目对大数据量的要求。
系统可用性可以分为 服务可用性 和 数据可用性
服务可用性 含义为：当前服务挂掉后，是否有其他服务器顶替当前节点提供服务支持。
数据可用性 含义为：当前服务挂掉后，存储在当前服务器上的数据，是否还可以对外提供访问和修改的服务。
副本可以理解为是某个数据的复制体，副本和源数据内容一致。副本的存在可以有效地满足系统可用性的需求，比如说，我们可以在原有节点的基础上复制一个和源节点一模一样的节点，这样一旦原有节点挂掉了，另外一个节点也还是可以替代源节点提供服务，而且复制出来的节点拥有和源节点一样的数据，这样也保障了数据可用性。
我们在上一小节讲到可以使用副本来解决系统可用性的问题，但是这里存在一个问题，不管存在多少个副本（节点），都无法增大源节点的存储空间。在这个问题上，ES引入了Shard分片这个概念来解决问题。
看完分片的特点后可能还有人不太清楚到底什么是分片，其实分片是n/1个源节点数据。比如说原ES集群中只有一个主节点，所有的索引数据都存储在这个节点上。现在我们将某个索引数据分成3份，分别存放在3个ES节点上，那么每台ES服务器上就各自有1个分片shard。该索引的所有节点Shard分片的集合，就是索引的全部数据。
下面我们来演示一下：
为了更好的了解ES的分片机制，大家不妨在上面的案例上进一步思考两个问题：
答案是不能。原因是我们创建索引时定义的分片数量只有3个，且都已经落在了3个节点上。所以即使再增加多一个节点，也不会有对应的Shard分片可以落在新的节点上，并不能扩大 test_shard_index 的数据容量。
答案是不能。因为新增的副本也是分布在这3个节点上，还是利用了同样的资源。如果要增加吞吐量，还需要新增节点。
通过上面两个问题，相信大家已经可以认识到分片的重要性，分片数过小，会导致后续无法通过增加节点实现水平扩容；（副本）分片数过大会导致一个节点上分布过多分片，造成资源浪费，同时会影响查询性能
集群健康状况，包括以下三种: green健康状态，指所有主副分片都正常分配； yellow指所有主分片都正常分配，但是有副本分片未正常分配； red表示有主分片未分配
我们可以通过这个api查看集群的状态信息： GET _cluster/health
我们也可以通过cerebro或者head插件来直接获取当前集群的状态
需要注意的是，即使当前集群的状态为 red ，也并不代表当前的ES丧失了提供服务的能力。只是说未被分配主分片的索引无法正常存储和操作而已。
这里故障转移的意思是，当ES集群出现某个或者多个节点宕机的情况，ES实现服务可用性的应对策略。
这里我们新建一个分片为3，副本为1的索引，分片分别分布在三个节点，此时集群为 green
当master节点所在机器宕机导致服务终止，此时集群会如何处理呢?
我们可以看到，从node1主节点宕机到ES恢复集群可用性的过程中，ES有着自己的故障转移机制，保障了集群的高可用性。我们也可以在自己的本地上去进行试验，建好索引后，kill掉主节点，观察集群状态就行。
同时，此时就算node2宕机了，那么node3也能够很快的恢复服务的提供能力。
我们知道，我们创建的文档最终会存储在分片上，那么在分布式集群的基础上，ES集群是怎么判断当前该文档最终应该落在哪一个分片上呢？
很显然，我们需要一个可以实现文档均匀分布到各个分片上的映射算法，那么常见的随机算法和round-robin（轮询）算法可以满足需要吗？答案是不可以，这两个算法虽然可以实现文档均匀分布分片的存储需要，但是当我们通过 DocumentId 查询文档时，ES并不能知道这个文档ID到底存储在了哪个节点的分片上，所以只能够从所有分片上检索，时间长。如果我们为这个问题建立一个文档和分片映射关系的表，虽然确实可以快速定位到文档对应的存储分片，但是当文档的数据量很大的时候，那么检索的效率也会随之变低。
对于上面这个问题，ES提供的解决方法是 建立文档到分片的映射算法
es 通过如下的公式计算文档对应的分片：
hash算法 保证可以将数据均匀地分散在分片中
routing 是一个关键参数，默认是文档id，也可以自行指定
number_of_primary_shards 是主分片数
我们可以看到，该算法与主分片数相关， 这也是分片数一旦确定后便不能更改的原因
我们已经知道了ES是如何将文档映射到分片上去了，下面我们就来详细讲解一下文档创建、读取的流程。
脑裂问题，英文为 split-brain ，是分布式系统中的经典网络问题，如下图所示:
3个节点组成的集群，突然node1的网络和其他两个节点中断
解决方案为 仅在可选举master-eligible节点数大于等于quorum时才可以进行master选举
在讲文档搜索实时性之前，先讲一下倒排索引的不可变更特性。由于倒排索引一旦生成，不可变更的特定，使得其有着以下3点好处：
下面，将针对Lucene实现文档实时性搜索的几个动作进行讲解，分析其是如何在新增文档后实现ES的搜索实时性的。
我们从上面的描述中知道，当我们新增了一个文档后会新增一个倒排索引文件 segment ，但是 segment 写入磁盘的时间依然比较耗时（难以实现实时性），所以ES借助文件系统缓存的特性， 先将 segment 在缓存中创建并开放查询来进一步提升实时性 ，该过程在es中被称为refresh。
在refresh之前文档会先存储在一个buffer中，refresh时将 buffer中的所有文档清空并生成 segment
es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒 ，这也是es被称为近实时(Near Real Time)的原因
reflush虽然通过 将文档存放在缓存中 的方式实现了秒级别的实时性，但是如果在内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题呢?
ES 引入 translog 机制。写入文档到 buffer 时，同时将该操作写入 translog 中。
translog文件会即时写入磁盘(fsync)，在ES 6.x中，默认每个请求都会落盘，我们也可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为index.translog.*。同时ES每次启动时会检查translog 文件，并从中恢复数据。
flush 负责将内存中的segment写入磁盘，主要做如下的工作:
Reflush和Flush执行的时机
ES的做法是 首先删除文档，然后再创建新文档
我们上面提到，新增文档是通过新建segment来解决，删除文档是通过维护.del文件来进行的，假如现在我们设置的 reflush 时间间隔为1秒，那么一小时单个ES索引就会生成3600个segment，一天下来乃至一个月下来会产生的segment文件数量更是不可想象。为了解决Segment过多可能引起的性能下降问题，ES中采用了Segment Merging（即segment合并）的方法来减少segment的数量。
执行合并操作的方式有两种，一种是ES定时在后台进行 Segment Merging 操作，还有一种是我们手动执行 force_merge_api 命令来实现合并操作。
‘叁’ 名称节点的数据保存在哪里
名称节点的数据保存在内存中。名称节点作为中心服务器,负责管理文件系统的命名空间及客户端对文件的访问。 名称节点通常用来保存元数据。数据节点的数据保存在磁盘中。数据节点用来存储具体的文件内容。数据节点在名称节点的统一调用下进行数据块的创建、删除和复制等操作。数据节点可以有多个。
名称节点的拓展
HDFS只设置唯一个名称节点带来的局限性，隔离问题，命名空间的限制，集群的可用性，性能的瓶颈。第2个副本放在与第1个副本不同的机架的数据节点上。第3个副本放在与第一个副本相同的机架的数据节点上。如果还有更多的副本，则继续从集群中随机选择数据节点进行存放。
如果是在集群内发起写操作请求，则把第一个副本放置在发起写操作请求的数据节点上。如果是在集群外发起写操作请求，则从集群内部挑选一台磁盘空间较为充足、CPU不太忙的数据节点，作为第一个副本的存放地。
‘肆’ Elasticsearch 集群
分片：分片就是对数据切分成了多个部分，Elasticsearch 默认会把一个索引分成五个分片，
数据保存在分片内，分片又被分配到集群内的各个节点里
副本：副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片
主节点：即 Master 节点。主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的 健康 是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。
数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。
负载均衡节点：也称作 Client 节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为 Ingest 节点。
1.Master：主节点，每个集群都有且只有一个
尽量避免Master节点又是数据节点： node.data true
主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。
2.Voting：投票节点
node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。
3.Coordinating：协调节点
每一个节点都隐式的是一个协调节点，如果同时设置了data.master = false和data.data=false，那么此节点将成为仅协调节点。
4.Master-eligible node（候选节点）
可以通过选举成为Master的节点
5.Data node（数据节点）
主要负责数据存储和查询服务
配置：
这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。
只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。
既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡
不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。
协调节点是如何工作的，他是怎么找到对应的节点的?
每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息
集群状态(Cluster Starte),维护了一个集群中,必要的信息
所有的节点信息
所有的索引和其相关的Mapping与Setting信息
分片的路由信息
协调节点作为es节点中的一个节点，默认情况下es集群中所有的节点都能当协调节点，主要作用于请求转发，请求响应处理等轻量级操作。
这意味着如果它们接收到用户请求，它们就可以处理用户请求
status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：
green 所有的主分片和副本分片都正常运行。
yellow 所有的主分片都正常运行，但不是所有的副本分片都正常运行。
red 有主分片没能正常运行
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到 Node 1 ，我们将其称为 协调节点(coordinating node) 。
以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序：
consistency 一直性： 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操作）, all （必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_操作。
master选举当然是由master-eligible节点发起
深入理解 Elasticsearch 7.x 新的集群协调层：
https://easyice.cn/archives/332
Elasticsearch的选举机制
https://www.jianshu.com/p/bba684897544
elasticsearch 选主流程
https://www.easyice.cn/archives/164
elasticsearch的master选举机制
https://www.cnblogs.com/jelly12345/p/15319549.html
https://blog.csdn.net/ailiandeziwei/article/details/87856210
shard_num = hash(_routing) % num_primary_shards
其中 _ routing 是一个可变值，默认是文档的 _id 的值 ，也可以设置成一个自定义的值。 _routing 通过 hash 函数生成一个数字，然后这个数字再除以 num_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。 这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量 ：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。
将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件
补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。
如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。
如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。
buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作
每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。
段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。
当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。
由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行
https://blog.csdn.net/qq_21299835/article/details/106534644
‘伍’ mysql集群中的数据节点是怎么存储数据的
问题1：数据节点实际就是单个的数据库实例而已，所以数据存储和一般实例没有太多区别，如果你的意思是怎么保证数据的存储一致性，那这个话就多了，不过，其实当做master-slave的高级模式来理解就好了，只是没有使用binlog的动态转换分发而已
问题2：关于集群的数据恢复，打字太费力了，这篇文章还算详细，你去看看好了
http://apps.hi..com/share/detail/18131208
最后，其中还给出了实际成功操作时的所有详细软件配置和版本
更多集群信息，看官网和论坛吧，MySQL Cluster NDB 7.1貌似已经可以在Windows下跑了
http://dev.mysql.com/doc/mysql-cluster-excerpt/5.1/en/mysql-cluster.html
‘陆’ 什么是集群存储
云存储是在云计算(cloud computing)概念上延伸和发展出来的一个新的概念，是指通过集
群应用、网格技术或分布式文机房集中监控系统件系统等功能，将网络中大量各种不同类
型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的
一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时，云计算系统中就
需要配置大量的存储设备，那么云计算系统就转变成为一个云存储系统，所以云存储是一
个以数据存储和管理为核心的云计算系统。他们基于虚拟化技术和集群架构，具有强大的
横向扩展能力。云存储设备横向扩展的方式让存储系统具有了无限扩展的能力，它能够实
现控制器与硬盘的同时扩展，也就是性能与容量可以同时实现线性扩展。
集群存储是通过将数据分布到集群中各节点的存储方式，提供单一的使用接口与界面，使
用户可以方便地对所有数据进行统一使用与管理。集群中所有磁盘设备整合到单一的共享
存储池中提供给前端的应用服务器，极大提高了磁盘利用率，可以为非结构化数据提供具
备极高IO带宽和灵活可扩展性的存储解决方案。
‘柒’ 存储虚拟化是什么集群存储又是什么
存储虚拟化广义上来说，就是通过映射或抽象的方式屏蔽物理设备复杂性,增加一个管理层面，激活一种资源并使之更易于透明控制。
存储虚拟化(Storage Virtualization)最通俗的理解就是对存储硬件资源进行抽象化表现。通过将一个（或多个）目标（Target）服务或功能与其它附加的功能集成，统一提供有用的全面功能服务。
集群存储是指：由若干个“通用存储设备”组成的用于存储的集群，组成集群存储的每个存储系统的性能和容量均可通过“集群”的方式得以叠加和扩展。
‘捌’ rac集群中节点信息存放在什么位置
从逻辑上看，RAC集群由存储层、网络层、集群件层、应用层4层组成。
存储层：RAC是一个多实例、单数据库的系统。数据文件、联机日志、控制文件等文件在集群中只有一份。不管有几个节点，这些节点都平等的使用这些数据文件。
网络层：整个RAC环境中，实际有3个网络存在。一个是由public网卡接入的网络，用于对外提供数据查询等服务；另一个是由private网卡组成的私有网络，用于RAC心跳和cache fusion；第三个是存储设备、光纤交换机、每个节点的HBA卡组成的存储网络。前两个网络上面传输的是IP数据，而后一个网络传输的SCSI数据。
集群件层：在单机环境下，Oracle是运行在OS Kernel之上。OS Kernel负责管理硬件设备，并提供硬件访问接口。Oracle不会直接操作硬件，而是由OS Kernel代替它来完成对硬件的调用请求。到了集群环境下，存储设备是共享的。OS Kernel的设计都是针对单击的，只能控制单击上多个进程间的访问，如果还依赖OS Kernel的服务，就无法保证多个主机之间的协调工作。这时就需要引入额外的控制机制，在RAC中，这个机制就是位于Oracle和OS Kernel之间的Clusterware，它会在OS Kernel之前截获请求，然后和其他节点上Clusterware协商，最终完成上层的请求。
应用层：在介绍这一层时，需要先引入一个名词CRS Resource，整个应用层是由若干 CRS Resource组成的。可以简单的理解，一个Resource通常是一个进程，或者有一组进程组成的完整服务。集群环境之所以能够提供高可用性，是因为集群软件（CRS）对运行于其上的应用进行监视，并在发生异常时进行重启、切换等干预手段。
‘玖’ Elasticsearch 集群
一个 Elasticsearch 集群由一个或多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识。
一个 Elasticsearch 实例即一个 Node，一台机器可以有多个实例，正常使用下每个实例应该会部署在不同的机器上。Elasticsearch 的配置文件中可以通过 node.master、node.data 来设置节点类型。
node.master：表示节点是否具有成为主节点的资格
node.data：表示节点是否存储数据
节点即有成为主节点的资格，又存储数据。这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。Elasticsearch 默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，这样相当于主节点和数据节点的角色混合到一块了。
节点没有成为主节点的资格，不参与选举，只会存储数据。在集群中需要单独设置几个这样的节点负责存储数据，后期提供存储和查询服务。主要消耗磁盘，内存。
不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。普通服务器即可(CPU、内存消耗一般)。
不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡。普通服务器即可（如果要进行分组聚合操作的话，建议这个节点内存也分配多一点）
在生产环境下，如果不修改 Elasticsearch 节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。
一个集群下可以有多个索引，每个索引是一系列相同格式文档的集合 （Elasticsearch 6.x 已不支持一个索引下多个Type） 。
每个索引有一个或多个分片，每个分片存储不同的数据。分片可分为主分片（ primary shard）和复制分片（replica shard），复制分片是主分片的拷贝。默认每个主分片有一个复制分片（默认一个索引创建后会有5个主分片，即：5主+5复制=10个分片），一个索引的复制分片的数量可以动态地调整，复制分片从不与它的主分片在同一个节点上（防止单点故障）。
复制分片有两个作用：
根据以下说明调整 elasticsearch.yml 对应参数配置，node2、node3 其他配置与node1一致。
到目前位置，集群的配置就完成了，下面我们分别启动每个实例。
根据配置文件中的注释：
所以我们配置了 discovery.zen.minimum_master_nodes: 2 ，所以必须有两个主节点启动成功，集群才算生效。
进入目录 elasticsearch-6.2.1-1 启动第一个节点，执行命令：bin\elasticsearch.bat。从日志中可以看出并没有成功，因为没发现足够的master节点。
当第二个master节点启动成功时，整个集群状态变为正常。
3个节点全部启动成功，通过 elasticsearch-head 插件查看集群状态，通过集群健康值：green，表示集群一切正常。目前集群内没有任何数据，所以看不出索引与分片的情况。
Elasticsearch 一般会配合 Kibana + X-Pack 对集群数据分析、监控等，官方标配。这里使用了 elasticsearch-head 插件，一个比较小巧的工具。插件的安装方法请看： elasticsearch-head 安装介绍
添加测试数据：
从截图可以看出，目前一共3个节点，一个索引 test，test 索引有5个主分片（边框加粗），5个复制分片（边框不加粗），分片会别均匀的分布到每个节点中。
我们尝试干掉node3，node3 从集群退出之后，集群在短时间内会对分片进行重新分布，当然依赖遵循主、复制分片不会在同一个Node。
如果我们继续把node2干掉，那么整个集群就挂了，集群健康值：未连接。因为当前可用的主节点数 1 < discovery.zen.minimum_master_nodes 设置的 2。
我们尝试把 discovery.zen.minimum_master_nodes 设置成 1，然后重启启动一个节点，会发现有一个 Unassigned 的节点，集群健康值：yellow (5 of 10)。这种情况下代表主分片全部可用，存在不可用的复制分片，5个复制分片没有分配到节点上，不过此时的集群是可用的，我们任何请求都能处理，只是所有的操作都落到主分片上，而且可能引发单点故障。当我们把第二个节点启动后，一切就恢复正常了，主分片的数据会同步到复制分片。
实际生产环境，每个节点可能设置不同的节点类型，我们在3个节点的基础上再增加两个节点，然后调整 node.master 和node.data 的值，最终设置为2个主节点，2个数据节点，1个客户端节点。
node1 和 node2 是具有主节点选举权限的节点，这里 node1 被选举为master节点。node3 和 node4 是数据节点，所以数据分片只会分配在这两个节点上。node5 是客户端节点，最终是对请求起到负载均衡的作用。
如果是Linux环境下，启动可能没有这么顺利，可以参考 Linux 环境下安装 elasticsearch 5.x、6.x 问题汇总 。
‘拾’ rabbitmq集群中各节点存储的数据一样吗
现在，我能提供。
怎么写呢代码，采用了将分值全部送出