2018-07-081.对于用户服务，在抢购期间可以准备降级策略，压力过大时保证用户登录的可用，注册和修改信息可以做降级处理
2.抢购下单涉及到订单，库存，和商品查询。可通过请求排队来限流，超出库存的请求直接返回。
为了应对库存和商品服务可能发生的故障，可以提前对商品数据和库存数据做缓存，如果对端服务故障，本地也可以提供服务
3.支付依赖第三方系统，合理设置熔断策略，如支付平均时长超过限制可提示用户稍晚做支付作者回复: 分析全面👍👍
58
2018-07-081.抢购页面最大程度静态化，一般用户开始前会尝试刷新页面，查询压力要比下单压力大很多
2.抢购页面要求登陆后访问，一般人不会抢购开始那一刻才进来，错开登陆压力
3.活动未开始，不允许点击抢购按钮。对请求做轻量分析，对于请求过频繁或者可疑ua等做拉黑，为防误杀要求输验证码
4.抢购下单接口采用排队+限流，降低压力的同时保证公平性，如抢购1000件，只放2000人进来，其他返回排队人数过多。进来的请求全部入列，固定数量的队列消费者控制订单生成速率以及走到支付流程的速率。支付是下单流程核心功能，降级不应该降级掉。队列做削峰，保证支付系统不会压力过大。
请指正～展开作者回复: 分析的很好，支付如果依赖第三方的话，需要考虑熔断，然后做补偿或者容错措施，例如提示用户10分钟后再来支付
20
2018-07-081.登录接口在流量特别大的时候，可以适当降级，较少参与人数，另外一点是登录一般有有效期（尤其对于web客户端），可以适当延长登录有效期。2.抢购接口采用队列方式，无法支撑时，也可以适当限流。另外一点，秒杀一般还会有一个秒杀结果查询的接口，也可以降级或者减小请求频次。3.支付接口，一般第三方支付对接入方有流量限制，可以提前申请扩大限制，同时做好降级准备。作者回复: 分析更好，支付接口依赖第三方应该是熔断，然后做好容错措施，例如提示用户10分钟后来支付
12
2018-09-14我发现了,系列文章越到后面,人越少.还好我坚持看到了这里...作者回复: 😄😄被你发现了，一定要坚持
9
2018-08-10老师你好，关于排队方式请教个问题：
比如用户从pc发一个请求过来，我们将这个请求放到队列，这个时候就直接返回客户端，客户端定时轮训排队状况，还是说是其它处理方案呢？作者回复: 常见的有：1. 轮询，2. Long polling，3. HTTP/2推送
5
2018-07-071、在抢购开始前，可以通过降级来保证登陆服务。例如提前半小时限制注册、修改用户信息的服务。
2、整个流量的洪峰应该在于下单。下单可以同时基于限流和排队两种方案，这个需要大概估计到。譬如说100W人抢购100件商品，可以在整点时对下单操作做99%的限流，把1000K的访问问题改写为10k，10k里面再进行排队。
3、支付属于第三方调用，使用熔断机制（譬如说下单后保留30分钟的支付的时间，等待支付宝服务恢复）
未实际开发过实际抢购系统，期望老师和其他同学提供好的方案借鉴学习展开作者回复: 基本思路就是这样的，另外，登录也可以降级
4
2018-09-09登录大体可分为免密登录和非免密登陆（包含登陆密码、人脸登陆、短信登录等），95%左右的都是免密登录，内部的实现相对也比较简单，采用限流方式就可以了；对于非免密登录，内部实现相对会复杂些，并且会有风控策略，因而面对大流量需要同时采取限流和内部降级两种策略了。
对于抢购，优先采用排队策略，可以避免限流策略下前面的用户因限流导致抢购失败而后面的用户限流通过情况下用户体验不好的情况。
支付采用熔断策略即可，同时要将对应的错误码进行适当的优化，并提供用户再次进行支付的入口。熔断策略的实现可能会稍微有点复杂，并且需要系统报警+人工确认双重保证，避免网络、机器、电源等情况引起的误触发。作者回复: 正确
3
2018-07-09功能：登录、抢购、支付。
接口故障应对方法：降级、熔断、限流和排队。
三个功能是有依赖关系的，登录了才能抢购，抢购了才能支付。因此如果从依赖关系考虑，总体访问量过大无法满足时，降级时优先保留登录，其次是抢购，再其次是支付。但是支付是成交关键，并且访问数量比登录抢购少很多，可以说不是一个数量级，因此我觉得支付优先级是最高的。
其中只有支付涉及外部调用，因此只需为支付提供熔断方案。
抢购功能提供排队和限流方案，对于每个参与抢购活动的商品根据商品数量设定队列长度，限流也根据商品数量进行限流。
支付失败要怎么处理？展开作者回复: 假如降级时优先保证登录，但是用户登录进来后发现抢购不了，其实体验也不好，而且已经抢购了的用户可能无法支付，这样体验更不好，甚至会引起投诉，因此抢购类降级是优先降登录会好些，保留抢购和支付，保证进来的用户能够完成业务流程。
支付失败真没什么好办法了，因为这是核心链路的核心功能。 3
2018-09-27访问的流量在每个环节可能逐步递减（登陆例外）
1、引导部分用户提前登陆；
2、秒杀价系统独立部署（感觉和其他系统部署在一起才需要降级）；
3、抢购使用排队方式。有界队列，队列大小可以预估较大长度，队列外的拒绝；
4、（如果要求以支付成功为准）通过队列和熔断。
（如果以下单成功为准）使用熔断。提醒稍后再付展开作者回复: 正确👍
2
2018-08-15我认为核心需要保证的业务的是抢购，抢购业务可能并发用户较多，对于抢购可以采取排队策略，对参与抢购的用户进行排队。对于登录服务，当发生接口故障的时候，为了保证抢购业务顺利，可以采取降级策略，可以让部分用户登录失败，可以停掉注册等接口，当大量调用支付系统，而支付系统反应慢而影响整个系统的时候，可以对支付系统进行容错处理，可以让用户过段时间再支付。对于熔断的阈值可以根据具体的业务来判断。作者回复: 分析正确👍👍
2
2018-07-26“每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。”我之前也思考过类似于淘宝秒杀或12306这种高并发系统，应该不会所以资源在一个队列里排队，这样整个系统并发度无法水平伸缩，那么请问老师一个技术细节问题，每个商品一个队列这个有啥推荐的实现方案吗？作者回复: 用kafka，用商品id做队列名称就可以了
2
2018-07-08老师，我有个双机那节的问题，如果采用了mysql 双主架构，对于库存这样的字段，在并发较高时，如果两个mysql同时 update 了库存（采用乐观锁，库存本身作为版本号)，这样会不会导致货物被两个人购买但库存却只减了1呢？该怎么解决呢？求赐教作者回复: 会的，库存不能用双主
2
2018-11-20
第一版（不看评论的思考回答）
假如有100种商品，每个商品1k件。首先设计100个队列。
对于已经登录的用户
限定每个队列只能有1w个排队的人，如果超过1w人，就提示人数太大，只能等下次了。
已经未登录的用户
如果抢购时间段同时登录人数太多，超过100w, 逐步降级和熔断
a.可以登录，但不能参与抢购了
b.暂停登录，拒绝服务 （防止把系统拖垮，影响正常的不抢购的用户）
第二版（看过评论之后的思考回答）
1、 忘记了熔断是对外的。老师特意提示了依赖了第三方支付。
所以上面 逐步降级和熔断 感觉应该是 逐步降级和限流
假如有100种商品，每个商品1k件。首先设计100个队列。
对于已经登录的用户
1、抢购 限定每个队列只能有1w个排队的人，如果超过1w人，就提示人数太大，只能等下次了。
2、熔断处理， 提示抢购成功的同学，“歇歇再支付，不着急。” 分散支付请求 。
已经未登录的用户
如果抢购时间段同时登录人数太多，超过100w, 逐步降级
a.可以登录，但不能参与抢购了
b.暂停登录，拒绝服务 （防止把其他系统拖垮，影响正常的不抢购的用户）展开作者回复: 认真思考，点赞👍
1
2018-10-06感谢老师的专栏，写的很专业，学到了很多，物超所值，尤其是一些方法类的东西，受益终生，以前学习过程中的疑问，也从老师这找到了答案。也期待老师的其他专栏。作者回复: 没有其它专栏的计划，写个专栏要几年😂
1
2018-07-08整点前降级其他非核心功能，登录采用限流，抢购采用排队加限流，支付对支付宝要有熔断，可加限流。完毕！作者回复: 没问题就降级，有点过分了呀，产品经理要打你😂
另外，支付最好也不要限流，支付限流的话，用户体验很不好，还不如前面限流 1
2018-07-07整点限量抢购核心业务应该是登录和抢购，抢购完了放入购物车不一定马上支付，所以在系统负载较高的时候可以让支付接口做降级处理，过了整点再恢复。抢购接口一般采取商品对应一个抢购队列，队列到上限之后拒绝流量进来，系统根据自身负载情况去消息队列进行流量的拉取，大致思路如上所述，还有什么遗漏还请老师指教作者回复: 一般不建议对支付做降级，用户体验很不好，还不如登录和抢购阶段限流，这是有心理学理论支撑的，用户没抢到前，如果抢不到他会认为自己运气不好，但如果用户抢到了没法支付，他会觉得自己损失了，会触发“损失厌恶”心理😄
1- 2019-09-20如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等功能，你会如何设计接口级的故障应对手段？
登录是首先要保证的，所以最好不要做限流或排队，因为登录功能非常影响用户的体验。万一出了状况那也只能限流了。
在用户登录成功发出抢购请求后如果出现后端故障或响应慢则应该考虑针对实际情况做降级或熔断。
一旦用户抢购成功发起了支付请求则应通过排队来确保支付成功。作者回复: 可以看看其它评论
2019-09-01课后思考及问题
1：降级——冗余代码或开关控制逻辑，当依赖的基础服务无法提供时，选择提供次一级的服务。
2：熔断——冗余代码开关逻辑，当依赖的某个外部服务提供的变量值达到某个特定值的时候，走别的分治逻辑
3：限流——流量超过预期的量，对超过的量进行限制，抛弃或先缓存一下随后处理
4：排队——也是流量过多，或者需要保留请求的处理次序，使用队列的方式缓存处理信息随后再处理。
如果我来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等功能，我会如何设计接口级的故障应对手段？
登录——我认为需要在前端加上验证码校验就行，防止同一个用户或用一个IP疯狂的登录，至于后端不应该做过多的限制，一个系统连登录都不行，估计会影响比较大。
抢购——这个是秒杀的关键，这里需要对接口进行限流、排队的控制，防止流量洪峰瞬间将系统拖垮。
支付——抢购成功后需要支付成功才算秒杀成功，这里又依赖支付宝这个外部服务，经抢购的过滤流量应该会下降不少，不过也要防止支付宝服务不稳定的情况发生，需要做好降级和熔断的业务处理。降级服务，需要安慰一下抢购成功支付失败的客户。展开- 2019-07-05如何应对域名故障？如域名被hold。
作者回复: 如果是APP，可以用HTTP-DNS，如果是网页，基本没办法
2019-05-10为啥没提供一些工具组建供参考作者回复: 不同语言不同行业都不同，JAVA推荐spring全家桶