这是一个创建于 401 天前的主题，其中的信息可能已经有所发展或是发生改变。
redis cluster, mysql mgr 都号称是高可用方案, 一旦节点故障,它们的故障检测、故障转移也是要时间的,至少也是秒级. 这期间他们应该是不可用的吧? 为什么这些方案也叫高可用呢
第 1 条附言 · 2023-10-05 16:47:20 +08:00
感谢各位的解释,是我对'高可用'的理解有误
 |
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
|
Select Language