分片架构设计技巧


Elasticsearch集群设计技巧

ES的基本架构

1.节点可以配置为不同角色,通过选举Master管理集群。

2.Coordinating:协调节点;Master:管理节点;Data:数据存储节点;

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

ES的选举

1.先根据节点的 clusterStateVersion 比较,clusterStateVersion 越大,优先级越高。

2.clusterStateVersion 相同时,进入 compareNodes,其内部按照节点的 ID 比较(ID 为节点第一次启动时随机生成)。

ES 的部署架构模式1 – Master 和 Data 混合部署

1. 节点同时配置为 Master 和 Data;

2. 每个节点都可以接收和处理客户端请求,写入操作会转发到数据主分片的 Node;

3. 适用于数据量不大的业务。

ES 的部署架构模式2 – Master 和 Data 分离部署

1. Master 节点和 Data 节点分离配置,Master 节点数量3个或者5个,Data 节点数量可以几十个;

2. Master 节点不处理读写请求,只负责集群管理,Data 节点处理读写请求和数据存储;

3. 适用于数据量比较大的业务。

ES 的部署架构模式3 – Coordinating 分离部署

1. Master 节点数量3个或者5个,Data 节点数量可以几十个,Coordinating(协调) 节点2个以上;

2. Master 节点不处理读写请求,只负责集群管理,Coordinating 负责读写聚合,Data 节点负责数据存储;

3. 适用于数据量比较大,读写请求比较复杂的业务。

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 指令来告诉实际的数据位置.

HDFS 架构

【NameNode】

集群管理节点,保存集群元数据,管理集群(平衡、分配等)。

【DataNode】

存储实际的数据,数据按照 block 存储。

【JournalNode】

1. 当 Active NameNode 修改集群状态后,会写日志到 JournalNode 集群里面;

2. StandBy NameNode 会监听 JournalNode,发生变化的时候会拉取日志;

3. JournalNode 至少3个,达到多数日志复制写入才算成功。

【FailoverController】

1. NameNode 节点内的一个独立进程,监控 NameNode 状态;

2. 依赖 ZooKeeper 做高可用。

MongoDB sharding 架构


【mongos】

1. 独立部署的代理程序,应用程序请求发给 mongos;

2. 可以和应用程序部署在一起,也可以和 Shard 服务器部署在一起;

3. 为了提升性能,mongos 会缓存 Config Server 上保存的 cluster

配置信息

【Config Server】

1. 存储集群的元数据;

2. 自身通过 replica set 保证高可用;

3. 当 Config Server 挂掉的时候,cluster 进入 read only。

【Shard】

1. 存储分片数据的服务器;

2. 自身通过 replica set 保证高可用,如果全部挂掉,分片就无访问了。

各个架构的简单分析对比


请使用浏览器的分享功能分享到微信等