前言
欢送各位进群 973961276 一起聊聊技术吹吹牛，每周都会有几次抽奖送专业书籍的流动，奖品虽不甚值钱，但也算个彩头不是
我是 Redis
你好，我是 Redis，一个叫 Antirez 的男人把我带到了这个世界上。
说起我的诞生，跟关系数据库 MySQL 还挺有渊源的。
在我还没来到这个世界上的时候，MySQL 过的很辛苦，互联网倒退的越来越快，它包容的数据也越来越多，用户申请也随之暴涨，而每一个用户申请都变成了对它的一个又一个读写操作，MySQL 是苦不堪言。尤其是到“双 11”、“618“这种全民购物狂欢的日子，都是 MySQL 受苦受难的日子。
据起初 MySQL 通知我说，其实有一大半的用户申请都是读操作，而且常常都是反复查问一个货色，节约它很多工夫去进行磁盘 I /O。
起初有人就推敲，是不是能够学学 CPU，给数据库也加一个缓存呢？于是我就诞生了！
出世不久，我就和 MySQL 成为了好敌人，咱们俩经常携手呈现在后端服务器中。
应用程序们从 MySQL 查问到的数据，在我这里注销一下，前面再须要用到的时候，就先找我要，我这里没有再找 MySQL 要。
为了方便使用，我反对好几种数据结构的存储：
- String
- Hash
- List
- Set
- SortedSet
- Bitmap
- ······
因为我把注销的数据都记录在内存中，不必去执行慢如蜗牛的 I / O 操作，所以找我要比找 MySQL 要省去了不少的工夫呢。
可别小瞧这简略的一个扭转，我可为 MySQL 加重了不小的累赘！随着程序的运行，我缓存的数据越来越多，有相当局部工夫我都给它挡住了用户申请，这一下它可乐得清闲自在了！
有了我的退出，网络服务的性能晋升了不少，这都归功于我为数据库挨了不少枪子儿。
零根底和大三大四的敌人看这里 >>c/c++ 企业级我的项目实战
曾经工作了想持续自我晋升跳槽涨薪的工程师看这里 >>c/c++ linux 服务器高级架构师学习
技术问题加我 WeChat：lingshengxy 收费征询，有工夫会一一答复
缓存过期 && 缓存淘汰
不过很快我发现事件不妙了，我缓存的数据都是在内存中，可是就算是在服务器上，内存的空间资源还是很无限的，不能无节制的这么存上来，我得想个办法，不然吃枣药丸。
不久，我想到了一个方法：给缓存内容设置一个超时工夫，具体设置多长交给应用程序们去设置，我要做的就是把过期了的内容从我外面删除掉，及时腾出空间就行了。
超时工夫有了，我该在什么时候去干这个清理的活呢？
最简略的就是定期删除，我决定 100ms 就做一次，一秒钟就是 10 次！
我清理的时候也不能一口气把所有过期的都给删除掉，我这外面存了大量的数据，要全面扫一遍的话那不晓得要花多久工夫，会重大影响我接待新的客户申请的！
工夫紧工作重，我只好随机抉择一部分来清理，能缓解内存压力就行了。
就这样过了一段日子，我发现有些个键值运气比拟好，每次都没有被我的随机算法选中，每次都能幸免于难，这可不行，这些长时间过期的数据始终霸占着不少的内存空间！气抖冷！
我眼里可揉不得沙子！于是在原来定期删除的根底上，又加了一招：
那些原来逃脱我随机抉择算法的键值，一旦遇到查问申请，被我发现曾经超期了，那我就绝不客气，立刻删除。
这种形式因为是被动式触发的，不查问就不会产生，所以也叫惰性删除！
可是，还是有局部键值，既逃脱了我的随机抉择算法，又始终没有被查问，导致它们始终绳之以法！而于此同时，能够应用的内存空间却越来越少。
而且就算退一步讲，我可能把过期的数据都删除掉，那万一过期工夫设置的很长，还没等到我去清理，内存就吃满了，一样要吃枣药丸，所以我还得想个办法。
我苦思好久，终于憋出了个大招：内存淘汰策略，这一次我要彻底解决问题！
我提供了 8 种策略供应用程序抉择，用于我遇到内存不足时该如何决策：
- noeviction：返回谬误，不会删除任何键值
- allkeys-lru：应用 LRU 算法删除最近起码应用的键值
- volatile-lru：应用 LRU 算法从设置了过期工夫的键汇合中删除最近起码应用的键值
- allkeys-random：从所有 key 随机删除
- volatile-random：从设置了过期工夫的键的汇合中随机删除
- volatile-ttl：从设置了过期工夫的键中删除剩余时间最短的键
- volatile-lfu：从配置了过期工夫的键中删除应用频率起码的键
- allkeys-lfu：从所有键中删除应用频率起码的键
有了下面几套组合拳，我再也不必放心过期数据多了把空间撑满的问题了~
缓存穿透 && 布隆过滤器
我的日子过的还挺舒坦，不过 MySQL 大哥就没我这么舒坦了，有时候遇到些烦人的申请，查问的数据不存在，MySQL 就要白忙活一场！不仅如此，因为不存在，我也没法缓存啊，导致同样的申请来了每次都要去让 MySQL 白忙活一场。我作为缓存的价值就没失去体现啦！这就是人们常说的缓存穿透。
这一来二去，MySQL 大哥忍不住了：“唉，兄弟，能不能帮忙想个办法，把那些明晓得不会有后果的查问申请给我挡一下”
这时我想到了我的另外一个好敌人：布隆过滤器
我这位敌人别的本事没有，就善于从超大的数据集中疾速通知你查找的数据存不存在（轻轻通知你，我的这位敌人有一点不靠谱，它通知你存在的话不能全信，其实有可能是不存在的，不过它他要是通知你不存在的话，那就肯定不存在）。
我把这位敌人介绍给了应用程序，不存在的数据就不用去叨扰 MySQL 了，轻松帮忙解决了缓存穿透的问题。
缓存击穿 && 缓存雪崩
这之后过了一段时间太平日子，直到那一天···
有一次，MySQL 那家伙正优哉游哉的摸鱼，忽然一大堆申请给他怼了过来，给他打了一个措手不及。
一阵忙活之后，MySQL 火冒三丈的找到了我，“兄弟，咋回事啊，怎么一下子来的这么猛”
我查看了日志，连忙解释到：“大哥，切实不好意思，刚刚有一个热点数据到了过期工夫，被我删掉了，不巧的是随后就有对这个数据的大量查问申请来了，我这里曾经删了，所以申请都发到你那里来了”
“你这干的叫啥事，下次留神点啊”，MySQL 大哥一脸不快乐的来到了。
这一件小事我也没怎么放在心上，随后就抛之脑后了，却没曾想几天之后竟捅了更大的篓子。
那一天，又呈现了大量的网络申请发到了 MySQL 那边，比上一次的规模大得多，MySQL 大哥一会儿功夫就给干趴下了好几次！
等了好半天这一波流量才算过来，MySQL 才缓过神来。
“老弟，这一次又是什么起因？”，MySQL 大哥累的没了力量。
“这一次比上一次更不巧，这一次是一大批数据简直同时过了有效期，而后又产生了很多对这些数据的申请，所以比起上一次这规模更大了”
MySQL 大哥听了眉头一皱，“那你倒是想个办法啊，三天两头折磨我，这谁顶得住啊？”
“其实我也很无奈，这个工夫也不是我设置的，要不我去找应用程序说说，让他把缓存过期工夫设置的平均一些？至多别让大量数据个体生效”
“走，咱俩一起去”
起初，我俩去找应用程序磋商了，不仅把键值的过期工夫随机了一下，还设置了热点数据永不过期，这个问题缓解了不少。哦对了，咱们还把这两次产生的问题别离取了个名字：缓存击穿和缓存雪崩。
咱们终于又过上了舒服的日子···
彩蛋
那天，我正在致力工作中，不小心出了错，整个过程都解体了。
当我再次启动后，之前缓存的数据全都没了，暴风雨似的申请再一次全都怼到了 MySQL 大哥那里。
唉，要是我可能记住解体前缓存的内容就好了···
预知后事如何，请关注后续精彩······