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);
}


相关文章
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
707 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
335 11
|
8月前
|
消息中间件 监控 Java
Apache Kafka 分布式流处理平台技术详解与实践指南
本文档全面介绍 Apache Kafka 分布式流处理平台的核心概念、架构设计和实践应用。作为高吞吐量、低延迟的分布式消息系统,Kafka 已成为现代数据管道和流处理应用的事实标准。本文将深入探讨其生产者-消费者模型、主题分区机制、副本复制、流处理API等核心机制,帮助开发者构建可靠、可扩展的实时数据流处理系统。
780 4
|
Java 关系型数据库 MySQL
新一代 Cron-Job分布式任务调度平台 部署指南
简单易用、超低延迟,支持用户权限管理、多语言客户端和多租户接入的分布式任务调度平台。 支持任何Cron表达式的任务调度,支持常用的分片和随机策略;支持失败丢弃、失败重试的失败策略;支持动态任务参数。
487 111
|
Java 调度 Maven
新一代 Cron-Job 分布式任务调度平台 正式发布!
简单易用、超低延迟,支持用户权限管理、多语言客户端和多租户接入的分布式任务调度平台。 支持任何Cron表达式的任务调度,支持常用的分片和随机策略;支持失败丢弃、失败重试的失败策略;支持动态任务参数。
558 116
|
存储 监控 固态存储
【vSAN分布式存储服务器数据恢复】VMware vSphere vSAN 分布式存储虚拟化平台VMDK文件1KB问题数据恢复案例
在一例vSAN分布式存储故障中,因替换故障闪存盘后磁盘组失效,一台采用RAID0策略且未使用置备的虚拟机VMDK文件受损,仅余1KB大小。经分析发现,该VMDK文件与内部虚拟对象关联失效导致。恢复方案包括定位虚拟对象及组件的具体物理位置,解析分配空间,并手动重组RAID0结构以恢复数据。此案例强调了深入理解vSAN分布式存储机制的重要性,以及定制化数据恢复方案的有效性。
478 5
|
机器学习/深度学习 人工智能 Shell
人工智能平台PAI操作报错合集之在分布式训练过程中遇到报错,是什么原因
阿里云人工智能平台PAI是一个功能强大、易于使用的AI开发平台,旨在降低AI开发门槛,加速创新,助力企业和开发者高效构建、部署和管理人工智能应用。其中包含了一系列相互协同的产品与服务,共同构成一个完整的人工智能开发与应用生态系统。以下是对PAI产品使用合集的概述,涵盖数据处理、模型开发、训练加速、模型部署及管理等多个环节。
|
SQL 监控 Go
新一代 Cron-Job分布式调度平台,v1.0.8版本发布,支持Go执行器SDK!
现代化的Cron-Job分布式任务调度平台,支持Go语言执行器SDK,多项核心优势优于其他调度平台。
295 8
|
11月前
|
运维 监控 Linux
WGCLOUD运维平台的分布式计划任务功能介绍
WGCLOUD是一款免费开源的运维监控平台,支持主机与服务器性能监控,具备实时告警和自愈功能。本文重点介绍其计划任务功能模块,可统一管理Linux和Windows主机的定时任务。相比手动配置crontab或Windows任务计划,WGCLOUD提供直观界面,通过添加cron表达式、执行指令或脚本并选择主机,即可轻松完成任务设置,大幅提升多主机任务管理效率。
|
数据采集 监控 数据可视化
11.7K Star!这个分布式爬虫管理平台让多语言协作如此简单!
分布式爬虫管理平台Crawlab,支持任何编程语言和框架的爬虫管理,提供可视化界面、任务调度、日志监控等企业级功能,让爬虫开发管理效率提升300%!
627 1