简单题，但是因为过于简单你反而会忘记装逼。
在这个问题之下，还是可以结合实践来刷亮点，例如说在回答的时候提及自己设计过的一些特殊的、有亮点的重试方案。在这里我直接给出一个一个在超时机制里面也说过的实践案例，你可以作为参考。
简单题。
其实这个问题大部分人都能想到基本的答案，你要刷亮点可以从两个角度出发：一个是使用自己实践中的案例来证明使用超时机制的必要性；另外一个则是从重试最终都要失败的角度，阐述监控和告警以及人手工介入作为兜底。
在这个问题之下你同样可以结合实践，引述自己使用过的重试策略，一方面是证明重试机制的效果，一方面则是表达自己有丰富的重试设计经验。
在这个问题之下，你同样可以阐述自己在实践中使用的重试案例来刷亮点。当然，最好的案例还是有些特色的，或者说有一些特殊之处的。
简单题，一般出现在社招。
在这个问题之下，你可以深入讨论非幂等接口的重试问题，从而引出表单重复提交这个典型场景，并进一步总结出来重试 + 幂等这一个分布式系统中的经典容错机制。
简单题，在校招和社招里面都能遇到。
在这个问题之下，可以结合实践用自己设计的有特色的重试策略来刷亮点。
简单题，在校招和初级工程师面试中可能遇到。
一般来说，在重试的时候，最简单的做法就是进程内重试。所以你可以结合实践来回答自己使用过的进程内重试，这里依旧会使用在重试中一直使用的案例：区分偶发性超时和频繁超时的重试机制。
你要刷亮点，可以从两个角度刷亮点。一方面是你在实践中使用的跨进程重试案例，另外一方面就是讨论跨进程重试类似于分布式任务调度，都要考虑负载均衡以及抢占（分布式锁）之类的问题。
刷亮点的要点在于指出这两者经常结合在一起使用，并且使用一个实践中的具体案例。
略难的题，难点在于很多人没有评估过，或者不知道怎么评估。
重试策略的有效性评估是很简单的事情，至少比评估熔断、限流、降级等的有效性简单多了。只需要评估在没有重试策略的情况下和有重试策略的情况下，业务执行的成功率就可以了。而后我用了当年我统计不同重试次数的成功率的案例来刷亮点，你照着背就可以了。
简单题，一般出现在社招中。
你在这个问题之下，要刷亮点就可以阐述雪崩问题和重试风暴问题，以及你对应的解决方案。而且，有些时候我会认为面试官问这个问题，可能就是醉翁之意在重试风暴。
在面试中其实你可以主动提起这个问题的，比如说在提到自己提高系统可用性的时候，可以综合阐述自己为了提高系统调用的成功率，使用了一些什么样的重试策略，如何设计出来的。
当然，在刷亮点的时候，还是可以使用一直提到的区分可重试不可重试的高端重试策略。
略难的题，这个一般只会出现在社招了，毕竟校招是没有啥经验的。
在这个问题之下，你要装逼，最佳的方案就是解决重试引发的雪崩和重试风暴问题，其它的都不重要。
略难的题，因为很多人在设计重试的时候，都是凭借感觉、经验随便设置一个重试间隔，以及重试次数。
在这个问题之下，你可以使用我之前做的一个实验，并且总结出来的规律刷亮点。
其实重试失败了之后没啥好说的，除了记录日志并且告警以外，做不了啥东西了。你在面试中可以坦白说这个，我也不觉得谁还能搞出来什么骚操作。
略难的题，这个题目一般只会出现在社招里面。
之所以是略难的题，倒不在于重试，而在于你可能不知道什么是级联失败。在这个问题之下，你还是可以用我提供的那个区分是否可重试的重试策略来刷亮点。
重试风暴是一个比较好理解的概念，风暴很容易就让你想到一大堆的重试请求。同样的，这个问题刷亮点还是可以用我提供的那个重试案例。
略难的题，能够问出这个问题的面试官还是有两把刷子的。
在这个问题下想要刷亮点，可以考虑设计一个同时使用了重试和熔断的服务治理策略。
略难的题，很多面试官会知道超时了可以重试，但是很少会这么问。
在这个问题之下，显然你可以用我之前一再提及的区分可以重试的超时和频繁超时的案例。
