深圳网站设计网站制作,wordpress博客工具,坪山模板网站建设公司,viralnova wordpress文章目录 1 背景2 方案3 效果4 可选项5 注意事项6 总结 1 背景
在分布式场景下#xff0c;为了保障系统的可用性和数据的最终一致性#xff0c;采用基于消息队列#xff08;MQ#xff09;的重试机制是一种常见的解决方案。伪代码如下#xff1a;
/*** 需要保证最终一致性… 文章目录 1 背景2 方案3 效果4 可选项5 注意事项6 总结 1 背景
在分布式场景下为了保障系统的可用性和数据的最终一致性采用基于消息队列MQ的重试机制是一种常见的解决方案。伪代码如下
/*** 需要保证最终一致性的函数*/
public void doSomething(Object args) {try {// 执行事务的操作executeTransaction();// 提交事务commitTransaction();} catch (Exception e) {// 回滚事务rollbackTransaction();// 记录日志log.error(e);// 序列化参数byte[] body serialize(args);// 构建消息, 指定Topic、BodyMessage msg new Message(doSomethingTopic, body);// 发送失败重试消息mq.send(msg);}
}/*** 消费者用于失败重试处理*/
Consumer(topic doSomethingTopic)
public void consume(Message msg) {// 反序列化Object args msg.deserialize();// 重试doSomething(args);
}在上述示例中我们需要编写一系列与业务无关的代码来实现业务逻辑的重试机制。为了减轻开发人员的负担并让其专注于核心业务我们可以对这些无关代码进行抽象和优化以提高开发效率和代码质量。
2 方案
通过如下步骤我们对重试逻辑进行了封装开发人员只需要在需要保证最终一致性的函数上标注一个重试注解便拥有基于MQ的分布式重试能力。
1. 使用注解与AOP 通过使用注解与面向切面编程AOP的技术将重试逻辑模块与业务代码解耦。开发人员可以在需要保证最终一致性的业务方法上添加注解通过AOP将重试逻辑应用到目标方法中从而自动触发重试机制。
2. 提供配置化选项为重试逻辑提供可配置化的选项例如设置最大重试次数、重试间隔时间等。这样开发人员可以根据具体业务需求进行调整而无需修改代码。
3. 异常处理和日志记录在重试逻辑中合理地处理异常并在必要时记录相关日志。这样可以帮助开发人员及时发现问题并进行排查。
4. 提供可视化监控工具开发一个可视化的监控工具用于实时跟踪重试操作和相关指标。这样可以帮助开发人员更好地理解重试的执行情况并进行故障排查和性能优化。 3 效果
我们引入了MQRetry注解用于标记业务逻辑函数一旦该函数发生异常该注解会将服务名、类的完整名称、方法名称以及实际参数列表发送到消息队列MQ中。同时系统会注册一个MQ消费者来消费这些消息并进行重试处理。
举个例子假设我们有一个名为doSomething的函数它包含了需要保证最终一致性执行的业务逻辑。仅需在该函数上添加MQRetry注解当函数出现异常时框架会自动发送一条MQ重试消息。这条消息可以被当前服务的任意一台服务器消费并重新执行doSomething函数。
Service
class Service {MQRetrypublic void doSomething(String params1, String params2, ListString params3) {//throw new RuntimeException(); 抛异常将重试//RetryContext.markRetryLater(); 标记为需要下次重试//int retryCount RetryContext.getRetryCount(); 获取重试次数}}Controller
class Controller {Autowiredprivate Service service;service.doSomething(1, 2, Arrays.asList(3, 4));
}4 可选项
除此之外我们还为开发人员提供了一些可选项提供一些可配置的能力。
/*** 基于MQ的分布式重试组件*/
Target(ElementType.METHOD)
Retention(RetentionPolicy.RUNTIME)
Documented
public interface MQRetry {/*** 最大重试次数默认与上限为16次*/int maxAttempts() default 16;/*** 忽略的异常类列表默认所有异常都重试*/Class? extends Throwable[] exclude() default {};/*** 需要重试的异常类列表默认所有异常都重试*/Class? extends Throwable[] include() default {};/*** 出现异常时的处理函数, 格式: Bean名.方法名. 如: smsService.onError* 也可以只设置函数名, 不设置Bean名将执行本类的函数. 如: onError* 要求函数参数必须与重试函数的参数完全一致*/String errorHandler() default ;/*** true: 第一次调用时, 同步执行MQRetry函数, 如果失败再使用MQ* false: 调用MQRetry函数时, 只会发送MQ*/boolean firstSyncCall() default true;/*** 消费线程数默认为20个*/int consumeThread() default 20;}5 注意事项 适用于异步场景重试函数不要设置返回值函数的返回值将不会有任何的实际意义。 At lease Once保证重试函数需要 保证幂等。 使用了AOP代理实现因此Transactional的注意事项同样适用于MQRetry如 this调用、private函数、final函数会导致重试失效。 如果重试函数需要增加参数请在函数参数最后位置添加。历史消息消费时对应参数将填充为null。
6 总结
在计算机领域中重试机制的重要性不言而喻。它通常分为两种模式客户端模式和服务端模式。客户端模式简单易用但可靠性较低而服务端模式虽然相对复杂但能够提供更高的可靠性。
无论是客户端模式还是服务端模式重试机制都是保障系统正常运行的重要一环。选择适合您业务需求的模式并通过合理的配置项进行优化将为您的系统带来更好的表现和用户体验。 关于作者 苑冲转转架构部存储服务负责人负责MQ、监控系统、KV存储、时序数据库、Redis、KMS秘钥管理等基础组件。喜欢深入思考问题对探索新领域和解决问题充满热情。 转转研发中心及业界小伙伴们的技术学习交流平台定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」综合性、「大转转FE」专注于FE、「转转QA」专注于QA更多干货实践欢迎交流分享~
