秒杀系统需求分析及架构设计

需求分析：
1.单品交易，多品交易

IO模型，线程模型，IO相关的知识点

业务分析：
1.可以确定是瞬时并发，非常态化并发
2.机器配额的选择与计算：
— 10W TPS — 但是是秒杀场景，假设秒杀100件商品
— JVM内存计算：假设单个订单对象大小0.5M,最终执行成功事务也就会产生100订单对象，100 * 0.5M = 50M (Eden区大于50M最佳)
— 线程栈占用内存估算：
1.栈内存在JDK1.8中规定，最小是128KB；
2.极端条件：忽略掉PC计数器以及本地方法栈大小，栈内存128KB来计算：
这里以64G内存的服务器做估算：
服务器内存标记为64G，实际内存在90%左右，即57.6GB；
JVM规定，所有的栈内存之和一般不超过实际内存的2/3 —> 57.6 / 3 * 2 = 38.4GB
38.4 * 1024 * 1024 / 128 = 314582.8 约等于 31W左右
但是这是极端计算，服务本身还有其他正在运行的进程，JVM还有垃圾回收线程等线程及其他因素也要占用内存
但64G服务器应该是满足的
— 由上述计算可以看出，主要压力在于线程数和网络IO,因此上层设计尤为重要；
3.为了应对单点故障，可以采用负载均衡将请求均摊多台服务器上，因此可以减小单台服务器的配置

服务架构设计：
高并发：
1.动静分离
2.多级缓存
3.负载均衡
4.接入层
5.HTTP 3.0
6.相应式网关
7.常态化、瞬时并发

高性能：
1.性能指标
2.高并发下谈高性能
3.多级缓存、读写分离
4.异步设计
5.再论并发，莫论一致性
6.不浪费，才是高性能

高可靠：
1.负载均衡 —LVS —> CDN —> Nginx —> 网关
2.服务无状态的设计 —如果服务有状态的话，比如说用户请求依赖于某个session,这样会带来服务间session同步成本，而且每多扩一台机器，就需要同步其他服务内存中数据，所以可以尽量把状态数据迁移一个公共的访问介质中，这样可以保证我们启动服务关闭服务速度更快，没有任何影响，总而言之就是需要尽量考虑做到服务无状态的设计；
3.服务治理 (熔断，降级) — 可用性上可能有所降低，但是可靠性上会强一些；
4.存储层可靠性
5.异地多活—异地多活其实间接带来并发的提升和性能提升,可以通过动态DNS,不同地域的人访问不同的数据中心(主主同步或者主从同步)
6.业务隔离 — 能够隔离开的业务尽量独立的部署不同的容器中，如果出现降级，熔断，故障的时候不会影响到其他的业务；

需要解决的问题：
超卖少卖问题 — 相对与超卖，少卖是很容易被忽视的问题，比如说秒杀成功却订单处理超时，网络抖动等导致少卖
秒杀库存设计
秒杀双写一致性
秒杀多级缓存
秒杀MQ异步
分布式事务问题
防止缓存穿透，击穿，雪崩