spring真的是只有想不到没有做不到～

你好，对于重试是否可以不让当前线程休眠呢。如果当前线程休眠 此时这个线程的利用率就不高，我觉得应该放到线程池里面是否好一些呢？

server error不是不应该重试，属于服务端内部错误，不是暂时性的

用过.net core上的Polly：http://www.thepollyproject.org/ 推荐给用C#的兄弟姐妹们。

之前做的重试策略是：异常发生的时候，数据库记录当前上下文，依据重试次数来确定重试时间，推送给延迟消息队列控制重试

又一篇好文。感恩。。。

重试依赖被调用方做了良好的幂等设计和接口返回码规范，知道什么情况下应该重试，什么情况下直接报故障。重试也需要做避让设计，防止被调用方压力过大，压垮系统。spring重试项目可以做到注解方式定义重试，防止代码注入。server mess还需要多了解了解。

总结：使用重试策略有个前提，就是问题不是永久性的，如果问题一直无法解决就没有必要再重试了。很有必要根据出错原因来判断是否有必要进行重试。重试策略主要分为以下几种：不退避、固定退避时长、随机时间退避、指数退避、随即指数退避。
应用重试机制需要注意以下几点：是否需要进行重试、使用什么重试策略以及重试几次、熔断和恢复策略、重试需要有幂等的支持、重试策略可以复用、复杂操作，比如有事务需要有特殊设计。

坚持学习，学习笔记 https://mubu.com/colla/3HCUwf3_nJM

重试策略的设计需要考虑重试的场景，重试的次数自己相应时间的限制。由于单机的服务变成了分布式的微服务，由于网络，流量等等未知原因，重试不可避免，应该考虑在代码设计中。对于事物性的操作，还需要考虑服务调用的幂等性，保证服务最终状态不出错

我们的系统比较靠后，提供的接口中会标识出当请求失败时是否建议调用方重试，具体重师与否有调用方自己选择。
一般超时才建议重试。

一个重试机制都有如此优雅的设计模式，想问下，重试是同步还是异步进行的，还是需要看业务呢

503 502 都需要重试吧 老师 500 400 403 401 可以不用重试吧

有一个很小白的错误，我记得n年前一个同事写过一个很简单的服务，轮询需要处理的数据，每次取出m条，然后处理。测试时发现，有数据的时候，没任何问题，一旦数据处理完毕，系统CPU负载就飙升。最后看了一下，当没有重试数据的时候，就不断的轮询，不断的轮询，导致CPU飙升。后面对于批量处理数据的代码，都要重点看下有没有必要的延时。。。

另外，对于很特殊的数据，比如会引起服务挂掉的特殊数据（本文中的SERVER_ERROR），必须要特殊处理一下，不要继续重试，否则就滚雪球直接崩盘了。

好文

503是服务过载，短暂不可用，可以重试吧？陈老师