分布式数据库中单节点故障的影响?
分布式数据库中，当存在节点异常时(物理故障异常宕机、系统资源导致HANG)，在故障恢复过程中，是否对应用有感知，如果应用有感知，影响时间大概多长时间，大家可以针对一些主流的分布式数据库产品聊下。
问题来自社区会员@leiou0410 某银行DBA，以下内容来自社区会员探讨
@zhanxuechao 数字研究院 咨询专家：
分布式数据库部署的时候一般采用集群、多副本的方式，理论上单节点故障对应用是无感知的，最多只会丢一个包，自动连接即正常。
@anikikong 中国民生银行 数据库运维工程师：
这个属于分布式数据库的强项，单节点异常的恢复通常能做到分钟级甚至秒级。对于应用完全无感知是不可能的，至少当前的事务会失败。这个我觉得在各种分布式数据库间差距不是很明显，属于分布式的强项之一。
@wangzk0206 scrcu 数据库管理员：
分布式数据库的高可用一般都是采用多数派协议实现的，单节点故障(少于多少派的情况下)都会自动切主，对业务感知是透明的。估计会有个别当时执行的事务出现回滚等现象，体现在tps上也就是突然掉下去一点，但随后立马恢复。
但是针对系统资源导致HANG这个故障场景，可能一般数据库感知都可能存在问题吧，一般很难感知到。我所了解的OB在这方面具有租户级别的资源隔离，当一台服务器资源使用过高的时候，可以通过OCP白屏(或者命令行黑屏)手工切主，将部分租户的主切到另外资源使用率低的服务器上，这样原有的服务器的资源利用率就会降低。
@huhu097 云南红塔银行 DBA：
以下为本人亲自测试结果，仅供参考：
@EastBrother 技术支持：
一般在做分布式数据库规划设计中，都会考虑分布式数据库的高可用架构以及应急处置策略等。最基本的原则肯定是要具备单点故障无维护的能力，还有所选分布式数据库集群软件的安全稳定性能力，一定要全面测试验证，要避免分布式数据库集群软件自身缺陷导致的争抢资源或频繁异常宕机的情况。
在做分布式数据库高可用架构规划时，可能会考虑以下几种方式：
1)单机房多副本，副本存放在不同节点中。该方案可以应对单节点故障，而且事务提交操作没有跨机房日志同步操作，对事务响应时间影响最小。在单节点故障情况下，数据不丢失，原故障节点对外提供的服务可能会有几秒或几十秒的影响，需要应用程序重新建立数据库的连接。
2)同城三机房，每个机房一个数据副本。该方案可以应对单机房故障，事务提交操作需要在同城机房间进行日志同步，对事务响应时间有较小影响。
3)两地三机房，可以使用3个副本或者5个副本。该方案在应对单机房故障的基础上，如果存放单机房的城市发生故障，数据也不会丢失;事务提交操作大概率在同城机房间进行日志同步，对事务响应时间有较小影响;但一旦同城的两个机房中一个机房发生故障，事务提交就需要跨城日志同步，对事务响应时间有较大影响。
4)三地三机房，多使用5个副本。可以应对城市级故障。事务提交操作需要跨城进行日志同步，对事务响应时间有较大影响。
分布式数据库架构可以有多种组合方式，以上4种方案也不是绝对的。不过在分布式架构下要重点关注网络的架构规划和时延情况，还要考虑业务系统的部署方案，比如对于可用性要求特别高的系统，可采用三地三机房方案将分布式数据库系统部署到三地三机房中，业务系统也需要部署到将相应的三个机房里，避免跨城数据库访问造成的性能损失;同时每一次事务提交需要跨城事务日志同步，对响应时间有一定的影响，这种情况下一定要提前测试验证好各种场景下网络延时或网络抖动对应用系统和对分布式数据库的影响情况。