“缓存+存储”架构下+Redis+持久化的探索与实践+-伍旭飞.pdf

缓存+存储架构Redis持久化探索与实践伍旭飞伍旭飞腾讯云数据库专家工程师•从业15年，先后从事游戏开发和数据库开发•现专注NOSQL数据库内核开发目录• 缓存诞生背景• 传统缓存方案的介绍• 传统缓存方案挑战• 业界一次努力的尝试• 次世代数据库思考以及方案• 革命成果缓存诞生的背景移动互联网海量用户• 大存储• 高并发• 低延时引入缓存的目的• 提高并发• 降低延迟• 解决热点• 降低成本传统的缓存架构AppServerRedisMemcachecachemysqlstorageAppServermysql原始架构传统缓存架构• 一致性问题• 击穿问题• 雪崩问题• 大key问题传统的缓存架构-读AppServer命中？是否读取存储更新缓存return• 并行更新存在一致性问题• 存在缓存击穿问题• 大key加载速度慢传统的缓存架构-更新1.更新存储AppServerStorageCache2.删除/更新缓存• 并行更新可能导致问题(读写并行)• 删除失败，缓存脏数据传统的缓存架构-延迟双删AppServerStorageCache2.删除缓存1.更新存储3.延迟N秒,再次删除缓存• 删除失败还是会导致脏数据• 双删会给Storage带来额外压力• 延迟时间,只减少脏数据概率传统的缓存架构-再打个补丁• 大hash/list/set/zset从存储加载到缓存依然很慢• 只能保证最终一致性,强一致依然无法保证AppServerStorageCache2.删除缓存1.更新存储3.延迟N秒,再次删除缓存4.删除失败放入队列重试传统的缓存架构-缓存淘汰淘汰策略• TTL淘汰• 缓存打满被动淘汰LRU/LFU问题• TTL设置不当容易导致雪崩• 依赖缓存打满被动淘汰性能太差传统的缓存架构-挑战• 业界期待技术革命推翻三座大山业界的一次努力尝试业界尝试-Tendis混存版clientLBProxyRedisRedisRedisTendisTendisTendisSinkSinkSink• Redis缓存所有Key成本太高• 异常情况下一致性问题未解决• 异步落冷导致性能抖动次世代数据库的思考如何更好的适配新硬件NVME SSD• 4K读写延迟低于100微秒• 4K随机读写大于10w+AEP/BPS持久内存• 8字节寻址• 读写延时~350ns• 4K随机读IOPS~600W• 4K随机写IOPS~200W随机读写依然比顺序读写慢，但是差距已经大幅缩小AEP/BPS新硬件的速度提升了一个数量级传统存储引擎的特点RocksDB• 基于机械磁盘优化• 读写放大明显• 适合写多读少,读操作IO路径长• Compaction抖动无法避免• SST文件内热点数据无法聚合Innodb• 适合基于Range查询• 针对key读/写IO路径长(B+树层次)• 基于Page缓存，k/v缓存命中效果不可控• B+树特点导致热点数据无法聚合适于Redis的存储引擎-数据组织IO访问• 读多写少• 单key查找为主(string/hash/set/zset)• 随机访问多• 极少数range查询依然采用b+tree(zset)请求延时• AEP/BPS加速持久化DRAM/AEP/SSDAEP/SSDpagebucket pageindex index index indexKVKVKVKVpageAEP/SSD适于Redis的存储引擎-热点动态聚合动态自适应热点聚合• 自适应业务热点变化• 缓存热点,减少IO访问次数• 增大缓存命中率exchange动态聚合算法• 标记阶段• 聚热阶段• 清除阶段K/VK/V热访问密度低热访问密度高适于Redis的存储引擎-冷数据降冷为什么需要降冷• 降成本• 提性能，将DRAM/AEP给热的数据• 正义(只有热数据才配占据DRAM/AEP)降冷算法• LRU主动降冷• LFU主动降冷• 驱逐被动降冷DRAM/AEPSSDcode pagecode pagecode page灵活的分级存储个性化场景适配• 多级存储灵活配置• 提速场景• 降成本场景• 归档场景AEPDRAMSSD索引/数据上浮• DRAM作为缓存• AEP作为缓存或者持久化存储革命成果-KeewiDBAppServertransaction mgrbuffer poolstorage enginehot collection一致性• 高内聚的设计解决一致性问题• 多级缓存满足各种性能要求• 让开发聚焦业务击穿• 精心设计的index远比key小• index上浮到DRAM/AEP，避免空key访问击穿雪崩及大Key• 动态智能热搬迁，热数据常驻DRAM/AEP• 大Key访问无需全部加载到内存,低延时高性能KeewiDBAll In One