一、第一代秒杀价构
在电商模块直接插入秒杀系统,MYSQL
核心逻辑(通过数据库updata 完成)
假设可以秒杀5台:
“updata tbl set count = count+1 where id =101 and count+1 <= 5”
但数据库太慢。
核心逻辑优化:
begin;
如果用户无法即可获得锁,则返回错误。从而这个事物回滚。
select 1 from tbl where id=pk updata nowait;
updata tbl set count = count+1 where id =101 and count+1 <= 5
end;
性能可以提高60倍。
及时这样网站还是崩溃了。量太大数据库撑不住。
问题分析:
同步处理:对每个客户请求都实时的去处理
资源耦合:秒杀系统和其他系统在一个模块里面,当秒杀系统占完资源其他系统资源也不够用。
二、第二代秒杀系统
1、资源隔离
2、日志做了异步处理
核心逻辑:
每台机器人工分配资格限额
每发一个资格,打印一条日志
收集日志,进行汇总
如果资格发光了,在对应的机器生成一个文件
放号控制系统放号时如果发现存在文件,则变为售完状态
流程图:
遇到的问题:
日志丢失:在日志收集模块
收集延迟
超卖:日志丢失和收集延迟会导致超卖
随着量大了会出现超卖问题。
核心逻辑优化:
日志收集改为写入redis里面
遇到的问题:
性能问题:cpu100%,用的是非编译语言写的。
延迟:分钟级
维持成本:扩容代价大,因为人工为每台机器分配资格
量为每秒处理10万的处理。
总结:
公平、排队、保护后端
三、第三代秒杀系统大改变
1、goleng重构
2、通用产品
3、平台全新架构、全面自动化
模块划分:
长连接模块:用了保持用户的链接,用了排队和限流
放号模块:根据策略用户能不能拿到资格(恶略用户,如机器人)
架构设计一
MQ:redis
GO+REDIS
核心流程一
关键技术:
token的伪造
单Ridis抗不住
机器人算单
Token伪造解决方案:
token组成:uid+time+商品id+source+salt
摘要生成:md5(uid+time+商品id+source+salt)
服务器重新计算摘要
和用户传过来的摘要进行对比
redis持久化存储,避免碰撞
性能问题:
恶意用户刷单:
黑名单
白名单
核心流程二
架构设计二
单这架构模式存在着时效性能差的问题。因为通过日志收集来做,当量很大的时候,日志打印的非常大,收集的话就会有延迟。
架构设计三
有运维问题
架构设计四
又崩溃了:
瞬时上百万请求
redis严重堆积
放号模块处理不来
问题处理
过载保护:限流和主动拒绝
长连接模块限流,来保护放号模块;放号模块对时间过久的请求拒绝处理。
架构设计五
长连接模块拿到的请求加上当前时间,放号模块拿到请求判断时间是否过期(设计过期时间)
核心流程三
这样就设计出了一个性能稳定,并发量大的秒杀系统。