关于'高可用'的问题

[nonopa]

redis cluster, mysql mgr 都号称是高可用方案, 一旦节点故障,它们的故障检测、故障转移也是要时间的,至少也是秒级. 这期间他们应该是不可用的吧? 为什么这些方案也叫高可用呢

感谢各位的解释,是我对'高可用'的理解有误

[Ericcccccccc]

如果你纠结的是"高可用"的定义, 要不你说说你心中的高可用是怎么样的?

[vcn8yjOogEL]

高可用不是始终可用

[nonopa]

@Ericcccccccc 故障切换无感知

[nonopa]

那我理解错了, '高' 不是 完全

[Worldispow]

自己去搜搜高可用的定义吧。
99%是高可用，99.99%也是高可用。
高可用只是说高，可没说是一定、完全可用。

[Ericcccccccc]

@nonopa 如果是这么讲, 就会引出更难回答的问题. 什么是故障切换, 什么是无感知.

[IndexOutOfBounds]

最近也在纠结类似的问题，异步复制下的故障转移总是有可能丢数据的，不知道实际生产咋处理

[sumarker]

所有的方案都是在某种特定场景下的
方案肯定是在多方权衡之下选择出来的
已知的 "高可用" 应该都是经过一些实际试验后得出一个比较满意的结果的...
而且“程序设计没有银弹”。。。

[coyove]

我理解 OP 期望的真正高可用只有 CRDT 这类最终一致性的数据结构能办到了。但最终一致的逻辑也会导致很多业务没法直接用的，或者说要从头大改代码。

[weeei]

你可能理解错了，高可用不是一直可用，#2 说的对。
故障切换无感知，这里是相对于「谁」？
如果是使用 App 的用户，需要 App 端配合达到用户无感知：每个 API 设置重试次数和重试间隔，比如重试 3 次，每次间隔是 5 秒，那么服务端只要在 15 秒内能提供服务，App 用户只会觉得是网络慢，不会感知到发生了故障。

[me1onsoda]

高可用是有具体指标的，比如 99.99 。那就意味着我这一年中可以有 0.01 的不可用时间，也就是这么多秒 3600×24×365×0.01

[opengps]

入门级的高可用，是对比单进程而言的，死了就是死了。
多进程或者多从机可以没全死不算死

[wudaye]

理解为高度可用，而不是一直可用

[pengtdyd]

楼上说的都太技术了。高可用==备胎，备胎可以多个，俗称《渣男架构》。

[adoal]

除了前面说的，故障间隙比较短，对用户感知的影响可以“糊弄”过去之外，所谓高可用，还有重要的一点是这个 failover 的过程是自动化的，检测到不可用时长超过某个阈值之后就自动拉起备机、关掉故障机、IP 漂过去， [运维人员对故障机的替换处理过程] 不影响线上服务。

[newshbb]

高可用？哪个大型 App 没断过服务

[lqw3030]

单次异常下的高可用，即一个节点发生异常时整体集群仍可以正常服务。配套的告警机制也是非常重要的，要及时恢复故障节点

[zhangckid]

真…楼主理解的基于 VM 的高可用开源项目…https://wiki.qemu.org/Features/COLO