1、es写数据过程
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都搞定之后，就返回响应结果给客户端。
2、写数据底层原理
1）数据写到primary shard后，写入内存buffer，同时将translog数据写到os cache中。注意，这时候数据是搜不到的。
2）每隔1s钟，或者快满了，内存buffer会将数据refresh到一个新的segment file中，同时清空内存buffer。只要内存buffer中有数据，每秒钟会产生一个新的segment file，但这时这个file文件是在os cache中，还没落在磁盘。如果buffer里面没有数据，就不会执行refresh操作形成空文件。
os cache即操作系统缓存，在数据写入磁盘文件之前，会先进入os cache。只要数据被r刷入os cache中，就可以被搜索到了。
3）每隔5s持久化translog到磁盘日志文件中。
4）重复1~3步骤，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。默认每隔30分钟会自动执行一次。
5）commit操作第一步：就是将buffer中现有数据refresh到os cache中去，清空buffer
6）commit操作第二步：将一个commit point写入磁盘文件，里面标识着这个commit point对应的所有segment file。
7）commit操作第三步：强行将os cache中目前所有的segment file都fsync到磁盘文件中去。
8）commit操作第四步：将translog清空，然后重建一个新的translog，此时commit操作完成。
9）整个commit过程，叫做flush操作。也可以通过api，手动执行flush，将os cache中的数据fsync强刷到磁盘，记录一个commit point，清空translog日志文件。
3、ES删除数据原理
1）将需要删除的数据写入.del文件，将这条数据标识为deleted状态，那么搜索的时候根据.del文件就知道这个doc被删除了，逻辑删除。
2）上面提到，buffer每次refresh就会产生一个segment file，所以1秒钟就会产生一个segment file，segment file会越来越多，会定期执行merge。
3）每次merge时，会将多个segment file合并成一个，同时会将标识为deleted的数据给物理删除掉，然后将新的segment file写入磁盘，这里会写一个commit point，标识所有新的segment file，然后打开segment file供搜索使用，同时删除旧的segment file。
4、es读数据过程
当写入了某个document，会自动给这个数据分配一个全局唯一的doc id，也可以指定doc id为订单id或用户id。然后根据doc id进行hash路由到对应的primary shard上面。
查询时可以根据doc id来查询，根据doc id进行hash，判断出来当时把doc id分配到了哪个shard上面去。具体步骤如下：
1）客户端发送请求到任意一个node，该节点成为coordinate node。
2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡。
3）接收请求的node返回document给coordinate node
4）coordinate node返回document给客户端
5、删除数据时为何不直接物理删除
因为每删一条数据都从segment file中删，效率会太低。
6、commit操作过程
commit操作：1、写commit point；2、将os cache数据fsync强刷到磁盘上去；3、清空translog日志文件
7、translog日志文件作用
translog日志文件的作用是什么？就是在你执行commit操作之前，数据要么是停留在buffer中，要么是停留在os cache中，无论是buffer还是os cache都是内存，一旦这台机器死了，内存中的数据就全丢了。
所以需要将数据对应的操作写入一个专门的日志文件，translog日志文件中，一旦此时机器宕机，再次重启的时候，es会自动读取translog日志文件中的数据，恢复到内存buffer和os cache中去。
8、es数据丢失问题
1）es是准实时的，数据写入1秒后才可以搜到。（这个不算数据丢失）
2）translog是先写os cache，默认每隔5秒刷一次到磁盘。这5秒，数据只停留在buffer、translog os cache、segment file os cache中，而不在磁盘上。此时如果宕机，会导致5秒的数据丢失。如果希望绝对不能丢数据，可以设置个参数，每次写入一条数据，同时写入磁盘上的translog，但这会导致写性能、写吞吐量下降一个数量级。
9、es搜索数据过程
es最强大的就是做全文检索。
1）客户端发送请求到一个coordinate node
2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard。
3）query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端
10、es写流程有4个核心概念
refresh、flush、translog、merge
11、总结
1）每隔1秒钟，将内存buffer中的数据刷到os cache中。
2）每往shard primary中写入一条数据，shard primary就会往os cache写入一条translog。每隔5s会将os cache钟的translog数据写到磁盘的translog日志文件。
3）每隔30分钟会将os cache中的数据刷入segment file中（在磁盘上）。
4）es是准实时的，NRT，near real-time。默认是每隔1秒refresh一次的，所以写入的数据1秒之后才能被看到。
5）可以通过es的restful api或者java api，手动执行一次refresh操作，将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。
12、一张图总结
