1、分片的基本认知
Shard即数据分片，是ES的数据载体。在ES中数据分为primary shard（主分片）和replica shard（副本分片），每一个primary承载单个索引的一部分数据，分布于各个节点，replica为某个primary的副本，即备份。分片分配的原则是尽量均匀的分配在集群中的各个节点，以最大程度降低部分shard在出现意外时对整个集群乃至服务造成的影响。
每个分片就是一个Lucene的实例，具有完整的功能。
2、分片创建策略
分片产生的目的是为了实现分布式，而分布式的好处之一就是实现“高可用性”（还包括高性能如提高吞吐量等会再后面内容展开讲），分片的分配策略极大程度上都是围绕如何提高可用性而来的，如分片分配感知、强制感知等。
互联网开发没有“银弹”，分片的数量分配也没有适用于所有场景的最佳值，创建分片策略的最佳方法是使用您在生产中看到的相同查询和索引负载在生产硬件上对生产数据进行基准测试。分片的分配策略主要从两个指标来衡量：即数量和单个分片的大小。
3、分片分配的基本策略
- ES使用数据分片（shard）来提高服务的可用性，将数据分散保存在不同的节点上以降低当单个节点发生故障时对数据完整性的影响，同时使用副本（repiica）来保证数据的完整性。关于分片的默认分配策略，在7.x之前，默认5个primary shard，每个primary shard默认分配一个replica，即5主1副，而7.x之后，默认1主1副
- ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。
- Paimary只能在索引创建时配置数量，而replica可以在任何时间分配，并且primary支持读和写操作，而replica只支持客户端的读取操作，数据由es自动管理，从primary同步。
- ES不允许Primary和它的Replica放在同一个节点中，并且同一个节点不接受完全相同的两个Replica
- 同一个节点允许多个索引的分片同时存在。
4、分片的数量分配多少
- 避免分片过多：大多数搜索会命中多个分片。每个分片在单个 CPU 线程上运行搜索。虽然分片可以运行多个并发搜索，但跨大量分片的搜索会耗尽节点的搜索线程池。这会导致低吞吐量和缓慢的搜索速度。
- 分片越少越好：每个分片都使用内存和 CPU 资源。在大多数情况下，一小组大分片比许多小分片使用更少的资源。
5、分片的大小决策
- 分片的合理容量：10GB-50GB。虽然不是硬性限制，但 10GB 到 50GB 之间的分片往往效果很好。根据网络和用例，也许可以使用更大的分片。在索引的生命周期管理中，一般设置50GB为单个索引的最大阈值。
- 堆内存容量和分片数量的关联：小于20分片/每GB堆内存，一个节点可以容纳的分片数量与节点的堆内存成正比。例如，一个拥有 30GB 堆内存的节点最多应该有 600 个分片。如果节点超过每 GB 20 个分片，考虑添加另一个节点。
- 查询当前节点堆内存大小：
GET _cat/nodes?v=true&h=heap.current
- 避免重负载节点：如果分配给特定节点的分片过多，会造成当前节点为重负载节点
6、重要的配置
6.1 自定义属性
node.attr.{attribute}
如何查看节点属性？
GET _cat/nodeattrs?v
6.2 索引级配置
index.routing.allocation.include.{attribute}：表示索引可以分配在包含多个值中其中一个的节点上。
index.routing.allocation.require.{attribute}：表示索引要分配在包含索引指定值的节点上（通常一般设置一个值）。
index.routing.allocation.exclude.{attribute}：表示索引只能分配在不包含所有指定值的节点上。
//索引创建之前执行 PUT <index_name> { "settings": { "number_of_shards": 3, "number_of_replicas": 1, "index.routing.allocation.include._name": "node1" } }
6.3 集群级配置
elasticsearch修改集群范围设置提供两种方式，
- persistent：永久性修改，persistent相关的修改保存在了
/path.data/cluster.name/nodes/0/_state/global-n.st，如果想删除设置，删除此文件即可。 - transient：集群重启后失效。
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.awareness.attributes": "rack_id" } }
7、索引分片分配：Index Shard Allocation
7.1 分片均衡策略：shard rebalance
当集群在每个节点上具有相同数量的分片而没有集中在任何节点上的任何索引的分片时，集群是平衡的。Elasticsearch 运行一个称为rebalancing 的自动过程，它在集群中的节点之间移动分片以改善其平衡。重新平衡遵循所有其他分片分配规则，例如分配过滤和强制意识，这可能会阻止它完全平衡集群。在这种情况下，重新平衡会努力在您配置的规则内实现最平衡的集群。如果您使用数据层然后 Elasticsearch 会自动应用分配过滤规则将每个分片放置在适当的层中。这些规则意味着平衡器在每一层内独立工作。
cluster.routing.rebalance.enable
(动态) 为特定类型的分片启用或禁用重新平衡：
all -（默认）允许对所有类型的分片进行分片平衡。
primaries - 只允许主分片的分片平衡。
replicas - 仅允许对副本分片进行分片平衡。
none - 任何索引都不允许进行任何类型的分片平衡。
cluster.routing.allocation.allow_rebalance
(动态) 指定何时允许分片重新平衡：
always - 始终允许重新平衡。
indices_primaries_active - 仅当集群中的所有主节点都已分配时。
indices_all_active -（默认）仅当集群中的所有分片（主分片和副本）都被分配时。
7.2 延迟分配策略（默认1m）：
当节点出于任何原因（有意或无意）离开集群时，主节点会做出以下反应
将副本分片提升为主分片以替换节点上的任何主分片。
分配副本分片以替换丢失的副本（假设有足够的节点）。
在其余节点之间均匀地重新平衡分片。
这些操作旨在通过确保尽快完全复制每个分片来保护集群免受数据丢失。即使我们在节点级别和集群级别限制并发恢复 ，这种“分片洗牌”仍然会给集群带来很多额外的负载，如果丢失的节点可能很快就会返回，这可能是不必要的
7.3 分片过滤：即（Shard allocation filtering，控制那个分片分配给哪个节点）。
index.routing.allocation.include.{attribute}：表示索引可以分配在包含多个值中其中一个的至少节点上。
index.routing.allocation.require.{attribute}：表示索引要分配在包含索引指定值的节点上（通常一般设置一个值）。
index.routing.allocation.exclude.{attribute}：表示索引只能分配在不包含所有指定值的节点上。
7.4 分片分配感知策略：Shard Allocation Awareness
Shard Allocation Awareness的设计初衷是为了提高服务的可用性，通过自定义节点属性作为感知属性，让 Elasticsearch 在分配分片时将物理硬件配置考虑在内。如果 Elasticsearch 知道哪些节点位于同一物理服务器上、同一机架中或同一区域中，则它可以分离主副本分片，以最大程度地降低在发生故障时丢失数据的风险。
启用分片感知策略
配置节点属性
node.attr.rack_id: rack1
通过以下设置告诉主节点在分配分片的时候需要考虑哪些属性。这些信息会保存在每个候选节点的集群状态信息中
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.awareness.attributes": "rack_id" } }
7.5 强制感知策略：Forced awareness
默认情况下，如果一个区域发生故障，Elasticsearch 会将所有故障的副本分片分配给其他区域。但是剩余区域可能没有足够的性能冗余来承载这些分片。
为了防止在发生故障时单个位置过载，您可以设置为cluster.routing.allocation.awareness.force不分配副本，直到另一个位置的节点可用。
部署强制感知策略
设置强制感知策略，告诉主节点当前通过某个属性来划分区域，并且告知区域有哪些值
cluster.routing.allocation.awareness.attributes: zone cluster.routing.allocation.awareness.force.zone.values: zone1,zone2
