redis cluster, mysql mgr 都号称是高可用方案, 一旦节点故障,它们的故障检测、故障转移也是要时间的,至少也是秒级. 这期间他们应该是不可用的吧? 为什么这些方案也叫高可用呢
1
Ericcccccccc 2023-10-05 15:08:54 +08:00
如果你纠结的是"高可用"的定义, 要不你说说你心中的高可用是怎么样的?
|
2
vcn8yjOogEL 2023-10-05 15:11:08 +08:00
高可用不是始终可用
|
3
nonopa OP @Ericcccccccc 故障切换无感知
|
4
nonopa OP 那我理解错了, '高' 不是 完全
|
5
Worldispow 2023-10-05 15:15:11 +08:00 via Android
自己去搜搜高可用的定义吧。
99%是高可用,99.99%也是高可用。 高可用只是说高,可没说是一定、完全可用。 |
6
Ericcccccccc 2023-10-05 15:28:16 +08:00
@nonopa 如果是这么讲, 就会引出更难回答的问题. 什么是故障切换, 什么是无感知.
|
7
IndexOutOfBounds 2023-10-05 15:31:46 +08:00 via Android
最近也在纠结类似的问题,异步复制下的故障转移总是有可能丢数据的,不知道实际生产咋处理
|
8
sumarker 2023-10-05 15:53:40 +08:00
所有的方案都是在某种特定场景下的
方案肯定是在多方权衡之下选择出来的 已知的 "高可用" 应该都是经过一些实际试验后得出一个比较满意的结果的... 而且“程序设计没有银弹”。。。 |
9
coyove 2023-10-05 16:01:48 +08:00
我理解 OP 期望的真正高可用只有 CRDT 这类最终一致性的数据结构能办到了。但最终一致的逻辑也会导致很多业务没法直接用的,或者说要从头大改代码。
|
10
weeei 2023-10-05 16:10:51 +08:00
你可能理解错了,高可用不是一直可用,#2 说的对。
故障切换无感知,这里是相对于「谁」? 如果是使用 App 的用户,需要 App 端配合达到用户无感知:每个 API 设置重试次数和重试间隔,比如重试 3 次,每次间隔是 5 秒,那么服务端只要在 15 秒内能提供服务,App 用户只会觉得是网络慢,不会感知到发生了故障。 |
11
me1onsoda 2023-10-05 16:35:22 +08:00
高可用是有具体指标的,比如 99.99 。那就意味着我这一年中可以有 0.01 的不可用时间,也就是这么多秒 3600×24×365×0.01
|
12
opengps 2023-10-05 16:50:02 +08:00
入门级的高可用,是对比单进程而言的,死了就是死了。
多进程或者多从机可以没全死不算死 |
13
wudaye 2023-10-05 17:02:52 +08:00
理解为高度可用,而不是一直可用
|
14
pengtdyd 2023-10-05 17:15:55 +08:00
楼上说的都太技术了。高可用==备胎,备胎可以多个,俗称《渣男架构》。
|
15
adoal 2023-10-05 17:17:58 +08:00
除了前面说的,故障间隙比较短,对用户感知的影响可以“糊弄”过去之外,所谓高可用,还有重要的一点是这个 failover 的过程是自动化的,检测到不可用时长超过某个阈值之后就自动拉起备机、关掉故障机、IP 漂过去, [运维人员对故障机的替换处理过程] 不影响线上服务。
|
16
newshbb 2023-10-05 17:58:15 +08:00
高可用?哪个大型 App 没断过服务
|
17
lqw3030 2023-10-05 23:20:50 +08:00
单次异常下的高可用,即一个节点发生异常时整体集群仍可以正常服务。配套的告警机制也是非常重要的,要及时恢复故障节点
|
18
zhangckid 2023-10-05 23:31:55 +08:00 via Android
真…楼主理解的基于 VM 的高可用开源项目…https://wiki.qemu.org/Features/COLO
|