Elastic Search分布式架构

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节点

创建或删除索引

增加或删除节点

管理ES集群元数据

coordinate node

节点平等的分布式架构

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

分片和副本机制

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
		}
}

横向扩容

primary&replica自动负载均衡，6个shard，3 primary，3 replica

扩容后, 每个node有更少的shard，IO/CPU/Memory资源给每个shard分配更多，每个shard性能更好

扩容的极限，6个shard（3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好

超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量

3台机器下，9个shard（3 primary，6 replica），资源更少，但是容错性更好，最多容纳2台机器宕机，6个shard只能容纳0台机器宕机

这里的这些知识点，你综合起来看，就是说，一方面告诉你扩容的原理，怎么扩容，怎么提升系统整体吞吐量；另一方面要考虑到系统的容错性，怎么保证提高容错性，让尽可能多的服务器宕机，保证数据不丢失

扩容极限后处理方法

超出扩容极限后, 比如就6个shard 但是要扩容到9台机器,同时想让系统的性能更好,只能增加replica shard的数量, primary shard数量是不能改变的,

原来3 primary shard 3 replica shard, 增加副本后 3 primary shard 6 replica shard,这样每台机器都有一个shard,性能最好