秒杀系统——电商发展
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、状态机(分为已支付、未支付)