2023年6月29日发(作者：)

Redis性能调优——缓存设计优化Redis 是⼀个开源的⾼性能的 Key-Value 服务器。本篇主要介绍⼀下缓存的设计与优化。1. 缓存的受益与成本-说明1、加速读写，通过缓存加速读写速度，例如 CPU L1/L2/L3 Cache、Linux page Cache 加速硬盘读写、浏览器缓存、Ehcache 缓存数据库结果；2、降低后端负载，后端服务器通过前端缓存降低负载，业务端使⽤ Redis 降低后端 MySQL 负载等。1、数据不⼀致，缓存和数据层有时间窗⼝不⼀致，和更新策略有关；2、代码维护成本增加，多了⼀层缓存逻辑；3、运维成本增加。缓存的受益缓存的成本缓存的使⽤场景：降低后端负载，对⾼消耗的 SQL，例如 join 结果集/分组统计结果缓存；加速请求响应，利⽤ Redis/Memcache 优化 IO 响应时间；⼤量写合并为批量写，例如计数器先 Redis 累加再批量写 DB。2.单线程架构Redis 在⼀个同⼀时间点只会执⾏⼀条命令。⼤多情况下，单线程是⾮常慢的。Redis 单线程架构为什么这么快？1. 主要原因：纯内存；2. ⾮阻塞 IO，Redis 使⽤ Event Loop 这样的模型作为 IO 多路复⽤的实现，并且 Redis ⾃⾝实现了⼀个事件处理，将 Event Loop连接、读写、关闭转换为⾃⾝的⼀个事件，不再往 IO 上浪费过多时间；3. 避免线程切换和竞态消耗；单线程架构要注意什么？1. ⼀次只运⾏⼀条命令；2. 拒绝长（慢）命令，例如 keys、flushall、flushdb、slow lua scrip、mutil/exec、operate big value（collection）；2.缓存更新策略策略LRU/LFU/FIFO 算法剔除超时剔除主动更新说明例如 maxmemory-policy例如 expire开发控制⽣命周期⼀致性最差较差强维护成本低低⾼两条建议：低⼀致性：推荐最⼤内存和淘汰策略；⾼⼀致性：推荐超时剔除和主动更新结合，超时剔除是给主动更新做了⼀个兜底，还需要最⼤内存和淘汰策略⼆次兜底。3.缓存粒度控制从 MySQL 获取⽤户信息：select * from user where id = {id}设置⽤户信息缓存：set user:{id} ‘select * from user where id = {id}’缓存粒度：全部属性：set user:{id} ‘select * from user where id = {id}’部分重要属性：set user:{id} ‘select importantColumn1, …importantColumnK from user where id = {id}’缓存粒度控制的三个⾓度：通⽤性：全部属性更好；占⽤空间：部分重要属性更好；代码维护：表⾯上全部属性更好，增删字段不需要维护代码。4.缓存穿透优化缓存穿透问题，⼤量请求不命中？发⽣缓存穿透的常见原因：业务代码⾃⾝问题；恶意攻击、爬⾍等等。如何发现问题？业务的响应时间；业务本⾝问题；相关监控指标：总调⽤数、缓存层命中数、存储层命中数；缓存穿透问题解决⽅案：⽅案⼀：缓存空对象。⽰例代码：public String getPassThrough(String key) { String cacheValue = (key); if (k(cacheValue)) { String storageValue = (key); (key, storageValue); //

如果存储数据为空,

需要设置过期时间 if (k(storageValue)) { (key, 300); // 300秒 } return storageValue; } else { return cacheValue; }}⽅案⼆：布隆过滤器拦截。通过很⼩的内存来实现对数据的过滤。5.缓存雪崩优化缓存雪崩：由于 cache 服务承载⼤量请求，当 cache 服务异常/脱机后，流量直接压向后端组件（例如 DB），造成级联故障。缓存雪崩优化⽅案：保证缓存⾼可⽤性，例如 Redis Cluster、Redis Sentinel、VIP；依赖隔离组件为后端限流；提前演练，例如压⼒测试。6.⽆底洞问题优化⽆底洞问题：增加机器性能没能提升，反⽽下降。问题关键点就是批量操作的链化，例如 mget 操作，时间复杂度为 O(node)，随着机器的增加，mget 批量操作的时间会越长，更多的机器不代表更多的性能。但是随着数据增长，⽔平扩展是必须的。优化 IO 的⼏种⽅法：命令本⾝优化，例如慢查询 keys、hgetall bigkey；减少⽹络通信次数；降低接⼊成本，例如客户端使⽤长连接/连接池、NIO 等 。7.热点key优化发现热点key：⽅法⼀：客户端，可以使⽤ Guava 的 AtomicLongMap，记录 key 的调⽤次数：public static final AtomicLongMap ATOMIC_LONG_MAP = ();String get(String key) { counterKey(key); ...}String set(String key, String value) { counterKey(key); ...}⽅法⼆：代理端客户端和 Redis 中间加⼀个代理进⾏收集统计。⽅法三：服务端使⽤ monitor 解析，输出统计。⽅法四：机器收集抓取分析 Redis 所在机器的 TPC 数据。四种⽅式对⽐：⽅案优点缺点1、内存泄露隐患，如果 key 量太⼤不建议使⽤；客户端1、实现简单；2、维护成本⾼；3、只能统计单个客户端；代理端1、代理是客户端和服务端的桥梁，实现最⽅便最系统；1、增加代理端的开发部署成本；1、monitor 本⾝的使⽤成本和危害，只能短时间使⽤；2、只能统计单个 Redis 节点；1、需要专业的运维团队开发，并且增加了机器的部署成本；服务端1、实现简单；机器收集1、对于客户端和服务端⽆侵⼊和影响；优化⽅案：避免 bigkey；热键不要⽤ hash_tag，因为 hash_tag 会落到⼀个节点上；如果真有热点 key ⽽且业务对⼀致性要求不⾼时，可以⽤本地缓存 + MQ 解决。8.热点key重建优化问题：热点 key + 较长的重建时间。获取缓存 -> 查询数据源 -> 重建缓存 -> 输出，这个步骤在⾼并发的情况下，由于查询数据源需要时间，所以会有很多请求会进⼊到 查询数据源 -> 重建缓存 这个过程。对数据源会造成很⼤压⼒，响应时间也会变慢。三个优化⽬标：减少重建缓存的次数；数据尽可能⼀致；减少潜在风险。两个优化⽅案：互斥锁（mutex key），查询数据源 -> 重建缓存 这个过程加互斥锁；永不过期，缓存层⾯不设置过期时间（没有⽤ expire），功能层⾯为每个 value 添加逻辑过期时间，但发现超过逻辑过期时间后，会使⽤单独的线程去构建缓存。两个优化⽅案的对⽐：策略互斥锁永不过期优点思路简单，保证⼀致性基本杜绝热点 key 重建问题缺点代码复杂度增加，存在死锁的风险不保证⼀致性，逻辑过期时间增加维护成本和内存成本9.总结缓存收益：加速读写、降低后端存储负载；缓存成本：缓存和存储数据不⼀致性、代码维护成本、运维成本；推荐结合剔除、超时、主动更新三种⽅案共同完成；穿透问题：使⽤缓存空对象和布隆过滤器来解决，注意它们各⾃的使⽤场景和局限性；⽆底洞问题：分布式缓存中，有更多的机器不保证有更⾼的性能。有四种批量操作⽅式：串⾏命令、串⾏ IO、并⾏ IO、hash_tag；雪崩问题：缓存层⾼可⽤、客户端降级、提前演练是解决雪崩问题的重要⽅法；热点 key 重建问题：互斥锁、永不过期能够在⼀定程度上解决热点 key 问题，开发⼈员在使⽤时要了解它们各⾃的使⽤成本。