ElasticSearch分布式架构

本文固定链接: http://www.chepoo.com/elasticsearch-distributed-architecture.html | IT技术精华网

今天介绍下ElasticSearch的分布式架构，如果你熟悉cassandra、hadoop、mongodb，你会发现ElasticSearch里面有很多他们的影子，没错，ElasticSearch吸收了目前主流的分布式系统的很多特性，下面简单介绍一把。

之前翻译过一篇[译]搜索引擎与时间机器，里面介绍了下作者在设计ElasticSearch的一些想法，现在看起来还是记忆犹新，因为他的这种思路实在是非常新颖，比如ES里面的将数据分为工作数据和持久化数据两种：

工作数据就是正常的提供查询和索引的数据，这部分数据假定是瞬时的，并且是不可靠的，随时可能丢失的数据，而持久化数据则是可靠的，一致的数据，工作数据可以都放在内存中，这样可以保证非常好的性能，而持久化数据则专心保证数据的一致性就ok了，我们自动的分布式系统有CAP原则，通过对数据分离方式，我们很好的解决了C和A的问题，你可能会问，你内存中的数据如果不对了怎么办？不就会影响数据的一致性吗？一方面数据可以从持久化数据进行加载，另外ES节点间的数据会定时刷新和同步，最终确保数据的一致，就算万一机器都歇了，没关系，从持久化目录里面重新加载数据即可。

单前面说的那个还不算什么，如果不能很好的解决动态扩容的问题，那就不算是ElasticSearch了，在ElasticSearch里面，索引目录有如下两个概念：shard（碎片）、replica（副本）碎片(shard)的意思很好理解，db可以有sharding，索引也可以做嘛，单个索引目录太大，GB级别的索引文件，你再继续往里塞数据，文件合并，优化，有过这种经验的人应该会明白这种痛苦，怎么办？拆呗（china？拆那？），一般的做法是按数据拆，自己按租户，按时间拆等等，很是麻烦，并且拆完了之后的事情也不少，跨目录查询怎么办？更新怎么办？接口要怎么变？这些在ElasticSearch里面都帮你想到了，对你而言，全是透明的，你操作的就是一个索引，你在创建索引的时候，根据索引的规模指定碎片的大小，其他的你就不用管了，至于它里面怎么实现数据的平均分配，其实很简单，就用了一个取模的算法，随机分配到各个碎片中，至于一致性哈希之类的，目前来说完全没有必要。

碎片可以解决单个索引太大的问题，但是凡任何事有利必有弊，索引碎片在实现上其实就分成了很多个索引目录，索引目录越多，对建索引的速度会有提示，尤其是多线程环境，因为我们建索引的时候单个索引目录肯定加锁，一旦涉及锁，势必要减慢速度，不过我多几个目录，不就可以并发执行了吗？是的，ES就是这么做的，但是前面说了，有利就有弊，索引搞得到处都是，ES查询起来就很费劲了，一般情况下，我们在没有使用Routing的情况下（后面再介绍routing），ES会同时多个线程去读取各个碎片的索引数据，然后再合并查询结果，另外在ES的分布式环境下，碎片如果分布在多台服务器上就要加上网络的开销，势必会影响查询速度了，在海量数据的前提下，这些其实都还好，并且ES支持多种查询方式(reflink:search type)：
Query And Fetch：
Query Then Fetch：
Dfs, Query And Fetch：
Dfs, Query Then Fetch：
Count：
Scan：
根据不同的查询需求，选择合适的查询类型，会收到意想不到的效果。
–
先整体看看单ES节点的模块结构吧：

再看看一次索引操作

再看看一次查询请求