秒杀系统(一)——电商发展

秒杀系统——电商发展

LAMP :linux Apache Mysql PHP

电商项目业务整体概览：

按运营模式：

按运营方向:

传统电商 淘宝天猫、京东、唯品会、聚美优品、当当…

社交电商 拼多多、京东、国美、苏宁

网红电商 抖音、快手

内容电商 头条三农领域

常见术语：

PV： Page view，即网站被浏览的总次数
UV： Unique Vister的缩写，独立访客
CR： ConversionRate的缩写，是指访问某一网站访客中，转化的访客占全访客的比例 （订单转化率=有效订单数/访客数）
SPU： Standard Product Unit （标准化产品单元）,SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。
SKU： Stock keeping unit(库存量单位) SKU即库存进出计量的单位（买家购买、商家进货、供应商备货、工厂生产都是依据SKU进行的），在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。SKU是物理上不可分割的最小存货单元。

其中比较常用的是PV、 和UV

秒杀系统主要思考方向：

容量规划、架构设计、数据库设计、缓存设计、框架选型、数据迁移

方案、性能压测、监控报警、领域模型、回滚方案、高并发、分库分表

电商演变

主要是阅读淘宝技术这十年这本书，有兴趣可以去读一读。

个人网站：内部调用（JVM）完成 数据库项目都同一台服务

主要流程：下单》登录》session 》http

第一版优化：数据库优化

数据库优化： 一般就是将 session存在redis中

1、换数据库 mysql 》redis 》oracle》tidb 关系型性能

​ 读多写少（访问商品）》redis 搜索 es内存搜索（全量、增量）

2、分库分表（读写分离）

​ jdbc应用层：shardingsphere（shardingjdbc）、tddl， 就再java应用中。 这个性能稍微好点

读多写少（访问商品） > Redis 搜索 es内存搜索（数据同步 全量、增量）

​ proxy代理层：mycat、mysql-proxy， 在代理中，连接mycat or shardingsphere proxy就类似一个数据库直接连接， 就解耦性比较好

上述第一版存在的问题

1、跨部门的问题：第一版本粘合性太强，不适合进行跨部门开发。例如商品部门、会员部门

垂直： 会员部门、商品部门 周四（开发》测试》预演》生产）

会员部门：成功（kpi） 失败（回滚）

2、性能解耦、开发的问题

带来很多问题：1个N个服务，服务之间调用依赖也会增多。

可以采用RPC调用：dubbo、fegin、http：

1、异步调用 RPC调用 2、分布式事务（数据库事务A B 两个数据库、A服务、B、C）

rocketmq、shardingsphere（mq）、异步下单 （秒杀场景： 异步、削峰（流量降级）、解耦）

但是异步可能会带来一些问题： 消息重复、消息丢失、消息积压、幂等性问题。

ps：解释一下幂等性：A、B服务 A<>B 重复调用你，返回的结果不变就是幂等性； 如果返回结果改变，就不存在幂等性 。幂等性指的是多次操作，结果是一致的。例如：多次操作数据库数据是一致的，不会因为多次点击而产生了副作用。

常见的解决幂等性的方式有以下：（类似防抖的感觉）

1.唯一索引，保证插入的数据只有一条；

2.token机制；每次接口请求前先获取一个token，然后再下次请求的时候在请求的header体中加上这个token，后台进行验证，如果验证通过删除token，下次请求再次判断token。具体流程：防止页面重复提交。采用token加redis或token加jvm内存。处理流程：1. 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间；2. 提交后后台校验token，同时删除token，生成新的token返回。token特点：要申请，一次有效性，可以限流。注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用

3.悲观锁或者乐观锁，悲观锁可以保证每次for update的时候其他sql无法update数据(在数据库引擎是innodb的时候,select的条件必须是唯一索引,防止锁全表)【分布锁思路】

4.先查询后判断，首先通过查询数据库是否存在数据，如果存在证明已经请求过了，直接拒绝该请求，如果没有存在，就证明是第一次进来，直接放行。

5、状态机（分为已支付、未支付）