一、第一代秒杀价构
在电商模块直接插入秒杀系统，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严重堆积
放号模块处理不来
问题处理
过载保护：限流和主动拒绝
长连接模块限流，来保护放号模块；放号模块对时间过久的请求拒绝处理。
架构设计五
长连接模块拿到的请求加上当前时间，放号模块拿到请求判断时间是否过期（设计过期时间）
核心流程三
这样就设计出了一个性能稳定，并发量大的秒杀系统。