这篇文章都是基于巨人的肩上的，看了感觉比较容易理解，有补充可以提出。
持久化流程：es是基于lucene上的
1.lucene持久化原理：一个文档分词并持久化成倒排索引，倒排索引不可变，不可变所以不锁，长期在缓存也不用变，可压缩
https://www.elastic.co/guide/cn/elasticsearch/guide/current/making-text-searchable.html
2.lucene更新索引的流程：
https://www.elastic.co/guide/cn/elasticsearch/guide/current/dynamic-indices.html
lucene是按段搜索，一个段 = 一个倒排索引（后期多个段会合并，这里说的是新的段）
lucene索引=所有段（倒排索引）+提交点(列出所有已知段的文件)
一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个 Elasticsearch 索引是分片的集合，即一个es索引包含多个lucene索引。 当 Elasticsearch 在索引中搜索的时候， 他发送查询到每一个属于索引的分片(Lucene 索引)，然后像 执行分布式检索 提到的那样，合并每个分片的结果到一个全局的结果集。
从小到大的粒度：文档 / lucene段 / 倒排索引 (后期多个可以合并成一个)-> lucene索引 / es分片 -> es索引
lucene提交新文档流程：新文档 / 段->在内存索引缓存->缓存提交->一个新的段（追加的倒排索引）被写入磁盘，一个有新段名字的提交点写入磁盘->刷新到磁盘->新段可搜索->缓存清空
删除文档：因为段（倒排索引）不可变，所以在.del文件中被标记删除
3.es优化持久化索引流程来实现近实时查询
https://www.elastic.co/guide/cn/elasticsearch/guide/current/near-real-time.html
https://www.elastic.co/guide/cn/elasticsearch/guide/current/translog.html
如果每个段都这样经常写磁盘，新段可被搜索的速度就会很慢了。
所以es在缓存提交到新段可搜索这里做了手脚，改后变成下面这样：
新文档 / 段->在内存索引缓存->内存缓存放到文件缓存的新段，事务日志记录下来（refresh）->新段可搜索->内存缓存清空->隔一段时间（默认30分钟）就会flulsh，段被全量提交，文件缓存的段（追加的倒排索引）被fsync写入磁盘，有新段名字的提交点写入磁盘，事务日志清空
4.合并段：段多了，搜索也慢，optimize用来合并
https://www.elastic.co/guide/cn/elasticsearch/guide/current/merge-process.html
小结：这些es都自动做好，所以基本我们不用考虑太多。
集群原理：集群有多个节点，一个节点有多个主副分片，不同节点的主分片组成es索引。节点间通信，万一挂了一个，其他节点的副分片随时顶上成挂了的节点的主分片有备无患。
1.一个 分片 是一个底层的 工作单元 ，它仅保存了 全部数据中的一部分。一个分片可以是 主 分片或者 副本 分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。
从小到大的粒度：文档 / lucene段 / 倒排索引 (多个可以合并成一个)-> lucene索引 / es分片 -> es索引
https://www.elastic.co/guide/cn/elasticsearch/guide/current/_add-an-index.html
2.集群健康状态
green
所有的主分片和副本分片都正常运行。
yellow
所有的主分片都正常运行，但不是所有的副本分片都正常运行。
red
有主分片没能正常运行
3.多节点的时候，一个节点有多个分片，有主有副，保证一个节点死了，集群也不死。
https://www.elastic.co/guide/cn/elasticsearch/guide/current/_scale_horizontally.html
索引原理：倒排索引
原文：http://www.cnblogs.com/dreamroute/p/8484457.html
看了一下，只是看了term dictionary，后面的压缩和联合索引看不下去了。
大概就是：
1.倒排索引有个term字典，term字典跟b-tree很像，也是logN。字典大不好放内存，所以在字典前有多了个term index，他是term的前缀经过fst后得出的集合。fst是什么？看不懂。
除了倒排索引，es还有其他优化：表示还是看原文吧，我不是很看懂下面的优化。最后id可以优化的：http://blog.mikemccandless.com/2014/05/choosing-fast-unique-identifier-uuid.html
2.压缩文档id，按块压缩，
有趣的地方是65535是界限分块，65535=2^16-1，就是2个字节表示的最大数，一个short的存储单位。块里的值个数如果不超过4096个值，那么就每个value用2个字节来存。如果大于，那就用bitset。原因可能是4096*2bytes=8192bytes<1kb？？？？？这里不懂了。
2.联合索引表示