服务间超时处理

2024-01-02 23:14:30
在一个很普遍的场景中，涉及到双端通信的情况下，不论是传统的单机服务，还是现在的微服务，甚至 事异步通信技术（进程内，进程与进程），一直都存在着三态的问题，即:成功，失败，超时。
如下图两个服务间：
成功失败具有明确的业务语义和边界，正常处理即可。最复杂的就是超时，因为网络通信原因，双端都不总是确定，到底哪个环节超时。
1-同步调用超时
超时点：
1-请求超时
2-服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接
3-服务端处理正常，但响应结果阶段超时
处理：
客户端 ：无论那个阶段，客户端都不确定请求是否被应答，即服务端处理的结果，客户端不知道是否成功。客户端此时能做的，有两种方法：
1-重试:客户端需要主动做好重试方案，比如类似mq的重试队列（1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h），主要的技术，spring-retry框组件，将请求扔到mq，依靠mq的重试队列主动重试，或者建立定时任务表重试。不管哪种方式，需要服务端接口具备幂等性
2-主动查询结果：超时后客户端主动查询，查询的时机类似重试机制。
服务端
服务端不存在请求超时和响应超时，但存在自身超时的情况，解决方案：
1-自身需要优化，比如慢sql等
2-引用三方接口的时候，跟第三方接口又形成了一个客户端-服务端模式，根据具体场景或者快速失败，或者做好容错措施，必要的时候，还会有比如金融领域的冲正操作。
2-异步调用超时
异步调用，类似ajax，客户端同步请求，服务端异步响应超时点：
1-请求超时
2-服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开
连接 3-服务端处理正常，但响应结果阶段超时
4-异步响应超时
处理：
客户端
参考同步-客户端
服务端
服务端不存在请求超时和同步响应超时，对于内部处理超时，同同步情况一样。那么就只剩下异步响应超时了。
比较有代表性的就是支付结果通知，可参考： 支付结果通知文档
存在此问题就是服务端通知客户端的时候（客户端需要同步提供响应服务端结果通知的接口），未接受到客户端的响应。
3-MQ超时
如何保证mq不丢消息，无论是kafka和RocketMQ，都支持ack的机制，用以确认消息的发送和接受的成功。此处不做过多分析，后续MQ模块补充。

文章来源:https://blog.csdn.net/f746262041/article/details/135349443
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。