优步是如何用Kafka构建可靠的重试处理保证数据不丢失

在分布式系统中,重试是不可避免的,我们经常使用后台跑定时进行数据同步,同步不成功就实现重试,重试次数多少取决于你追求一致性还是可用性,如果希望两个系统之前无论如何都必须一致,那么你设置重试次数为无限,当然这是理想情况,实际情况是有重试次数限制和重试时间限制,如果超过不成功怎么办?丢弃会造成数据丢失进而永久不一致,人工介入又非常复杂,通过引入死信队列可以优雅处理这种问题。本文是优步Uber工程师夏宁(Ning Xia)发布的一篇如何使用Kafka的死信队列实现重试处理的。

从网络错误到复制问题甚至下游依赖关系等场景中随时可能发生的中断,大规模运行的服务必须尽可能地优雅发现、识别并处理故障。

考虑到优步Uber的运维范围和效率,我们的系统发生故障时必须智能化地具有容错性和不妥协性。为了实现这一目标,我们决定使用开源分布式消息传递平台Apache Kafka,该平台已经过业界测试,并能提供大规模的高性能。

利用这些属性,优步行车保险工程团队通过扩展卡夫卡,在我们现有的事件驱动架构中使用无阻塞请求重新处理和死信队列(DLQ),实现错误处理的解耦,在不中断实时流量情况下实现可观察的错误处理。这一策略有助于我们遍布200多个城市的驾驶员能够可靠地实现每次行程的保费扣除。

在本文中,我们重点介绍了使用实时SLA重新处理大型系统中的请求并分享经验教训的方法。

在事件驱动的体系结构中工作

优步的驾驶员损伤保护系统的后端位于Kafka消息传递架构中,该架构贯穿优步大型微服务生态系统内的多个依赖关系的Java服务。本文我们更专注于我们的重试和死信的策略,并通过一个总的应用程序来管理不同产品的预订,以实现蓬勃发展的在线业务。

在这个模型中,我们希望提供以下功能&#x

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值