/tags/cache.html Recent content in Cache on IT 运维小秋 Hugo -- gohugo.io zh-cn chenwx716@139.com chenwx716@139.com Tue, 13 Dec 2022 00:00:00 +0800 /p/cache.html Tue, 13 Dec 2022 00:00:00 +0800 chenwx716@139.com /p/cache.html <p><strong>目的:</strong></p> <ol> <li>加速访问</li> <li>减轻后端服务的压力</li> </ol> <p>原理:</p> <ul> <li>离用户更近的位置存储</li> <li>离应用更近的位置存储</li> <li>更高速的存储介质存储</li> </ul> <p>需要缓存的内容</p> <ul> <li>热点数据</li> <li>静态资源</li> </ul> <p>过期策略</p> <ul> <li>固定时间：比如指定缓存的时间是30分钟；</li> <li>相对时间：比如最近10分钟内没有访问的数据；</li> <li>事件通知: 缓存管理线程按事件通知进行删除</li> </ul> <p>缓存淘汰算法</p> <ul> <li>FIFO (First In First Out) 先进先出</li> <li>LRU (Least Recently Used) 最近最少使用</li> <li>LFU (Least Frequently Used) 在一段时间内使用频率最小的数据被移除缓存</li> </ul> <h2 id="缓存媒介">缓存媒介</h2> <p><strong>常用中间件</strong>: Varnish, Ngnix, Squid, Memcache, Redis, Ehcache 等;</p> <p><strong>缓存的内容</strong>: 文件, 数据, 对象;</p> <p><strong>缓存的介质</strong>: CPU, 内存(本地, 分布式), 磁盘(本地, 分布式)</p> <h2 id="分级缓存">分级缓存</h2> <p>用户侧</p> <ul> <li>客户端程序内</li> <li>浏览器 cookie, sessionStorage, localStorage, IndexDB</li> </ul> <p>CDN缓存</p> <ul> <li>用户就近访问, 主要原理还是依靠智能 DNS, 主要缓存 HTML, CSS, JS, 视频等静态资源;</li> </ul> <p>应用服务缓存</p> <ul> <li>nginx 本地缓存: html/css/js/ico 等少量小文件</li> <li>nginx + Lua Shared Dict 对简单的接口数据缓存</li> <li>squid/Varnish: 大量静态资源, 如视频 / 图片</li> <li>redis 缓存动态内容, 减轻数据库压力</li> <li>本地缓存, 即同一个主机或pod内附加一个缓存服务</li> <li>应用内缓存</li> </ul> <p>存储侧缓存</p> <ul> <li>例如 mysql 增大 buffer_pool</li> <li>SSD 和 SATA 区分冷热文件缓存</li> </ul> <h2 id="常见问题">常见问题</h2> <h3 id="数据一致性问题">数据一致性问题</h3> <ul> <li>双写</li> <li>异步刷新</li> <li>先缓存后DB/先DB后缓存</li> <li>独立的缓存管理进程负责更新缓存</li> </ul> <p>需要考虑一致性的地方</p> <ul> <li>cache - db</li> <li>cache - 多级缓存</li> <li>cache - 副本</li> </ul> <p>cache和db的前后更新顺序</p> <p><strong>insert key</strong></p> <p>先 write cache 再 DB;</p> <p>假如缓存写成功, 但写数据库失败或响应延迟, 则下次读取(并发读)缓存时, 就出现脏读，所以这种方式不可取。</p> <p>先 write DB, 再 cache;</p> <p>假如写数据库成功, 但写缓存失败, 则下次读取(并发读)缓存时, 则读不到数据，读不到数据时, 再请求一次数据库, 并刷新缓存；</p> <p><strong>update key</strong></p> <p>先 del cache key, 再 update db, 再 add key</p> <p>如果更新库失败, 则后续读 key 时会先读缓存, 引发 cache miss, 再读取库, 更新缓存, 并不会造成数据不一致；</p> <p>如果是分布式环境, 则可能服务 A 在 del cache key 后, 未完成更新 db 时, 服务 B 读库, 并更新了 cache, 造成数据不一致。</p> <p>解决办法:</p> <ol> <li>锁, 对此 key 添加写锁, 如果更新库成功或失败后才释放</li> <li>串行队列执行关于此 key 的业务</li> <li>关于此 KEY 的业务定点到某一个 server 去串行执行;</li> </ol> <p><strong>缓存异步刷新</strong></p> <p>如果数据库操作和写缓存不在一个操作步骤中, 比如在分布式场景下, 无法做到同时写缓存或需要异步刷新(补救措施)时候；</p> <p>解决办法: 看业务特性进行针对性解决。</p> <h3 id="热点数据缓存">热点数据缓存</h3> <p>即只能缓存少量的数据时, 将访问比例最大的部分数据进行缓存;</p> <p>如: 最近登录用户, 最新活动数据</p> <p>队列模型</p> <ol> <li>建立一个定长队列，放置最近1000个用户的UID，最新用户放置在队列顶部；</li> <li>当请求发送过来时，判断UID是否在队列中，是则访问热点缓存<br /> 不在队列中，则读取库或者冷缓存，然后将UID放入队列，并将数据写如热缓存；</li> <li>定期移除队列的后200位UID，并且移除热缓存的key；<br /> 热点用户将一直存在于队列顶部区域，不会被移除</li> </ol> <p>场景2: 某几个热点key被hash到同一个缓存节点, 节点失效或重启时影响极大;</p> <p>办法: 定期或开发阶段 对缓存key进行统计分析, 业务上再进行key拆分；</p> <h3 id="缓存雪崩">缓存雪崩</h3> <p>雪崩是指当大量缓存集中失效时(ttl到期或重启缓存服务)，大量的请求直接访问数据库的场景</p> <p>应对方法：</p> <ul> <li>合理规划缓存的失效时间, 离散过期时间分布；</li> <li>合理评估数据库的负载压力, 限制连接数</li> <li>应用层熔断和限流机制；</li> <li>多级缓存设计，考虑备用缓存</li> </ul> <h3 id="缓存穿透">缓存穿透</h3> <p>场景1: 某个key不存在, 大量请求频繁落到数据库上去查询并更新缓存;</p> <p>场景2: 大量请求一些不存在的资源, 如通过遍历商品编号获取属性的恶意请求;</p> <p>办法</p> <ul> <li>缓存预热, 提前写入缓存或推送到用户侧</li> <li>对空值的结果也进行缓存, ttl 时间稍短</li> <li>入口安全拦截措施阻挡恶意访问;</li> <li>只有获取到分布式锁的线程才能去数据库查询并更新缓存</li> </ul> <h3 id="太多分片导致的多次网络io开销">太多分片导致的多次网络IO开销</h3> <p>例如一笔业务需要3次缓存操作；如果分为3个缓存实例，则有可能与3个设备发生3次网络IO，增加了业务时延；<br /> 办法：</p> <ol> <li>连接池，避免新建连接</li> <li>缓存分布方式优化，通过对key进行范围存储，避免hash的无序，来确保关联key存放于固定实例上</li> <li>合并数据，将多次小操作，合并为一次大操作来减少网络IO</li> </ol> <h3 id="持久化问题">持久化问题</h3> <ol> <li>设计上要求缓存不需要持久化</li> <li>如果缓存失效对数据库压力太大，还是需要持久化</li> <li>缓存节点的复制，由异步改为双写</li> <li>多级缓存</li> </ol> <h2 id="反向代理缓存">反向代理缓存</h2> <p>一般指在网站服务器机房部署代理服务器, 实现负载均衡, 数据缓存, 安全控制等功能</p> <p>常用的代理缓存有 Varnish, Squid, Ngnix, nginx+lua 简单比较如下:</p> <ul> <li>varnish 和 squid 是专业的 cache 服务, 多用于资源站进行对象缓存;</li> <li>简易的静态资源缓存推荐使用nginx</li> <li>少量简易的动态内容缓存可以使用nginx+lua或类似网关服务</li> </ul> <h2 id="分布式缓存">分布式缓存</h2> <p>主要指缓存用户经常访问数据的缓存，数据源为数据库</p> <p>一般起到热点数据访问和减轻数据库压力的作用</p> <p>主要使用 Memcache and Redis</p> <p>常用分片算法</p> <ol> <li>哈希算法，哈希后取模</li> <li>一致性哈希算法: 一致性 Hash 是将数据按照特征值映射到一个首尾相接的 Hash 环上，同时也将缓存节点映射到这个环上</li> <li>Range Based 算法: 例如根据key前缀分片</li> </ol> <h2 id="进程内缓存">进程内缓存</h2> <p>应用内部自身的缓存, 如应用字典等常用数据, 一般配合外部缓存或二级双缓存</p> <p>场景</p> <ul> <li>频繁访问的配置项目</li> <li>高并发时的小规模的热点数据, 如果活动配置</li> </ul> <p>特点</p> <ul> <li>不需要序列化和反序列化，无网络开销, 速度最快</li> <li>总大小需要严格控制</li> <li>考虑数据一致性</li> </ul> <p><strong>二级缓存面临的分布式一致性问题</strong></p> <ol> <li> <p>消息队列修改方案<br /> 应用在修改完自身缓存数据和数据库数据之后，给消息队列发送数据变化通知，<br /> 其他应用订阅了消息通知，在收到通知的时候修改缓存数据。</p> </li> <li> <p>Timer 修改方案<br /> 对&quot;实时一致性&quot;不敏感的情况下，每个应用都会启动一个 Timer，定时从数据库拉取最新的数据，更新缓存</p> </li> </ol> <h2 id="cdn加速缓存">CDN加速缓存</h2> <p>Content Delivery Network, 即内容分发网络</p> <p>CDN 主要解决将数据缓存到离用户最近的位置, 一般缓存静态资源文件(页面, 脚本, 图片, 视频, 文件等);</p> <p>工作路径:</p> <ol> <li>客户端发起请求, 先进行 DNS 解析, cname 到 cdn 的 dns 负载均衡服务器;</li> <li>cdn 域名服务器将最近 CDN 节点的 IP 响应给用户</li> <li>客户端请求最近的 CDN 节点;</li> <li>CDN 节点如果有缓存则响应缓存, 无缓存则回源获取数据后再响应。</li> </ol> <p><strong>动态接口加速</strong><br /> cdn除了做静态资源缓存，另一个主要作用是对动态接口的加速。</p> <p>因为用户直接到源服务器的网络质量，不一定有 用户-cdn节点-源服务器 的网络质量好;</p> <p>所以cdn的接口加速一般也会有较好的效果;</p> <p><strong>其它用途</strong></p> <ol> <li>减少源站带宽资源</li> <li>抗攻击, 抵御 ddos 攻击</li> </ol> <p><strong>缓存一致性问题</strong></p> <ul> <li>静态资源文件名采用hash命名方式</li> <li>合理配置过期时间</li> <li>调用厂商缓存刷新接口释放缓存</li> </ul> <hr /> <h2 id="缓存架构设计要点">缓存架构设计要点</h2> <p><strong>容量规划</strong></p> <ul> <li>缓存内容的大小：总容量大小，主要key的大小，最大key的大小，单实例大小，主机内存大小，实例数；</li> <li>缓存内容的数量</li> <li>淘汰策略</li> <li>缓存的数据结构</li> </ul> <p><strong>性能优化</strong></p> <ul> <li>每秒的读峰值</li> <li>每秒的写峰值</li> <li>线程模型</li> <li>预热方法</li> <li>缓存分片</li> <li>冷热数据的比例</li> </ul> <p><strong>高可用</strong></p> <ul> <li>复制模型</li> <li>失效转移</li> <li>持久策略</li> <li>缓存重建: 迁移或清空后如何快速恢复</li> </ul> <p><strong>缓存监控</strong></p> <ul> <li>容量</li> <li>可用性</li> <li>响应时间</li> <li>大对象, 慢查询</li> <li>命中率</li> </ul> <p><strong>注意事项</strong></p> <ul> <li>是否有可能发生缓存穿透</li> <li>是否有大对象</li> <li>是否使用缓存实现分布式锁</li> <li>是否使用缓存支持的脚本（Lua）</li> <li>是否避免了 Race Condition(多线程竞争)</li> </ul> <p><strong>业务设计</strong></p> <ul> <li>不同的业务单元使用隔离的缓存实例，避免干扰</li> <li>缓存超时时间：较长的超时时间会占用过多线程池连接数</li> <li>key应该设置失效时间，避免内存不足</li> <li>失效时间不能集中，可加随机值，避免缓存雪崩</li> <li>低频访问的内容不需要放在缓存中</li> <li>单个key不宜过大，特别是redis这种单线程实例，会产生阻塞</li> <li>redis危险命令: keys HGETALL 容易造成请求阻塞</li> <li>有大量的更新数据时，尤其是批量处理时，可以使用批量模式加速</li> <li>在通常情况下，读的顺序是先缓存，后数据库；写的顺序是先数据库，后缓存</li> <li>要考虑到如果后期缓存迁移时的业务连续性</li> <li>所有集合型的数据结构(哈希、列表等)，则都要考虑为它设置最大限制，避免内存用光;</li> <li>考虑缓存降级，如主备切换期间，业务侧的缓存连接异常时，如何连接到备，或数据库</li> <li>key使用不同的前缀进行逻辑隔离，避免不同业务的干扰</li> </ul>