今天我们聊一聊商城项目的业务中关于缓存的使用。在前面的内容中，我们已经介绍过商城业务中的核心接口，创建订单，https://www.inbai.net/article/141.html，在这篇文章里，我们详细介绍了创建订单的流程，不过我们更多的讨论的是业务分析，而没有深入去研究创建订单的性能。那么，今天我们就关于商城项目的性能方面，展开我们的话题，也就是在合适的地方使用上合适的缓存机制。

如果今天你是去面试，而你的简历中正好有商城项目，我想就商城项目的性能优化这一点，就够面试官问一上午了。下面，我们来盘点一下，商城当中，使用缓存的场景有哪些，又该如何恰当使用这些缓存。

场景一： 查询商品信息。
商城中，前端需要调用的几个商品信息查询的接口，一个是商品列表，另一个是商品详情。对于这两个接口，我们要设计合理的缓存。一种方法是，直接在接口上加Spring的缓存注解，但是这会有一个问题，哪个值作为商品的key？如果是商品详情，我们当然可以把商品的spuId或者skuId作为key，那商品列表呢？商品列表还会包括一些需要控制的部分，如筛选条件，如商品的价格区间，商品的名称，商品的分类，商品的库存数，商品的销量等等。还有一点是，商品列表会有分页，用户可能是从第二页开始查10个，也可能从第三页开始查30个。基于这两点看来，商品列表似乎不是一个简单的缓存列表就可以解决问题的。

我在这里提供一种方案，因为我们的商品列表数据都会用ES来做索引，单独查询ES的速度还是很快的。在查ES之前，我们加缓存，不是说有筛选条件，有分页就不能做缓存，当然是可以的，大不了就把入参都缓存到key里面。而且效率也是会很高，但是要设置好过期时间，不然如果有人恶意调接口的话，没几下缓存就满了。

另一种方案是，可以单独缓存查询条件和商品的id，具体的信息，通过商品id再查商品信息的缓存，这样一来，缓存的大小可以得到控制。

那这些查询商品详情的缓存，在哪些地方使用呢？首先是商品列表，然后通过商品列表进入商品详情页面，用户在实际下单时，查询商品详情，购物车列表中，展示商品详情。

场景二：查商品分类。

商品分类是肯定要做缓存的，因为这个基本属于不怎么变化的东西。

场景三：支付配置信息。

其实做了商城的话，一定会涉及到支付。那么，当我们支付的时候，有一堆支付配置信息需要获取，用这些信息组成client，发起支付。那这些支付配置，一方面是不怎么变化，另一方面是使用非常频繁，所以理当是缓存。

主要的场景是上面这些，下面再来说明一下，缓存中，哪些地方不是缓存？

比如一个这样的场景，用户下完订单之后，查订单需要展示商品详情，比如商品价格，商品名称，商品图片等等。这里的商品信息，能否通过商品详情的缓存来获取呢？答案是不能的。订单里的商品详情，是下单那一刻存进去的商品信息快照，对外展示时，不能调商品详情缓存展示，不然会出现价格不一致。

以上是关于商城项目业务分析中，使用缓存的一部分内容。

使用缓存