秒杀系统架构优化思路

1. 秒杀主要面对的问题是瞬间流量和并发、双抢或多抢问题，前者主要靠精简计算逻辑、异步处理、消息队列等，后者主要靠数据库锁机制或者内存资源锁。在整体逻辑上可以设置流量闸和降级机制。 2. 秒杀系统两大特性：排队和限流;不可能完全实时，排队是关键。如果发现即将过载，限流可以保证大部分业务正常 3. case: 对应抽奖的算法，如1分钟内有10个奖品，把1分钟分成10个段，让每个段都能有奖品送出 sol: 因为抽奖，一般来说都是限制了参与用户上限的。没有限制的，一般也限制了多少人之类必须抽完。这种普遍的做法，都是讲奖品队列先生成好的。打个比方，我预计这次活动，大概有100个奖品，大约1w个人参与。 我会生成一个1w个奖品队列，其中一部分是没有奖金，将100个奖品随机打散在这个队列里面。然后1w个队列领取完了，后面进来的都返回固定的没有抽中的数据。队列可以直接用redis。大队列可以拆分小队列的。 这样前端可以随意做代理。不影响数据，也不影响算法。而且开发实现简单，性能高，基本上一台机器，同时开几百个万人活动都没问题。不要在用户请求的时候去算，很容易出现并发问题。上锁会有性能问题。 每次去算会有数据一致性问题，你需要将所有的请求分配到同一台机器上面，  而且每次都需要根据剩余奖品个数去动态调整你的系数，奖品越少，中的概率越底。奖品剩余个数会有一致性问题，很容易就出现奖品超了。 而且每次去算，请求量大了，随机数是不靠谱的，原生的随机数哪怕是加种子，  也容易出现重复，导致某一个时段，奖品被刷完了，需要做的技术手段限制太多。