一、ElasticSearch的容错机制
以9个shard，3个节点为例：
1.如果master node 宕机，此时不是所有的primary shard都是Active status，所以此时的集群状态是red。
容错处理的第一步:是选举一台服务器作为master
容错处理的第二步:新选举出的master会把挂掉的primary shard的某个replica shard 提升为primary shard,此时集群的状态为yellow，因为少了一个replica shard，并不是所有的replica shard都是active status
容错处理的第三步：重启故障机，新master会把所有的副本都复制一份到该节点上，（同步一下宕机后发生的修改），此时集群的状态为green，因为所有的primary shard和replica shard都是Active status
二、改变文档内容原理解析（Put是全部替换 post是部分替换）
三、文档增删改内部原理
1:发送增删改请求时，可以选择任意一个节点，该节点就成了协调节点(coordinating node)
2.协调节点使用路由算法进行路由，然后将请求转到primary shard所在节点，该节点处理请求，并把数据同步到它的replica shard
3.协调节点对客户端做出响应
四、文档查询内部原理
第一步：查询请求发给任意一个节点，该节点就成了coordinating node，该节点使用路由算法算出文档所在的primary shard
第二步：协调节点把请求转发给primary shard也可以转发给replica shard(使用轮询调度算法(Round-Robin Scheduling，把请求平均分配至primary shard 和replica shard)
第三步：处理请求的节点把结果返回给协调节点，协调节点再返回给应用程序
特殊情况：请求的文档还在建立索引的过程中，primary shard上存在，但replica shar上不存在，但是请求被转发到了replica shard上，这时就会提示找不到文档