限制同一用户访问次数
限流器底层算法
令牌桶算法
可能会有突发流量，处理速度有波峰波谷。但不会长期。
之前一直没有请求，桶满。突然来一大波流量，消耗掉了所有令牌，业务组件承担一波突发流量。波峰过后正常，每秒十个请求
漏桶算法
服务器压力稳定，处理请求的速度恒定
并发问题
表结构设计
秒杀项目主要涉及7张表，其核心是用户表、商品表、订单表：
- 用户表（user_info）
手机号作为用户名，密码存储的是密文，采用MD5加密。 - 商品表（item）
商品名称，价格，图片链接，存储的是绝对路径（HTTP），描述存储的是富文本信息（HTML）。 - 库存表（item_stock）
与商品表是多对一关系，将库存从商品表拆分出来，是为了减小修改库存时锁的粒度。 - 活动表（promotion）
与商品表是一对一关系，一个商品只能参与一个活动，我们对秒杀业务模型做了精简的。 - 订单表（order_info）
与商品表是多对一关系，订单中记录了下单时的单价、数量、金额，相当于商品在下单一刻的快照。 - 序列表（serial_number）
用于记录订单等业务场景中的序列号，分别存储了业务名称、当前序号、增长步长。
生成序号时必须严格互斥，不能采用非锁定读（MVCC），所以我们按订单为维度来生成序号，竞争很大。
这里可以做进一步优化，比如增加商品列、用户列、服务器列等，将单一的订单维度拆分为更多维度，
随着维度（粒度）的降低，竞争便会缩小。当然，也可以考虑不用此表生成序列，而是采用雪花算法（百度一下）。 - 库存流水表（item_stock_log）
用户记录商品在下单时的状态流转情况，便于追溯订单的状态，从而为MQ回查订单状态提供依据。
库存流水表与商品表是多对一关系，记录了商品ID、扣减数量、订单状态。
超卖
下单时锁库存、超时释放订单回补库存，解决超卖问题。分布式锁防止超卖
