根据实际的业务维度，区分对待地给各个业务服务配置不同的超时时间，同时，最好也将它们的部署服务也分离出来。例如，天天酷跑的查询服务耗时通常为100ms，那么超时时间我们就设置为1s，某新手游的查询服务通常耗时为700ms，那么我们就设置为5s。这样的话，整体系统的成功率，就不会受到比较大的影响。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
（2） 解决同步阻塞等待
“快慢分离”可以改善系统的同步等待问题，但是，对于某些耗时本来就比较长的服务��言，系统的进程/线程资源仍然在同步等待过程中，无法响应其他新的请求，只能阻塞等待，它的资源仍然是被占据，系统的整体吞吐率仍然被大幅度拉低。
解决的思路，当然是利用I/O多路复用，通过异步回调的方式，解决同步等待过程中的资源浪费。AMS的一些核心服务，采用的就是“协程”（又叫“微线程”，简单的说，常规异步程序代码里嵌套比较多层的函数回调，编写复杂。而协程则提供了一种类似写同步代码的方式，来写异步回调程序），以解决同步等待的问题。异步处理的简单描述，就是当进程遇到I/O网络阻塞时，就保留现场，立刻切换去处理下一个业务请求，进程不会因为某个网络等待而停止处理业务，进而，系统吞吐率即使遇到网络等待时间过长的场景，通常都能保持在比较高的水平。
值得补充一点的是，异步处理只是解决系统的吞吐率问题，对于用户的体验问题，并不会有改善，用户需要等待的时间并不会减少。
3. 防重入，防止重复发货前面我们提到，我们设置了一个比较“合理的超时时间”，简而言之，就是一个比较短的超时时间。而在数据写入的场景，会引起新的问题，就我们的AMS系统而言，就是发货场景。如果是发货请求超时，这个时候，我们需要思考的问题就比较多了。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
（1） 发货等待超时，发货服务执行发货失败。这种场景，问题不大，后续用户重新点击领取按钮，就可以触发下一次重新发货。
（2） 发货等待超时，发货服务实际在更晚的时候执行发货成功，我们称之为“超时成功”。比较麻烦的场景，则是每次都是发货超时，而实际上都发货成功，如果系统设计不当，有可能导致用户可以无限领取礼包，最终造成活动运营事故。
第二种场景，给我们带来了比较麻烦的问题，如果处理不当，用户再次点击，就触发第多次“额外”发货。
例如，我们假设某个发货服务超时时间设置为6s，用户点击按钮，我们的AMS收到请求后，请求发货服务发货，等待6s后，无响应，我们给用户提示“领取失败”，而实际上发货服务却在第8秒执行发货成功，礼包到了用户的账户上。而用户看见“领取失败”，则又再次点击按钮，最终导致“额外”多发一个礼包给到这个用户。
例子的时序和流程图大致如下：
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
这里就提到了防重入，简单的说，就是如何确认不管用户点击多少次这个领取按钮，我们都确保结果只有一种预期结果，就是只会给用户发一次礼包，而不引起重复发货。我们的AMS活动运营平台一年上线的活动超过4000个，涉及数以万计的各种类型、不同业务系统的礼包发货，业务通信场景比较复杂。针对不同的业务场景，我们做了不同的解决方案：
（1） 业务层面限制，设置礼包单用户限量。在发货服务器的源头，设置好一个用户仅能最多获得1个礼包，直接避免重复发放。但是，这种业务限制，并非每个业务场景都通用的，只限于内部具备该限制能力的业务发货系统，并且，有一些礼包本身就可以多次领取的，就不适用了。