分片架构设计技巧

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做高可用

各个架构的简单分析对比

维度ESRedis ClusterMongoDB shardingHDFS
实现复杂度高,需要选举Master节点,且角色类型众多高,需要Gossip协议来交互信息低,Config Server管理集群低,NameNode管理集群
部署复杂度中,需要根据业务规模采用不同的部署模式低,只有一种模式,平滑伸缩高,3类节点,且Config server和Shard要部署主备高,部署Zookeeper、NameNode、DataNode、JournalNode
硬件成本中,每个分片要部署master和slave节点高,Config server和Shard要部署主备高,节点类型很多
支持集群规模超大规模中等规模,建议服务器数量100以内超大规模超大规模
适用场景数据查询和分析缓存数据存储数据存储
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值