微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

SpringCloud微服务架构

29 ES 集群

29.3 集群职责及脑裂

29.3.1 ES 集群的节点角色

elasticsearch中集群节点有不同的职责划分：

节点类型	配置参数	默认值	节点职责
master eligible	node.master	true	备选主节点：主节点可以管理和记录集群状态、决定分片在哪个节点、处理创建和删除索引库的请求
data	node.data	true	数据节点：存储数据、搜索、聚合、CRUD
ingest	node.ingest	true	数据存储之前的预处理
coordinating	上面3个参数都为false则为coordinating节点	无	路由请求到其它节点 合并其它节点处理的结果，返回给用户

默认情况下ES 的集群节点，拥有这全部的角色，“身兼数职”

但是在实际开发中，肯定不能让一个节点身兼数职

【原因】

• 不同的职责对硬件的需求不一样
• 职责之间可能会产生相互影响

一个典型的ES 集群，肯定会把每个节点的职责做拆分，不同的节点做不同的事

【如何控制？】

29.3.2 ES集群的分布式查询

elasticsearch中的每个节点角色都有自己不同的职责，因此建议集群部署时，每个节点都有独立的角色。

这就是一个典型的ES 集群的结构

29.3.3 ES 集群的脑裂

默认情况下，每个节点都是master eligible节点，因此一旦master节点宕机，其它候选节点会选举一个成为主节点。当主节点与其他节点网络故障时，可能发生脑裂问题。

【举个栗子】

现在有三个节点

节点1 当选了主节点，剩下两个候选节点

假设现在发生了网络故障

现在node2 和 node3 无法与node1 取得连接了【现在就相当于集群分开了】

然后它俩可能就会以为“老大”挂了，就又选了一个主节点【现在的情况，集群中出现了两个主节点】

【进行一些数据交换后】

一旦网络恢复

就会出现不一致的情况，这样就出事儿了

为了避免脑裂，需要要求选票超过 ( eligible节点数量 + 1 ）/ 2 才能当选为主，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes，在es7.0以后，已经成为默认配置，因此一般不会发生脑裂问题。

29.3.4 总结

master eligible节点的作用是什么？

• 参与集群选主
• 主节点可以管理集群状态、管理分片信息、处理创建和删除索引库的请求

data节点的作用是什么？

• 数据的CRUD

coordinator节点的作用是什么？

• 路由请求到其它节点
• 合并查询到的结果，返回给用户