标签：性能 strong 保存 定时同步 其他 hbase 一个用户 思路 排队
秒杀系统是一个并发量要求高、负载均衡要求高的、业务场景简单但是逻辑稍微复杂的系统，所以经常会作为面试高级后端开发的面试题。主要考察的就是对问题的拆解、分析、解决，以及架构设计的能力。
服务端是一个潜在的考察点，还是有很多问题需要解决的。有些网上给出的设计方案没有对这块做详细考虑。
客户端限流（在浏览器上行不通）
客户端做一定控制来限流（比如概率），防止刷单，减少成功次数，显示在排队，实际上没发网络请求
前端展示
秒杀按钮展示要有个定时器，涉及到前后端时钟同步的问题
校对时间差
获取服务端时间，客户端时间 - 服务端时间，比较得到差值，用这种方法来同步。然而注意到网络是有开销的，这个开销需要想办法消除。否则这种毫秒级甚至秒级的时间差，会影响到秒杀的公平性。
如果这个同步是很长时间之前同步的呢，可能时间过了很久后已经相差较多了。
如果客户修改系统时间怎么办
这一层要考虑限流问题，以及防止恶意刷量的问题。首先限流要尽量在上层去做，以最大程度减少后端系统的压力。其次，要避免用户找到url，不停的大量发送网络请求，或者在活动前就发送，这样也是有问题的。
限流
这属于分布式限流，一般采用 redis 来做限流，可以用令牌桶来做
防止提前刷 url
这个可以在服务端根据系统时间来决定要不要处理，也可以用一个随机的网址来保证无法模拟 url 请求（这个点还比较模糊）
而且这里涉及到服务端各服务器的时钟同步
同一个 url
这里可以用 redis 记录或者本地记录来进行计数过滤，保证用户每秒发送请求响应次数不超过一个阈值
悲观锁
性能比较差
乐观错
性能好些
缓存
缓存来保存库存量，减少访问 mysql 带来的并发，用 redis 可以做到
但是如果在拿到资格后出现问题，怎么办？在缓存里已经被减掉了，这时需要归还资格，否则卖出的数就会少，这个错误可能会出现在生单，订单入库的阶段，直到入库，这个资格才能算作彻底被消费掉
mysql 更合适，有唯一键的限制，hbase 存放海量数据
同步还是异步的问题
同步
好处，等待结果写入库里，完全闭环
异步
可能会写入失败，丢失订单信息，因为订单详情是要尽快展示给用户的，所以一旦失败，该取消这次秒杀的结果，还是继续认为成功，是比较棘手的问题。异步出错了，可能可以修复，但是也可能会一直出错，重试无效。这种应该归还，然后把结果通知给用户。如果异步默认生单成功，但是怎么也写不进去，那就会有问题了。（这块每太想清楚）
先说说异步做法
交由本地线程池处理
占用 service 层资源
发送 kafka
减少了 service 层资源占用，但是要保证 kafka 可靠，这里需要保证 有副本，ack -> ALL，replica 设置>1
如何保证同一个用户只能下一个单
因为资源被占用后，后续不一定生单成功，所以如果资源没了，不应该直接展示秒杀结束
server 端时间同步
标签：性能 strong 保存 定时同步 其他 hbase 一个用户 思路 排队
原文地址：https://www.cnblogs.com/43726581Gavin/p/9066053.html
