在一个微服务系统里，服务调用（同步或异步）失败处理是一个非常重要的一个环节，而失败重试又是一个常用的处理模式；本文从消息中间件的角度来分析下 AWS 上常见的消息服务的重试和失败处理策略。
在一个微服务系统里，服务调用（同步或异步）失败处理是一个非常重要的一个环节，而这些失败场景里，通信异常处理又是比较常见的问题；如我在微服务架构开发和平台演进篇 中所总结的通信异常处理常见手段：
微服务之间利用消息系统进行解耦和异步通信是一个常见的事件驱动模式，所以本篇我们来总结下，AWS 消息服务提供了哪些自动重试的机制和失败处理策略；本文涉及的服务包括 Amazon SNS, Amazon SQS 及 Amazon EventBridge。
Amazon SQSAmazon Simple Queue Service (SQS) 是一种完全托管的轻量级消息队列服务，可让您分离和扩展微服务、分布式系统和无服务器应用程序。在 SQS 中有个特殊的消息队列死信队列（Dead Letter Queue）来保存正常消息队列中未被成功处理的消息。通常可以设定标准队列里面的消息被读取 N 次但没有被删除就认为未处理成功，这样的消息会自动被转存到死信队列。
Amazon SNS - SQS 为订阅者模式
假定由于网络等原因后端 SQS 队列不可用，SNS 支持自动重试，比如说下图的第一个SQS Queue （Q1）突然不可用，那对于 SNS 服务而言，会尝试如下重试策略：（1）立刻重试10次（2）每隔20秒重试一次，总计不超过10,000次 （可最多持续23天）
Amazon SNS - Lambda 函数 为订阅者模式
对于 Lambda 函数，如果订阅消息的 Lambda 函数不可用， 重试策略是（1）每隔1秒钟，重试一次，总共2次（2）接着随机在1分钟~20分钟选一个时间间隔重试不超过20次（3）每隔20分钟再重试38次；总共50次尝试，持续最长12个小时的重试尝试。
Amazon SNS - HTTP/S 为订阅者模式对于 HTTP/S 订阅，首先SNS 如何定义一个失败的消息传递：（1）HTTP status codes 100 to 101 and 500 to 599 (inclusive).（2）A request timeout (15 seconds).（3）Any connection error such as connection timeout, endpoint unreachable, bad SSL certificate, etc.
对于这样的订阅，Amazon SNS 支持自定义的重试策略（delivery policies）最多100次重试，消息在系统保留时间最多1个小时。重试策略会横跨4个阶段（1）即刻重试（无延迟阶段）（2）前退避阶段，使用最短延迟重试指定重试次数（3）退避阶段，设置最短延迟和最长延迟时间，利用重试退避功能指定从最短延迟到最长延迟之间增长有多快（4）后退避阶段，使用最长延迟时间重试操作。默认重试3次，每个20秒一次。
重试退避功能用于计算延迟的算法，在退避阶段，从第一次到最后一次重试的延迟时间计算方法（1）线性的（2）算术的（3）几何的（4）指数的：
Amazon EventBridge 是一种无服务器事件总线，支持您使用自己的应用程序、软件即服务 (SaaS) 应用程序和 AWS 服务的数据轻松将应用程序连接到一起。EventBridge 提供来自事件源（例如 Zendesk、Datadog 或 Pagerduty）的实时数据流，并将该数据路由到 AWS Lambda 之类的目标。您可以设置路由规则来确定发送数据的目的地，以便构建能够实时响应所有数据源的应用程序架构。EventBridge 让事件驱动型应用程序的构建变得简单，因为它可以为您完成事件摄取和传送、安全保障、授权以及错误处理工作。
该服务的重试策略如下：
支持失败自动重试，最长事件消息保留24小时左右默认重试策略，利用指数退避算法，最多重试次数在185次左右
小结
本文首发于 GitChat，未经授权不得转载，转载需与 GitChat 联系。
阅读全文: http://gitbook.cn/gitchat/activity/5d5bfacc1d99df205cf5c0cb
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。
