这篇文章给大家分享的是有关Elasticsearch中分布式的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

可用性和扩展性

高可用

服务可用性—允许有节点停止服务

数据可用性—部分节点丢失，不会丢失数据

可扩展性

请求量提升/数据的不断增长 ，可以实现水平扩展

节点

节点是一个es的实例

本质上就是一个JAVA进程

分片和副本

• 分片特性
  分片存储部分数据，可以分布任意节点上；
  分片在创建索引时指定且不许更改，默认为5个；
  分片有主副之分，四线数据高可用；
  副本分片的数据由主分片同步，提高读取吞吐量；

• 实例操作

集群设置：node1/node2/node3，且node1为主节点；创建索引：PUT test_index{  "settings":{    "number_of_shards":3, ##分片数为3    "number_of_replicas":1 ##副本数为1  }}分片和副本分布：node1-p0 r1 node2-p1 r2 node3-p2 r0

• 问题

1-在上述的分布式环境中，增加节点数是否提高test_index的数据容量？不能，因为只有3个分片，且已经分布在3台节点上，新增节点无法使用；2-增加副本数是否可以提高test_index的读取吞吐量？不能，新增的副本依然分布在三个节点上，利用同样资源；3-建议：分片数过小，无法通过新增节点实现水平扩容；分片数过大，导致一个节点上存在多个分片，造成资源浪费；

集群状态

• 集群状态
  Green:健康状态，所有主副分片正常分配；
  Yellow:主分片分配正常，但是副本分片分配不正常；
  Red:存在主分片未分配；

• 故障转移

文档分布式存储

• 文档到分片的映射
  文档在分片中尽量分布均匀，充分利用资源；

脑裂问题

• 脑裂
  同一个集群中两个master，维护不同的cluster state，网络恢复后无法选择正确的master；

• 实例操作

文档搜索实时性

• refresh
  segment写入磁盘耗时，借助文件系统缓存特性，将segment缓存并开放搜索实时性，称为refresh；
  refresh之前将文档存储到一个buffer中，refresh时将buffer中的文档清空生成segment；

• translog
  解决内存中segment未写入磁盘就发生宕机问题；
  文档写入buffer时，同时将请求操作写入translog，6.x默认每个请求都落盘；
  Es启动时检查translog文件，并从中恢复数据；
  

• flush
  负责将内存中的segmet写入磁盘；
  将index buffer清空，其中的文档生成一个新的segment，相当于一个refresh操作；
  更新commit point并写入磁盘；
  执行fsync操作，将内存中的segment写入磁盘；
  删除旧的translog日志；
  

• 删除与更新文档
  segment一旦创建就不能更改，如何删除与更新文档呢?

• segment merge
  Es会定时在后台进行segment merge操作，减少segment的数量；
  通过force_merge api实现手动强制做segment merge；

感谢各位的阅读！关于“Elasticsearch中分布式的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！