电商系统：商品详情页

最新推荐文章于 2022-09-22 08:53:21 发布

RealKeyboardMan

最新推荐文章于 2022-09-22 08:53:21 发布

阅读量2.3k

点赞数

分类专栏：系统设计

本文链接：https://blog.csdn.net/weixin_40108561/article/details/105923574

版权

20 篇文章 0 订阅

订阅专栏

高并发问题

商品详情页（商详页）一定是整个系统中DAU（日均访问次数）最高的页面之一。不难理解，用户购买前一定会货比三家。如果在设计时没考虑高并发的问题，大促的时候，商品系统必然是第一个被流量冲垮的系统。

数量多、重量大。
为什么数量多，国内一线电商SKU（库存单元，在电商行业可以理解为商品）的数量大约在几亿到几十亿，当然实际没这么多种商品，这里面有很多原因，比如同一个商品有不同版本型号，再比如，商家为了促销需要，可能会反复上架同一个商品或者给同一个商品配不同的马甲。
为什么重量大，一个商品详情页，包含大量文字、图片和视频，甚至还有AR/VR玩法。

在这里插入图片描述

包括商品的主副标题、价格、颜色等商品最基本的属性，这些属性是固定的，不太可能因为需求或者不同的商品而变化，而且这部分数据也不会太大，可以在数据库建一张表来保存商品基本信息。
此外，还需要在数据库之前，加一个缓存，抵挡大部分读请求，可以使用Redis或Memcached，这两种都是``基于内存的KV存储`。
缓存具体使用方法：处理商品信息读请求时，先查缓存，找到就直接返回，没找到再查数据库，把数据库中的信息返回给前端，顺便把数据放到缓存中。更新商品信息时，在更新数据库同时，删除掉缓存中的数据。`
这种缓存更新策略，称为Cache Aside，是最简单实用的一种策略，适用范围也最广泛，此外还有Read/Write Through、Write Behind等。
设计商品信息基本表时，有一点需要注意，一定要保留商品数据的每一个版本，因为商品数据是随时变化的，但是订单中关联的商品数据是下单时刻的数据，这很重要。可以为每一个历史版本的商品数据保存快照，可以创建一个历史表存储，也可以保存到kv存储中。

参数就是商品特征，比如电脑内存、手机屏幕尺寸等。不同类型商品参数完全不同。
由于不同种商品参数维度不同，所以不方便用固定表结构来存储，而MongoDB最大的特点，表结构不需要事先定义，其实，是根本没有表结构。支持把任意数据放入同一张表。
MongoDB的每一行数据，存储层就是BSON格式（一种更紧凑的JSON），当然这样的灵活性是有代价的，不支持SQL，多表联合查询和复杂事务比较弱。
对于商品参数信息，数据量大，结构不统一的特点，MongoDB都可以很好满足。

图片视频占用空间比较大，一般存储方式是数据库只保存图片和视频的ID或URL，实际的图片视频以文件的方式单独存储。
首选方式是保存在对象存储（Object Storage）中。各大云厂商都提供对象存储服务，比如七牛云或者开源的MinIO等。对象存储可以简单理解为无限容量的大文件KV存储。
访问图片视频时，也不需要经过商品后端服务，页面直接通过对象存储提供的URL来访问，几乎所有对象存储云服务都自带CDN（Content Delivery Network）加速服务，响应时间比直接请求业务服务更短。

商品介绍在详情页中比重最大，包含大量带格式的文字图片视频，图片视频使用对象存储，文本一般随着详情页静态化，保存在HTML中。
静态化是相对于动态页面来讲，部署到Tomcat中的Web系统，返回的都是动态页面，也就是在Web请求时，动态生成的。比如详情页，发送请求获取各种数据，动态拼接页面返回给浏览器。不过现在基本不这么做，因为每个SKU的商详页，每次动态生成的页面内容时完全一样的。生成多次不仅浪费服务器资源，速度还慢，关键Tomcat能抗的并发照Nginx差远了。
商品介绍是不怎么变的，那不如把页面事先生成好，保存成一个静态的HTML，访问时直接返回这个HTML，这就是静态化。
静态化之后，不仅仅可以节省服务器资源，还可以利用CDN加速，把商详页放到离用户最近的CDN服务商，提高访问速度。
商品价格、促销信息等需要频繁变动的，不能静态化，可以使用AJAX请求商品系统动态获取。

关注

专栏目录