besteffortnotification（Best-effortdelivery）是最简单的一种灵活事务，适用于一些最终一致性时间敏感度不高的业务，被动方处理结果不影响主动方的处理结果。典型使用场景：如银行通知、商户通知等Best-effortnotificationBest-effortdelivery是最简单的一种灵活交易，适用于一些对最终一致性时间敏感度不高的业务，处理结果被动方不影响主动方的处理结果。典型使用场景：如银行通知、商户通知等。尽力而为通知实现方案一般满足以下特点：不可靠消息：业务活动的主动方，在完成业务处理后，向被动方发送消息业务活动的一方，直到通知N次后才通知，导致消息丢失（不可靠信息）。周期性校对：业务活动的被动端，根据定时策略，查询业务活动的主动方（主动方提供查询接口），恢复丢失的业务信息。BestEffortNotification示例：笔者曾经在一个短信发送平台工作过。背景是公司有多个业务需要发送短信。如果每个业务独立实现短信发送功能，就会出现功能实现的重复。因此特地做了一个短信平台项目，所有的业务方都连接到这个短信平台上，实现发送短信的功能。简化架构如下：短信发送流程业务方发送短信的流程包括以下步骤：业务方向短信平台提交短信发送请求；短信平台收到待发送的短信，记录在数据库中，并标记状态为“已收到”；短信平台调用外部短信发送服务商的接口发送短信。externalprovider接口也是异步发送短信到用户手机，所以调用该接口后立即返回，进入第4步；短信发送状态更新为“已发送”；短信发送服务商将短信发送结果异步通知短信平台。通知可能会失败，所以最多只会通知N次。;短信平台收到短信发送结果后，更新短信发送状态，可能成功也可能失败（比如手机欠费）。成功与否并不重要，重要的是我们知道短信发送的最终结果；如果最多只有N条通知，如果全部失败，则短信平台不知道短信是否发送成功。因此，短信发送服务商需要提供查询接口，方便短信平台驱动的查询，并进行定期校对。在这种情况下，短信投放商将短信投放结果通知短信平台的过程是最典型的best-effort通知方案，通知N次后不再通知。通过提供短信结果查询接口，短信平台可以进行定期校对。并且由于短信发送业务的时间敏感性不高，更适合采用这种方案。需要注意的是，短信结果查询接口非常重要，一定要定期查看。因为后期需要对账，所以笔者在做这个项目的时候，一个月的短信发送总量在高峰期可以达到1亿条左右。就算一条短信只要5毛钱，一个月也是500W。参考文献灵活事务：尽力而为声明本文首发于微信公众号，版权所有，禁止转载！
