实际上 ， 对于应用系统中的每一台服务器 ， 还需要一层防护机制 ， 限流熔断 ， 这样做的目的是为了防止单台机器请求量过高 ， 使得服务器负载过高 ， 不至于服务器宕机或者大量请求访问数据库 。简单思路就是为每一台服务器设计一个阀值 ， 当请求量大于该值就直接返回用户空白页面或者提示用户几秒后刷新重新访问 。
数据一致性
数据一致性问题主要体现在缓存更新的时候 ， 如何更新缓存 ， 保证数据库与缓存以及各层缓存层之间的一致性 。
对于缓存更新问题 ， 先写缓存还是先写数据库 ， 这里省略若干字 。之前的文章介绍过 ， 有兴趣的读者可以翻阅 。
在单层缓存系统中 ， 我们可以先删除缓存然后更新数据库的方案来解决其数据一致性问题 ， 那么对于多级缓存呢？如果使用这种方案 ， 我们需要考虑 ， 如果先删除缓存 ， 那么需要逐层去做删除操作 ， 那么这一系列操作对系统带来的耗时也是和可观的 。
如果我们使用分布式事务机制 ， 就需要考虑该不该将写缓存放入事务当中 ， 因为我们更新分布式缓存 ， 需要走网络通信 ， 大量的请求将导致网路抖动甚至阻塞 ， 增加了系统的延迟 ， 导致系统短时间内不可用 。如果我们不将写缓存这一操作放入事务当中 ， 那么可能引起短时间内数据不一致 。这也就是分布式系统的CAP理论 ， 我们不能同时达到高可用和一致性 。那么该如何抉择呢？
这里我们选择保证系统的可用性 ， 就一个秒杀系统来讲 ， 短暂的不一致性问题对用户的体验影响并不大（当然 ， 这里不涉及支付系统） ， 而可用性对用户来说却很重要 ， 一个活动可能在很短的时间内结束 ， 而用户需要在这段时间内抢到自己心仪的商品 ， 所以可用性更重要一些（这里需要根据具体场景进行权衡） 。
在保证了系统的可用性的基础上 ， 我们该如何实现呢？如果实时性要求不是很高 ， 我们可以采用全量+增量同步的方式进行 。首先 ， 我们可以按照预计的热点key对系统进行缓存预热 ， 全量同步数据到缓存系统 。接着 ， 在需要更新缓存的时候 ， 我们可以采用增量同步的方式更新缓存 。比如我们可以使用阿里Canal框架同步binlog的方式进行数据的同步 。
缓存过期
缓存系统中的所有数据 ， 根据数据的使用频率以及场景 ， 我们可以分为过期key以及不过期key ， 那么对齐过期缓存我们该如何淘汰呢？下面有常用的几种方案：
FIFO：使用FIFO算法来淘汰过期缓存 。
LFU：使用LFU算法来淘汰过期缓存 。
LRU：使用LRU算法来淘汰过期缓存 。
以上几种方案是在缓存达到最大缓存大小的时候的淘汰策略 ， 如果没有达到最大缓存大小 ， 我们有下面几种方式：
定时删除策略：设置一个定时任务 ， 在规定时间内检查并且删除过期key 。
定期删除策略：这种策略需要设置删除的周期以及时长 ， 如何设置 ， 需要根据具体场合来计算 。
惰性删除策略：在使用时检查是否过期 ， 如果过期直接去更新缓存 ， 否则直接返回 。
【千万级并发！如何设计一个多级缓存系统？】
推荐阅读
- 白冰|网红白冰怎么了？粉丝千万却突然宣布停更，网友：要减肥了
- 淘宝直播怎么升级钻粉 淘宝直播间怎么升级钻粉需要多少
- 淘宝直播等级分几级 淘宝直播等级有什么用
- 优化不止系统层级，ColorOS新模式力压小米、华为
- 6月9日微信支付升级维护通知
- 老师，我想对您说”，六年级学生作文够真实 老师我想对你说作文600字
- 如何设计一个高并发系统？
- 科夫级护卫舰 戈尔什科夫海军元帅级护卫舰
- 淘宝层级如何提升 淘宝商家层级
- 茶有千万种 正如这世上有千姿百态的女子样