缓存问题汇总

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会拒绝服务