常见术语
PV：page view，即网站被浏览的总次数。
UV：Unique Vister的缩写，独立访客。
CR：ConversionRate的缩写，是指访问某一网站的访客中，转化的访客占全部访客的比例（订单转化率=有效订单/访客数）。
SPU：Standard Product Unit(标准化产品单元)，SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。
举例：苹果手机11，这是一个SPU。
SKU：Stock keeping unit(库存量单位）SKU即库存进出计量的单位（买家购买，商家进货，供应商备货，工厂生产都是依据SKU进行的），在服装、鞋类商品中使用最多最普遍。例如纺织品中一个SKU通常标识：规格、颜色、款式。SKU是物理上不可分割的最小存货单元。
举例：苹果手机11 128G 紫色，这是一个SKU；苹果手机11 128G 绿色，这又是一个SKU；苹果手机11 256G 紫色，这还是一个SKU。
常见系统
CMS：后台模块
OMS：订单模块
PMS：商品模块
SMS：营销模块
UMS：用户模块
电商平台需要考虑问题
容量规划：
架构设计：
数据库设计：
缓存设计：
高并发方案：
性能压测：
回滚方案：
分库分辨：
数据迁移：
监控报警：
领域模型：
框架选型：
电商平台发展模型
1.单一服务部署
存在问题：单服务部署，tomcat容器线程数有限，并发量高了，很多请求要么超时，要么请求不到。
2.集群部署
应用服务采用集群部署，利用nginx网关，做负载均衡。
存在问题：http请求是无状态的，我们如果依赖session来存储token，服务A的请求负载到服务B上，没有session信息，导致客户重新登录，体验不好。
3.分布式session方案
3.1 客户端存储session
3.2 Session sticky(粘性，粘的)
基于nginx实现
做负载均衡的时候，根据ip做hash处理。比如IP尾号为1、3、5、7、9的请求到服务A上，IP尾号为2、4、6、8、0的请求到服务B上。就可以解决session问题，固定的ip会分配到固定服务器上。
缺点：存在单点故障问题
1.某个服务挂了，会造成分配到这个服务器上的客户全部异常，没有解决高可用性。
2.某个ip段的客户数量就是很大，超过这个服务器承受范围了，也会引起服务器故障和客户的请求超时，甚至请求异常。
3.3 Session Relication(拷贝、复制)
基于tomcat广播机制实现
多个tomcat之间，互相拷贝，复制彼此的session（session广播）。这样子不管请求到哪个服务器上，都有session。
缺点：消耗内存，消耗宽带。
3.4 Session Center
基于redis等第三方工具实现
不管请求到哪个服务器，都把session信息，保存在redis中。每个服务器，都从redis里获取用户信息。
这种方案，是目前大家普遍在用的，但是它也需要对redis进行高可用性维护，增加了系统复杂度。
