正在播放：缓存之道 — 将用户缓存进行更灵活的单独管理
更新时间：1年前
代码之道 - 高效缓存
| 标 题 | 时 间 |
|---|---|
| 代码之道 — 从工程项目全局的角度考虑整个项目的组织和管理 | 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 14:01:32
今天再看这个教程，我知道又可以再干点什么了。coding10教程，就是有生命力。
yang 2020-12-03 09:52:35
不还是单个 用户去查询，仍然不是where in 的形式？也就是说第一次查询的时候，还是有N+1的问题 不知道我理解的有没有问题
codinget 2020-12-03 10:09:56
你还没有真正理解N+1是怎么一回事，继续好好想想吧，N+1 是多余重复查询了N次，这里的数据都只是查询了一次，以后网站所有页面再查询用户数据都时候也不会再走数据库，而且直接从缓存中获取数据。从网站整体上说，极大减少了数据库的查询次数。
yang 2020-12-03 10:19:24
我是指第一次查询，没有同步缓存的时候，查询用户的话 不是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:27
其实最有趣的事情就是“第一次”这个阶段，当前这套解决方案是针对网站全局做的方案，在我们访问当前页面之前，早已经有多个用户访问过之前的其他网页，在其他的网页，不管是什么类型的网页，只要有用户数据的，早已形成了缓存信息，所有当我们再访问的时候，基本上也不会一个一个再去查询用户的数据，用户发表评论的时候，或者其他操作的时候，他的用户信息其实也已经被缓存了。所以第一次的时候也不要用whereIn的方式，那本身就是再浪费过去的缓存结果。不要只想我们自己的操作，这是一个涉及到全体用户的事情。这个系列的课程我是挖了坑的，但是坑不在这里，我希望你是能找到那个坑的人。
yang 2020-12-03 10:32:05
这么说就没问题了， 业务来说： 博客站的话 一般来说都是 可以 不登录的， 其实数据预热 就可以解决这个问题
codinget 2020-12-03 11:05:01
预热也可以，我喜欢比较温和的方案，不想在短时消耗系统大量计算资源。
yang 2020-12-03 20:35:07
enen，是的
暂无相关资源