今天这节课我们看一下，如何设计一个快速、可靠的存储架构支撑商品系统。
相对于上节课提到的订单系统，电商的商品系统主要功能就是增删改查商品信息，没有很复 杂的业务逻辑，支撑的主要页面就是商品详情页（下文简称：商详）。不过，设计这个系统 的存储，你仍然需要着重考虑两个方面的问题。
第一，要考虑高并发的问题。不管是什么电商系统，商详页一定是整个系统中 DAU（日均 访问次数）最高的页面之一。这个也不难理解，用户购物么，看商详了不一定买，买之前一 定会看好多商详货比三家，所以商详的浏览次数要远比系统的其他页面高。
**第二，要考虑的是商品数据规模大的问题。**商详页的数据规模，我总结了六个字，叫：数量多，重量大。
先来看一下，一个商详页都有哪些信息需要保存。我把一个商详页里面的所有信息总结了一 下，放在下面这张思维导图里面。
右边灰色的部分，来自于电商的其他系统，左边彩色部分，都是商品系统需要存储的内容。
这么多内容怎么存放，早期系统可以像保存订单数据那样，设计一张商品表，把数据一股脑都存进去。一张表存不下就再加几张子表。如果说，你要低成本快速构建一个小规模电商，这么做还真就是一个挺合理的选择。
如果规模大一点，就要采用分而治之的思路进行解决。把商品系统需要存储的数据按照特点，分成商品基本信息、商品参数、图片视频和商品介绍几个部分来分别存储。
商品的基本信息，包括商品的主副标题、价格、颜色。这些属性都是固定的。不会因为商品类型改变而改变。可以在数据库中建一张表保存商品基本信息。
然而，还需要在数据库前面，加一个缓存，帮助数据抵挡绝大部分的读请求。这个缓存，可以使用 Redis，也可以用 Memcached。这两种存储系统都是基于内存的 KV 存储，都能解决问题。
**读取方式：**处理商品信息的读请求时，先去缓存查找，如果找到就直接返回缓存中的数据。如果在缓存中没找到，再去查数据库，把从数据库中查到的商品信息返回给页面，顺便把数据在缓存里也放一份。
**更新方式：**更新商品信息的时候，在更新数据库的同时，也要把缓存中的数据给删除掉。这种缓存更新的策略，称为 Cache Aside，是最简单实用的一种缓存更新策略。
设计商品基本信息表的时候，有一点需要提醒你的是，一定要记得保留商品数据的每一个历史版本。因为商品数据是随时变化的，但是订单中关联的商品数据，必须是下单那个时刻的商品数据，这一点很重要。
你可以为每一个历史版本的商品数据保存一个快照，可以创建一个历史表保存到 MySQL 中。
我们再来分析商品参数，参数就是商品的特征。比如说，电脑的内存大小、手机的屏幕尺寸、酒的度数、口红的色号等等。和商品的基本属性一样，都是结构化的数据。但麻烦的是，不同类型的商品，它的参数是完全不一样的。