Redis Cluster is not able to guarantee strong consistency. In practical terms this means that under certain conditions it is possible that Redis Cluster will lose writes that were acknowledged by the system to the client.
To improve the resiliency of writes to the system, indexing operations can be configured to wait for a certain number of active shard copies before proceeding with the operation. If the requisite number of active shard copies are not available, then the write operation must wait and retry, until either the requisite shard copies have started or a timeout occurs.
但是这个检查并写入并不是原子操作，因此有下面一段话：
It is important to note that this setting greatly reduces the chances of the write operation not writing to the requisite number of shard copies, but it does not completely eliminate the possibility, because this check occurs before the write operation commences.
5 个回复
hapjin
赞同来自: wkdx 、novia 、wajika
而对于ES来说，客户端向ES 索引 写一篇文档，根据文档ID(如果不指定会自动生成)murmur3 哈希选择该索引的某个primary shard，将这篇文档写入到primary shard上，然后再将文档同步到replica，这里的同步过程：我的理解是，同步给 In-sync 集合里面的副本。这样，当insync集合里面的replica都写入成功后，各个replica向primary shard返回确认，当primary shard 所在节点认为in-sync副本列表集合里面的rpelica都写入成功后，primary shard再向ES 客户端返回写入成功的响应。由于 replica 分布在不同的ES节点上，当某台节点宕机，就可以通过"副本"保证了数据不丢失。参考：ES replication models
关于这个 in-sync 同步副本列表集合，可以参考 Kafka 的 min.insync.replica 参数的意义，二者原理是相似的。至于哪些分片 属于 in-sync 集合，这个是集群的"元数据"信息，由ES的master节点来维护，由ZenDiscovery来保证一致性。
至于 wait_for_active_shards 这个参数，它只是在请求前检查活跃的 分片数量，当活跃分片的数量大于等于wait_for_active_shards，就具有 写文档 的资格:
但是这个检查并写入并不是原子操作，因此有下面一段话：
参考：index-wait-for-active-shards
novia - 1&0
赞同来自: byx313
你是指异步复制吗？这样的话，主分片已经返回给客户端，如果复制失败了，那数据就会不一致了。早起es好像就是用的这个机制，后面改为同步了
code4j - coder github: https://github.com/rpgmakervx
赞同来自:
个人的理解是这样：
其实你说的主分片复制到副本 我理解是一种异步的流程。而这么做如果复制失败了副本和主分片就不一样了。而elasticsearch有一个配置是确保有多少分片同步到数据后才结束一次写流程的，所以异步的方式应该是不满足这个需求的，需要再一次写流程中进行流量转发，等待请求完成。
byx313 - BLOG:https://www.jianshu.com/u/43fd06f9589c
赞同来自:
你的意思是只要写入p shard就算成功，然后集群再异步同步？
caizhongao
赞同来自: