《后端存储实战课》课程学习笔记（三）
电商的商品系统主要功能就是增删改查商品信息，没有很复杂的业务逻辑，支撑的主要页面就是商品详情页。设计这个系统的存储，你仍然需要着重考虑两个方面的问题。
第一，要考虑高并发的问题。
不管是什么电商系统，商品详情页一定是整个系统中 DAU（日均访问次数）最高的页面之一。 如果说，在设计存储的时候，没有考虑到高并发的问题，大促的时候，支撑商品详情页的商品系统必然是第一个被流量冲垮的系统。 第二，要考虑的是商品数据规模的问题。
这么多内容怎么存？
不能用数据库，那应该选择哪种存储系统来保存这么复杂的商品数据呢？ 任何一种存储都是没办法满足的，解决的思路是分而治之，我们可以把商品系统需要存储的数据按照特点，分成商品基本信息、商品参数、图片视频和商品介绍几个部分来分别存储。 我们先来分析商品的基本信息，它包括商品的主副标题、价格、颜色等一些商品最基本、主要的属性。
这些属性都是固定的，不太可能会因为需求或者不同的商品而变化，而且，这部分数据也不会太大。 所以，还是建议你在数据库中建一张表来保存商品的基本信息。 然后，还需要在数据库前面，加一个缓存，帮助数据抵挡绝大部分的读请求。 设计商品基本信息表的时候，一定要记得保留商品数据的每一个历史版本。
因为商品数据是随时变化的，但是订单中关联的商品数据，必须是下单那个时刻的商品数据，这一点很重要。 你可以为每一个历史版本的商品数据保存一个快照，可以创建一个历史表保存到 MySQL 中，也可以保存到一些 KV 存储中。 我们再来分析商品参数，参数就是商品的特征。
比如说，电脑的内存大小、手机的屏幕尺寸、酒的度数、口红的色号等等。 和商品的基本属性一样，都是结构化的数据。 但麻烦的是，不同类型的商品，它的参数是完全不一样的。 大多数数据库，都要求数据表要有一个固定的结构。但有一种数据库，没有这个要求。特别适合保存像“商品参数”这种，属性不固定的数据，这个数据库就是 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 请求商品系统动态获取。 这样就兼顾了静态化带来的优势，也能解决商品价格等信息需要实时更新的问题。
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/666973.html
如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！
