OpenSource - 分布式重试平台

简介: OpenSource - 分布式重试平台

概述


在当前广泛流行的分布式系统中,确保系统数据的一致性和正确性是一项重大挑战。为了解决分布式事务问题,涌现了许多理论和业务实践,其中BASE理论是目前业界广泛接受的分布式一致性理论。


基于BASE理论,采用柔性事务并优先保障系统的可用性和数据的最终一致性已逐渐成为技术共识。 为了确保分布式服务的可用性和数据一致性,并防止由于网络抖动、连接超时等问题导致短时不可用的情况,根据"墨菲定律",在核心流程中增加重试和数据核对校验的动作成为提高系统鲁棒性常用的技术方案。


在此背景下EasyRetry应运而生。EasyRetry是一款基于BASE思想实现的分布式服务重试组件,旨在通过重试机制确保数据的最终一致性。它提供了控制台任务观测、可配置的重试策略、重试后执行回调以及丰富地告警配置等功能。


通过这些手段,可以对异常数据进行全面监测和回放,从而在确保系统高可用性的同时,大大提升数据的一致性。


fb9bebd821224a7c8fcca86d72aacef1.png


通常的业务场景有:


   保障系统稳定性,减少网络抖动导致异常,增加重试能力

   保障服务容错性,对核心流程进行拆分,在业务低峰期进行数据核对

   保证信息的可达性,在服务间通知时增加重试

但由于正常业务场景较难触发重试流程,从而导致研发测试对重试场景和流量并不重视,始终处于重要但无序的"管理真空"


Easy-RETRY 是一个针对业务系统重试流量的治理平台,其自身具有高可用高性能高负载的特点,服务特性有:


   支持千万级别的重试流量分派

   支持流量容量扩容,自动识别并处理

   支持流量处理节点水平扩容

   高效利用系统资源支持高并发

   支持多种算法调度客户端执行

   打包上报,支持高并发业务场景

   加密通讯,保障信息安全


dc0240041cf84e5981149b9085c9a162.png




重试方案对比

设计思想



流量管理平台预览

地址: http://preview.easyretry.com/ 账号: admin 密码: admin


61766d9cdde748fda2c6adddd838419e.png


39a3940675f049549b380d83682e9b60.png


999888d59a11436d980fd5485d499871.png

94b3f9725cc64d4fbb468211a6d71d01.png

a43d4ec63d5f48be92a95a4d57012e84.png



场景应用


   为了小伙伴们能更快了解EasyRetry的使用场景和优势,以下新增了一些模拟案例仅供大家参考。 同时期待大家积极参与并分享自己在项目中使用EasyRetry的经验和案例,共同推动技术的发展和应用的实践。


   这样可以让更多需要使用EasyRetry的小伙伴们找到适合自己的应用场景, 并充分利用EasyRetry的优势,以提升系统的可靠性和稳定性。




强通知场景

强通知性


在某些业务场景下,需要强制保证将通知、消息等数据发送到目标端接口,但由于网络的不确定性以及目标系统、应用、服务的不确定性,可能会造成通知消息的发送失败。


此类场景下可以使用LOCAL_REMOTE或者ONLY_REMOTE模式进行重试。



发送MQ场景


众所周知消息队列的异步、削峰、解耦优点, 在业务系统承担着十分重要的角色,如果保障消息的可达性就尤为重要了。


下面模拟一个常见的的下单流程。

ac58d3450f1841da8827d0e50ef1eb8b.png



订单中心下单完成后回抛出下单成功消息从而解耦了订单和其他业务系统的耦合关系,其他相关的业务系统只需要监听订单的下单成功的消息即可完成自己的业务逻辑。

但是若由于网络的不稳定、消息队列故障等等,可能导致消息未发送出去,这时候就需要增加重试流程来保障消息的强可达性


然后接入EasyRetry后将变的非常简单,您只需要简单的一个注解就保障强可达性

以下代码案例仅供参考

@Retryable(scene = "create-order-success", retryStrategy = RetryType.ONLY_REMOTE)
public void sendCreateOrderSuccessMessage(Message message) {
    ......
    // 发送消息
    mqProducer.publish("主题", "key", message);
}


如果您不想使用注解的方式您可是使用手动模式

public void createOrder(Order order) {
    // 其他逻辑
    // 发送消息
    try {
        mqProducer.publish("主题", "key", order);
    } catch (Exception e) {
        // 发送出现异常
        EasyRetryTemplate retryTemplate = RetryTaskTemplateBuilder.newBuilder()
          .withExecutorMethod(RetrySendMqMessageExecutorMethod.class)
          .withParam(order)
          .withScene(RetrySendMqMessageExecutorMethod.SCENE)
          .build();
        retryTemplate.executeRetry();
    }
}


@ExecutorMethodRegister(scene = RetrySendMqMessageExecutorMethod.SCENE, async = true, forceReport = true)
public class RetrySendMqMessageExecutorMethod implements ExecutorMethod {
    public static final String SCENE = "retrySendMqMessageExecutorMethod";
    @Override
    public Object doExecute(Object objs) {
        Object[] params = (Object[]) objs;
        // 发送消息
        mqProducer.publish("主题", "key", params[0]);
        return null;
    }
}    


回调场景

这里引用一个使用EasyRetry的小伙伴重试框架-Easy-Retry接入之路,他们线上真实的使用场景。


他们一个paas平台, 其中功能模块有“事件中心”,“审核中心”,“支付中心”等相关的一些组件。他们都有一个类似的东西,当我发起事件的时候,需要将事件通知到其他的应用, 比如


   【审核中心】当我审核的时候需要将审核结果返回给其他应用,

   【支付中心】当我支付完成后也会将结果推送给其他应用。

然而,我们的其他应用可能会有不可用的状态, 可能会导致回调通知的时候会报错, 所以不难想象到我们需要做一个重试机制来保障回调的可达性。

下面是一个支付中心的调用过程


b479f681638d438989f498fec8f90caf.png


用户在商品中心下单然后通过支付中心唤起收银台进行付款,第三方支付平台回调支付中心,支付平台回调商品中心完成业务流程;


但是若回调失败了就会导致商品中心和 支付中心数据不一致,这肯定不是我们所期望的。

所以需要新增一个重试机制来保障数据的最终一致性。

   以下代码案例仅供参考


@Retryable(scene = "callbackProductCenter", retryStrategy = RetryType.ONLY_REMOTE)
public void callbackProductCenter(CallbackDTO callback) {
    ......
    // 回调商品中心
    String responseStr = restTemplate.postForObject("第三方接口", "参数", String.class);
}


如果您不想使用注解的方式您可是使用手动模式

public void callbackProductCenter(CallbackDTO callback) {
    // 其他逻辑
    try {
        // 回调商品中心
        String responseStr = restTemplate.postForObject("第三方接口", "参数", String.class);
    } catch (Exception e) {
        // 发送出现异常
        EasyRetryTemplate retryTemplate = RetryTaskTemplateBuilder.newBuilder()
          .withExecutorMethod(RetrySendMqMessageExecutorMethod.class)
          .withParam(order)
          .withScene(RetrySendMqMessageExecutorMethod.SCENE)
          .build();
        retryTemplate.executeRetry();
    }
}
@ExecutorMethodRegister(scene = CallbackProductCenterExecutorMethod.SCENE, async = true, forceReport = true)
public class CallbackProductCenterExecutorMethod implements ExecutorMethod {
    public static final String SCENE = "callbackProductCenterExecutorMethod";
    @Override
    public Object doExecute(Object objs) {
        Object[] params = (Object[]) objs;
        // 回调商品中心
        String responseStr = restTemplate.postForObject("第三方接口", "参数", String.class);
        return null;
    }
}    


异步场景


在一些核心的接口上,我们总是想不断的提高接口的性能,我们知道提高接口性能的方式常用的就是异步、缓存、并行等,


这里我们说说异步,比如下面一个场景

5d6dca4bc6994a68859e56ef5b477c3a.png



@Retryable(scene = "sendEmail", retryStrategy = RetryType.LOCAL_REMOTE)
public void sendEmail(EmailDTO email) {
    ......
    // 发送下单确认邮件
    String responseStr = restTemplate.postForObject("邮箱地址", email, String.class);
}


相关文章
|
5月前
|
Java 调度 Maven
【分布式任务调度平台 XXL-JOB 急速入门】从零开始将 XXL-JOB 接入到自己的项目(下)
【分布式任务调度平台 XXL-JOB 急速入门】从零开始将 XXL-JOB 接入到自己的项目(下)
253 0
|
11月前
|
监控 Java 调度
分布式系列教程(17) - 分布式任务调度平台XXL-JOB
分布式系列教程(17) - 分布式任务调度平台XXL-JOB
261 0
|
2月前
|
存储 监控 固态存储
【vSAN分布式存储服务器数据恢复】VMware vSphere vSAN 分布式存储虚拟化平台VMDK文件1KB问题数据恢复案例
在一例vSAN分布式存储故障中,因替换故障闪存盘后磁盘组失效,一台采用RAID0策略且未使用置备的虚拟机VMDK文件受损,仅余1KB大小。经分析发现,该VMDK文件与内部虚拟对象关联失效导致。恢复方案包括定位虚拟对象及组件的具体物理位置,解析分配空间,并手动重组RAID0结构以恢复数据。此案例强调了深入理解vSAN分布式存储机制的重要性,以及定制化数据恢复方案的有效性。
69 5
|
3月前
|
机器学习/深度学习 人工智能 Shell
人工智能平台PAI操作报错合集之在分布式训练过程中遇到报错,是什么原因
阿里云人工智能平台PAI是一个功能强大、易于使用的AI开发平台,旨在降低AI开发门槛,加速创新,助力企业和开发者高效构建、部署和管理人工智能应用。其中包含了一系列相互协同的产品与服务,共同构成一个完整的人工智能开发与应用生态系统。以下是对PAI产品使用合集的概述,涵盖数据处理、模型开发、训练加速、模型部署及管理等多个环节。
|
2月前
|
数据库 C++ Ruby
为什么你应该选择分布式平台与微服务?
为什么你应该选择分布式平台与微服务?
|
2月前
|
消息中间件 Java Kafka
"Kafka快速上手:从环境搭建到Java Producer与Consumer实战,轻松掌握分布式流处理平台"
【8月更文挑战第10天】Apache Kafka作为分布式流处理平台的领头羊,凭借其高吞吐量、可扩展性和容错性,在大数据处理、实时日志收集及消息队列领域表现卓越。初学者需掌握Kafka基本概念与操作。Kafka的核心组件包括Producer(生产者)、Broker(服务器)和Consumer(消费者)。Producer发送消息到Topic,Broker负责存储与转发,Consumer则读取这些消息。首先确保已安装Java和Kafka,并启动服务。接着可通过命令行创建Topic,并使用提供的Java API实现Producer发送消息和Consumer读取消息的功能。
60 8
|
3月前
|
存储 缓存 分布式计算
高并发架构设计三大利器:缓存、限流和降级问题之缓存的应对策略问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之缓存的应对策略问题如何解决
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
人工智能平台PAI产品使用合集之如何配置cluster系统自动生成分布式参数
阿里云人工智能平台PAI是一个功能强大、易于使用的AI开发平台,旨在降低AI开发门槛,加速创新,助力企业和开发者高效构建、部署和管理人工智能应用。其中包含了一系列相互协同的产品与服务,共同构成一个完整的人工智能开发与应用生态系统。以下是对PAI产品使用合集的概述,涵盖数据处理、模型开发、训练加速、模型部署及管理等多个环节。
|
3月前
|
机器学习/深度学习 存储 分布式计算
PAI机器学习平台如何进行分布式训练?
【7月更文挑战第1天】PAI机器学习平台如何进行分布式训练?
93 1