小米抢购限流峰值系统「大秒」架构解密
原文地址：
大秒系统的架构设计
大秒系统主要由如下几个模块构成
限流集群 HTTP 服务
放号策略集群 Middle 服务
监控数据中心 Dcacenter
监控管理体系 Master
准实时防刷模块 antiblack
基础存储与日志队列服务: Redis 集群、Kafka 集群等
整个大秒体系中大秒前端模块 (HTTP/middle/antiblack) 和监控数据中心使用 golang 开发，大秒监控管理体系使用 Python + golang 开发。
大秒前端的架构设计从三个系统展开
1.限流集群 HTTP 服务
2.策略集群 Middle 服务
3.准实时反作弊 antiblack 服务
1、限流集群 HTTP 服务
抢购高峰时，通常会有几百万的用户同时请求，瞬时流量非常大，HTTP 集群顶在最前线，接受用户的请求，将合法的请求发送的处理队列，处理队列设置一定的长度限制，通常情况下，抢购用户数与销售商品的比例在100：1，甚至更高，为了避免系统不被冲垮，保障绝大多数用户的体验，我们认为流量是部分可丢失的，当处理队列满时，丢弃入队请求；
虽然设计上过载流量是部分可丢弃的，但是策略层处理能力是非常 power 的，即便是需要丢弃流量，也是按流量的恶意程度，逐级丢弃的，正常用户购买请求不受影响。
2、策略集群 Middle 服务
HTTP 模块将满足条件用户的请求按照 uid 哈希的规则，转发到 Middle 集群中相应的节点，Middle 集群根据商品放号策略判断 (uid:sku:time) 组合是否可以分配购买资格，并返回给相应的 HTTP 服务；
使用 Middle 服务本地内存维护用户的购买记录信息，支持各种购买规则，比如：单次活动不限购买数量，单次活动仅限购买一款商品，单次活动每款商品仅限购买一次。
3、准实时防刷 antiblack 服务
基于日志流的防刷架构，在每台 HTTP 节点上部署日志收集 Agent，使用高吞吐量的 Kafka 做日志转储队列，antiblack 模块实时分析用户请求日志，基于 IP 粒度、Uid 粒度等做防刷。
虽然此处将 antiblack 模块定义为准实时防刷模块，但是作弊信息识别的延迟时长在 1 分钟之内，其中主要的时延发生在日志的转储过程中。
对于 HTTP 节点和 Middle 节点采用pull的模式拉去系统监控数据和业务监控数据，优点如下
(1) 灵活性高
由数据中心控制监控数据采集的粒度，在数据中心处理能力既定的情况下，可以根据前端集群的伸缩规模，灵活的调整数据采集的粒度，比如米粉节时，大秒前端集群扩容至过百台，管理的过大秒商品的数量在400个左右，业务级监控数据量很大，此时监控数据采集时间间隔很容易降配至 2s。
对于除Http服务和Middle服务之外的服务集群，如：redis，管理平台各个模块等可以使用监控数据采集agent，将采集到的数据周期性的push到redis队列，dcacenter采集协程实时的从redis队列中拉去消息，对于基础服务以及python实现的服务，增加了监控数据采集灵活性。
(2) 增强服务的可靠性与伸缩性
大秒在设计之初采用push的方式，在每台前端机器上部署一个数据采集agent，agent和大秒前端服务同时alive，才代表抢购系统健康运行。这样即增加了系统的不稳定因素，由不利于系统的伸缩，将监控数据采集逻辑内置到前端golang程序中，提供tcp管理端口，在数据中心使用pull方式采集数据，很好的解决了这个问题。减少了服务的数量，增强了整个系统的可靠性与伸缩性。
大秒的几点设计原则
分治是解决复杂问题的通则；我们从第一代抢购系统演进到当前的大秒系统，衍生出了很多服务，每个服务的产生都是为了专门解决一个问题，分离整个复杂系统，针对每个服务需要解决的问题，各个击破，重点优化。由此，才保障了秒杀体系整体性能、可靠性的提升；
服务化设计；系统解耦，增强系统的伸缩性与可靠性；
无状态设计，增强系统的伸缩性，提升集群整体处理能力；
状态数据局部化，相对于数据中心化，提升集群整体处理能力。
中心化监控管理，热备部署，既保证了服务的高可用性，又能够提升开发和管理效率。随着集群规模的增大以及管理数据的增多，分离管理信息到不同的数据管理节点，实现管理能力的扩容。通常情况下，中小型分布式系统，单机管理能力即可满足。
避免过度设计，过早的优化；小步快跑，频繁迭代。
没有华丽的技术，把细小的点做好，不回避问题，特别是在高并发系统中，一个细小的问题，都可以引发整个服务雪崩。