原文转载：ES分布式架构及底层原理
es分布式架构原理
elasticsearch设计的理念就是分布式搜索引擎，底层实现还是基于Lucene的，核心思想是在多态机器上启动多个es进程实例，组成一个es集群。一下是es的几个概念：
- 接近实时
es是一个接近实时的搜索平台，这就意味着，从索引一个文档直到文档能够被搜索到有一个轻微的延迟 - 集群（cluster）
一个集群有多个节点（服务器）组成，通过所有的节点一起保存你的全部数据并且通过联合索引和搜索功能的节点的集合，每一个集群有一个唯一的名称标识 - 节点（node）
一个节点就是一个单一的服务器，是你的集群的一部分，存储数据，并且参与集群和搜索功能，一个节点可以通过配置特定的名称来加入特定的集群，在一个集群中，你想启动多少个节点就可以启动多少个节点。 - 索引（index）
一个索引就是还有某些共有特性的文档的集合，一个索引被一个名称唯一标识，并且这个名称被用于索引通过文档去执行搜索，更新和删除操作。 - 类型（type）
type 在6.0.0已经不赞成使用
文档（document）
一个文档是一个基本的搜索单元
总结：
es中，存储数据的基本单位就是索引，比如说es中存储了一些订单系统的销售数据，就因该在es中创建一个索引，order—index，所有的销售数据就会都写到这个索引里面去，一个索引就像数据库。而type就相当于每一张表，
一个index里面可以有多个type，而mapping就相当于表的结构定义，定义了什么字段类型等，你往index的一个type里添加一行数据就叫做一个document，每一个document有多个filed，每一个filed就代表这个document的一个字段的值。
分片（shards）
在一个搜索里存储的数据，潜在的情况下可能会超过单个节点的硬件的存储限制，为了解决这个问题，elasticsearch便提供了分片的功能，它可以将索引划分为多个分片，当你创建一个索引的时候，你就可以简单的定义你想要的分片的数量，每一个分片本身是一个全功能的完全独立的索引，可以部署到集群中的任何一个节点。分片的两个总要原因：
（1）它允许你水平切分你的内容卷
（2）它允许通过分片来分布和并执行操作来应对日益增长的执行量
复制（replica）
在一个网络情况下，故障可能会随时发生，有一个故障恢复机制是必须的，为了达到这个目的，ES允许你制作一个或多个拷贝放入一个叫做复制分片或短暂的复制品中。复制对于以下两个主要原因很重要
（1）高可用。它提供了高可用的以来防止分片或者节点宕机，为此，一个非常重要的注意点就是绝对不要讲一个分片的拷贝放在跟这个分片相同的机器上。
（2）高并发。它允许你的分片可以提供超出自身吞吐量的搜索服务，搜索行为可以在分片所有的拷贝中并行执行。
总之，一个完整的流程就是，ES客户端将一份数据写入primary shard,它会将分成成对的shard分片，并将数据进行复制，ES客户端取数据的时候就会在replica或primary 的shard中去读。ES集群有多个节点，会自动选举一个节点为master节点，这个master节点其实就是干一些管理类的操作，比如维护元数据，负责切换primary shard 和replica shard的身份之类的，要是master节点宕机了，那么就会重新选举下一个节点为master为节点。如果时非master宕机了，那么就会有master节点，让那个宕机的节点上的primary shard的身份转移到replica shard上，如果修复了宕机的那台机器，重启之后，master节点就会控制将缺失的replica shard 分配过去，同步后续的修改工作，让集群恢复正常。
在海量数据中怎样提高效率
- filesystem cache
ES的搜索引擎是严重的依赖底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的index segment file 索引数据文件 - 数据预热
对于那些你觉得比较热的数据，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问以下，让数据进入filesystem cache里面去，这样期待下次访问的时候，性能会更好一些。 - 冷热分离
关于ES的性能优化，数据拆分，将大量的搜索不到的字段，拆分到别的存储中去，这个类似于MySQL的分库分表的垂直才分。
- document的模型设计
不要在搜索的时候去执行各种复杂的操作，尽量在document模型设计的时候，写入的时候就完成了，另外对于一些复杂的操作，尽量要避免
- 分页性能优化
翻页的时候，翻得越深，每个shard返回的数据越多，而且协调节点处理的时间越长，当然是用scroll，scroll会一次性的生成所有数据的一个快照，然后每次翻页都是通过移动游标完成的。 api 只是在一页一页的往后翻
