衷心感谢改版期间大家给予的帮助和体谅

微信登录

微信登录

因恶意注册过多,目前只支持微信模式
正在播放:代码之道 — 从工程项目全局的角度考虑整个项目的组织和管理
发布于: 2019.05.21
标 题 时 间
代码之道 — 从工程项目全局的角度考虑整个项目的组织和管理 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
nilsir 2019.10.24 10:27

老哥, 我生产环境有300万的key, 这个时候需要模糊找到一些key, 然后删除掉, 有没有什么高性能的处理方式呢

codinget 2019.10.24 02:22

有点没理解,举个例子撒,如果想要效率高些,索引肯定是要的,另外就是最好别使用like的方式匹配,用locate指令效率高很多

nilsir 2019.10.24 05:19

redis缓存key有300万左右, 现在要查询到一些匹配的key, 然后给他们删除掉, 现在用的keys命令去找, 也试了scan, 都很慢, 会影响redis的其他操作

codinget 2019.10.24 05:34

原来是redis的呀,那我劝你使用别的方案,但凡数据量大了,模糊匹配永远都是低效的,不要采用手动模糊匹配的方式去清理redis缓存,添加自动淘汰机制,自动清理不需要的数据,一些历史久远的数据,在实际种没有啥价值的,都给它清除了。以后也不要将它们添加到 redis 种,可以适当的让数据库承接一下,redis快,但是也不能什么都给它。

小陈 2020.11.26 11:15

上面说300w key的 之前我在易联互动的时候,客户数据库放了160w兑换码,没索引, 查找需要140s+,加了两个联合索引之后, 查询时间基本是在 0.0x 数据库效率没有你想的这么拉胯, 里面有一部分逻辑是我设计的, 我当时也用了redis承载了部分数据,不过redis ,不过有效期很短,大约两分钟,redis自动会过期, 但是时间长了,发现redis会很慢,redis5.x 没有多线程, 后面全部转为数据库,性能很棒,就是本机mysql 相信你的mysql !

标 题
找一条适合自己的路,坚持走下去
编程原力 京ICP备17045322号-2
版权所有, 侵权者追究法律责任