本文介绍: 在查询时，给获取锁添加超时时间，避免突然大量请求访问冷门数据，大量线程阻塞等待锁如果多处操作缓存和数据库，要注意加同一把锁，来保证数据的一致性在 MQ 的通知中，加锁的话，注意需要阻塞等待加锁，而不是拿不到锁就退出，因为 MQ 中的通知需要修改缓存，收到通知后是一定要修改的对于数据库中不存在的数据，在 Redis 中使用{}来进行缓存，避免缓存穿透，空缓存就可以将过期时间设置的短一些，避免大量空缓存占用缓存空间。
分页列表缓存的延迟构建
首先，先来讲一下业务场景，用户会在 APP 中去分享内容，那么假如用户分享的是美食菜谱内容，在用户分享之后，先将这个美食菜谱的内容作为 k–v 进行缓存，但是呢，其实对于用户分享的美食菜谱内容其实是会进行分页查询的，比如说别人点击进入你的主页，肯定是分页查询你主页分享的内容，那么我们就要考虑一下什么时候对这个分页查询的缓存列表进行构建呢？
当用户 A 新增分享的时候，另一个用户 B 此时正好来查询用户 A 的分享列表，用户 B 线程先去缓存中查询，发现没有，再去数据库中查询用户 A 的分享列表，此时 B 拿到了 A 新增分享之前的旧数据，此时如果用户 A 新增分享并落库，并且去缓存中对用户 A 的列表缓存进行重建，那么此时缓存列表中是用户 A 的最新数据，但是此时用户 B 的线程在数据库中已经查到了用户 A 的旧数据，用户 B 的线程继续执行，将用户 A 的旧数据给放入到列表缓存中，覆盖掉了用户 A 更新的缓存，那么此时就会导致缓存数据库不一致
解决办法就是在这两处构建缓存的时候都加上分布式锁即可，加分布式锁的地方在下图标红的位置：
查询用户列表时，分页缓存的构建流程：
总结
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
