缓存架构实战-06-横向扩容
单master读写分离架构瓶颈
master数据和slave一样,master最大能容纳多少,slave就最大能容纳多少,无法超过master内存上限
使用多个master解决,可以横向扩容
使用redis cluster
一致性hash
数据如何分布到节点
节点构成圆环,节点宕机,顺时针旋转
缓存热点问题,虚拟节点均匀分布
hash slot算法
redis cluster核心机制
每个master16384个slot,key找的是slot,节点宕机slot分布到存活节点
hash slot也可是分布均匀
redis cluster环境搭建
redis cluster会自动做读写分离,主备切换
要求至少3个master,每个master至少一个slave
正式环境建议6台机器
# 这里使用三个节点
# 3节点创建cluster目录
mkdir -p /etc/redis-cluster
# 3节点创建日志目录
mkdir -p /var/log/redis
# redis-01节点复制配置文件
cd /etc/redis
cp 6379.conf 7001.conf
# redis-01节点
mkdir -p /var/redis/7001
mkdir -p /var/redis/7002
# redis-02节点
mkdir -p /var/redis/7003
mkdir -p /var/redis/7004
# redis-03节点
mkdir -p /var/redis/7005
mkdir -p /var/redis/7006
# 修改配置
cd /etc/redis
cp 6379.conf 7001.conf
------------------
# 7001.conf
cluster-enabled yes
cluster-config-file /etc/redis-cluster/node-7001.conf
cluster-node-timeout 15000
daemonize yes
pidfile /var/run/redis_7001.pid
dir /var/redis/7001
logfile /var/log/redis/7001.log
bind 192.168.68.101
appendonly yes
------------------
# 复制配置
cp 7001.conf 7002.conf
scp 7001.conf root@redis-02:/etc/redis/7003.conf
scp 7001.conf root@redis-02:/etc/redis/7004.conf
scp 7001.conf root@redis-03:/etc/redis/7005.conf
scp 7001.conf root@redis-03:/etc/redis/7006.conf
-------------
# 7002.conf
cluster-enabled yes
cluster-config-file /etc/redis-cluster/node-7002.conf
cluster-node-timeout 15000
daemonize yes
pidfile /var/run/redis_7002.pid
dir /var/redis/7002
logfile /var/log/redis/7002.log
bind 192.168.68.101
appendonly yes
-------------
# 7002.conf修改所有的7001为7002
# 7003-7006还需修改ip
# 启动脚本
cd /etc/init.d
cp redis_6379 redis_7001
cp redis_6379 redis_7002
# 分布修改端口
# 类似地修改redis-02/03的两个启动脚本
# 分别启动3个节点的6个脚本
# 查看启动日志
cat /var/log/redis/7001.log
# 使用redis官方提供的工具构建集群
# 只在redis-01节点安装即可
yum install -y ruby
yum install -y rubygems
gem install -y redis-3.3.0.gem
cp /usr/local/redis-3.2.8/src/redis-trib.rb /usr/local/bin
# --replicas 1 每个master有几个slave
redis-trib.rb create --replicas 1 192.168.68.101:7001 192.168.68.101:7002 192.168.68.102:7003 192.168.68.102:7004 192.168.68.103:7005 192.168.68.103:7006
# 续写分离\高可用\多master可以扩容
# 集群测试
redis-cli -h 192.168.68.101 -p 7001
set mykey1 v1
# 报错
# redis cluster找到key对应的hashslot对应的master
# (error) MOVED 1860 192.168.68.103:7005
set mykey2 v2
# 根据7005写入mykey1
redis-cli -h 192.168.68.103 -p 7005
set mykey1 v1
# redis-cli加-c参数自动进行重定向
redis-cli -h 192.168.68.101 -p 7001 -c
# slave主要是做热备和主备切换,读数据需要先执行 readonly
# jedis客户端对读写分离支持不好
# 可以基于jedis自己封装读写分离
# 测试高可用性
# 查看主从节点信息
redis-trib.rb check 192.168.68.101:7001
# kill 7001进程并删除pid
rm -f /var/run/redis_7001.pid
# 可以看到7001对应的slave切换成了master
# 重启7001称为slave
redis-cli -h 192.168.68.101 -p 7001
info replication
master水平扩容
# redis-03节点新建7007（master）
mkdir -p /var/redis/7007
cp /etc/redis/7005.conf /etc/redis/7007.conf
# 修改关键词7005的各项配置
cp /etc/init.d/redis_7005 /etc/init.d/redis_7007
# 修改端口
# 启动7007
# 7007加入集群
redis-trib.rb add-node 192.168.68.103:7007 192.168.68.101:7001
# 查看，可以看到7007没有slot
redis-trib.rb check 192.168.68.101:7001
# 迁移数据
redis-trib.rb reshard 192.168.31.187:7001
添加slave
mkdir -p /var/redis/7008
# redis-03 7008
cp /etc/redis/7007.conf /etc/redis/7008.conf
vi /etc/redis/7008.conf
# 修改配置
cp /etc/init.d/redis_7007 /etc/init.d/redis_7008
# 修改端口
vi /etc/init.d/redis_7008
./redis_7008 start
# 添加slave到指定master
redis-trib.rb add-node --slave --master-id f886107b2fea04f847941b7c5e110d283cd6b9e2 192.168.68.103:7008 192.168.68.101:7001
删除node
先resharding将数据移到其他节点再删除
redis-trib.rb del-node 192.168.68.101:7001 bd5a40a6ddccbd46a0f4a2208eb25d2453c2a8db
清空了一个master的hashslot时，redis cluster就会自动将其slave挂载到其他master上去
自动化slave迁移
如果每个master只有一个slave，如果slave master同时宕机，则可用性降低
可以通过挂多个slave，其他master没有slave则自动迁移
redis cluster核心原理
节点间通信使用gossip协议
另一种方案，集中式存储元数据(hashslot与node映射、master slave映射等) -> zk
gossip协议，每个master维护一份元数据
元数据变更则发送给其他节点
集中式时效性较好，缺点是单点性能瓶颈
gossip更新有延时
每个节点暴露与其他节点通信的端口
meet 加入新节点
ping 互相交换数据
pong 返回ping和meet，包含自己的状态和其他信息
fail 节点宕机
jedis客户端原理
1.请求重定向
2.计算hash slot
3.hash slot查找
本地缓存hashslot -> node的映射表，如果进行了reshard返回moved，那么利用该节点的信息，更新本地映射表
hashslot正在迁移则返回ask
通过hash tag可以保证路由到相同的节点
高可用和主备切换原理
与哨兵原理几乎一致
pfail 主观宕机
cluster-node-timeout时间内没有pong，则认为pfail，并gossip ping其他节点
fail 客观宕机，超过半数的节点认为pfail
根据offset选举，大部分节点投票给某个从节点，则切换为master
