ElasticSearch(进阶)

1.1 解析ES的分布架构

1.1.1 分布式架构的透明隐藏特性(Elasticsearch 集群分配多少分片合理)

ElasticSearch是一个分布式架构,隐藏了复杂的处理机制

分片机制(shard):我们不用关心数据是按照什么机制分片的,最后放入哪个分片中

分片的副本(replica):任何一个服务器随时可能故障或宕机,此时shard可能就会丢失,因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务,保证数据不丢失,多个replica还可以提升搜索操作的吞吐量和性能。primary shard(建立索引时一次设置,不能修改,默认5个),replica shard(随时修改数量,默认1个),默认每个索引10个shard,5个primary shard,5个replica shard,最小的高可用配置,是2台服务器

集群发现机制(cluster discovery):当前启动了一个es进程,当启动了第二个es进程时,这个进程作为一个node自动就发现了集群,并加入进去

shard负载均衡:比如现在有10shard,集群中有3个节点,es会均衡的进行分配,以保持每个节点均衡的负载请求

请求路由!!es路由原理 在es中,一个index会被分片,一个index中存在很多document,这个document存放在不同的shard ,而一个document只能存在于一个primary shard中,这样,当客户端创建一个document并存入es时,es内部就需要决定这个document存于那一个primary shard,这就是es中的document 路由分发

1.1.2 扩容机制

垂直扩容:购置新的机器,替换已有的机器

水平扩容:直接增加机器

rebalance:增加或减少节点时会自动均衡

master节点:主节点的主要职责是和集群操作相关的内容,如创建或删除索引,跟踪哪些节点是集群的一部分,并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。

节点对等:每个节点都能接受请求,每个节点接受请求后都能把该请求的路由到有关数据的其他节点上,接收原始请求的节点负责采集数据并返回给客户端


1.2 分片和副本机制

  • index包含有多个shard
  • 每个shard都是一个最小工作单元,承载部门数据;每个shard都是一个lucene实例,有完整的建立索引和处理请求的能力
  • 增减节点时,shard会自动在nodes中负载均衡
  • primary shard和replica shard,每个document肯定只存在某一个primary shard以及其对应的replica shard中,不可能存在多个primary shard
  • replica shard是primary shard的副本,负责容错,以及承担读请求负载
  • primary shard的数量在创建索引的时候就固定了,replica shard的数量可以随时修改(因为在保存文档的时候是根据路由Id进行hash算法确定这个文档保存在哪个主分片下,若主分片数量修改,那么同样的路由Id进行读取此文档,经过hash算法之后确定了此文档所在分片的位置,但此时分片的位置显然不是原档存入的位置,所以会造成数据缺失,查找不到数据)
  • (创建索引时若不指定)primary shard的默认数量是5,replica是1,即默认有10个shard,5个primary shard,5个replica shard
  • primary shard不能和自己的replica shard放在一个同一个节点上(否则节点宕机,primary shard和副本都丢失,起不到容错的作用),但是可以和其他primary shard的replica shard放在同一个节点上

1.3 单节点环境下创建索引分析

# 创建myindex索引 指定主节点3个 副本节点一个(每个主节点下均有一个副本节点)
PUT myindex
{
  "settings": {"number_of_shards": 3, "number_of_replicas": 1}
}

按上面设置进行创建索引时,只会将3个primary shard分配到仅有一个的node上,另外三个replica shard是无法分配的(一个shard的副本replica是不能在同一个节点的)。集群可以正常工作,但一旦出现节点宕机,数据全部丢失,而且集群不可用,无法接受任何请求

# 查看集群健康 显示为yellow(因为无法安置设置的副本节点)  但还是能进行正常的存储和读取
GET _cat/health

1.4 两个节点环境下创建索引分析

将3个primary shard分配到一个node上,另外三个replica shard分配到另一个节点上

primary shard和replica shard保持同步

primary shard和replica shard都可以处理客户端的请求


1.5 水平扩容的过程

  1. 扩容后primary shard和replica shard会自动的负载均衡
  2. 扩容后每个节点上的shard会减少,那么分配给每个shard的cpu、内存、IO资源会更多,性能提高
  3. 扩容的极限,如果有6个shard,扩容的极限就是6个节点,每个节点上一个shard,如果想超出扩容的极限,比如说扩容到9个节点,那么可以增加replica shard的个数
  4. 6个shard,3个节点,最多能承受几个节点所在的服务器宕机?(容错性) 3个节点,6个shard,最多能接受1台服务器宕机
    提高容错性?接受的宕机的台数越多,容错性越好
    提高容错性:增加shard的个数(增加shard的个数可以让每个节点下有更多的shard,增加到足够多的数量可以满足一个节点包含所有的数据,那么只要有一个节点在,服务就能正常进行,一般来说,shard总数量 = 节点个数 * 主shard个数) 比如现在有3个primary shard,3个node,为了达到最大容错率,需要增加6个replica shard,这样就能容忍最多两台服务器宕机
    总结扩容是为了提高系统的吞吐量,同时也要考虑容错性,也就是让尽可能多的服务器宕机还能保证数据不丢失

1.6 ES的容错机制

以9个shard,3个节点为例:
如果master node宕机,此时不是所有的primary shard都是Active status,所以此时的集群状态是red

  • 容错处理的第一步:选举一台服务器作为master
  • 容错处理的第二部:新选举出的master会把挂掉的primary shard的某个replica shard提升为primary shard,此时集群的状态为yellow,因为少了一个replica shard,并不是所有的replica shard都是Active status
  • 容错处理的第三步:重启故障机,新master会把所有的副本都复制一份到该节点上,(同步一下宕机后发生的修改),此时集群的状态为green,因为所有的primary shard和replica shard都是Active status

1.7 文档的核心元数据

  • _index: 说明了一个文档存储在哪个索引中,同一个索引下存放的是相似的文档(文档的field多数是相同的)索引名必须是小写,不能以下划线开头,不能包括逗号
  • _type: 表示文档属于索引中的哪个类型,一个索引下只能有一个type,类型名可以是大写也可以是小写,不能以下划线开头,不能包括逗号
  • _id: 文档的唯一标识,和索引,类型在一起唯一标识了一个文档,可以手动指定值,也可以由es来生成这个值

1.8 文档id生成方式

  • 手动指定 通常是把其他系统的已有数据导入到es时
  • es生成id值 es生成的长度为20个字符,使用的是base64编码,URL安全;使用的是GUID算法,分布式下并发生成Id值不会冲突

1.9 改变文档内容原理解析

  • POST:根据用户传递过来的数据查询出doc,然后使用用户提交过来的数据进行更新到doc中,再将已有的doc标记为deleted,根据此doc创建一个新的doc
  • PUT:先从es中查询出doc返回给用户,用户再将修改后的doc传递给es,es将原来的doc标记为deleted,再将用户传递过来的doc创建为一个新的doc
  • 总结:①post方式比put方式网络数据传输的次数要少(不需要查询返回给用户),从而提高了性能 ②post方式从查询文档到修改文档再到创建新的文档都是在es内部实现的 ③post方式发生并发冲突的可能性降低

1.10 文档数据路由原理解析

  • 数据路由:一个索引有多个分片组成,当添加(查看、修改、删除)一个文档时,es就需要决定这个文档存储在哪个分片上,这个过程就叫做数据路由(routing)
  • 路由算法:
shard = hash(routing) % number_of_primary_shards

示例:一个索引,三个primary shard
① 每次增删改查时都有一个routing值,默认是文档的_id的值
② 对这个routing值使用哈希函数进行计算
③ 计算出的值再和主分片个数取余数
余数肯定在0----(number_of_primary_shards-1)之间,文档就在对应的shard上
routing默认值是文档的_id的值,也可以手动指定一个值,手动指定对于负载均衡以及提高批量读取的性能都有帮助

  • primary shard个数一旦确定就不能修改了
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容