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

微信登录

微信登录

因恶意注册过多,目前只支持微信模式
付费课程, 订阅后即可观看
正在播放:缓存之道 — 将用户缓存进行更灵活的单独管理
发布于: 2019.06.08
标 题 时 间
代码之道 — 从工程项目全局的角度考虑整个项目的组织和管理 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
running8 2020.11.22 02:01

今天再看这个教程,我知道又可以再干点什么了。coding10教程,就是有生命力。

yang 2020.12.03 09:52

不还是单个 用户去查询,仍然不是where in 的形式?也就是说第一次查询的时候,还是有N+1的问题 不知道我理解的有没有问题

codinget 2020.12.03 10:09

你还没有真正理解N+1是怎么一回事,继续好好想想吧,N+1 是多余重复查询了N次,这里的数据都只是查询了一次,以后网站所有页面再查询用户数据都时候也不会再走数据库,而且直接从缓存中获取数据。从网站整体上说,极大减少了数据库的查询次数。

yang 2020.12.03 10:19

我是指第一次查询,没有同步缓存的时候,查询用户的话 不是where in 的形式,而是 一个一个用户 where user_id = 1 ; where user_id = 2 我在想极端情况,第一次查询 也会很多 select user 的 sql ,我在想 第一次的时候采用where in 的形式,然后将数据拆分缓存,然后 后面的查询 手动去查 缓存 如果有 就 将 where in () 括号中的user_id 减去, 为空 则不执行 where in 还没把后面的看完,这只是我 粗略的 想法 ,还望批评指正

codinget 2020.12.03 10:27

其实最有趣的事情就是“第一次”这个阶段,当前这套解决方案是针对网站全局做的方案,在我们访问当前页面之前,早已经有多个用户访问过之前的其他网页,在其他的网页,不管是什么类型的网页,只要有用户数据的,早已形成了缓存信息,所有当我们再访问的时候,基本上也不会一个一个再去查询用户的数据,用户发表评论的时候,或者其他操作的时候,他的用户信息其实也已经被缓存了。所以第一次的时候也不要用whereIn的方式,那本身就是再浪费过去的缓存结果。不要只想我们自己的操作,这是一个涉及到全体用户的事情。这个系列的课程我是挖了坑的,但是坑不在这里,我希望你是能找到那个坑的人。

yang 2020.12.03 10:32

这么说就没问题了, 业务来说: 博客站的话 一般来说都是 可以 不登录的, 其实数据预热 就可以解决这个问题

codinget 2020.12.03 11:05

预热也可以,我喜欢比较温和的方案,不想在短时消耗系统大量计算资源。

yang 2020.12.03 08:35

enen,是的

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