哪层缓存比较合理， API 层？业务层？

[xe2v321]

场景：APP 请求 API 层返回最新版本信息(API 和实际业务是不同项目)
疑问：
1 、版本信息缓存在 API 层，可以减少业务层一部分的请求，但是版本信息更新 API 层是未知的
2 、缓存如果在放在业务层，能够知道信息的变更可以即使更新缓存，但是请求已经到了业务层

[damngood]

我们当前的做法是缓存放在业务层, api handler 层只做校验和组装请求返回的工作.

不过如果把 redis 层暴露在 handler 层应该也是可以的吧, 不过那就要做好缓存失效通知的工作. 那样可能更细粒度点, 而且也相应复杂些.

毕竟 cache invalidate 是计算机系统两大难题之一.. /sigh

[catror]

用 MQ 把更新通知发到 API 层
用 Redis 缓存，业务层写 API 层读
版本信息实时性要求不高，隔几分钟让缓存失效就好了

[MinQ]

可不可以这么设计，如果变更不是特别频繁的话，API 层用一个时间戳记录数据有没有被修改过。要求更新数据的时候同步更新时间戳，查询数据时发现缓存的时间戳和现在不一样了，表示数据变更过了，就拉新的数据，否则直接丢缓存回去

[coderxy]

api 层合理，因为有的复杂接口是涉及到多个业务接口组合的数据。

[fhsan]

api 缓存结果

[hpeng]

真要求高，做一层缓存更新失效通知就好了。

[ychost]

API 层合理，业务层如果变了可能改缓存设计，但是在 API 就不会，另外你这个是缓存命中率问题，无论在那一层都会有的