• 分片架构设计技巧

    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以内超大规模超大规模
    适用场景数据查询和分析缓存数据存储数据存储
  • 相关阅读:
    Linux下快速搭建YApi接口管理平台
    【华为OD机试真题 JS】求满足条件的最长子串的长度
    8.4 【MySQL】文件系统对数据库的影响
    部署搭建decentraland流程讲解
    vue里面使用EventBus（事件总线）
    AJAX请求及解决跨域问题
    jetson 裁剪之后从sd卡版本移植到emmc版本
    二叉树oj题集（LeetCode）
    这几类外贸订单不要随意接
    【牛客网-公司真题-前端入门篇】——奇安信秋招笔试-前端-卷1
  • 原文地址：https://blog.csdn.net/lee_nacl/article/details/128016491