分布式系统:RPC

本文深入探讨了RPC(远程过程调用)的可靠性问题,包括可能出现的故障、不同的RPC语义,如“best effort”、“最多一次”和“恰好一次”,以及如何处理重复请求、服务器崩溃和重启等挑战。Go RPC选择了不重发的策略,而实现恰好一次的RPC则较为复杂,需要结合无限重试、去重检测和服务端的故障容忍机制。
摘要由CSDN通过智能技术生成

如何做到可靠的RPC

  • RPC可能会遇到什么故障?

    • 包丢失、断网、服务器太慢、服务器崩溃(crash)
  • 客户端没有收到回复,就可以认为是出错了

    • 但是它无法区分到底服务器执行了命令没有。
    • 可能服务器没有见到请求
    • 可能服务器没有执行请求就崩溃了
    • 可能服务器执行完请求,还没有来得及发回复就崩溃了。
  • 没有收到回复的时候,RPC可以选择实现这几种语义:

    • 不重发(Go RPC)
    • 尽最大努力"best effort":简单地重试几次。服务器端会收到重复请求。
    • 最多一次(at most once):服务器端记录并分辨重复请求。
    • 恰好一次(exactly once):比较复杂!

“best effort”

  • 最简单的处理办法是: “best effort”(尽最大努力)

    • Call() 等待答复,等一段时间
    • 如果超时了,就重新发送
    • 如此反复几次
    • 还是没用,就放弃并返回error
    • 附注:ZeroMQ的手册里面,给这个再普通不过的方法起了个很神秘的名字:Lazy Pirate Client
  • “尽最大努力”有些时候是不对的。服务器有会收到重复的请求。

    • 比如:客户端执行
      Put("k&
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值