这是我参与11月更文挑战的第21天，活动详情查看：2021最后一次更文挑战
一、分布式系统的可用性与扩展性
- 高可用性
- 服务可用性 - 允许有节点停止服务
- 数据可用性 - 部分节点丢失，不会丢失数据
- 可扩展性
- 请求量提升 / 数据的不断增长 （将数据分布到所有节点上）
二、分布式特性
- Elasticsearch的分布式架构的好处
- 存储的水平扩容
- 提高系统的可用性，部分节点停止服务，整个集群的服务不受影响
- Elasticsearch的分布式架构
- 不同的集群通过不同的名字来区分，默认名字 “elasticsearch”
- 通过配置文件修改，或者在命令行中 -E cluster.name=budong 进行设定
- 一个集群可以有一个或者多个节点
三、节点
- 节点是一个Elasticsearch的实例
- 本质就是一个Java进程
- 一台机器可以运行多个Elasticsearch进程，但是生产环境一般建议一台机器上只运行一个Elasticsearch 实例
- 每一个节点都有名字，通过配置文件配置，或者启动时候 - E node.name=node1指定
- 每一个节点在启动之后，会分配一个UID，保存在data目录下
Master-eligible nodes 和 Master Node
- 每个节点启动后，默认就是一个Master eligible 节点
- 可以设置node.master: false禁止
- Master- -eligible节点可以参加选主流程，成为Master节点
- 当第一个节点启动时候，它会将自己选举成Master节点
- 每个节点上都保存了集群的状态，只有Master节点才能修改集群的状态信息
- 集群状态(Cluster State) ，维护了一个集群中，必要的信息
- 所有的节点信息
- 所有的索引和其相关的Mapping与Setting 信息
- 分片的路由信息
- 任意节点都能修改信息会导致数据的不一致性
- 集群状态(Cluster State) ，维护了一个集群中，必要的信息
Data Node & Coordinating Node
- Data Node
- 可以保存数据的节点，叫做Data Node。负责保存分片数据。当集群无法保存现有数据时，可以增加一个数据节点来解决这个问题。Data Node在数据扩展上起到了至关重要的作用
- Coordinating Node
- 负责接受Client的请求，将请求分发到合适的节点，最终把结果汇集到一起
- 每个节点默认都起到了Coordinating Node的职责
其他的节点类型
- Hot & Warm Node
- 不同硬件配置的DataNode,用来实现Hot&Warm架构，降低集群部署的成本
- Machine Learming Node
- 负责跑机器学习的Job,用来做异常检测
- Tribe Node
- (5.3开始使用Cross Cluster Serarch) Tribe Node连接到不同的Elasticsearch 集群,并且支持将这些集群当成一个单 独的集群处理
四、分片（Primary Shard & Replica Shard）
- 主分片，用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上
- 一个分片是一一个运行的Lucene的实例
- 主分片数在索引创建时指定，后续不允许修改，除非Reindex
- 副本，用以解决数据高可用的问题。分片是主分片的拷贝
- 副本分片数，可以动态题调整
- 增加副本数，还可以在一定程度上提高服务的可用性(读取的吞吐)
一个三节点的集群中，blogs索引的分片分布情况
PUT /blogs
{
"settings": {
”number_of_sharads“ : 3,
"number_of_replicas" : 1
}
}
- number_of_sharads：代表主分片数3个
- number_of_replicas：副本只有一份
- 当有数据进来时，Elasticsearch内部把主分片分散在三个节点上，将每个分片的副本分散在其他节点上
- 当节点有故障时，Elasticsearch会有故障转移的机制
思考：增加一个节点或改大主分片数对系统的影响？
我们接着往下看。
分片的设定
- 对于生产环境中分片的设定，需要提前做好容量规划
- 分片数设置过小
- 导致后续无法增加节点实现水平护展
- 单个分片的数据量太大，导致数据重新分配耗时
- 分片数设置过大，7.0 开始，默认主分片设置成1，解决了over-sharding的问题
- 影响搜索结果的相关性打分，影响统计结果的准确性
- 单个节点上过多的分片，会导致资源浪费，同时也会影响性能
- 分片数设置过小
