开门见山，根据es官网的doc
根据我自己的理解(先从网上学习了基本的es教程并在虚机上搭了一套es跑起来之后然后研究了es包中特别是conf文件夹中所有conf文件之后发现对于master节点和primaryreplication shard 还是有点confused，所以直接到官网学习这部分的doc)，贴上该doc的翻译
Translation：
1.介绍：
es的每个索引都是被分配到分片上，每个分片都会有多个副本，这些副本组成了一个replication group，它们在文档被添加或移除时会强制保持同步。如果没有保持同步，从两个不同的副本上读取的数据可能不一样。保持分片副本同步并从中提取读取的过程就是我们所说的数据复制模型。
es数据同步模型基于主备份模式并在微软研究院的PacificA这篇论文中有一个很好的描述。这个模型基于来自于replication group的单个副本，这个副本充当了主分片角色，而其他的副本就被成为副本分片。主分片作为所有索引操作的主要实体，它负责验证并确定这些索引操作是正确的。一旦某个索引操作被主分片接收，那么主分片也会负责复制这个操作到所有的副本分片。
本节的目的是对es复制模型进行高级的概述，并讨论它对写入和读取操作各种交互的影响

基本的写入模型
es中的所有索引操作首先都会通过路由被解析到replication group.这个机制一般是通过文档ID完成的。一旦replication group被确定了，操作将在内部转发到repicaltion group的主分片。主分片首先负责检查这个操作确定没有问题之后就会分发该操作到副本分片，由于副本分片可以拖机，所以主分片不需要分发到所有的副本分片。相反，es会保存一张含有那些应该接收到该操作的分片的列表。这个列表被称为in-sync列表，它由master节点保存。顾名思义，这个"好的"分片副本集合会保证处理那些需要向客户保证的索引和删除操作。主分片负责维持集群的不变性也因此不得不将所有的操作复制给到这个集合中的其他分片。
主分片主要处理以下基本事项：
1.检查进来的操作并在结构不符合预期的情况下拒绝
2.本地执行操作，eg：创建或删除指定的文档，它会检查这个文本并在不符合规则的情况下拒绝该操作（索引中的关键字太长无法放入Lucene中）
3.分发操作到其他处在in-sync集合中的其他副本分片，如何这个集合中的副本分片含有多个，就会异步执行
4.一旦所有的in-sync集合中的副本分片执行完毕并且成功返回给了主分片，主分片就会将成功的结果反馈给客户端

故障处理
在特殊情况下会导致错误发生，例如磁盘可能会损坏，节点可能会和其他节点失去练剑，或者有些错误配置导致副本分片上的操作失败尽管这些操作在主分片上是成功的。这些情况虽然是常见的，但是主分片不得不汇报这些情况。
一旦主分片自己坏掉了，该分片所在的节点会向master节点汇报这件事，此时索引操作将会等待master从副本分片中选择一个分片作为新的主分片(默认等待1分钟)，然后这个索引操作会被路由到这个新的主分片中。注意：master也会不断地监控节点的状态并可能决定主动降级主分片，这种情况一般发生在主分片所在的节点因为网络原因从集群中断开了。
一旦主分片在本地成功执行了该索引操作，接下来主分片在副本分片上执行操作的时候可能会处理潜在的故障。这可能会因为在副本分片上发生了真实的故障或者由于网络问题阻止了请求从主分片到达副本分片（或者阻止了从副本分片到主分片的响应）。所有以上几种情况都会导致一个相同的结果：in-sync中的某个副本分片没有执行应该需要被执行的操作。为了保证稳定性，主分片会发送一个消息到master节点要求将有问题的分片及时从in-sync集合中移除。只有这个有问题的副本分片被master节点从in-sync中移除，主分片才会确认执行成功并返回到客户端。注意：master节点同时也会让另外一个节点生成一个新的副本分片从而保证存储系统处于一个健康的状态。
主分片在分发操作给副本分片的时候也会通过副本分片来检测自己是否还是主分片，因为如果主分片由于网络原因失去了连接，在意识到它已经失去连接之前它还会继续向副本分片分发执行操作，但是副本分片会拒绝这些操作。当主分片接收到来自副本分片的拒绝反馈，它将会联系master节点并将接收到通知自己不再时主分片，然后它再将操作路由到新的主分片。
注意：如果没有副本分片怎么办？
这种情况在索引配置错误或者所有的副本分片都出现故障的时候是可能发生的，此时主分片在处理操作的时候没有任何其他分片的保证，这种情况看起来很糟糕。另一方面，主分片也不会让其他分片(没有)出现故障（也就是不能让自己出现故障，因为自己故障了整个单点集群就算挂了），但是会请求master节点检查自己，这样master节点就会知道只有一个好的主分片，从这个意义上我们可以说master不会让另外的节点成为新的主节点也因此所有的数据在主节点上都不会被丢失，当然因为只有一个主节点，物理机上存在的数据可能会丢失。

基础的读模式：
es读取有两个方面，一个方面是通过ID进行轻量级的读取，另一方面可以在消费大量的CPU性能的情况下通过非常复杂的繁重的聚合查询。
然而主备模式的美妙之处之一就是他会保持所有的副本分片都是平等的(除了飞行模式：目前不知道什么是飞行模式)。因此，in-sync中的一个节点就可以满足读操作
当一个节点接收到读请求时，这个节点负责将该请求分发到与这个读请求相关的分片上去，收集rep并将结果反馈给客户端。我们称这个节点为这个请求的协同节点。基础的流程如下：
1.将读请求分发给相关的分片。注意：由于大多数查找会发送一个或多个索引，它们一般需要从多个分片中读取，每一个代表整个数据的子集。
2.从这个相关分片的replication group中选一个活跃分片，这个活跃分片有可能是主分片也有可能是副本分片，默认情况下，es会简单地在分片中进行循环。
3.发送分片级别的读请求到被选中的分片中
4.整合结果并返回，注意如果是通过ID查找，只有一个分片会是相关分片也就可以略过这步了
故障处理：
当一个分片因为故障不能返回结果，协同节点会从相同的replicaiton group中选取一个分片然后发送分片级别的请求给到这个分片。同样的错误也会发生在没有分片副本的情况下。在有些情况下，eg:"_search"，es需要更快地返回结果时，它不会等待上面结果得到处理而是会直接返回部分结果（部分结果会被显示在返回体头部的_shards中）。

一些简单的含义：
以下基本流程中的每一个都决定了es时如何作为一个读写系统的行为的。更重要的是，因为读写请求都可以同步执行，所以这两个流程可能会交互在一起。这里有一些固有的含义：

高效读取
正常情况下，对每一个相关replication group执行一次读取操作
只有在失败的情况下，相同的分片才会有多个副本进行相同的查询
读取未被认证
由于主要的第一个索引在本地然后复制请求，因此并发读取可能在确
认之前已经看到了更改(关于这句话不明白什么意思)
默认两个副本
此模型可以容错，同时只保留两个数据副本，这与基于法定数量的系统形成对比，其中容错的最小副本数为3

故障
单个分片会拖慢整个索引速度
由于主分片在执行复制操作过程中会等待in-sync中所有副本的结果，如果一个分片速度很慢会导致整个索引速度下降，这是我们为上述阅读效率支付的代价。当然一个速度慢的分片也会拖累路由到它身上的搜索。

脏数据
一个主分片在本地执行写操作之后，如果此时该分片坏了，那么就不能让其他分片进行复制操作，从而导致脏数据。