《Redis集群》图解
2022-04-24 11:24:40 0 举报登录查看完整内容
Redis 集群图解
作者其他创作
大纲/内容
Redis_01
不断的检查主从服务器是否运行正常
RDB
Redis
Sentinel
需要先启动master和slave
client端解决方案需要client端实现一部分代码逻辑
Redisrandom
slave默认: readonly
Redis从
master的所有写操作会同步到两个slave上
slave
队列
监控者
redis-sentinel 26379.conf
返回Redis_03的信息
client01
自动故障转移Automatic failover
hash算法
人工操作方式
同步阻塞
靠谱!
AKF
Redis_02
slave加载RDB
repl-backlog-size开启增量同步
LVS主
Redis的实现方式
这里指定要移动到哪个master上
异步的方式同步允许丢失一部分数据
Redis主
版本5之前
监控者挂掉
写操作
replicaof host port
使用代理技术做负载均衡此时需要关注代理性能问题
Redis用户信息
LVS备
异步非阻塞
lpush
网络IO传输RDB
replicaof host port追随
redis-server 26380.conf --sentinel
slaveof
psubscribe * : 监听所有频道或者 psubscribe __sentinel__:hello : 监听sentinel聊天的频道
传输RDB给slave
数据迁移
弱一致性
client
先flush old data再Loading DB
master
Proxynginx
CRC16(key) mod 16384
读
redis-cli --cluster info 127.0.0.1:30001 (需要是任意的一个master的ip port) 查看槽位信息
master6379
proxy
强一致性
Redis cluster
redis-cli --cluster reshard 127.0.0.1:30001(需要进行槽位转出的master的IP和PORT) 指定要从30001转移处槽位
使用如下命令检查也行: 指定任意一个master的信息就行redis-cli --cluster check masterIP:masterPort
Redis页面
最好的方式
listooxx
不可靠
可以看出此时槽位分布式比较均匀的
twemproxy分片代理具体算法配置内配置
版本5之后
数据不好拆分
master读写
6380
自动的故障转移
优化方案
sharding
repl-diskless-sync yes不再落磁盘直接网络传输(网络IO)只有一次IO
predixy分片代理具体算法配置内配置
Redis_03
Redis短时间下线
启动后
repl-diskless-sync no先落磁盘(磁盘IO)再网络传输(网络IO)要经过两次IO
直接取模10 %10的算法
client请求Redis_03
简单使用
100G的内存
repl-backlog-size
26379.conf
逻辑拆分random随机
容量问题
也就是哨兵机制: sentinel
master等待slave完成写salve返回
移动完毕
Redis页面数据
方案来源: github: twemproxy
Redisb开头的key
半数以上
不支持事务不支持哨兵等
传输
repl-diskless-sync
两次IO
单机Redis存在的问题
replicaof
replicaof no one
??????WTH...
需要多个监控程序协同进行监控
Redis采用的是弱一致性
主从复制配置
这种扩展模式也就是AKF
监控monitoring
Redis订单数据
2个节点决策成功才是成功
算法拆分hash+取模(模Redis台数)modula
replica-serve-stale-data
Redissharding分片
读写
replicaof host 6380
slave6380
逻辑randomlpush
使用代理技术做负载均衡使用keepalive + LVS来处理代理的性能问题
hash+取模 弊端: span style=\"font-size: inherit;\
磁盘IO
sentinel启动后会自动修改配置文件
算法拆分一致性hashkemata
通过AKF解决单机版Redis问题
假如当前取模 %2
人工解决方案
场景
redis-cli --cluster create ip:port..ipN:portN
按key拆分
不搞一言堂!要民主!少数服从多数!
redis-cli -c -p port
offset
提醒Notification
Redis订单
代理层3种算法randommodula一致性hash
判断master是否故障
Redisa开头的key
容量有有限
启动三台sentinel
clientlpop
ooxx 可以看做消息队列中的topic
redis-server 26379.conf --sentinel
repl-diskless-sync传输方式
开启后
需要参考人为是怎么监控的
压力问题比如请求压力
git clone https://github.com/twitter/twemproxy.gitcd twemproxyyum install -y automake libtoolautoreconf -fvi./configuremakecd twemproxy/scriptscp nutcracker.init /etc/init.d/twemproxycd /etc/init.dchmod +x twemproxycd /usr/local/opt/twemproxy/confspan style=\"font-size: inherit;\
slave6381
replicaof host 6380
一次IO
slave6379
一变多
重新启动
这里输入需要转移出的槽位的数量
redis-server 26381.conf --sentinel
等价
监控者需要有奇数台
26381.conf
算法拆分hash+取模(模Redis台数)
26380.conf
单点故障
按业务划分
基于X轴的扩展: 解决了单点故障以及部分压力问题
所以: 最终只要其中监控者做出决策就作为最终决策
repl-backlog-size未开启全量同步
最终一致性
AKF之: 一变多
????
keepalive
Redis主从复制
收藏
收藏
0 条评论
回复 删除
下一页
