第10单元-ES聚合查询-05-es的source源如何同步的原理

项目需求：

对于几千万的注册用户，发布的朋友圈的数据是海量的，需要能够搜索，同时也要完成可用性。

需求描述：

对于几千万的注册用户，发布的朋友圈的数据是海量的，需要能够搜索，同时也要完成可用性。第一个要求是大量的朋友圈数据，需要存储到分布式集群中，给出解决方案。另外，在服务器突然宕机的情况，仍然能够保障搜索业务不中断，不少数据。同时要充分利用底层的数据同步原理，提高数据的稳定性。

路由文档到分片
1、文档路由到分片上：一个索引由多个分片构成，当添加（删除、修改）一个文档时，Elasticsearch就需要决定这个文档存储在哪个分片上，这个过程就称为数据路由（routing）。
2、路由算法：

shard = hash(routing) % number_of_primary_shards

示例：一个索引，3个 primary shard

• 每次增删改查时，都有一个 routing 值，默认是文档的 _id 的值。
• 对这个 routing 值使用 hash 函数进行计算。
• 计算出的值再和主分片个数取余数，余数的取值范围永远是（0 ~ number_of_primary_shards - 1）之间，文档就在对应的 shard 上。routing 值默认是文档的 _id 的值，也可以手动指定一个值，手动指定对于负载均衡以及提升批量读取的性能都有帮助。
• 正是这种路由机制，导致了 primary shard（主分片）的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题，部分数据将无法被检索

增删改查时主分片与复制分片如何交互
假设有三个节点的集群。它包含一个叫做bblogs的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上，所以我们的集群是这样的：

我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。下面的例子中，我们将发送所有请求给Node 1，这个节点我们将会称之为请求节点(requesting node)。

新建、 索引与删除一个文档
新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。

1、客户端发送了一个索引或者删除的请求给node 1。
2、node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中（node 1知道shard 0的primary shard位于node 3节点上），node 1会把这个请求转发到node 3。
3、node 3在shard 0 的primary shard上执行请求。如果请求执行成功，它node 3将并行地将该请求发给shard 0的其余所有replica shard上，也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求，那么将会向node 3回复一个成功确认，当node 3收到了所有replica shard的确认信息后，则最后向用户返回一个Success的消息。
客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。此时修改已经生效。

有很多可选的请求参数允许你更改这一过程。你可能想牺牲一些安全来提高性能。这一选项很少使用因为Elasticsearch已经足够快，下面将一一阐述。

replication

• 复制默认的值是 sync（同步操作）。这将导致主分片得到复制分片的成功响应后才返回。
• 当 replication 设置为 async（异步操作），请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。
• 该选项不建议使用。默认的sync复制允许Elasticsearch强制反馈传输。async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。

参考文章

• https://blog.csdn.net/zx711166/article/details/82017439