这一篇将以一个小商城系统为例, 我们该怎么搭建它的缓存体系. 我们假设这个应用流量特别大, 每天都有上百万上千万的请求. 它的大致缓存架构可能像下面所画.
image.png
一级缓存到用户
用户可能间隔很短时间内进行多次查询, 我们可以对用户的请求级别做一层缓存, 将用户的响应直接缓存起来, 很短时间内用户再次请求直接返回上次的结果.
二级缓存到一级缓存
一个商品, 可能有一个基础表, 说明它的店家, 库存. 还有一个基础表说明这个商品的标准价格, 等等, 还有一个基础表说明商品的优惠政策.这三个表可能就组成了一个商品. 那么从一个, 那么从基础数据到商品的处理谁来查都是一样的, 且多次查询结果不同概率小. 我们可以把它加一层缓存. 我们把它叫做二级缓存.从组成商品后可能还会进行销售控制, 价格控制, 商品之间的PK等等(这个可能产品或业务改动比较频繁, 所以不适合放在二级缓存内),然后输出给用户.
三级缓存到二级缓存
不同的优惠政策优势不一样, 这个没优势, 我就不输出你了, 或是把你放到最后输出. 用有优势的优惠政策生成的商品展示给用户, 更加有竞争力.优惠政策PK完, 再根据库存, 标准价格等生成商品, 放到二级缓存.
DB到三级缓存
直接查DB肯定是不行的. 所以我们需要把DB的数据处理后放到三级缓存, 后面直接用就行了. 比如店家库存, 标准价格等这些当然很简单, 直接放到三级缓存, 或者分片, 或冷热数据分离放到三级缓存. 优惠政策这个可能需要经过更加复杂的处理后才能放进三级缓存, 单从优惠政策就能看出哪个更有优势的或者两个优惠政策根本就是一样的, 我们可以进行简单的PK, 尽可能多的减少三级缓存的大小.利用Bot周期性的填充三级缓存保证缓存的新鲜度.
本地缓存
上面的缓存可能放在Redis里, 查出来, 序列化,PK等都是要时间的, 当然, 由于数据量大, 上面的肯定是放不进本地缓存的. 但是为了进一步优化, 我们可以将一些常用的,量不是很大的放到本地缓存, 比如上面提到的销售控制数据, 我们可以将它转换成我们需要的格式, 放进本地缓存(定期刷新), 需要的时候使用即可.
网友评论