redis备份
aof重写是根据redis的现存数据来重写的
rdb与aof优缺点?
rdb优点
写入影响最小
恢复更快
适合冷备份
缺点:
容易丢数据
fork线程生成rdb文件时 数据量大会会阻塞主线程
aof优点
尽量数据不丢失
缺点:
占用磁盘多一点
qps会受一点影响
数据恢复的时候比较慢 不方便数据冷备
hash取模算法:
其中一个master宕机之后会导致大部分请求无法拿到缓存 请求落到数据库中
一致性哈希算法:
圆环顺时针寻找节点 ,只会丢失挂掉master那部分数据
redis cluster:
key crc16值对16384取模 当其中一个master宕机之后 slot会迁移到其他机器 key只对16384取模
集群节点间通信:
gossip协议
meet 发送给新加入的节点 通知节点加入我们的集群
ping 发送ping及自己维护的集群元数据给其他node 互相交换元数据
每秒10次 选择5个最久没通信节点 避免数据交换时间过长 带上自己的数据和1/10其他节点的数据
pong 返回自己的状态 可以用于广播和更新
fail 判定某个节点为fail后会通知其他node
缓存
雪崩
事前保证redis集群/主从的高可用
事中 使用ehcache+限流降级避免mysql被打死
事后 redis持久化机制尽快恢复缓存
穿透
空值也写入缓存
缓存一致性问题
先删除缓存 再更新数据库
将更新和读取串行化 根据相同的标识路由到相同的队列中,后台线程进行处理 需要解决的问题是如果需要部署多台实例需要做实例间的请求路由
redis并发竞争
使用分布式锁控制并发 确保同一时间只有一个实例处理
加一个version值,只有新的version才能更新
生产环境的redis如何部署的?
redis热点数据如何处理?
服务端使用内部缓存,存储热点数据,分担redis压力,redis使用lfu算法 hotkeys查出redis热点数据
redis脑裂问题?
通过配置最少slave参数+断开连接时间 当脑裂发生master会拒绝服务
原文：https://www.cnblogs.com/isnotnull/p/14890539.html