流量大、数据多的商品详情页系统该如何设计？
- 电商的商品系统主要功能就是增删改查商品信息，没有很复杂的业务逻辑，支撑的主要页面就是商品详情页。设计这个系统的存储，你仍然需要着重考虑两个方面的问题。
- 第一，要考虑高并发的问题。
- 不管是什么电商系统，商品详情页一定是整个系统中 DAU（日均访问次数）最高的页面之一。
- 如果说，在设计存储的时候，没有考虑到高并发的问题，大促的时候，支撑商品详情页的商品系统必然是第一个被流量冲垮的系统。
- 第二，要考虑的是商品数据规模的问题。
- 商品详情页的数据规模，数量多，重量大。
- 第一，要考虑高并发的问题。
商品系统需要保存哪些数据？
- 这么多内容怎么存？
- 不能用数据库，那应该选择哪种存储系统来保存这么复杂的商品数据呢？
- 任何一种存储都是没办法满足的，解决的思路是分而治之，我们可以把商品系统需要存储的数据按照特点，分成商品基本信息、商品参数、图片视频和商品介绍几个部分来分别存储。
商品基本信息该如何存储？
- 我们先来分析商品的基本信息，它包括商品的主副标题、价格、颜色等一些商品最基本、主要的属性。
- 这些属性都是固定的，不太可能会因为需求或者不同的商品而变化，而且，这部分数据也不会太大。
- 所以，还是建议你在数据库中建一张表来保存商品的基本信息。
- 然后，还需要在数据库前面，加一个缓存，帮助数据抵挡绝大部分的读请求。
- 设计商品基本信息表的时候，一定要记得保留商品数据的每一个历史版本。
- 因为商品数据是随时变化的，但是订单中关联的商品数据，必须是下单那个时刻的商品数据，这一点很重要。
- 你可以为每一个历史版本的商品数据保存一个快照，可以创建一个历史表保存到 MySQL 中，也可以保存到一些 KV 存储中。
使用 MongoDB 保存商品参数
- 我们再来分析商品参数，参数就是商品的特征。
- 比如说，电脑的内存大小、手机的屏幕尺寸、酒的度数、口红的色号等等。
- 和商品的基本属性一样，都是结构化的数据。
- 但麻烦的是，不同类型的商品，它的参数是完全不一样的。
- 大多数数据库，都要求数据表要有一个固定的结构。但有一种数据库，没有这个要求。特别适合保存像“商品参数”这种，属性不固定的数据，这个数据库就是 MongoDB。
- MongoDB 是一个面向文档存储的 NoSQL 数据库，在 MongoDB 中，表、行、列对应的概念分别是：collection、document、field，其实都是一回事儿。
- MongoDB 最大的特点就是，它的“表结构”是不需要事先定义的，其实，在 MongoDB 中根本没有表结构。
- 由于没有表结构，它支持你把任意数据都放在同一张表里，你甚至可以在一张表里保存商品数据、订单数据、物流信息等这些结构完全不同的数据。
- 并且，还能支持按照数据的某个字段进行查询。
- 当然，这样的灵活性也是有代价的，MongoDB 不支持 SQL，多表联查和复杂事务比较孱弱，不太适合存储一般的数据。
- 但是，对于商品参数信息，数据量大、数据结构不统一，这些 MongoDB 都可以很好的满足。
- 我们也不需要事务和多表联查，MongoDB 简直就是为了保存商品参数量身定制的一样。
使用对象存储保存图片和视频
- 图片和视频由于占用存储空间比较大，一般的存储方式都是，在数据库中只保存图片视频的 ID 或者 URL，实际的图片视频以文件的方式单独存储。
- 现在图片和视频存储技术已经非常成熟了，首选的方式就是保存在对象存储（Object Storage）中。
- 各大云厂商都提供对象存储服务，比如国内的七牛云、AWS 的 S3 等等，也有开源的对象存储产品，比如 MinIO，可以私有化部署。
- 虽然每个产品的 API 都不一样，但功能大同小异。
- 对象存储可以简单理解为一个无限容量的大文件 KV 存储，它的存储单位是对象，其实就是文件，可以是一张图片，一个视频，也可以是其他任何文件。
- 每个对象都有一个唯一的 key，利用这个 key 就可以随时访问对应的对象。
- 基本的功能就是写入、访问和删除对象。
将商品介绍静态化
- 商品介绍在商品详情页中占得比重是最大的，包含了大量的带格式文字、图片和视频。
- 其中图片和视频自然要存放在对象存储里面；
- 商品介绍的文本，一般都是随着商品详情页一起静态化，保存在 HTML 文件中。
- 商品详情页静态化之后，不仅仅是可以节省服务器资源，还可以利用 CDN 加速，把商品详情页放到离用户最近的 CDN 服务器上，让商品详情页访问更快。
- 至于商品价格、促销信息等这些需要频繁变动的信息，不能静态化到页面中，可以在前端页面使用 AJAX 请求商品系统动态获取。
- 这样就兼顾了静态化带来的优势，也能解决商品价格等信息需要实时更新的问题。
