Redis 缓存数据

1 看场景，即时性不高的可能消费方和服务方都会缓存，能减少接口请求。
2 组合对象，就类似于宽表，能减少一次 redis 查询，确定性能要求真的这么极限么，那不如直接用内存。
3 分页查询多存在于后台管理，对性能要求不高。第二种场景也大多是查询“我的”数据，大多命中索引，一般不会放缓存中。第三种场景类似于商品列表，这种一般会被预热到缓存里，或者直接就是静态化的。

这种活,不考虑上 ES 么,天生干这个的

@dxddd 是有一个计算服务，调用频繁，我们考虑了两种方法，单独缓存 A 和 B,组合对象不缓存，组合对象 C 去调用缓存 A 和 B 的，也是利用了缓存。还有一个问题：使用了 Spring Cache 对于新增和更新也是两种方案，@CacheEvict 删除缓存，下次查询就再次缓存，@CachePut 去更新，旧的接口返回 Boolean 或者 void ，可能需要操作完还需要再去查询，或者通过发布事件去查询；对于新的接口我们是新增和更新返回缓存对象

@spritecn 我们目前不考虑 es ，这个也不是我说的算