本文已参与「新人创作礼」活动，一起开启掘金创作之路。
我们先来回顾一下redis的主要功能:
1. 哨兵机制与主从复制
2. 支持事务
3. 支持LUA脚本
4. 支持持久化
5. 支持集群
事务在上期博文已经讲述过了, 那么本期集群就讲讲集群!
集群的优点:
负载均衡: 单台服务器的资源是有限的, 可以通过主从复制进行读写分离, 将一部分压力转到其他服务器上,
提高数据的可用性
集群可以做到 读写分离 及 数据容灾
常见的集群方案:
1. twemproxy
2. codis
基本与twemproxy一致, 他支持节点数量改变的情况下旧节点的数据恢复到新节点
3. redis3.0自带的集
他的特点是分布式算法不是一致性的hash, 而是hash槽的概念 支持节点设置从节点
常见的集群模型有哪些
1. 树形结构: 如:
2. 链式结构: 如:
个人感觉链式结构好点: 这样可以解决单点故障, 如果master挂掉, slave1立马可以顶上来, 其他的不变
无论是哪种结构, master只能有一个
主从复制的模型是什么?
为了使部分节点挂掉或者大部分节点无法通信的情况下集群仍然可用,
所以集群使用了主从复 制的模型, 每个节点都会有N-1个复制品
集群的写操作会丢失吗?
redis的写操作并不能保证强一致性, 这就意味着在集群下一些特殊的条件下数据可能会导致写 操作的丢失
集群在什么情况下会导致数据的不可用?
假设当前集群有三个节点A,B,C 并没有进行主从复制, 这时如果B 宕机了,
那么集群就会缺少 5501-11000这个范围的槽, 导致集群的不可用
集群涉及到的命令:
cluster info 打印集群信息
cluster nodes 获取集群已知节点
redis cluster槽的概念:
redis集群没有使用一致性hash, 而是采用桶的概念, 当需要redis集群添加数据的时候
根据CRC16(key) mod 16384 (对key的值取模), 决定数据放到哪个槽中
redis cluster槽为什么是16384个?
在redis节点发送心跳包时需要把所有的槽放到这个心跳包里, 以便让节点知道当前集群信息, 16384=16k,
在发送心跳包时使用bitmap压缩后是2k (2 * 8 (8 bit) * 1024(1k) = 2K), 也就是通过2k的空间压缩了16k的槽
虽然CRC16算法最多可以分配65535 (2^16-1)个槽 (65535 = 65k), 压缩后就是8k
(8 * 8 (8 bit) * 1024(1k) = 8K), 也就是说每次需要8K的心跳包, 而且集群一般不会有1000个master节点,
所以16K的槽是比较合适的, 作者也给出了解答
结束
这就是我对redis集群篇的总结, 下一章是对集群的主从复制进行总结
感觉有用就点个赞吧 如果有错误或更好的方法评论区请多多指出 相互学习共同进步
