我是雷迪斯。你好，我是雷迪斯。一个叫安提瑞兹的人把我带到了这个世界。 说起image的诞生，和关系数据库MySQL颇有关系。 在我来到这个世界之前，MySQL的日子很不好过，互联网发展越来越快，包含的数据越来越多，客户请求激增，每一个客户请求都变成了一个又一个的读写操作。MySQL就惨了。 尤其是到了“双11”“618”这种全民购物狂欢的日子，MySQL就苦不堪言了。 后来根据MySQL的说法，其实客户的请求有一半以上都是读操作，经常会重复查询一些东西，浪费了很多磁盘I/O的时间。 后来有人想，是不是可以学习CPU，给数据库加个缓存。所以我出生了！我出生不久，MySQL和我就成了好朋友，我们经常一起出现在后台服务器。 应用程序从MySQL查询的数据在我这里注册。以后需要的时候，请先找我要。我这里没有问MySQL要。 为了方便使用image，我支持几种数据结构的存储:StringHashlistSetSortedSetBitmap.....因为我把所有注册的数据都记录在内存里，不用进行蜗牛式的I/O操作，所以找我比MySQL要花很多时间。 不要小看这个简单的改变，我可以为MySQL减轻很多负担！随着程序的运行，我缓存的数据越来越多，有相当一段时间，我屏蔽了客户对它的请求，让它很安心！有了我的参与，网络服务的性能提升了很多，这是因为我为了数据库被拍了很多。 过期缓存& amp；出缓存，但很快发现不对劲。我缓存的数据都在内存里，但是即使在服务器上，内存的空间资源还是非常有限的，所以不能一直不检查。我只好想了个办法，还是吃枣药丸。 很快，我想到了一个解决方案:为缓存的内容设置一个超时，并将具体的设置留给应用程序。我要做的就是把过期的内容从我这里删除，及时腾出空间。 当映像超时结束时，我应该何时执行此清理工作？最简单的就是定期删除。我决定每100ms做一次，也就是每秒10次！我清除的时候，一口气删不掉所有过期的。我有很多数据存储在里面，不知道要多久才能全部扫描完，严重影响我接收新用户请求！时间紧，任务重，只好随机选取一部分清除，可以缓解记忆压力。 这样过了一段时间，发现有些关键值是幸运的。他们不是每次都被我的随机算法选中，每次都幸免于难。这是不可接受的。这些姗姗来迟的数据已经占用了大量的内存空间！寒心！我不能眼里揉沙子！于是在原来定期删除的基础上，我又加了一招:那些逃过了我的随机选择算法的键值，一旦遇到查询请求，被发现过期，那么我会毫不犹豫地立即删除。 因为这种方法是被动触发的，不查询是不会发生的，所以也叫懒删！但是还是有一些关键值，逃过了我的随机选择算法，从来没有被查询过，导致他们逍遥法外！与此同时，可用的内存空间越来越少。 而且就算退一步，我也可以把过期的数据全部删除。万一过期时间设置的时间长了，我还没来得及清除，内存就满了，还得吃枣丸，得想个办法。 我苦思良久，终于想出了一个大招:记忆消除策略。这一次，我会彻底处理这个问题！我提供了八种策略供应用程序选择，可以用来在遇到内存不足的情况下做决策:noeviction:返回错误，不会删除任何键值allkeys-lru:用lru算法删除最近最少使用的键值volatile-lru:用LRU算法删除最近最少使用的键值allkeys-random:从所有的键中随机删除volatile-random:从有失效时间的键集中随机删除volatile-t。Tl:从设置了过期时间的密钥中删除剩余时间最短的密钥。volatile-lfu:从设置了过期时间的密钥中删除出现频率最低的密钥。allkeys-lfu:删除所有键中出现频率最低的键。有了以上几组组合拳，我再也不用担心用更多过期数据填满空间了~缓存穿透& & ampBloom Filter我的生活挺舒服的，但是MySQL没有我舒服。有时候遇到一些烦人的请求，查询到的数据不存在，MySQL就会白忙一场！不仅如此，因为不存在，我也无法缓存，导致同样的请求到来，每次都要让MySQL徒劳无功。 我作为缓存的价值还没有显示出来！这就是人们常说的缓存渗透。 图像不停的来来往往，MySQL哥哥忍不住说了一句:“哎，哥哥，你能不能帮我想个办法，把我知道不会有结果的查询请求屏蔽掉？”这时我想到了我的另一个好朋友:布鲁姆滤镜图像。我的朋友擅长从庞大的数据集中快速告诉你你要找的数据是否存在。(悄悄的，我朋友有点不靠谱，它不可能把存在的信息都告诉你。 Image将这位朋友的详细信息提供给了应用程序，因此不需要用不存在的数据来麻烦MySQL，这很容易帮助解决缓存渗透的问题。 高速缓存分解和。雪崩之后，有一个和平的时间，直到那一天...有一次，MySQL的家伙正在悠闲地钓鱼，突然一大堆请求让他擦肩而过，猝不及防。 忙碌了一段时间后，MySQL一怒之下找到了我。“哥哥，发生了什么事？怎么来得这么快？”图片我查了一下日志，赶紧解释道:“大哥，真的很糟糕。刚刚一个热数据过期了，我删了。不幸的是，大量对这些数据的查询请求来了，我在这里删除了它，所以所有的请求都发送给了你。” 我也没太在意这点小事，然后就把它抛在脑后了，没想到几天后我就闹得更大了。 那一天，大量的网络请求被发送到MySQL，比之前多了很多。大哥MySQL短时间内下了好几次！这波流量过了很久，MySQL才回过神来。 “老弟，这次又是什么原因？”MySQL哥太累了，没力气。 “这次比上次更不幸。这一次，大量数据几乎同时过期，然后出现了大量对这些数据的请求，所以比上次更大。”老大哥imageMySQL对此皱起了眉头。“那你最好想办法折磨我三天。谁能受得了？”“其实，我也很无奈。这次也不是我定的。为什么我不和应用程序对话，让他均匀地设置缓存过期时间？至少不要让很多数据集体失效。”“走吧，我们一起走。”后来我们去申请讨论。我们不仅随机设置了键值的过期时间，还设置了热数据永不过期，缓解了很多问题。 哦，对了，我们还把这两个问题分别命名为:缓存崩溃和缓存雪崩。 最后，我们又过上了舒适的生活...彩蛋那天，我正在努力，一不小心出错了，整个过程就崩溃了。 再启动的时候，之前缓存的数据都没了，所有像风暴一样的请求又一次向MySQL的大哥袭来。 唉，要是我能记得崩溃前缓存了什么就好了...