业务系统缓存加速的五种缓存设计

缓存内容的五个维度：

1. 业务实体缓存
2. 数据表记录缓存
3. 业务接口缓存
4. 业务实体关系缓存
5. 计算中间结果缓存

第一种， 最常用， 通常缓存业务完整的实体信息， 比如 ，商品信息缓存、包裹信息缓存、用户信息缓存等等。缓存的key通常是 业务实体ID， 比如商品id， 包裹id，用户id 等等， 它在查找业务信息的时候有很好的加速效果。它的缺点是， 业务实体中的任何信息变更都要删除缓存数据， 而业务实体的信息大多情况分布在多张表中，意味着，任何一张表的改动都要删除缓存中的业务实体。 优点是，它是面向业务场景的， 在业务系统中会多处用到该缓存， 缓存的应用地方比较丰富。

第二种， 由于数据表主要用于存储数据的结构和关联关系（1:1，1:n，n:n）, 它支持不同的字段进行操作。 如果将数据表中的记录缓存在redis中， 除非的查询场景非常单一，没有复杂的查询逻辑和查询字段，那么，可以使用表级别的缓存，它的优点是，db中的数据更新，则很容易的就删除掉缓存中的数据，操作模式简单， 它的缺点是， 换存的数据记录无法支持复杂的查询，

第三种， 该类缓存是将接口参数做为key ， 接口的response做为value， 它的缺点是， 缓存更新很麻烦， 比如当db中修改一条数据， 很难找到该数据所对应的缓存信息，并删除它，所以，它的大多应用场景在于对数据不敏感，缓存可以依赖其自动过期机制刷新缓存， 而不需要手动删除缓存的场景。 它的优点是，针对接口的加速效果明显，针对高频的接口， 极其有效的降低db的和服务的压力。

第四种，它犹如数据库中的relation表，它维护两个实体之间的关系， 关系既可以是静态关系，也可以是动态关系。 比如，用户和角色的关系（静态， 一般情况很少改动）， 用户和作品之间的收藏关系（动态， 用户可以随时去掉收藏和再次收藏），所以它既是关系维护，也是状态维护，这类缓存的key 一般是两个实体id的拼接，vlaue为关系结果， 比如key为用户id和作品id，value为用户对作品的收藏状态。它最大的缺点是， 缓存的key的数量大，比如用户id为10个， 作品id为10个， 那么它的key的总数就有10*10=100个，另外这类缓存的key一般都比较长， 因为需要两个id一起拼接，优点是， 它的vlaue值一般比较单一，通常是枚举值或许简单的json结构。其次，当对于1:n、n:1、1:1 的关系的时候， 缓存会被简化，比如， 用户和session实体的缓存，它的key就是用户id， value 就是session的内容， 不会存在一个用户id+sessionid的拼接后的缓存key场景， 分布式锁缓存（setnx实现）属于1:1关系缓存

第五种，这类缓存通常是大量数据计算的中间结果， 缓存它的目的是为了查询时不用对大量的数据进行计算，比如，排行榜（它需要一个sort set 和map实现）、用户风险评估结果（key value）， 它既可以通过定时的更新， 也可以通过某个事件的触发进行持续计算，在持续计算的场景下， 它可能一次计算，需要操作多次缓存， 缓存的读写可能比较频繁。