第10章 集群

1. 数据分布

1.1 数据分布理论

  • 哈希分区:离散度好,数据分布业务无关
  • 顺序分区:离散度易倾斜,数据分布业务相关,可顺序访问
  1. 节点取余分区:hash(key)%N,当节点数量变化时,映射关系需重新计算,会导致数据迁移,通常翻倍扩容

  2. 一致性哈希分区:为系统中每个节点分配一个token,构成一个哈希环

    • 加减节点会造成部分数据失效
    • 不适合少量节点
    • 普通的一致性哈希分区在增加节点时要增加一倍或减去一半才能保证数据负载均衡


      一致性哈希.jpg
  3. 虚拟槽分区:使用分散度良好的哈希函数把所有数据映射到一个固定的整数范围0~16383,5个节点的话,每个节点平均负责3276个槽


    槽集合.jpg

1.2 Redis数据分区

采用虚拟槽分区,slot = CRC16(KEY)&16383,特点:

  • 解耦数据和节点之间的关系,简化节点扩容和收缩难度
  • 节点自身维护槽的映射关系
  • 支持节点、槽、键支架你的映射查询

1.3 集群功能限制

  1. key批量操作支持有限
  2. key事务操作支持有限
  3. key作为数据分区的最小粒度
  4. 不支持多数据库空间
  5. 复制结构只支持一层

2. 搭建集群

2.1 准备节点

至少6个节点,开启cluster-enable yes

2.2 节点握手

一批运行在集群模式下的节点通过Gossip协议彼此通信
客户端执行命令:

cluster meet 127.0.0.1 6380

2.3 分配槽

通过一下命令为节点分配槽

cluster addslots {0...5461} //分配槽
cluster replicate cfb....   //命令一个节点称为从节点

2.4 使用redis-trib.rb搭建集群

采用Ruby实现的Redis集群管理工具

3. 节点通信

3.1 通信流程

分布式存储中提供维护节点元数据信息的机制
1 集中式
2 P2P方式

Redis集群采用P2P的Gossip(流言)协议,节点彼此不断通信交换信息,类似流言传播

  1. 集群中每个节点单独开辟一个TCP通道,用于节点之间彼此通信
  2. 每个节点在固定周期内通过特定规则选择几个节点发送ping消息
  3. 接收到ping消息的节点用pong响应

3.2 Gossip消息

  • ping 检测节点是否在线和交换信息
  • pong 响应ping
  • meet 通知新节点加入
  • fail 判定有节点下线,广播fail消息
消息解析流程.jpg

3.3 节点选择

Redis集群呢节点通信采用固定频率,每次选择需要通信的节点,选多了会成本过高,选少了会降低信息交换频率,Gossip协议需要兼顾信息交换实时性和成本开销

选择通信节点规则.jpg
  1. 选择发送消息的节点数量 5 + 10*num(node.pong_received > cluster_node_timeout/2)
  2. 消息数据量

4. 集群伸缩

4.1 伸缩原理

通过指令,每个节点把一部分槽和数据迁移到新的节点,即:
集群伸缩 = 槽和数据在节点之间的移动

4.2 扩容集群

  1. 准备新节点
  2. 加入集群
  3. 迁移槽和数据(或是作为从节点负责故障转移)
槽和数据迁移流程.jpg

4.3 收缩集群

  1. 下线迁移槽
  2. 忘记节点cluster forget {downNodeId}

5. 请求路由

Redis集群为了追求性能最大化,采用客户端直连节点而不是代理的方式

5.1 请求重定向

重定向流程.jpg
  1. 计算槽
  2. 槽节点查找

5.2 Smart客户端

Smart客户端通过在内部维护slot->node的映射关系,本地就可实现键到节点的查找,而move重定向负责协助smart客户端更新slot->node映射

Jedis客户端命令执行流程.jpg

5.3 ASK重定向

当slot对应的数据在迁移过程中,可能一部分数据在源节点,另一部分在目标节点,客户端需要智能识别

  1. 客户端根据本地slots缓存,发送命令到源节点
  2. 如果键对象不存在,可能存在于目标节点,源节点恢复ASK重定向异常
  3. 客户端从ASK重定向信息中提取目标节点信息,发送asking命令道目标节点

为了支持ASK重定向,源节点和目标节点在内部的clusterState结构中维护当前正在迁移的槽信息,用于识别槽迁移情况

6. 故障转移

解决集群部分失败场景,自动故障转移

6.1 故障发现

  • 主观下线:某个节点认为另一个节点不可用
  • 客观下线:标记一个节点真正下线,多个节点认为此节点不可用达成共识

广播fail消息是客观下线最后一步,通知集群内所有节点标记故障节点为客观下线并立刻生效
通知故障节点的从节点触发故障转移流程

6.2 故障恢复

  1. 从节点资格检查
  2. 准备选举时间
  3. 发起选举
  4. 选举投票
  5. 替换主节点

6.3 故障转移时间

  1. 主观下线识别时间 = cluster-node-timeout
  2. 主观下线消息传播时间 <= cluster-node-timeout/2
  3. 从节点转移时间<=1000毫秒

7. 集群运维

  1. 集群完整性,所有槽都被分配
  2. 带宽消耗,考虑集群内Gossip消息通信
  3. Pub/Sub广播问题,发布订阅加重带宽负担
  4. 集群倾斜,不同节点间数据量和请求量出现明显差异:数据倾斜,请求倾斜
  5. 集群读写分离
  6. 手动故障朱阿姨
  7. 数据迁移
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,227评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,755评论 1 298
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,899评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,257评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,617评论 3 288
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,757评论 1 221
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,982评论 2 315
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,715评论 0 204
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,454评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,666评论 2 249
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,148评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,512评论 3 258
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,156评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,112评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,896评论 0 198
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,809评论 2 279
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,691评论 2 272

推荐阅读更多精彩内容