同步进度
单线程模型
请求null数据
缓存击穿
String
跳表
延迟消息
主从保持长连接
内存对齐，减少碎片
识别
不支持回滚
实现
全部
Jemalloc
优化实践
1、为啥用“删”不用“更新”？如果更新缓存：写写并发 -> 数据不一致所以需要删除缓存但是可能会造成缓存击穿，解决 -> 加锁2、先删缓存还是先更新数据库a. 先写表（成本低），缓存删除失败会数据不一致，但是缓存删除失败概率较小适用：并发少（读写并发）进化 -> 旁路异步删除b. 先删缓存，数据库更新失败不会导致数据不一致，但是会产生读写并发问题导致数据不一致解决 -> 延迟双删：删（保证原子性） -> 改 -> 删（降低读写并发风险）
识别实践
AOF
京东JIMDB
删除过期
动态发现广播通知构建本地缓存
占用内存
redis
过期时间随机偏移
Lua脚本
导致
LRU
ttl
搜索困难
磁盘预读和缓存
优先级
主从同步
分类
加锁更新
服务端自动熔断限流
先更新数据，再删缓存
多线程IO
线程缓存，减少锁竞争
redis为什么用跳表？mysql为什么用B+树？
memcached
编号
三种策略
应用
惰性删除
影响性能
LFU
哨兵
缓存问题
操作系统控制
手动
频繁插入和删除操作，动态性能优
过期执行费时
发现
混合
Hash
保证原子性
击穿
打分
选主方式
定期删除
排行榜
内存淘汰策略
哈希槽
文件小、恢复速度快、适合做备份和恢复
配置：从库回应的最长时间
List
缓存null
带多级索引的链表
延迟双删：先删缓存，再更新数据，再删
迁移myql
内存分配不均
每次
本地缓存lru（热点少情况）
穿透
LRANGE、ZRANG等返回数据量大，判断阈值识别
异步更新
与数据库的一致性
Set
CRC16算法
pipeline
主从
监控(cpu+redis命令统计排序)
每秒
数据分片
随机选20个
SDS
原子
大热key场景优化
分片方式
X
单点瓶颈
单线程同时处理多个端
大key问题
删除
5种
大量缓存同时过期，请求直接打到数据库
ZSet
集合大小
集群脑裂
阶段1：累积命令，错误不执行事务
分布式集群
从节点请求主节点的RDB
服务端预测QPS和实际QPS比较：平方(QPS/预测QPS)
服务端、SDK自动缓存
故障时手动切换
事务机制
设置ttl
影响备份迁移
热key问题
why
布隆过滤器
单线程
集群模式
每秒10次
处理
快！
多线程
有过期时间
过期策略
阶段2：执行事务，错误继续执行命令
增量
页分裂和页合并，磁盘IO少
数据处理
VS
雪崩
滑动窗口
随机
提前拆分备份（有写放大问题）
数据结构高效
简单的kv
管理端操作删除
配置：同步的最少集群数量
IO多路复用
一次网络提交
缓存过期，大量请求直接打到数据库
不淘汰
治理
数据类型
全量
可靠性高，粒度更细，但文件大，恢复慢
丢失，重复，不一致无法彻底解决
其他功能
> 25%，循环
多次网络提交
AOF、RDB
字典
Redis
协议：RESP
经验
事务、lua脚本
不能完全保证数据不丢失
磁盘友好，叶子结点形成链表，节点大小=页
RDB
热点发现能力
CPU瓶颈
从节点请求主节点主节点同步写操作
旁路删除：基于binlog删除缓存
可在逻辑中有依赖关系
bigkeys
持久化
不保证原子性
增强的事务
内存友好，数据结构简单
键值设计上内存优化
拆分
流程控制，编排
客观下线
对比memcached
为什么不异步更新反而“删”？操作成本考虑，风险考虑缓存的可能需要其他上下文信息
分数.时间戳
hash槽（16384）
其他高级
优化网络延迟
B+树
基于内存
宽带瓶颈
服务端、SDK黑名单
