分布式引擎-es

1.es的分布式架构原理能说一下么（es是如何实现分布式的啊）？

存储数据的基本单位是索引，比如你现在在es中存一些订单数据，你就应该在es中创建一个索引，order_idx,一个索引差不多就是相当于mysql中的一张表。index -> type -> mapping -> document -> field。

index：mysql里面一张表

type：详单于订单分类。例如一个是实物商品订单type，一个是虚拟商品订单type；很多情况下，一个index里可能就一个type，但是确实如果说是一个index里有多个type的情况，你可以认为index是一个类别的表，具体的每个type代表了具体的一个mysql中的表

mapping就是这个type的表结构定义，往index的mapping里面写一条数据就叫做document。每个document有多个field，每个field就代码这个document的一个字段的值。

【具体存储方式】shard上存储。每个shard会做备份。primary shared做写入数据，会将数据同步到其他replica shard上去。

【集群】多个节点会选举出一个master节点。这个节点是负责管理工作。维护索引元数据，切换primary shard和replica shard身份。master宕机了，会重新选举出一个master。如果非master节点宕机了，转移primary shard的身份到其他的机器上的。恢复了之后会把空缺的replica shard分配过去，同步后续修改的数据。

2.es写入数据的工作原理是什么啊？es查询数据的工作原理是什么啊？

a)写的过程

1）客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）

2）coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）

3）实际的node上的primary shard处理请求，然后将数据同步到replica node

4）coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端

b)读数据

写入了一条document，这个document会自动分配一个全局的唯一的id，可以通过docid进行hash路由到对应的primary shared上面去。也可以指定doc id，比如用户订单id，用户id

1）客户端发送请求到任意一个node，成为coordinate node

2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡

3）接收请求的node返回document给coordinate node

c) es搜索数据过程

1）客户端发送请求到一个coordinate node

2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard也可以

3）query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果

4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端

 

写数据库原理：

写入buffer以及translog日志。写数据的时候先写到os cache中，每隔一秒钟写入一个新的segmentfile，这时候就可以进行查询了。这个也可以手动调用es的restfulapi活着java api，手动执行refresh。当写入不断增加的话，translog文件会越来越大，达到一定程度会执行commit操作。1.写commit point 2.将os cathe数据fsync强刷到磁盘中去。3.清空translog日志

注意：1.translog日志也是写在osche中，默认5秒钟刷到一次到磁盘中。如果宕机会丢失数据，可以设置每次写操作都会异步到磁盘中，但是性能会差很多。如果需要数据一定不丢失，可以写入buffer的时候，同时写入磁盘上的translog。2.segment文件多了会进行merge操作。

四个核心：refresh、flush、translog、merge

3.es在数据量很大的情况下（数十亿级别）如何提高查询效率啊？

  （1）性能优化的杀手锏——filesystem cache

       a).让写入es的数据小于等于，或者是略微大于es的filesystem cache的内存容量

       b).搜索几个关键字。如id,name，查出来的数据去hbase中获取。

 （2）数据预热

       对于那些你觉得比较热的，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问一下，让数据进入filesystem cache里面去。这样期待下次别人访问的时候，一定性能会好一些。

（3）冷热分离

     将经常用的数据放到一个索引中。确保热数据在预热之后，保留在filesystem os cache。

（4）document模型设计

         在放到es中就进行了联合查询，查询出来的结果在程序中执行。

 （5）分页性能优化

        1）不允许深度分页/默认深度分页性能很惨

        2）类似于app里的推荐商品不断下拉出来一页一页的（scroll api）

4.es生产集群的部署架构是什么？每个索引的数据量大概有多少？每个索引大概有多少个分片？

（1）es生产集群我们部署了5台机器，每台机器是6核64G的，集群总内存是320G

（2）我们es集群的日增量数据大概是2000万条，每天日增量数据大概是500MB，每月增量数据大概是6亿，15G。目前系统已经运行了几个月，现在es集群里数据总量大概是100G左右。

（3）目前线上有5个索引（这个结合你们自己业务来，看看自己有哪些数据可以放es的），每个索引的数据量大概是20G，所以这个数据量之内，我们每个索引分配的是8个shard，比默认的5个shard多了3个shard。