惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cloudbric
Cloudbric
T
Threat Research - Cisco Blogs
Simon Willison's Weblog
Simon Willison's Weblog
AWS News Blog
AWS News Blog
P
Privacy & Cybersecurity Law Blog
H
Help Net Security
云风的 BLOG
云风的 BLOG
G
GRAHAM CLULEY
Spread Privacy
Spread Privacy
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
A
Arctic Wolf
Project Zero
Project Zero
Engineering at Meta
Engineering at Meta
P
Privacy International News Feed
Blog — PlanetScale
Blog — PlanetScale
Stack Overflow Blog
Stack Overflow Blog
M
MIT News - Artificial intelligence
The Register - Security
The Register - Security
Recorded Future
Recorded Future
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
C
Cisco Blogs
PCI Perspectives
PCI Perspectives
Recent Announcements
Recent Announcements
Martin Fowler
Martin Fowler
A
About on SuperTechFans
W
WeLiveSecurity
GbyAI
GbyAI
V
Vulnerabilities – Threatpost
The GitHub Blog
The GitHub Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
C
Check Point Blog
Y
Y Combinator Blog
月光博客
月光博客
Scott Helme
Scott Helme
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News
F
Fortinet All Blogs
U
Unit 42
G
Google Developers Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Threatpost
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google Online Security Blog
Google Online Security Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Cisco Talos Blog
Cisco Talos Blog
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
MongoDB | Blog
MongoDB | Blog
博客园 - 司徒正美

文章 - 硬盘在歌唱 on 硬盘在歌唱

Open Prompt:AI 时代的 PR 协作新范式 记一例浮点数精度问题 AI 辅助编程时代,哪些编程语言会更流行? 从认知心理学看代码可读性 父子对谈30则 都2024了,你还没随身带录音笔吗? 写段子的窍门 给TiDB(MySQL)写一个代理网关 论怎么与基层干部打成一片 怎么做一个匿名论坛 适合程序员的桌面窗口管理方案 Go语言泛型初体验 TrueTime和原子钟 价值6万元的TiDB Hackathon创意 价值10万元的TiDB Hackathon创意 TiDB1024谜题解题报告 Paxos从入门到学会Raft 一个小故事,关于科幻,关于老师 beancount 复式记账实践
双中心主从模式
2021-09-11 · via 文章 - 硬盘在歌唱 on 硬盘在歌唱

在之前的Paxos从入门到学会Raft一文中,为了引入paxos/raft共识算法,简单地讨论了一下主从模式以及为什么主从模式不能最大限度地同时保证高可用和一致性。不过在现实场景中,常常因为基础设施不足,网络成本控制等原因,无法使用需要三中心的paxos/raft,所以我想再详细讨论下只有两中心的场景下的妥协方案。

简单回顾下上次的讨论:在两中心主从模式下,我们如果想要主从切换时不丢数据,就必须使用同步模式,即主中心写入的数据,需要同步到从中心落盘,再给客户端返回写入成功。

同步模式的困境在于,从任何一个中心的视角来看,都无法区分出“另一个中心故障”和“两中心网络断连”这两种异常情况。这导致主从模式下的failover是一定无法由程序自动进行的:

如果主中心在发现从中心故障(或断连)时自动切换至独立运行(异步)模式,那么当主中心发生故障时,从中心无法切换至独立运行模式,因为从中心无从判断主中心是真故障了,还是网络断连了(这种情况下主中心可能已切换至独立运行模式)。

反过来如果我们让从中心在发现主中心故障(或断连)时自动切换至独立运行模式,同样的道理,我们也无法处理从中心故障的情况。

这里我们面对的是一个经典的CA抉择问题,大方向上有两个选择。

第一个方向是优先保证一致性,一旦出现故障或者网络断连了就主动停止服务,由运维来选择一个中心来恢复服务。我们都知道,一旦需要人工介入,高可用性这块基本上就免谈了。还有一个可能产生麻烦的点在于在发生故障的前提下(且可能是网络故障),或许会给运维人员接入生产环境带来一定的困难,这也会进一步增加故障恢复时间。

另一个方向就是优先保证高可用。典型的做法是主中心在发现从中心故障(或断连)时,自动切换成异步模式提供服务。如前所述,一旦主中心故障,就需要人工干预来进行主备切换了。要特别注意这种情况下主备切换不仅比较tricky还有丢数据(不一致)的可能,以下两段划重点:

  1. 主备切换之前,需要先把主中心的服务给“掐掉”,因为主中心是有自动切换异步模式单独服务的机制的,如果在主备切换之后假性故障的主中心死灰复燃,两个中心同时提供服务,会产生非常严重的后果!那么怎么把主中心的服务掐掉呢?如果此时能接入主中心,可以直接停掉所有进程或者通过配置开关禁用自动切异步模式的功能;还可以通过网关、防火墙等配置断开应用和主中心数据服务的连接;另一个选项是在应用层做主备切换,保证所有应用都只连接从中心的服务。如果这些都做不到,此时做主备切换就要承担很大的风险了,建议上报给老板做决策。

  2. 主从数据可能不同步。理论上讲在同步模式下主中心发生故障,从中心一定有全量数据。但是实际上如果此时不能接入主中心检查状态,我们单看从中心无法排除这种可能性:主中心在完全故障之前,先跟从中心发生网络断连,随后自动切换异步模式并写入了一些数据。因此,做主备切换之前,除非能接入主中心并确认其没有切换过异步模式,还要承担丢数据的风险,这里同样建议您先上报老板。


工程实践中,C和A并不是非此即彼的选择题,常常有权衡的空间。在双中心主备切换的场景中,我们可以牺牲一些可用性来换一些一致性。

做法也很简单,就是给主中心切换异步模式设置一个比较大的超时时间,比如30分钟。这样当从中心故障时,主中心需要等待30分钟才能独立提供服务,牺牲了可用性。换来的一致性保证是,当主中心故障(或断连)时,如果我们在30分钟之内做主备切换,就能确定一定不丢数据。

具体的超时时间可以根据需要进行调整,很大的值其实就是一致性模式,很小的值对应的是高可用模式。看到这里熟悉Oracle的朋友们应该都会心一笑了,这其实就是DataGuard的maximize protection模式和maximize availability模式嘛。


接下来简单聊一下架构层面改进的两种思路。

第一个思路是向三中心架构推进一步。开头也说了使用paxos/raft三中心的主要问题是成本太高了,然而实际上不需要完整的三中心三副本也能达到比较好的效果。主备模式的主要缺陷在于两个数据中心的地位是完全对等的,出现网络隔离的时候无法判断对面是不是真挂了。

我们可以在第三个数据中心部署一个简单的etcd服务来扮演“仲裁者”的角色,在主从中心正常工作的时候,不需要与etcd作任何消息交换,发生故障时,哪边能连上etcd,哪边就有权切换成独立服务模式。假如主从网络断连,同时它们又同时能连接到etcd,那么主中心切换成异步模式并把状态信息通过etcd传递到从中心。

由于跟第三个数据中心之间只需要传递简单的状态信息,可以考虑使用移动网络、无线电或者卫星通信(如北斗短报文)来进一步减少成本。

另一个思路成本更低一些,不使用第三个数据中心,直接在主从中心之间建立低成本旁路通信同步状态。这时因为没有“仲裁者”了,在出现整个数据中心故障时仍然会陷入“两难”的境地,不过在发生网络故障时,主从中心可以通过旁路进行状态交换然后迅速进行异步模式切换。


最后来点主题升华哈。权衡是软件工程架构设计的最经典命题之一,绝大部分情况下都没有完美的设计,只有特定约束条件下最平衡的设计。诚然,一个又一个“不可能三角”告诉我们完美的系统是不存在的,但换个角度来看,不可逾越的鸿沟也是可以去不断逼近的极限,这就是工程师的浪漫呀!