1.redis的cluster?
- 分散一台服务器的访问压力,将数据分散在不同的数据库服务器,实现负载均衡
- 分散一台服务器的存储压力
- 容易实现可扩展性
2.负载均衡算法
- CRC16:(了解)
g(x)=1·x8+0·x7+0·x6+1·x5+1·x4+0·x3+0·x2 +0·x1+1·x0,即对应的二进制数为100110001; 每一位 - 轮询
- 加权轮询
- 随机
- hash(ip)
3.分布式Session
上面讲到了hash(ip),这里就说一下,对于分布式来说,我们要保证分布式session的实现:
- hash(ip):保证一台主机一直访问一台服务器
- 共享session:维护一个session服务器库,所有的服务器都从这里取
- 同步session:所有的服务器,只要一个修改,其他的都要同步。
4.redis cluster(重点来了)
客户段请求的key,经过CRC16得到一个值,然后对16384取余,来决定放置到哪个槽,每个节点负责一部分的槽,如: 两次寻址过程:
- 1 当前的节点通过crc16进行计算,如果是自己则进行执行
- 2 如果不是自己,返回错误Moved,然后告诉他哪个节点找
- 3 注意的是每个数据库会维护一部分槽slot,并且节点之间知道每个节点的slot的部分范围
-
5.补充,为什么槽的大小是16384,不是65536?
- 在redis节点发送心跳包时需要把所有的槽放到这个心跳包里,以便让节点知道当前集群信息,16384=16k,在发送心跳包时使用char进行bitmap压缩后是2k(2 * 8 (8 bit) * 1024(1k) = 16K),也就是说使用2k的空间创建了16k的槽数。
- 虽然使用CRC16算法最多可以分配65535(2^16-1)个槽位,65535=65k,压缩后就是8k(8 * 8 (8 bit) * 1024(1k) =65K),也就是说需要需要8k的心跳包,
作者认为这样做不太值得;并且一般情况下一个redis集群不会有超过1000个master节点,所以16k的槽位是个比较合适的选择。
综合来说:就是进行hash槽信息的同步的时候,保证发送的信息量少,并且一般不会超过1000个节点(一般不超过1000个也说明节点数不能太多,所以16384够用了!)
参考链接: https://www.jianshu.com/p/de268f62f99b
|