现在的电商平台百花齐放，
https://www.woshipm.com/pd/4369061.html
在商品信息电子化过程中，商品的特性可以由多个“属性|属性值对”进行描述。“属性|属性值对”完全相同的商品，可以抽象成为一个 SPU。
另一方面，这些“属性|属性值对”在 SPU 中固化下来，逐步标准化。
基于 SPU 的商品信息结构，可以实现丰富的应用，比如商品信息与资讯、评论、以及其它 SPU 的整合。
SPU 的全称为[Standard Product Unit]，也叫标准化产品单元，它是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个 SPU。
https://blog.csdn.net/yucaixiang/article/details/90239817
在软件工程中最大的难题就是如何应对需求日新月异的变化，但是繁琐又复杂的需求迭代又是不能提前预料的，那就要为未知的变化做好准备，但是想想就觉得复杂，而且实现起来也是一件非常痛苦的事情，但好在有前人已经给我们提出了非常好的设计原则、设计模式，来应对(封装)未知的变化，你所要了解的就是充分的理解这些东西，站在巨人的肩膀上前行。
单一职责原则
单一职责原则内涵：
单一职责原则是针对类来说的，即一个类应该只负责一项职责。
例子 1：
如类 T 负责两个不同职责：职责 P1，职责 P2。当职责 P1 需求变更而改变 T 时，可能造成职责 P2 发生故障，所以需要将类 T 的粒度分解为 T1，T2。
例如，产品经理就是整理需求，程序员就是写代码，分工明确：
//产品经理 public class ProduceManager { //…整理需求}//勤奋的程序员 public class Coder { //…写代码}
大白话：
一个类干好自己应该干的事情，别越界而导致业务耦合。
好处：
开闭原则
开闭原则内涵：
一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。
例子 2：
我们的公司里面有许许多多的程序员，无论男女都在认真的写代码。
但是有天我们的程序媛们觉得自己有“加工资的需求”。
此时，我们可以将这个动作抽象到新的接口里面，然后 FemaleCoder 去实现这个动作以完成拓展。
//公司工作 class Company{ private List
新的接口标识“涨工资的需求”：
//待遇福利 interface Salary{ //涨工资动作 void raise();}
修改新增的 FemaleCoder 类：
//程序媛 class FemaleCoder implements Coder, Salary{ @Override public void coding() { //… }
@Override public void raise() { //…我要加薪 }}
UML 图：
大白话：
对增加新功能代码时，尽量保证不修改已有代码，然后将扩展的代码增加到项目中
好处：
里氏替换原则
里氏替换原则内涵：
所有引用基类的地方必须能透明地使用其子类的对象。
遵循里氏替换原则，在子类中尽量不要重写和重载父类的方法。
举例子 3：
我们的子类程序猿 (MaleCoder) 和程序媛(FemaleCoder) ，同继承了基类程序员（CoderPeople）。
那么凡是程序员使用的地方，无论对于程序员还是程序媛，都应该可以无缝替换。
//写代码的人 class CoderPeople { public void coding(){ //… }}//程序媛 class FemaleCoder extends CoderPeople{ @Override public void coding() { //… }}//程序猿 class MaleCoder extends CoderPeople{}
调用点：
public class LiskovSubstitutionPrinciple { public static void main(String[] args) { //用 CoderPeople 的子类 FemaleCoder 的实例来替换 CoderPeople 的实例，程序工作正常 working(new FemaleCoder()); } private static void working(CoderPeople shape){ System.out.println(“开始写代码”); shape.coding(); System.out.println(“结束写代码”); }}
UML：
大白话：
里氏替换原则首先突出的是面向对象的三大特性之一：“继承”。它要求我们去遵守，是因为不遵守导致的代价太大了。
使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
好处：
大大降低程序运行出错的概率。
接口隔离原则
接口隔离原则内涵：
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。（原则中的接口，是一个泛泛而言的接口，不仅仅指 Java 中的接口，还包括其中的抽象类）
** 举例子 4：**
这个图的意思是：类 A 依赖接口 I 中的方法 1，方法 2，方法 3，类 B 是对类 A 依赖的实现；类 C 依赖接口 I 中的方法 1，方法 4，方法 5，类 D 是对类 C 依赖的实现。对于类 B 和类 D 来说，虽然存在用不到的方法（红色标记所示），但由于实现了接口 I，所以也必须要实现这些用不到的方法。
如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。
如果将这个设计修改为符合接口隔离原则，就必须对接口 I 进行拆分。在这里我们将原有的接口 I 拆分为三个接口，拆分后的设计如图所示：
注意：
可能会觉得接口隔离原则和之前的单一职责原则很相似，其实不然。
大白话：
定义接口时要权衡考虑是否可拆分多个模块中。
使用接口时要权衡考虑是否简化实现的接口列表。
好处：
迪米特法则
迪米特法则内涵：
一个对象应该对其他对象有最少的了解。
迪米特原则核心观念就是：类间解耦，弱耦合。
举例子 5：
这个例子中，我们知道 总公司经理 管理 总公司员工，分公司经理 管理 分公司员工。
下面的例子是符合迪米特法则的：
//总公司员工 class Employee{ private String id;}//分公司员工 class SubEmployee{ private String id;}//分公司经理 class SubCompanyManager{ List
下面的例子是不符合迪米特法则的，因为分公司员工对于总公司经理来说，是不需要知道的类：
//总公司经理 class CompanyManager{ //总公司员工 List
UML：
大白话：
一个类对自己需要耦合或者调用的类知道的最少，你类内部怎么复杂，我不管，那是你的事，我只知道你有提供好的公用方法，我能正常调用即可。
依赖倒置原则
依赖倒置原则内涵：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；
抽象不应该依赖细节，细节应该依赖抽象。
核心思想是面向接口编程。
举例子 6：
程序员喜欢搬砖，随着年龄和经验增加，从一开始搬的普通砖头，逐渐变为银砖，到后来慢慢变为金砖…
那么分析可以知道：程序员是高层模块，而“普通砖头”、“银砖”和“金砖”都视为底层模块。
底层模块
//砖头 interface Brick{}//石头砖头 class StoneBrick implements Brick{}//银砖头 class SilverBrick implements Brick{}//金砖头 class GoldBrick implements Brick{}
**
高层模块
//搬砖的程序员 class CoderMan{ void movingBrick(Brick brick){ //…. }}
如此一来，不管哪种砖头，程序员都可以搬了。（无论以后怎样扩展 Brick 类，都不需要再修改 CoderMan 类了）
CoderMan coderMan = new CoderMan(); coderMan.movingBrick(new StoneBrick()); coderMan.movingBrick(new SilverBrick()); coderMan.movingBrick(new GoldBrick());
UML：
大白话：
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
好处：
总结
文章主要参考书籍有《大话设计模式》和网上一些零散的文章，写出来的目的一方面是自己对这六项原则系统地整理一下，另外也因为设计模式对编程人员来说的确非常重要，笔试面试都会用得到，希望对大家有所帮助。
国内的电商平台高速发展了这么多年，服务千千万万个商家与用户，我们可以通过在线上的方式购买各式各样的商品，从早期的虚拟产品到如今的大小家电等等，给人们带来了线上购物的便利。而作为一个电商平台的中的核心角色”商品体系”，就显得尤为重要，它不仅要在第一时间显示用户搜索的不同类型的商品，还要联合订单系统、支付系统等等完成线上一整套的下单操作。
由于笔者能力有限，本篇文章尽可能的从概念分析，到领域模型，再到上层应用，对电商的商品和类目体系进行逐步拆解。
我们在电商平台的交易流程，对应着在现实世界中的交易流程，而商品也是对应着现实世界中的实物，在商品模型中，通过一系列的属性组合，将现实中的实物进行数字化，也就有了电商平台中的商品体系。同样线上交易的过程，也是线上实物商品流通的过程的数字化的转变。
既然要把线上商品跟线下的实物作为对应，那么在线下的实物商品的交易过程是怎么样的？
商品模块是电商系统核心模块，本文主要讲解商品模块功能需求、术语概念、功能设计、数据结构、相关功能设计思路。
近几年开发了很多电商类系统，将我们一些设计经验整理并分享给大家。
SPU：Standard Product Unit（标准化产品单元），一种商品，各种规格集合，如：iPhone 12；
SKU：Stock Keeping Unit（库存量单位），也称单品，一种商品的具体规格，如：一部 黑色 128G 的 iPhone 12 手机，黑色 + 128G 就是商品的具体规格。
可以看到一种商品 SPU 包含多种 SKU，SPU（SKU1、SKU2……SKU n），且 SKU 唯一。
商品模块一般包括商品、商品分类、商品规格管理，可能还有商品审核。商品模块比较复杂的地方在于商品参数、规格管理。
商品参数仅用于商品信息展示，一般不参与实际业务逻辑；
手机参数关注点是内存、存储、摄像头、CPU 等；
手表参数关注点是表盘材质、表镜材质、适用人群、是否防水；
化妆品参数关注点是功能、肤质、产地；
如果是全品类平台，不同行业商品存在不同参数，我们可以按行业构建参数模板。如果是垂直行业，如农产品、五金等，可以将商品参数直接存储商品表，存储商品表的问题在于如果参数比较多，那么商品表参数字段会很多，如果跨行业，冗余字段会比较多，但单表维护比较方便。前期建议不过渡设计，直接单表维护，后期需要可以再拆表，并将原商品表参数字段迁移到子表。
商品规格管理是商品模块比较重要的部分，一般有单规格、多规格。如果将系统商品规格设计成单规格，后期如果有多规格需求，系统扩展会比较麻烦，所以建议将系统设计成多规格方式或支持单规格、多规格两种方式。如果为了快速验证业务，项目很大程度上需要重写，行业类目需要，可以考虑用单规格方式以降低开发成本。
什么是单规格 以农产品大米为例，如果将大米按重量分成 2.5kg / 5kg，规格相对简单，只有一个层级；
什么是多规格 以服装为例，如 T 恤，有颜色（黑、白、黄、绿……），有尺寸（S、M、L……）、材质（棉、涤纶），规格有多个层级，比较复杂；
多规格字段数量具有不确定性，可采用 JSON 实现，如服装类商品； *规格-颜色（黑、白、红、黄、蓝）； *规格-大小（S、M、L）； * 规格-材质（纯棉、涤纶）；
通过规格配置表、规格值表，两表可以完成规格数据存储，我们以最简单的基础字段作分析。
我们以商品 iPhone 12 为例，分析具体数据存储
如果觉得 2 表维护繁琐，可以将 product_attrs 表冗余至 products 表字段，但 products 表存储会增大；
对于属性值存储类型，有些喜欢用 text / varchar 存储，Mysql 5.7 及以上支持 JSON 类型，可以考虑直接采用 JSON 存储；
价格字段采用了 int 类型，也可以采用 decimal 类型，int 类型可以降低精度计算问题；（微信支付采用整型，支付宝采用浮点型）
如果不想用 JSON 存储，可以将规格属性映射成数字，如给具体的颜色、尺寸、款式属性标记成 1、2、3（唯一）……通过数字组合产生对应 SKU，那么上面 product_attr_vals 商品规格值表变成如下，但这种方式在 DB 层的数据可读性比较差。
merchant_id 供应商 ID
shop_id 店铺 ID
share_title 分享标题，用于微信分享
share_descrip 分享描述
category_id 商品分类 ID
unit 单位
vip_amount 会员价
market_amount 市场价
max_amount / min_amount 最大/最小价格
content 图文详情
logo 商品图
orderby 排序
status 状态（上架、下架）
stock 总库存（展示用）
sale 销售量（还可以细分真实、虚拟）
is_delete 是否删除（逻辑删除）
check_stats 审核状态
admin_id 操作员
商品除了售价，还包括一部分费用，是集成在商城系统还是交给 ERP 系统处理，看具体系统规模和使用场景，商品的价格在零售价背后其实还包括采购价、包装费、运费、仓管费、订单处理费、税费、推广费，这些费用都是商品的成本，如果忽略这些成本，那么商品售卖的时候可能会产生负利润，也就是亏本。所以考虑商品的隐性费用成本很重要。
建表 SQL
CREATE TABLE products( id INT NOT NULL AUTO_INCREMENT COMMENT ‘主键’ , name VARCHAR(30) COMMENT ‘商品名称’ , title VARCHAR(50) COMMENT ‘商品标题’ , share_title VARCHAR(50) COMMENT ‘分享标题’ , share_descip VARCHAR(50) COMMENT ‘分享描述’ , shop_id INT NOT NULL DEFAULT 0 COMMENT ‘店铺 ID’ , mch_id INT NOT NULL DEFAULT 0 COMMENT ‘供应商 ID’ , category_id INT COMMENT ‘商品分类’ , unit VARCHAR(15) COMMENT ‘单位’ , sale_amount INT NOT NULL DEFAULT 0 COMMENT ‘零售价’ , vip_amount INT NOT NULL DEFAULT 0 COMMENT ‘会员价’ , marker_amount INT NOT NULL DEFAULT 0 COMMENT ‘市场价’ , max_amount INT NOT NULL DEFAULT 0 COMMENT ‘最高价’ , min_amount INT NOT NULL DEFAULT 0 COMMENT ‘最低价’ , content TEXT COMMENT ‘商品详情’ , logo VARCHAR(150) COMMENT ‘商品 LOGO’ , orderby MEDIUMINT(5) NOT NULL DEFAULT 99 COMMENT ‘排序’ , status TINYINT(2) NOT NULL DEFAULT 0 COMMENT ‘状态’ , stock INT NOT NULL DEFAULT 0 COMMENT ‘库存’ , sale INT NOT NULL DEFAULT 0 COMMENT ‘销量’ , is_delete TINYINT(2) NOT NULL DEFAULT 0 COMMENT ‘是否删除’ , check_status TINYINT(2) NOT NULL DEFAULT 0 COMMENT ‘审核状态’ , shipping_template_id INT NOT NULL DEFAULT 0 COMMENT ‘运费模板 ID’ , admin_id INT NOT NULL DEFAULT 0 COMMENT ‘操作员’ , created_at DATETIME COMMENT ‘创建时间’ , updated_at DATETIME COMMENT ‘更新时间’ , PRIMARY KEY (id) ) COMMENT = ‘商品表’; CREATE TABLE product_attrs( id INT NOT NULL AUTO_INCREMENT COMMENT ‘主键’ , name VARCHAR(30) COMMENT ‘规格名’ , product_id INT NOT NULL DEFAULT 0 COMMENT ‘商品 ID’ , values JSON COMMENT ‘规格配置项’ , created_at VARCHAR(30) COMMENT ‘创建时间’ , updated_at VARCHAR(30) COMMENT ‘更新时间’ , PRIMARY KEY (id) ) COMMENT = ‘商品规格配置表’; CREATE TABLE product_attr_vals( id INT NOT NULL AUTO_INCREMENT COMMENT ‘主键’ , product_id INT NOT NULL DEFAULT 0 COMMENT ‘商品 ID’ , attr_vals JSON COMMENT ‘规格配置项组合值’ , sale_amount INT NOT NULL DEFAULT 0 COMMENT ‘零售价’ , vip_amount INT NOT NULL DEFAULT 0 COMMENT ‘会员价’ , market_amount INT NOT NULL DEFAULT 0 COMMENT ‘市场价’ , stock INT NOT NULL DEFAULT 0 COMMENT ‘库存’ , sale INT NOT NULL DEFAULT 0 COMMENT ‘销量’ , thumb VARCHAR(150) COMMENT ‘预览图’ , orderby MEDIUMINT(5) NOT NULL DEFAULT 99 COMMENT ‘排序’ , created_at DATETIME COMMENT ‘创建时间’ , updated_at DATETIME COMMENT ‘更新时间’ , PRIMARY KEY (id) ) COMMENT = ‘商品规格值表’;
我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的 Java 多线程的 18 般武艺进行处理，并且可以完美的运行，毫无 Bug！但是这是单机的应用，也就是所有的请求都会分配到当前服务器的 JVM 内部，然后映射为操作系统的线程进行处理！而这个共享变量只是在这个 JVM 内部的一块内存空间！
后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡：
如上图所示，变量 A 存在 JVM1、JVM2、JVM3 三个 JVM 内存中（这个变量 A 主要体现是在一个类中的一个成员变量，是一个有状态的对象，例如：UserController 控制器中的一个整形类型的成员变量），如果不加任何控制的话，变量 A 同时都会在 JVM 分配一块内存，三个请求发过来同时对这个变量操作，操作的结果不对。即使不是同时发过来，三个请求分别操作三个不同 JVM 内存区域的数据，变量 A 之间不存在共享，也不具有可见性，处理的结果也是不对的！
在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。
通过 SETNX 设置 Key-Value 来获得锁，随即进入死循环，每次循环判断，如果存在 Key 则继续循环，如果不存在 Key，则跳出循环，当前任务执行完成后，删除 Key 以释放锁。
这种方式可能会导致死锁，为了避免这种情况，需要设置超时时间。
点击查看代码
点击查看代码
点击查看代码
点击查看代码
点击查看代码
启动项目，并在浏览器输入 http://localhost:8080/index，连续刷新界面，控制台在打印了一次“执行方法”，5 秒之后再次打印。
点击查看代码
点击查看代码
点击查看代码
启动项目，并在浏览器输入 http://localhost:8080/index，连续刷新界面，控制台在打印了一次“执行方法”，5 秒之后再次打印。
它的基本原理和 Redis 的 SETNX 类似，其实就是创建一个分布式锁表，加锁后，我们就在表增加一条记录，释放锁即把该数据删掉，具体实现，我这里就不再一一举出。
乐观锁一般通过 version 来实现，也就是在数据库表创建一个 version 字段，每次更新成功，则 version + 1，读取数据时，我们将 version 字段一并读出，每次更新时将会对版本号进行比较，如果一致则执行此操作，否则更新失败！
点击查看代码
基于 Mysql 的 InnoDB 引擎的设计：
点击查看代码
我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：
点击查看代码
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google Chubby 的一个开源实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
点击查看代码
点击查看代码
启动项目，并在浏览器输入 http://localhost:8080/index，连续刷新界面，控制台在打印了一次“执行方法”，5 秒之后再次打印。
将值 value 关联到 key ，并将 key 的过期时间设置为 seconds (以秒为单位)。若给定的 key 已经存在，SETEX 命令将覆盖旧值。set expire 它其实就是将 SET 命令与 EXPIRE 合并为原子性操作，因为如果单独使用 SET/EXPIRE 命令，如果 SET 操作成功，但是 EXPIRE 操作失败，就无法保证其操作原子性。
如果 key 不存在，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何操作，SETNX 则(SET if Not eXists)简写。
通常很多场景下，大部分使用 SETNX 实现分布式锁的逻辑，如果 SETNX 返回 1，说明该进程获得锁，SETNX 将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。
如果 SETNX 返回 0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。
考虑一种情况，如果进程获得锁后，断开了与 Redis 的连接（可能是进程挂掉，或者网络中断），如果没有有效的释放锁的机制，那么其他进程都会处于一直等待的状态，即出现“死锁”。
上面在使用 SETNX 获得锁时，我们将键 lock.foo 的值设置为锁的有效时间，进程获得锁后，其他进程还会不断的检测锁是否已超时，如果超时，那么等待的进程也将有机会获得锁。
然而，锁超时时，我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况，进程 P1 已经首先获得了锁 lock.foo，然后进程 P1 挂掉了。进程 P2，P3 正在不断地检测锁是否已释放或者已超时，执行流程如下：
P2 和 P3 进程读取键 lock.foo 的值，检测锁是否已超时（通过比较当前时间和键 lock.foo 的值来判断是否超时）
P2 和 P3 进程发现锁 lock.foo 已超时
P2 执行 DEL lock.foo 命令
P2 执行 SETNX lock.foo 命令，并返回 1，即 P2 获得锁
P3 执行 DEL lock.foo 命令将 P2 刚刚设置的键 lock.foo 删除（这步是由于 P3 刚才已检测到锁已超时）
P3 执行 SETNX lock.foo 命令，并返回 1，即 P3 获得锁
P2 和 P3 同时获得了锁
从上面的情况可以得知，在检测到锁超时后，进程不能直接简单地执行 DEL 删除键的操作以获得锁。
为了解决上述算法可能出现的多个进程同时获得锁的问题，我们再来看以下的算法。
我们同样假设进程 P1 已经首先获得了锁 lock.foo，然后进程 P1 挂掉了。接下来的情况：
进程 P4 执行 SETNX lock.foo 以尝试获取锁
由于进程 P1 已获得了锁，所以 P4 执行 SETNX lock.foo 返回 0，即获取锁失败
P4 执行 GET lock.foo 来检测锁是否已超时，如果没超时，则等待一段时间，再次检测
如果 P4 检测到锁已超时，即当前的时间大于键 lock.foo 的值，P4 会执行以下操作
GETSET lock.foo <current Unix timestamp + lock timeout + 1>
由于 GETSET 操作在设置键的值的同时，还会返回键的旧值，通过比较键 lock.foo 的旧值是否小于当前时间，可以判断进程是否已获得锁
假如另一个进程 P5 也检测到锁已超时，并在 P4 之前执行了 GETSET 操作，那么 P4 的 GETSET 操作返回的是一个大于当前时间的时间戳，这样 P4 就不会获得锁而继续等待。注意到，即使 P4 接下来将键 lock.foo 的值设置了比 P5 设置的更大的值也没影响。
另外，值得注意的是，在进程释放锁，即执行 DEL lock.foo 操作前，需要先判断锁是否已超时。如果锁已超时，那么锁可能已由其他进程获得，这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。
比如说：某个查询数据库的接口，因为调用量比较大，所以加了缓存，并设定缓存过期后刷新，问题是当并发量比较大的时候，如果没有锁机制，那么缓存过期的瞬间，大量并发请求会穿透缓存直接查询数据库，造成雪崩效应，如果有锁机制，那么就可以控制只有一个请求去更新缓存，其它的请求视情况要么等待，要么使用过期的缓存。
下面以目前PHP社区里最流行的PHPRedis扩展为例，实现一段演示代码：
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true