这是一个创建于 738 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 PRO 所有的方案都是在某种特定场景下的 方案肯定是在多方权衡之下选择出来的 已知的 "高可用" 应该都是经过一些实际试验后得出一个比较满意的结果的... 而且“程序设计没有银弹”。。。 |
 | 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 xyooyx 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