在我的理解中，es集群和redis集群在某种程度上是想象的，但建议您查看redis的设计和实现。 很有帮助
个人ESS体验：
es在分配索引时已经指定了主片的数量。 竹节纱安已确定今后不变； 一个群集可以有多个节点，但可以有一个主节点，每个节点可以有不同的片，每个片可以包括主片和复制片。 由于同一分片的主从分片被分配给不同的节点，因此可以避免主机停机对数据丢失的影响。 在主节点宕机时从该从节点中选择一个节点作为主节点，选择宕机的复制分区作为主分区，对进行数据读写的一个主分区进行多个复制分区主要节点的主要作用是与群集操作相关的内容，如创建和删除索引、跟踪属于群集的节点以及确定分配给相关节点的分片。 原文地址： https://es.xiaoleilu.com/
节点(node )是Elasticsearch实例，群集)由一个或多个具有相同cluster.name的节点组成，它们协作共享数据和负载。 加入新节点或删除节点时，群集会识别并平衡数据。
选择群集中的一个节点作为主节点(master )，并临时管理群集级别的更改，例如创建或删除索引，以及添加或删除节点。 主节点不参与文档级别的更改或搜索。 这意味着当流量增加时，其主节点不会成为群集的瓶颈。 任何节点都可以是主节点。 因为我们示例中的群集只有一个节点，所以它用作主节点。
作为用户，您可以与群集中的任何节点(包括主节点)进行通信。 每个节点都知道文档所在的节点，并且可以将请求转发到相应的节点。 我们访问的节点收集每个节点返回的数据，最后一起返回给客户端。 这一切都由Elasticsearch处理。
集群健康在Elasticsearch集群中可以监测和统计很多信息，但最重要的是集群健康(cluster health )。 集群的健康有三种状态：绿色、黄色和红色。
在没有索引的空群集上执行上述查询时，GET /_cluster/health将返回以下信息：
{ ' cluster _ name ' : ' elastic search '，' status': 'green '，1 'timed_out': false，' number _ of _ of }
1 status是我们最感兴趣的字段
status字段提供了表示群集服务状况的综合指标。 三种颜色的含义：
颜色语义green所有主切片和复制切片均可用于yellow1所有主切片，但不是所有复制切片。 red并不是所有主要切片都可以添加索引。 要将数据添加到Elasticsearch中，需要一个存储索引(index ) ——相关数据的位置。 实际上，索引只是指一个或多个切片的逻辑命名空间。
“平铺”(shard )是最低级别的“工作单位”(worker unit )，它只存储索引中所有数据的一部分。
瓷砖是Elasticsearch在群集中分发数据的关键。 把瓷砖当成数据的容器。 文档保存在分片中，分片指定给你群集中的节点。 当qsdlf集群放大或缩小时，Elasticsearch会自动在您的节点之间迁移分片以保持集群平衡。
分片可以是“主分片”(primary shard )或“复制分片”(replica shard )。 因为索引中的每个文档都属于单独的主拼贴，所以主拼贴的数量决定了索引中可以存储的最大数据数。
理论上可以存储在主片上的数据大小没有限制，限制取决于实际使用情况。 最大分片容量完全取决于使用情况，包括硬件存储的大小、文档的大小和复杂性、文档索引和查询方法以及预期的响应时间。
复制拼贴是主拼贴的副本，可防止硬件故障导致的数据丢失，并提供读取请求，如搜索和从其他shard读取文档。
当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。
让我们在群集中唯一的空节点上创建一个名为blogs的索引。 默认情况下，每个索引分配五个主切片，但为了演示目的，只分配三个主切片和一个复制切片。 每个主切片都有一个复制切片。
put/blogs { ' settings ' : { ' number _ of _ shards ' :3，' number_of_replicas' : 1 }}
>我们的集群现在看起来就像上图——三个主分片都被分配到Node 1。如果我们现在检查集群健康(cluster-health)，我们将见到以下信息：
{ "cluster_name": "elasticsearch", "status": "yellow", <1> "timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 3, "active_shards": 3, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 3 <2>}<1> 集群的状态现在是 yellow
<2> 我们的三个复制分片还没有被分配到节点上
集群的健康状态yellow表示所有的主分片(primary shards)启动并且正常运行了——集群已经可以正常处理任何请求——但是复制分片(replica shards)还没有全部可用。事实上所有的三个复制分片现在都是unassigned状态——它们还未被分配给节点。在同一个节点上保存相同的数据副本是没有必要的，如果这个节点故障了，那所有的数据副本也会丢失。
现在我们的集群已经功能完备，但是依旧存在因硬件故障而导致数据丢失的风险。
增加故障转移在单一节点上运行意味着有单点故障的风险——没有数据备份。幸运的是，要防止单点故障，我们唯一需要做的就是启动另一个节点。
启动第二个节点
为了测试在增加第二个节点后发生了什么，你可以使用与第一个节点相同的方式启动第二个节点（《运行Elasticsearch》一章），而且命令行在同一个目录——一个节点可以启动多个Elasticsearch实例。
只要第二个节点与第一个节点有相同的cluster.name（请看./config/elasticsearch.yml文件），它就能自动发现并加入第一个节点所在的集群。如果没有，检查日志找出哪里出了问题。这可能是网络广播被禁用，或者防火墙阻止了节点通信。
如果我们启动了第二个节点，这个集群看起来就像下图。
双节点集群——所有的主分片和复制分片都已分配:
第二个节点已经加入集群，三个复制分片(replica shards)也已经被分配了——分别对应三个主分片，这意味着在丢失任意一个节点的情况下依旧可以保证数据的完整性。
文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都可以被检索。
cluster-health现在的状态是green，这意味着所有的6个分片（三个主分片和三个复制分片）都已可用：
{ "cluster_name": "elasticsearch", "status": "green", <1> "timed_out": false, "number_of_nodes": 2, "number_of_data_nodes": 2, "active_primary_shards": 3, "active_shards": 6, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0}<1> 集群的状态是green.
我们的集群不仅是功能完备的，而且是高可用的。
横向扩展随着应用需求的增长，我们该如何扩展？如果我们启动第三个节点，我们的集群会重新组织自己，就像图4：
图4：包含3个节点的集群——分片已经被重新分配以平衡负载：
ode3包含了分别来自Node 1和Node 2的一个分片，这样每个节点就有两个分片，和之前相比少了一个，这意味着每个节点上的分片将获得更多的硬件资源（CPU、RAM、I/O）。
分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。我们拥有6个分片（3个主分片和三个复制分片），最多可以扩展到6个节点，每个节点上有一个分片，每个分片可以100%使用这个节点的资源。+
继续扩展如果我们要扩展到6个以上的节点，要怎么做？
主分片的数量在创建索引时已经确定。实际上，这个数量定义了能存储到索引里数据的最大数量（实际的数量取决于你的数据、硬件和应用场景）。然而，主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。
复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。让我们把复制分片的数量从原来的1增加到2：
PUT /blogs/_settings{ "number_of_replicas" : 2}增加number_of_replicas到2：
从图中可以看出，blogs索引现在有9个分片：3个主分片和6个复制分片。这意味着我们能够扩展到9个节点，再次变成每个节点一个分片。这样使我们的搜索性能相比原始的三节点集群增加三倍。
当然，在同样数量的节点上增加更多的复制分片并不能提高性能，因为这样做的话平均每个分片的所占有的硬件资源就减少了（译者注：大部分请求都聚集到了分片少的节点，导致一个节点吞吐量太大，反而降低性能），你需要增加硬件来提高吞吐量。
不过这些额外的复制节点使我们有更多的冗余：通过以上对节点的设置，我们能够承受两个节点故障而不丢失数据。
应对故障我们已经说过Elasticsearch可以应对节点失效，所以让我们继续尝试。如果我们杀掉第一个节点的进程（以下简称杀掉节点），我们的集群看起来就像这样：
图5：杀掉第一个节点后的集群
我们杀掉的节点是一个主节点。一个集群必须要有一个主节点才能使其功能正常，所以集群做的第一件事就是各节点选举了一个新的主节点：Node 2。
主分片1和2在我们杀掉Node 1时已经丢失，我们的索引在丢失主分片时不能正常工作。如果此时我们检查集群健康，我们将看到状态red：不是所有主分片都可用！
幸运的是丢失的两个主分片的完整拷贝存在于其他节点上，所以新主节点做的第一件事是把这些在Node 2和Node 3上的复制分片升级为主分片，这时集群健康回到yellow状态。这个提升是瞬间完成的，就好像按了一下开关。
为什么集群健康状态是yellow而不是green？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只有一个复制分片被分配，这就是集群状态无法达到green的原因，不过不用太担心这个：当我们杀掉Node 2，我们的程序依然可以在没有丢失数据的情况下继续运行，因为Node 3还有每个分片的拷贝。
如果我们重启Node 1，集群将能够重新分配丢失的复制分片，集群状况与上一节的 图5：增加number_of_replicas到2 类似。如果Node 1依旧有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分。
es存储的一些小理解：
分配文档到不同的容器 或 分片 中，文档可以储存在一个或多个节点中按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失将集群中任一节点的请求路由到存有相关数据的节点集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复es在创建集群的时候默认初始化的分片是5个，可通过调用接口设置分片数量，一个分片对应一个Lucene实例，以及它本身就是一个完整的搜索引擎，文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。
Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 qsdlf的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。
一个分片可以是 主 分片或者 副本 分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。
路由一个文档到一个分片的路由规则。
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
在设置完分片后存储的文档会根据一定的算法将文档保存到某个分片内，分片下会存在多个副本，多个副本冗余存在该文档。
下次查询该文档时集群master会根据以上的算法和查询文档的ID定位到保存该文档的分片，分片再查询其下副本内的文档返回给master，最后返回客户端调用者。