Elasticsearch集群设计技巧

ES的基本架构

1. 节点可以配置为不同角色，通过选举Master管理集群
2. Coordinating：协调节点；Master：管理节点；Data：数据存储节点

数据是按照索引分片的，而不是按照节点分片，每个分片可以有多个副本来保证高可用，例如图中P0有2个R0副本

ES的选举

1. 先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高
2. clusterStateVersion相同时，进入compareNodes，其内部按照节点的ID比较（ID为节点第一次启动时随机生成）

Zen Discovery 采用了很多分布式共识算法中的想法，但只是有机地采用，并没有严格按照理论所规定的那个模型，7.0 是基于 Raft 但不全是 Raft

ES的部署架构模式

模式1-Master和Data混合部署

1. 节点同时配置为Master和Data
2. 每个节点都可以接收和处理客户端请求，写入操作会转发到数据主分片的Node
3. 适用于数据量不大的业务

模式2-Master和Data分离部署

1. Master节点和Data节点分离部署，Master节点数量3个或5个，Data节点数量可以几十个
2. Master节点不处理读写请求，只负责集群管理，Data节点处理读写请求和数据存储
3. 适用于数据量比较大的业务

模式3-Coordinating分离部署

1. Master节点数量3个或5个，Data节点数量可以几十个，Coordinating节点2个以上
2. Master节点不处理读写请求，只负责集群管理，Coordinating负责读写聚合，Data节点负责数据存储
3. 适用于数据量比较大，读写请求比较复杂的业务

模式4-Cross cluster replication

1. 配置为2个集群为 Cross cluster replication，Leader负责数据读写，Follower复制数据、负责数据读取
2. 适用场景：本地化、聚合存储

Redis cluster设计技巧

Redis cluster基本架构

1. Cluster分为多个分片，不同分片保存不同数据
2. 每个分片内部通过主备复制来保证可用性
3. 分片内部自动实现Master选举，但不依赖Sentinel，Cluster本身具备分片选举的能力
4. 客户端连接集群需要特定的实现，例如jedisCluster，因为Cluster有特有的Redis命令

Redis数据分布和路由

1. 所有key按照Hash算法分为16384个槽位，然后将槽位分配给分片
2. 节点之间通过Gossip交换信息，节点变化的时候会自动更新集群信息
3. 每个节点都有所有key的分布信息
4. Client连接任意节点，由节点用move指令来告诉实际的数据位置

MongoDB/HDFS集群设计技巧

MongoDB sharding架构

mongos

1. 独立部署的代理程序，应用程序请求发给mongos
2. 可以和应用程序部署在一起，也可以和Shard服务器部署在一起
3. 为了提升性能，mongos会缓存Config Server上保存的cluster配置信息

Config Server

1. 存储集群的元数据
2. 自身通过replicat set保证高可用
3. 当Config Server挂掉的时候，cluster进入read only

Shard

1. 存储分片数据的服务器
2. 自身通过replica set保证高可用，如果全部挂掉，分片就无法访问了

HDFS架构

NameNode

集群管理节点，保存集群元数据，管理集群（平衡、分配等）

DataNode

存储实际的数据，数据按照block存储

JournalNode

1. 当Active NameNode修改集群状态后，会写日志到JournalNode集群里面
2. StandBy NameNode会监听JournalNode，发生变化的时候会拉取日志
3. JournalNode至少3个，达到多数日志复制写入才算成功

FailoverController

1. NameNode节点内的一个独立进程，监控NameNode状态
2. 依赖Zookeeper做高可用

各个架构的简单分析对比