标 题 | 时 间 |
---|---|
代码之道 — 从工程项目全局的角度考虑整个项目的组织和管理 | 04:47 |
代码之道 — 项目的前期准备工作 | 11:30 |
一个好的后台系统可以极大的简化项目的开发和项目维护 | 15:25 |
代码之道 — 兵马未动,测试数据先行,重新生成测试数据 | 07:44 |
代码之道 — 快速构建用于演示的博客前台 | 15:41 |
代码之道 — 解决数据库查询的 N+1 查询浪费问题 | 06:19 |
代码之道 — 逐步构建完善的数据缓存系统 | 09:50 |
缓存之道 — 最简单粗暴的缓存机制如何实现 | 18:34 |
缓存之道 — Stay hungry ,Stay foolish,谦逊是美德 | 08:01 |
缓存之道 — 将用户缓存进行更灵活的单独管理 | 08:37 |
缓存之道 — 将评论缓存进行整体粗粒度切割 | 07:28 |
缓存之道 — 中心化的管理方式会让维护和开发变得更简单 | 02:18 |
缓存之道 — 更新单个评论时如何对缓存进行高效处理 | 05:39 |
缓存之道 — 发布新评论、删除评论时如何高效对缓存数据处理 | 05:29 |
缓存之道 — 理解读写分离的切勿僵化,缓存系统继续出发 | 04:18 |
缓存之道 — 博客总览页面分页缓存机制最简单粗暴的实现方式 | 07:59 |
缓存之道 — 分页数据缓存机制大改造 | 05:27 |
缓存之道 — 创建自己的分页器 | 06:08 |
缓存之道 — 使用 Bootstrap4 完成分页器的美化和高亮功能 | 06:23 |
缓存之道 — 创建新的博客时如何对缓存数据进行处理 | 07:29 |
缓存之道 — 更新和删除博客时如何对缓存进行操作 | 05:49 |
缓存之道 — 实现所有Model类都可以使用的抽象缓存接口 | 13:26 |
缓存之道 — 实现适用于所有Model类的抽象缓存的分页器 | 07:22 |
标 题 |
---|
老哥, 我生产环境有300万的key, 这个时候需要模糊找到一些key, 然后删除掉, 有没有什么高性能的处理方式呢
有点没理解,举个例子撒,如果想要效率高些,索引肯定是要的,另外就是最好别使用like的方式匹配,用locate指令效率高很多
redis缓存key有300万左右, 现在要查询到一些匹配的key, 然后给他们删除掉, 现在用的keys命令去找, 也试了scan, 都很慢, 会影响redis的其他操作
原来是redis的呀,那我劝你使用别的方案,但凡数据量大了,模糊匹配永远都是低效的,不要采用手动模糊匹配的方式去清理redis缓存,添加自动淘汰机制,自动清理不需要的数据,一些历史久远的数据,在实际种没有啥价值的,都给它清除了。以后也不要将它们添加到 redis 种,可以适当的让数据库承接一下,redis快,但是也不能什么都给它。
上面说300w key的 之前我在易联互动的时候,客户数据库放了160w兑换码,没索引, 查找需要140s+,加了两个联合索引之后, 查询时间基本是在 0.0x 数据库效率没有你想的这么拉胯, 里面有一部分逻辑是我设计的, 我当时也用了redis承载了部分数据,不过redis ,不过有效期很短,大约两分钟,redis自动会过期, 但是时间长了,发现redis会很慢,redis5.x 没有多线程, 后面全部转为数据库,性能很棒,就是本机mysql 相信你的mysql !