分布式数据库中单节点故障的影响？

以下为本人亲自测试结果，仅供参考

一般在做分布式数据库规划设计中，都会考虑分布式数据库的高可用架构以及应急处置策略等。最基本的原则肯定是要具备单点故障无维护的能力，还有所选分布式数据库集群软件的安全稳定性能力，一定要全面测试验证，要避免分布式数据库集群软件自身缺陷导致的争抢资源或频繁异常宕机的情况。
在做分布式数据库高可用架构规划时，可能会考虑以下几种方式：
1、单机房多副本，副本存放在不同节点中。该方案可以应对单节点故障，而且事务提交操作没有跨机房日志同步操作，对事务响应时间影响最小。在单节点故障情况下，数据不丢失，原故障节点对外提供的服务可能会有几秒或几十秒的影响，需要应用程序重新建立数据库的连接。
2、同城三机房，每个机房一个数据副本。该方案可以应对单机房故障，事务提交操作需要在同城机房间进行日志同步，对事务响应时间有较小影响。
3、两地三机房，可以使用3个副本或者5个副本。该方案在应对单机房故障的基础上，如果存放单机房的城市发生故障，数据也不会丢失；事务提交操作大概率在同城机房间进行日志同步，对事务响应时间有较小影响；但一旦同城的两个机房中一个机房发生故障，事务提交就需要跨城日志同步，对事务响应时间有较大影响。
4、三地三机房，多使用5个副本。可以应对城市级故障。事务提交操作需要跨城进行日志同步，对事务响应时间有较大影响。
分布式数据库架构可以有多种组合方式，以上4种方案也不是绝对的。不过在分布式架构下要重点关注网络的架构规划和时延情况，还要考虑业务系统的部署方案，比如对于可用性要求特别高的系统，可采用三地三机房方案将分布式数据库系统部署到三地三机房中，业务系统也需要部署到将相应的三个机房里，避免跨城数据库访问造成的性能损失；同时每一次事务提交需要跨城事务日志同步，对响应时间有一定的影响，这种情况下一定要提前测试验证好各种场景下网络延时或网络抖动对应用系统和对分布式数据库的影响情况。

这个属于分布式数据库的强项，单节点异常的恢复通常能做到分钟级甚至秒级。对于应用完全无感知是不可能的，至少当前的事务会失败。这个我觉得在各种分布式数据库间差距不是很明显，属于分布式的强项之一。

分布式数据库的高可用一般都是采用多数派协议实现的，单节点故障（少于多少派的情况下）都会自动切主，对业务感知是透明的。估计会有个别当时执行的事务出现回滚等现象，体现在tps上也就是突然掉下去一点，但随后立马恢复。
但是针对系统资源导致HANG这个故障场景，可能一般数据库感知都可能存在问题吧，一般很难感知到。我所了解的OB再这方面一个好的地方是它具有租户级别的资源隔离，当一台服务器资源使用过高的时候，可以通过OCP白屏（或者命令行黑屏）手工切主，将部分租户的主切到另外资源使用率低的服务器上，这样原有的服务器的资源利用率就会降低。

分布式数据库部署的时候一般采用集群、多副本的方式，理论上单节点故障对应用是无感知的，最多只会丢一个包，自动连接即正常。

当数据库单个节点发生故障后，管理平台要进行周期性系统感知，一般是30s或者分钟级别。在这段时间内业务是有感知的，一般是会交易超时或者错误。这和是否主流数据库没有关系。在实际操作中，先选定你们的数据库，再分析数据库架构，然后设计故障案例测试，也可以据此知道应用应该如何优化代码，比如链接断开时的自动重连等。

我理解是有感知的，虽然可能对数据正确性和选择的版本无感，但是清理过期数据和同步过期数据；还是需要一定较长的时间，对于TPS特别高的场景，可能会长时间阻碍问题节点的数据查询。

ob
ck
一般应用层面无感知