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以内 | 超大规模 | 超大规模 |
适用场景 | 数据查询和分析 | 缓存 | 数据存储 | 数据存储 |