es如何知道哪个分片应该存储这个文档？
当我们创建一个新的文档，es怎么知道它应该存在分片1还是2？
处理不是随机的，因为我们将来还需要检索这个文档，事实上，由一个非常简单的公式计算。
shard = hash(routing) % number_of_primary_shards
routing值是一个字符串，默认是文档的_id,但是也可以是其它值
这个解释了，为什么主分片的个数仅仅在索引创建时决定而不能再改变了
如果改变了，所有的之前的值都无效，文档也找不到了。
所有的文档API(
get
, index, delete, bulk, update and mget)接受一个路由参数，
这个参数可以用来决定文档到分片的映射
http://my.oschina.net/qiangzigege/blog/264438
为了解释的目的，我们想象一下，我们有一个集群，有3个节点，
它包含了一个blogs索引，有2个主分片，
每个主分片有2个从分片备份，一个主分片的从分片不会放在主分片所在节点上，
所以，我们的集群看起来如图8所示，
Figure 8. A cluster with three nodes and one index
Figure 8. 集群，3个节点，1个索引
我们可以发送请求至任意一个节点，每个节点都可以服务请求，
每个节点知道每个文档的位置，可以路由请求给正确的节点，
我们发送所有的请求给节点1，称之为请求节点。
发送请求，我们可以轮流发送给所有的节点，实现轮询达到负载均衡的目的。
http://my.oschina.net/qiangzigege/blog/264441
创建，索引和删除请求是写操作，必须在主分片上成功完成，然后才能复制到相关的从分片。
Figure 9. Creating, indexing or deleting a single document
图9：创建，索引和删除一个文档。
如图9所示，流程，
1）客户发送一个创建，索引或者删除的请求到节点1.
2）节点使用文档的_id来决定文档属于分片0转发请求给节点3.
3）节点3执行请求，如果成功，并发的转发请求给它的从分片。一旦所有从分片报告成功，
节点3报告成功给请求节点，请求节点报告成功给客户端。
一旦客户端接受到了成功的响应，文档改变已经在所有的主从分片上执行了，客户的改变是安全的。
这里有很多可选请求参数来影响这个过程，不过很少使用因为es已经很快。
replication
默认的主从同步是同步执行的，引起主分片来等待从分片的成功响应。
如果你设置主从同步是异步的，它将返回成功给客户端，然后仍然转发请求给从分片，
但是你不知道从分片成功还是失败。
建议使用默认的同步策略。
consistency 一致性
主分片需要quorum或者说是最大分片备份数（一份备份可以是主分片，也可以是从分片）
用于写操作前的一致性校验。
quorum = int((主分片+从分片数量)/2)+1
这里的“从分片数量”是指 索引设置中定义的值，而非当前系统中活跃的分片数量
quorum的值可以是主分片个数、全部分片个数（主+从）、默认的quorum、分片备份的最大值
如果定义了一个索引有3个从分片， 则quorum=int(（主分片+3从分片）/2)+1=3
但如果只开启了2个节点，则没有足够的活跃节点来支持完成写操作
超时
如果没有足够的从分片可用怎么办，es等待，默认等待1分钟，你可以使用timeout参数来设置。
100是100 毫秒，30s 是30秒。
一个新的索引默认有1个从分片 http://my.oschina.net/qiangzigege/blog/264460
一个文档可以从主分片或者任何一个从分片读取。
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<
span
></
span
> Figure 10. 检索一个文档
下面我们列出了检索文档的顺序。
1）客户端发请求给节点1.
2）节点通过_id知道文档属于分片0.
分片0在3个机器上都有，这种情形下，转发请求给节点2.
3）节点2返回文档给节点1.
对于读请求，请求节点会选择一个不同的节点来达到负载均衡，。。
轮询所有的分片。
有可能文档已经被索引在主分片上，但是还没有复制到从分片，
这种情况下，一个从分片会报告文档不存在，此时主分片会返回文档。
|
更新API包含读和写的过程。
1)客户端发送更新请求给节点1.
2）转发请求给节点3.
3）节点3检索文档，改变文档，重新索引文档，如果期间文档被别人修改了，则重新尝试直到达到最大次数。
4）如果节点3更新文档成功，转发新的文档给从分片，一旦从分片报告成功，节点3报告成功给请求节点。
注意：这里主从间交互的是更新过的文档，而不是转发请求。
|
http://my.oschina.net/qiangzigege/blog/264471