3

首先问题描述的挺不清晰的
1. userId 是哪个表的 id ？ T1 吗？
2. 那“如果用 userId ，projectId 作为两个接口的 Redis 缓存 key” 意思是分别做 AB 两个接口的返回值缓存？还是 UserId+projectId 做 key ，score 做 value ？
如果缓存的是连表查询的结果，并且假设你问的是更新方案的思路 那么俺觉得任意一表有写操作的时候，就应该把缓存失效掉。如果并发不高 直接更新缓存也是可以的。2 楼说的是具体的实现方案了。

4

@matrix1010
感谢分享这篇好文章，看了大致思路是建一个 key 的关联表（ A ，B ，C 接口缓存的 key ），C 接口更新数据的时候，通过这个 key 关联表查处 A ，B 接口哪些 key 要更新
这样做成本太大了，就跟你说的一样，这类问题没有完美解决方法，这个文章的思路并不通用，

7

对于读多写少的场景可以这样设计:
0. 缓存 key 上添加 sql 的标识以及参数: com.xx.xxmaaper.selectX1: userId: projectId
1. 获取 sql 中关联的表名,设计存储这样的 json, json 中的 key 为表名,value 为 缓存过的相关的 sql 标识,设个过期时间取个名放到 redis 中
```json
{
"T1":["com.xx.xxmaaper.selectX1"] ,
"T2": ["com.xx.xxmaaper.selectX1"]
}
```
2. 写一个拦截器,拦截修改更新的 sql ,获取上一步中的 json,如果更新的 sql 中所涉及的表存在于这个 json key 中,前缀删除 redis 中这个 key 的 values 也就是缓存过的 sql 结果,同时更新这个 json.

8

我觉得这是缓存颗粒度大小的问题，根据场景来决定缓存的颗粒度

9

这就是一个缓存设计问题。可大可小。引入缓存就要仔细解决缓存不一致问题。连表查这种缓存不一致是最熬人的。没什么特别通用的办法。