倒排索引原理_拜托，面试请不要再问我分布式搜索引擎的架构原理！
欢迎关注头条号：石杉的架构笔记
周一至周五早八点半！精品技术文章准时送上！！！
精品学习资料获取通道，参见文末
目录
(1)倒排索引到底是啥？
(2)什么叫分布式搜索引擎？
(3)ElasticSearch的数据结构
(4)Shard数据分片机制
(5)Replica多副本数据冗余机制
(6)全文总结
“ 这篇文章，我们来聊一下最近这一两年行业内Java高级工程师面试的时候尤为常见的一个问题：谈谈你对分布式搜索引擎的理解，聊聊他的架构原理？
很多同学可能从来没接触过这个东西，所以本文我们就以现在最火最流行的Elasticsearch为例，来聊一下分布式搜索引擎的核心架构原理。
(1)倒排索引到底是啥？
要了解分布式搜索引擎，先了解一下搜索这个事儿吧，搜索这个技术领域里最入门级别的一个概念就是倒排索引。
我们先简单说一下倒排索引是个什么东西。
假如说你现在不用搜索引擎，单纯使用数据库来存放和搜索一些数据，比如说放了一些论坛的帖子数据吧，那么这个数据的格式大致如下：
表格
很简单吧，假设有一个id字段标识了每个帖子数据，然后title字段是帖子的标题，content字段是帖子的内容。
那么这个时候，比如我们要是用数据库来进行搜索包含“Java”这个关键字的所有帖子，大致SQL如下：
如代码图不清晰，请移步同名公众号查看
咱们姑且不论这个数据库层面也有支持全文检索的一些特殊索引类型，或者数据库层面是怎么执行的，这个不是本文讨论的重点，你就看看数据库的数据格式以及搜索的方式就好了。
但是如果你通过搜索引擎类的技术来存放帖子的内容，他是可以建立倒排索引的。
也就是说，你把上述的几行数据放到搜索引擎里，这个倒排索引的数据大致看起来如下：
关键词 id
Java [1, 2, 3]
语言 [1]
面试 [3]
资源 [2]
所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每个关键词对应出现在了哪些id标识的数据里。
那么你要搜索包含“Java”关键词的帖子，直接扫描这个倒排索引，在倒排索引里找到“Java”这个关键词对应的那些数据的id就好了。
然后你可以从其他地方根据这几个id找到对应的数据就可以了，这个就是倒排索引的数据格式以及搜索的方式，上面这种利用倒排索引查找数据的方式，也被称之为全文检索。
(2)什么叫做分布式搜索引擎？
其实要知道什么叫做分布式搜索引擎，你首先得知道，假如我们就用一台机器部署一个搜索引擎系统，然后利用上述的那种倒排索引来存储数据，同时支持一些全文检索之类的搜索功能，那么会有什么问题？
其实还是很简单，假如说你现在要存储1TB的数据，那么放在一台机器还是可以的。
但是如果你要存储超过10TB，100TB，甚至1000TB的数据呢？你用一台机器放的下吗？
当然是放不下的了，你的机器磁盘空间是不够的。
大家看一下下面的图：
如图不清晰，请移步同名公众号查看
所以这个时候，你就得用分布式搜索引擎了，也就是要使用多台机器来部署搜索引擎集群。
比如说，假设你用的是Elasticsearch(后面简写为：ES)。
现在你总共有3TB的数据，那么你搞3台机器，每台机器上部署一个ES进程，管理那台机器上的1TB数据就可以了。
这样不就可以把3TB的数据分散在3台机器上来存储了？这不就是索引数据的分布式存储吗？
而且，你在搜索数据的时候，不就可以利用3台机器来对分布式存储后的数据进行搜索了？每台机器上的ES进程不都可以对一部分数据搜索？这不就是分布式的搜索？
是的，这就是所谓的分布式搜索引擎：把大量的索引数据拆散成多块，每台机器放一部分，然后利用多台机器对分散之后的数据进行搜索，所有操作全部是分布在多台机器上进行，形成了完整的分布式的架构。
同样，我们来看下面的图，直观的感受一下。
如图不清晰，请移步同名公众号查看
(3)Elasticsearch的数据结构
如果你要是使用Elasticsearch这种分布式搜索引擎，必须要熟悉他的一些专业的技术名词，描述他的一些数据结构。
比如说“index”这个东西，他是索引的意思，其实他有点类似于数据库里的一张表，大概对应表的那个概念。
比如你搞一个专门存放帖子的索引，然后他有id、title、content几个field，这个field大致就是他的一个字段。
然后还有一个概念，就是document，这个就代表了index中的一条数据。
下面就是一个document，这个document可以写到index里去，算是index里的一条数据。
而且写到es之后，这条数据的内容就会拆分为倒排索引的数据格式来存储。
表格
(4)Shard数据分片机制
那么这个时候大家考虑一下，比如说你有一个index，专门存放论坛里的帖子，现在论坛里的帖子有1亿，占用了1TB的磁盘空间，这个还好说。
如果这个帖子有10亿，100亿，占用了10TB、甚至100TB的磁盘空间呢？
那你这个index的数据还能在一台机器上存储吗？答案明显是不能的。
这个时候，你必须得支持这个index的数据分布式存储在多台机器上，利用多台机器的磁盘空间来承载这么大的数据量。
而且，需要保证每台机器上对这个index存储的数据量不要太大，因为控制单台机器上这个index的数据量，可以保证他的搜索性能更高。
所以这里就引入了一个概念：Shard数据分片结构。每个index你都可以指定创建多少个shard，每个shard就是一个数据分片，会负责存储这个index的一部分数据。
比如说index里有3亿帖子，占据3TB数据。然后这个index你设置了3个shard。
那么每个shard就可以包含一个1TB大小的数据分片，每个shard在集群里的一台机器上，这样就形成了利用3台机器来分布式存储一个index的数据的效果了。
大家看下面的图：
如图不清晰，请移步同名公众号查看
现在index里的3TB数据分布式存储在了3台机器上，每台机器上有一个shard，每个shard负责管理这个index的其中1TB数据的分片。
而且，另外一个好处是，假设我们要对这个index的3TB数据运行一个搜索，是不是可以发送请求到3台机器上去？
3台机器上的shard直接可以分布式的并行对一部分数据进行搜索，起到一个分布式搜索的效果，大幅度提升海量数据的搜索性能和吞吐量。
(5)Replica多副本数据冗余机制
但是现在有一个问题，假如说3台机器中的其中一台宕机了，此时怎么办呢？
是不是这个index的3TB数据的1/3就丢失了？因为上面有1TB的数据分片没了。
所以说，还需要为了实现高可用使用Replica多副本数据冗余机制。
在Elasticsearch里，就是支持对每个index设置一个replica数量的，也就是每个shard对应的replica副本的数量。
比如说你现在一个index有3个shard，你设置对每个shard做1个replica副本，那么此时每个shard都会有一个replica shard。
这个初始的shard就是primary shard，而且primary shard和replica shard是绝对不会放在一台机器上的，避免一台机器宕机直接一个shard的副本也同时丢失了。
我们再来看下面的图，感受一下：
如图不清晰，请移步同名公众号查看
在上述的replica机制下，每个primary shard都有一个replica shard在别的机器上，任何一台机器宕机，都可以保证数据不会丢失，分布式搜索引擎继续可用。
Elasticsearch默认是支持每个index是5个primary shard，每个primary shard有1个replica shard作为副本。
(6)文末总结
好了，本文到这儿就结束了，再来给大伙简单小结。
我们从搜索引擎的倒排索引开始，到单机无法承载海量数据，再到分布式搜索引擎的存储和搜索。
然后我们以优秀的分布式搜索引擎ES为例，阐述了ES的数据结构，shard数据分片机制，replica多副本机制，解释了一下分布式搜索引擎的架构原理。
最后还是强调一下，在Java面试尤其是高级Java面试中，对于分布式搜索引擎技术的考察越来越重，所以这块技术的重要性，还是不容小觑的！
End
私信头条号，发送：“资料”，获取更多“秘制” 精品学习资料
如有收获，请帮忙转发，您的鼓励是作者最大的动力，谢谢！
一大波微服务、分布式、高并发、高可用的原创系列文章正在路上,
欢迎关注头条号：石杉的架构笔记
周一至周五早八点半！精品技术文章准时送上！！！
十余年BAT架构经验倾囊相授
推荐阅读
1、拜托！面试请不要再问我Spring Cloud底层原理！
2、微服务注册中心如何承载大型系统的千万级访问？
3、「性能优化之道」每秒上万并发下的Spring Cloud参数优化实战
4、「“剁手党”狂欢的背后」微服务架构如何保障99.99%的高可用？
5、兄弟，用大白话告诉你小白都能看懂的Hadoop架构原理
6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
7、「性能优化的秘密」Hadoop如何将TB级大文件的上传性能优化上百倍
8、拜托，面试请不要再问我TCC分布式事务的实现原理！
9、最终一致性分布式事务如何保障实际生产中99.99%高可用？
10、拜托，面试请不要再问我Redis分布式锁的实现原理
11、Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上？
12、亿级流量系统架构之如何支撑百亿级数据的存储与计算
13、亿级流量系统架构之如何设计高容错分布式计算系统
14、亿级流量系统架构之如何设计承载百亿流量的高性能架构
15、亿级流量系统架构之如何设计每秒十万查询的高并发架构
16、亿级流量系统架构之如何设计全链路99.99%高可用架构
17、七张图彻底讲清楚ZooKeeper分布式锁的实现原理
18、大白话聊聊Java并发面试问题之volatile到底是什么？
19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？
20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？
21、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化
22、互联网公司的面试官是如何360°无死角考察候选人的？(上篇)
23、互联网公司面试官是如何360°无死角考察候选人的？(下篇)
24、「Java进阶面试系列之一」你们系统架构中为何要引入消息中间件？
25、「Java进阶面试系列之二」系统架构引入消息中间件有什么缺点
26、「行走的Offer收割机」一位朋友斩获BAT技术专家Offer的面试经历
27、「Java进阶面试系列之三」消息中间件在你们项目里是如何落地的？
28、扎心！线上服务宕机时，如何保证数据100%不丢失？
29、 一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！
30、「高并发优化实践」10倍请求压力来袭，你的系统会被击垮吗？
31、消息中间件集群崩溃，如何保证百万生产数据不丢失？
32、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(上)？
33、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(中)？
34、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(下)？
35、亿级流量架构第二弹：你的系统真的无懈可击吗？
36、亿级流量系统架构之如何保证百亿流量下的数据一致性(上)
37、亿级流量系统架构之如何保证百亿流量下的数据一致性(中)？
38、亿级流量系统架构之如何保证百亿流量下的数据一致性(下)？
39、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失(1)
40、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失(2)
41、面试大杀器：消息中间件如何实现消费吞吐量的百倍优化？
42、兄弟，用大白话给你讲小白都能看懂的分布式系统容错架构
43、从团队自研的百万并发中间件系统的内核设计看Java并发性能优化
44、如果20万用户同时访问一个热点缓存，如何优化你的缓存架构？
45、「非广告，纯干货」英语差的程序员如何才能无障碍阅读官方文档？
46、面试最让你手足无措的一个问题：你的系统如何支撑高并发？
47、Java进阶必备：优雅的告诉面试官消息中间件该如何实现高可用架构
48、「非广告，纯干货」中小公司的Java工程师应该如何逆袭冲进BAT？