09 Redis_IMAGE_02REDIS集群知识点
2020-10-07 19:42:51 0 举报
登录查看完整内容
为你推荐
查看更多
redis学习记录2
作者其他创作
大纲/内容
LVS
redis集成布隆
jedis
redis
监控
同步阻塞
redis2
redis中提供的master-slave模式：异步发送数据的方式正常的情况下：master和replica之间的数据同步是采用追加的方式，主要是靠replicationID以及offset，来部分追加同步的。全量复制：1.其他情况，如果replica宕机，如果slave采用的rdb的形式的话，会采用追加的形式，但是如果采用的是AOF的话，就是全量同步，因为AOF在重写之后没有记录replicationID2.如果master挂机，全量replica。3.如果replica挂机一段时间之内，master的的写操作字节超出了缓冲区域，那么在从机在追随主机之后，也是会全量的复制的
无状态！
时点性无关
2
业务
client02
解决数据倾斜问题
有可能取到不一致的数据强调：最终一致性
clientservice
逻辑：kemata一致性哈希没有取模data，node
0~2^32
sentinel
网络IO
不要因为技术而技术
client
master对slave机器进行发送信息
API
从业务接收查询的是你系统根本不存在的数据
单机、单节点、单实例1，单点故障2，容量有限3，压力
client04
主从复制配置
client01
零点
面试常问：击穿，穿透，雪崩，分布式锁，API （jedis，luttce，springboot：low/high level）
击穿
数据可以分类，交集不多
关注代理成性能
redis的连接成本很高对server端造成的
1：client
proxy
这个是物理的
多线程一个线程取DB一个线程监控是否取回来。更新锁时间
redis02
数据分治聚合操作很难实现事务
环上的点是虚拟的
2-3：client
client03
算法bitmap ->redis无状态
优点：你加节点，的确可以分担其他节点的压力，不会造成全局洗牌缺点：新增节点造成一小部分数据不能命中1，问题，击穿，压到mysql2，方案：没去取离我最近的2个物理节点更倾向于 作为缓存，而不是数据库用！！！！
redis1
配置文件redis源码目录
分布式锁：redis
穿透：数据库和redis缓存中没有相应的数据，大量并发压到数据库解决方案：过滤器 布隆过滤器可以在client端实现算法以及redis的热点数据的bitmap可以在client端实现算法redis中维护bitmap可以使用redis的组件布隆过滤器但是布隆过滤器有个问题，数据无法删除，如果某个时间点我们的热点数据需要下线，对于这样的数据布隆过滤器无法进行有效拦截，可以通过设置特殊的value进行标识也可以采用布谷鸟过滤器，这个过滤器可以删除过滤器中的key映射关系。
sharding分片
穿透
hash%10
3，只有获得锁的去访问DB
2-1：client
问题：1，如果第一个人挂了？
分区容忍性
set k1 a
RDB
强依赖击穿方案
LRULFU
布隆过滤器
hash
DB
弊端：3个模式不能做数据库用预分区
对 主 做HA高可用自动的故障转移：代替人
雪崩：是击穿的放大版大量的key因为过期时间失效，解决方案：1.如果是对过期时间没有要求的话，我们在设置key的过期时间分布设置（随机过期时间设置）2.如果过期时间只能是某一个时间点的话，我们可以参考击穿的解决方案，采用锁+多线程的方式解决
X
befor：肯定发生了高并发
replica-serve-stale-data yesreplica-read-only yesrepl-diskless-sync norepl-backlog-size 1mb #增量复制min-replicas-to-write 3min-replicas-max-lag 10
异步
主读写自己又是一个：单点
推导：1，统计不准确，不够势力范围问题：网络分区脑裂：对外提供两种不同的结果2 在3个节点成功解决脑裂问题3 在4个节点成功解决脑力问题3 在5个节点成功解决脑力问题n/2+1 过半！使用奇数台！为什么使用奇数台，因为再能保证服务的前提下，提供偶数台服务所承受的风险要比奇数台的风险要大
虚拟节点
keepalived
数据没办法划分拆解
主从复制
node02
kafka可靠，集群响应速度够快
DBMySQL
最终数据会一致
逻辑：业务拆分
redis-sentienl
有一些不一样的地方的
业务层加判断零点延时。。。
offset
强一致性破坏可用性
redis01
redis单机单进程缓存数据库
并发有了：阻止并发到达DBredis又没有keyredis是单进程单实例setnx() -> 锁1，get key2，setnx3-1，ok，去 DB3-2，false，sleep -> 1
磁盘IO
2-2：client
大量的key同时失效间接造成大量的访问到达DB
无论企业后面技术多么复杂对于客户端，是透明的
3
逻辑：randomlpush
弊端：取模的数必须固定%3%4%10影响分布式下的扩展性
clientget k1
slave
nginx
无论是主从还是主备的模式，都会存在单点故障的问题三种模式解决单点故障的问题，但是都会有响应的问题
2，setnx
master
rdb
少量的或者是某一个KEY的过期造成并发访问数据库
datakey
port 26379sentinel monitor mymaster 127.0.0.1 6381 2
算法：hash+取模modula
Z
k1 -> （4）redis3
都给出OK强一致性由于网路的原因，有可能已经出现了单点故障，但是我们的监控没有反馈，破坏了可用性
可以设置锁的过期时间
redis缓存key 过期时间LRULFU
1，null
通过AKF一变多数据一致性！！！！所有节点阻塞直到数据全部一致*，同步方式阻塞方式强一致性！破坏可用性！反问自己：为什么一变多，解决可用性*，通过异步方式1，容忍数据丢失一部分
代理层：逻辑实现！modularandomkemata
规划一个环形哈希环
RDBAOF
redismaster
雪崩
redis缓存
集群方式
2-2：clientrpop
问题：不能删除布谷鸟空key
随机过期时间
pool连接池
队列
save
消息队列ooxx：topic&partitionkafka
node03
redisepoll
通过发布订阅发现其他哨兵
x轴扩展主从集群
twpredixyclustercodis
弱一致性丢失数据
hashcrc16crc32fnvmd5[映射]算法
由一个技术、程序实现只要是一个程序就会有单点故障的问题一变多的集群
redis-server --sentinel
AKFX：全量，镜像Y：业务，功能Z：优先级，逻辑再拆分
你自己实现分布式协调很麻烦
redis3
人是怎么监控的
hash tag{oo}k1{oo}k2
主备
1
直接通过网络发送RDB
client包含
问题：2，没挂，但是，锁超时了。。。
node01
y轴扩展业务分区
z轴扩展数据分片
VIP
1，setnx2，过期时间3，多线程（守护线程）延长过期redisson （已经实现好的jar包，直接引入即可，但是一般来说我们都是用zookeeper做分布式锁）zookeeper 做分布式锁！
Y
需要人工维护主的故障问题
用户client
ooxxlist
收藏
收藏
0 条评论
回复 删除
下一页
