分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

分布式数据库系统的容错处理 – 100% 成功率, 超时和性能

作者:佚名 2021-06-30 14:55:39

运维

数据库运维

分布式 本文分享实际经验, 介绍什么样的选择是普适的, 各位可以参考。

[[408364]]

之前写过一篇文章, 介绍”可靠通信三原则”. 对于一个分布式数据库, 如果想实现 100% 高可用(也即客户端的请求永远不会返回失败), 同样可以用可靠通信三原则中的重试理论和去重理论来解决. 但在实践上, 需要在成功率, 耗时(速度和性能)各方面进行取舍. 本文分享实际经验, 介绍什么样的选择是普适的, 各位可以参考.

客户端访问数据库服务器, 发起大量的请求, 绝对不可能做到每一个请求都是成功的. 因为网络原因, 请求可能失败. 因为服务器内部处理冲突, 或者分布式节点间协调冲突, 都可能导致请求失败.

所谓容错处理, 就是在遇到错误的时候进行重试. 因为错误必然发生, 只有重试才能消除错误的影响, 就好像 IP 层必然会丢包, 但 TCP 协议通过重传达到某种程度的可靠传输.

某些实现了 Basic Paxos + 日志复制状态机模型的系统, 因为所谓的”Leaderless”, 会产生大量冲突. 即使是使用 Raft, 在某些情况下意外发生选举, 也会导致请求冲突.

面对冲突(失败)到底应该由谁来重试呢? 这涉及到工程实践上模块职责划分的问题, 模块职责的划分, 往往比代码实现更重要. 一般来说, 发生重试的位置越底层, 性能会越好; 发生重试的位置越上层, 判断是否应该重试的依据就能更全面.

我们简单把数据库系统(生态)划分为几个大的模块, 从底层(左)到上层(右)是:

  1. replication -> server -> client SDK -> user 

最常见的做法是让 user 自己重试, 例如常见的 Redis SDK, 如果某台 server 宕机导致请求失败, 那么要求用户换一个 IP, 重新创建连接, 再次重复请求.

某些系统会封装专属的 client SDK, 例如, 把官方的 Redis SDK 做一下简单封装, 拦截每一个请求的结果, 如果发现错误, SDK 内部就自动重试. 这样做, user 就不需要有重试逻辑, 代码可以简化. 是这样的, 多个协作的模块, 如果某个模块揽了一些职责, 那它的上层模块就能省些工夫.

如果 user 既不想重试, client SDK 也不想重试, 那怎么办呢? 能不能把职责全推给 server 呢? 绝对不可能, 参见这篇文章的总结. 那么, 为什么 SDK 重试之后, user 就不需要重试呢? 因为 SDK 和 user 是在同一个运行空间内, 它们是一个整体, 两者之间没有可靠传输问题.

那么, 既然 client SDK 必须有重试逻辑, server 是否就不需要有重试逻辑了呢? 理论上可以, 但实践上, server 自身依然要降低自己的故障率, 降低故障率的必要手段就是 重试 . 例如, server 请求 paxos 模块同步一条操作日志, 但因为非预期的 multi-master 出现, 导致和其它节点争抢同一个位置失败, 这时, server 如果直接报错给 client, 那么, server 的故障数量就加一. 但是, server 可以重试, 再次调用 paxos 模块, 去争抢下一个位置, 直到成功. 这样, client 就会很少见到 server 报错.

但是, 无论是 server 还是 client 都不可能无限次重试, 因为每一次重试都会消耗时间, 最极端的情况可能要重试几个小时直到永远, 这当然不行, 所以, 需要引入 超时机制 , 重试一定次数之后即使还是失败, 也必须报错给上层.

重试会增加总的耗时, 这样, 给上层带来的不好效果就是, 上层觉得下层速度慢, 性能差. 所以, 必须有系统思维, 做出判断, 做综合的取舍. 从经验上看, 无论 server 还是 client SDK, 都必须分析细化, 尽可能重试, 以提高成功率. 大部分情况下, 开发者往往过多地放弃重试, 而较少地进行重试, 毕竟, 多一种重试场景, 就多写一段代码, 人总是会想偷懒的.

要设计一个高可靠的系统, 可靠传输三原则是非常有用的基础理论, 但不是银弹. 本质上, 软件开发就是大量的分析细化体力活, 以及对系统复杂度的把控.

重试带来的额外问题就是去重, 这也是可靠传输三原则里的第二项原则. 你可能听过”幂等性”这个词汇, 和去重是一回事. 如果一个操作是非幂等的, 那么, 就不能重试.

但是, 实践上, 我们可以把幂等性的职责向上推, 尽可能推给上层. 毕竟, 至少对于 user 来说, 100% 的成功率, 优先级比对幂等性的疑虑要高得多. 用户同意下层不考虑幂等性, 而大胆地去重试, 但是, 对下层偶然的失败会非常敏感. 简单说就是: 别管什么幂等性, 在超时时间限制以内, 大胆重试!

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/287961.html<

(0)
管理的头像管理
上一篇2025-05-16 02:48
下一篇 2025-05-16 02:49

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注