秒杀系统架构

   今天被问到秒杀系统的设计，说实话没做过这个东西，就简单的按照处理高并发的后台逻辑进行回答的，答了个寂寞，就收集相关的资料整理一下，看看秒杀系统的演变过程。

架构原则：1.数据量尽量少         在网络上传输数据是需要时间的，数据量少网络传输时间就少；服务端处理数据也是要时间的；

                  2.请求数量尽量少      每个请求都要通过三次握手来建立连接；要是页面有连接数限制的话，有些请求需要等待执行；要是不同请求的域名存在不同的情况，还涉及到dns解析；

                  3.路径要尽量短         每经过一个服务节点都需要通过创建socket连接进行通信，然而每多一个连接就会增加新的不确定性，对整个请求的可用性就要下降；

                  4.依赖尽量少             依赖指的是完成一次用户请求必须依赖的系统和服务，不同的服务间它们的重要性等级是不同的，要防止重要系统被不重系统拖垮；

                  5.不要有单点              单点是大忌，单点意味着性能有限无法实现高可用要求；

设计不能过度，所以架构通常是一个演变过程，不可能一步到位的。

初始阶段用的人少，简单架构就行了。

当请求量变大的时候（从1w/s到10w/s）；当前架构就会遇到瓶颈，这个时候需要进一步的改造架构来提升性能了。

在原有的架构上将秒杀服务独立出来形成秒杀系统，这样可用进行针对性优化；

对秒杀系统做一个集群，这样秒杀系统在高流量情况下不会影响正常购买商品的集群的负载；

通过缓存系统缓存热点数据提高读性能；

通过秒杀题来防止秒杀器抢单；

当请求流量超过100w/s时，当前架构是支持不住的，需要进一步做架构优化

1.对页面进行彻底的动静分离；2.在服务端对秒杀商品进行本地缓存；3.增加系统限流保护，防止最坏的情况发生