亿级流量场景下，大型架构设计实现【全文检索高级搜索---ElasticSearch篇】-- 中

一、Elasticsearch的基础分布式架构：

一、Elasticsearch对复杂分布式机制的透明隐藏特性
二、Elasticsearch的垂直扩容与水平扩容
三、增减或减小节点时的数据rebalance
四、master节点
五、节点对等的分布式架构

--------------------------------------------------------------------------------------------------------------------

一、Elasticsearch对复杂分布式机制的透明隐藏特性

Elasticsearch是一套分布式的系统，分布式是为了应对大数据量
隐藏了复杂的分布式机制

分片机制（咱们以前随随便便就将一些document插入到es集群中去了，咱们有没有care过数据怎么进行分片的，数据到哪一个shard中去）

cluster discovery（集群发现机制，咱们以前在作那个集群status从yellow转green的实验里，直接启动了第二个es进程，那个进程做为一个node自动就发现了集群，而且加入了进去，还接受了部分数据，replica shard）

shard负载均衡（举例，假设如今有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每一个节点的均衡的读写负载请求）

shard副本，请求路由，集群扩容，shard重分配

--------------------------------------------------------------------------------------------------------------------

二、Elasticsearch的垂直扩容与水平扩容

垂直扩容：采购更强大的服务器，成本很是高昂，并且会有瓶颈，假设世界上最强大的服务器容量就是10T，可是当你的总数据量达到5000T的时候，你要采购多少台最强大的服务器啊

水平扩容：业界常常采用的方案，采购愈来愈多的普通服务器，性能比较通常，可是不少普通服务器组织在一块儿，就能构成强大的计算和存储能力

普通服务器：1T，1万，100万
强大服务器：10T，50万，500万

扩容对应用程序的透明性

--------------------------------------------------------------------------------------------------------------------

三、增减或减小节点时的数据rebalance

保持负载均衡

--------------------------------------------------------------------------------------------------------------------

四、master节点

（1）建立或删除索引
（2）增长或删除节点

--------------------------------------------------------------------------------------------------------------------

五、节点平等的分布式架构

（1）节点对等，每一个节点都能接收全部的请求
（2）自动请求路由
（3）响应收集

 ************************************************ 示例图 ******************************************

 

 二、shard&replica机制再次梳理以及单个或者两个node环境中建立index图解

一、shard&replica机制再次梳理
二、图解单node环境下建立index是什么样子的

------------------------------------------------------------------------------------------------

一、shard&replica机制再次梳理

（1）index包含多个shard
（2）每一个shard都是一个最小工做单元，承载部分数据，lucene实例，完整的创建索引和处理请求的能力
（3）增减节点时，shard会自动在nodes中负载均衡
（4）primary shard和replica shard，每一个document确定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard
（5）replica shard是primary shard的副本，负责容错，以及承担读请求负载
（6）primary shard的数量在建立索引的时候就固定了，replica shard的数量能够随时修改
（7）primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard
（8）primary shard不能和本身的replica shard放在同一个节点上（不然节点宕机，primary shard和副本都丢失，起不到容错的做用），可是能够和其余primary shard的replica shard放在同一个节点上

------------------------------------------------------------------------------------------------

二、图解单node环境下建立index是什么样子的

（1）单node环境下，建立一个index，有3个primary shard，3个replica shard
（2）集群status是yellow
（3）这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是没法分配的
（4）集群能够正常工做，可是一旦出现节点宕机，数据所有丢失，并且集群不可用，没法承接任何请求

PUT /test_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}

 

 

二、图解2个node环境下replica shard是如何分配的

（1）replica shard分配：3个primary shard，3个replica shard，1 node
（2）primary ---> replica同步
（3）读请求：primary/replica

三、图解横向扩容过程，如何超出扩容极限，以及如何提高容错性
（1）primary&replica自动负载均衡，6个shard，3 primary，3 replica
（2）每一个node有更少的shard，IO/CPU/Memory资源给每一个shard分配更多，每一个shard性能更好
（3）扩容的极限，6个shard（3 primary，3 replica），最多扩容到6台机器，每一个shard能够占用单台服务器的全部资源，性能最好
（4）超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
（5）3台机器下，9个shard（3 primary，6 replica），资源更少，可是容错性更好，最多容纳2台机器宕机，6个shard只能容纳0台机器宕机
（6）这里的这些知识点，你综合起来看，就是说，一方面告诉你扩容的原理，怎么扩容，怎么提高系统总体吞吐量；另外一方面要考虑到系统的容错性，怎么保证提升容错性，让尽量多的服务器宕机，保证数据不丢失

*********************************************************** 扩容过程图 --------------> 自动进行负载均衡

 

*********************************************************** 容错图 --------------> 

**************************************************************** 纠正图 ---->>

 

四、图解Elasticsearch容错机制：master选举，replica容错，数据恢复

（1）9 shard，3 node
（2）master node宕机，自动master选举，red
（3）replica容错：新master将replica提高为primary shard，yellow
（4）重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green

 

五、 初步解析document的核心元数据以及图解剖析index建立反例

一、_index元数据
二、_type元数据
三、_id元数据

{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"test_content": "test test"
}
}

------------------------------------------------------------------------------------------------------------------------------------------

一、_index元数据

（1）表明一个document存放在哪一个index中
（2）相似的数据放在一个索引，非相似的数据放不一样索引：product index（包含了全部的商品），sales index（包含了全部的商品销售数据），inventory index（包含了全部库存相关的数据）。若是你把好比product，sales，human resource（employee），全都放在一个大的index里面，好比说company index，不合适的。
（3）index中包含了不少相似的document：相似是什么意思，其实指的就是说，这些document的fields很大一部分是相同的，你说你放了3个document，每一个document的fields都彻底不同，这就不是相似了，就不太适合放到一个index里面去了。
（4）索引名称必须是小写的，不能用下划线开头，不能包含逗号：product，website，blog

二、_type元数据

（1）表明document属于index中的哪一个类别（type）
（2）一个索引一般会划分为多个type，逻辑上对index中有些许不一样的几类数据进行分类：由于一批相同的数据，可能有不少相同的fields，可是仍是可能会有一些轻微的不一样，可能会有少数fields是不同的，举个例子，就好比说，商品，可能划分为电子商品，生鲜商品，日化商品，等等。
（3）type名称能够是大写或者小写，可是同时不能用下划线开头，不能包含逗号

三、_id元数据

（1）表明document的惟一标识，与index和type一块儿，能够惟一标识和定位一个document
（2）咱们能够手动指定document的id（put /index/type/id），也能够不指定，由es自动为咱们建立一个id

 

六、document id的手动指定与自动生成两种方式解析

课程大纲

一、手动指定document id
二、自动生成document id

------------------------------------------------------------------------------------------------------------

一、手动指定document id

（1）根据应用状况来讲，是否知足手动指定document id的前提：

通常来讲，是从某些其余的系统中，导入一些数据到es时，会采起这种方式，就是使用系统中已有数据的惟一标识，做为es中document的id。举个例子，好比说，咱们如今在开发一个电商网站，作搜索功能，或者是OA系统，作员工检索功能。这个时候，数据首先会在网站系统或者IT系统内部的数据库中，会先有一份，此时就确定会有一个数据库的primary key（自增加，UUID，或者是业务编号）。若是将数据导入到es中，此时就比较适合采用数据在数据库中已有的primary key。

若是说，咱们是在作一个系统，这个系统主要的数据存储就是es一种，也就是说，数据产生出来之后，可能就没有id，直接就放es一个存储，那么这个时候，可能就不太适合说手动指定document id的形式了，由于你也不知道id应该是什么，此时能够采起下面要讲解的让es自动生成id的方式。

（2）put /index/type/id

PUT /test_index/test_type/2
{
"test_content": "my test"
}

二、自动生成document id

（1）post /index/type

POST /test_index/test_type
{
"test_content": "my test"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "AVp4RN0bhjxldOOnBxaE",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

（2）自动生成的id，长度为20个字符，URL安全，base64编码，GUID，分布式系统并行生成时不可能会发生冲突

 

七、document的全量替换、强制建立以及图解lazy delete机制

一、document的全量替换
二、document的强制建立
三、document的删除

------------------------------------------------------------------------------------------------------------------------

一、document的全量替换

（1）语法与建立文档是同样的，若是document id不存在，那么就是建立；若是document id已经存在，那么就是全量替换操做，替换document的json串内容
（2）document是不可变的，若是要修改document的内容，第一种方式就是全量替换，直接对document从新创建索引，替换里面全部的内容
（3）es会将老的document标记为deleted，而后新增咱们给定的一个document，当咱们建立愈来愈多的document的时候，es会在适当的时机在后台自动删除标记为deleted的document

------------------------------------------------------------------------------------------------------------------------

二、document的强制建立

（1）建立文档与全量替换的语法是同样的，有时咱们只是想新建文档，不想替换文档，若是强制进行建立呢？
（2）PUT /index/type/id?op_type=create，PUT /index/type/id/_create

------------------------------------------------------------------------------------------------------------------------

三、document的删除

（1）DELETE /index/type/id
（2）不会理解物理删除，只会将其标记为deleted，当数据愈来愈多的时候，在后台自动删除

 

八、深度图解剖析Elasticsearch并发冲突问题

 

九、分布式文档系统-深度图解剖析悲观锁与乐观锁两种并发控制方案

 

十、图解Elasticsearch内部如何基于_version进行乐观锁并发控制

 

（1）_version元数据

PUT /test_index/test_type/6
{
"test_field": "test test"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

第一次建立一个document的时候，它的_version内部版本号就是1；之后，每次对这个document执行修改或者删除操做，都会对这个_version版本号自动加1；哪怕是删除，也会对这条数据的版本号加1

{
"found": true,
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 4,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}

咱们会发现，在删除一个document以后，能够从一个侧面证实，它不是当即物理删除掉的，由于它的一些版本号等信息仍是保留着的。先删除一条document，再从新建立这条document，其实会在delete version基础之上，再把version号加1