秒杀系统架构

秒杀系统是一个并发量要求高、负载均衡要求高的、业务场景简单但是逻辑稍微复杂的系统，所以经常会作为面试高级后端开发的面试题。主要考察的就是对问题的拆解、分析、解决，以及架构设计的能力。

基础架构

服务端是一个潜在的考察点，还是有很多问题需要解决的。有些网上给出的设计方案没有对这块做详细考虑。

客户端限流（在浏览器上行不通）

客户端做一定控制来限流（比如概率），防止刷单，减少成功次数，显示在排队，实际上没发网络请求
前端展示

秒杀按钮展示要有个定时器，涉及到前后端时钟同步的问题
- 校对时间差
  
  获取服务端时间，客户端时间 - 服务端时间，比较得到差值，用这种方法来同步。然而注意到网络是有开销的，这个开销需要想办法消除。否则这种毫秒级甚至秒级的时间差，会影响到秒杀的公平性。
  - 发送更轻量级的服务响应
  - 优化代码，使客户端和服务端计算时间的流程很短
  - 回调计算时间先执行
  如果这个同步是很长时间之前同步的呢，可能时间过了很久后已经相差较多了。
  - 定时同步，半小时一次
  如果客户修改系统时间怎么办
  - 记录客户端的周期时间序列（这个周期可以设置的短一些，比如10秒这样子），第一次为基准，先做客户端与服务端同步，得到差值 T
  - 在第二个周期，计算两个时刻的时间差，再减去周期时间，就是相差的时间，如果在某一个很小的范围内，说明没有问题，如果不在范围内，说明可能修改了时间，那么修改 T 为 T + 差值

这一层要考虑限流问题，以及防止恶意刷量的问题。首先限流要尽量在上层去做，以最大程度减少后端系统的压力。其次，要避免用户找到url，不停的大量发送网络请求，或者在活动前就发送，这样也是有问题的。

限流

这属于分布式限流，一般采用 redis 来做限流，可以用令牌桶来做
防止提前刷 url

这个可以在服务端根据系统时间来决定要不要处理，也可以用一个随机的网址来保证无法模拟 url 请求（这个点还比较模糊）
而且这里涉及到服务端各服务器的时钟同步
同一个 url

这里可以用 redis 记录或者本地记录来进行计数过滤，保证用户每秒发送请求响应次数不超过一个阈值

mysql 更合适，有唯一键的限制，hbase 存放海量数据

同步还是异步的问题