分片架构设计技巧

news2024/9/27 7:23:39

Elasticsearch集群设计技巧

ES的基本架构

在这里插入图片描述

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

在这里插入图片描述

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

ES的选举

在这里插入图片描述

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

在这里插入图片描述

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

ES的部署架构模式

模式1-Master和Data混合部署

在这里插入图片描述

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

模式2-Master和Data分离部署

在这里插入图片描述

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

模式3-Coordinating分离部署

在这里插入图片描述

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

模式4-Cross cluster replication

在这里插入图片描述

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

Redis cluster设计技巧

Redis cluster基本架构

在这里插入图片描述

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

Redis数据分布和路由

在这里插入图片描述

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

MongoDB/HDFS集群设计技巧

MongoDB sharding架构

在这里插入图片描述

mongos

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

Config Server

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

Shard

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

HDFS架构

在这里插入图片描述

NameNode

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

DataNode

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

JournalNode

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

FailoverController

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

各个架构的简单分析对比

维度	ES	Redis Cluster	MongoDB sharding	HDFS
实现复杂度	高，需要选举Master节点，且角色类型众多	高，需要Gossip协议来交互信息	低，Config Server管理集群	低，NameNode管理集群
部署复杂度	中，需要根据业务规模采用不同的部署模式	低，只有一种模式，平滑伸缩	高，3类节点，且Config server和Shard要部署主备	高，部署Zookeeper、NameNode、DataNode、JournalNode
硬件成本	低	中，每个分片要部署master和slave节点	高，Config server和Shard要部署主备	高，节点类型很多
支持集群规模	超大规模	中等规模，建议服务器数量100以内	超大规模	超大规模
适用场景	数据查询和分析	缓存	数据存储	数据存储