C++ 全栈知识体系C++ 全栈知识体系
✿导航
  • 基础
  • 函数
  • 知识点
  • IO框架
  • 新版本特性
  • 数据库原理
  • SQL语言
  • SQL - MySQL
  • NoSQL - Redis
  • NoSQL - ElasticSearch
  • 算法基础
  • 常见算法
  • 领域算法
  • 分布式算法
  • 数据结构与算法
  • 计算机网络
  • 操作系统
  • 计算机组成
  • 开发
  • 测试
  • 架构基础
  • 分布式系统
  • 微服务
  • 中间件
  • 概念
  • 理论
  • 架构设计原则
  • 设计模式
  • 协议
  • 技术选型
  • 编码规范
  • 流水线构建 - CI/CD
  • 知识点 - Linux
  • 网站 - Nginx
  • 容器化 - Docker
  • 容器编排 - Kubernetes
  • 服务网格 - Service Mesh Istio
  • 常用快捷键 - Shortcut
  • 工具使用 - Tools
  • 开源项目
  • 学习项目
  • 个人项目
  • 项目开发
  • 项目Idea
  • 并发
  • 部署
  • 分布式
  • 知识
  • 问题
  • 编程语言与技术
  • 系统与架构
  • 软件开发实践
  • 数据处理与应用设计
  • 个人
  • 产品
  • 团队
  • 知识体系
  • Vue
关于
✿导航
  • 基础
  • 函数
  • 知识点
  • IO框架
  • 新版本特性
  • 数据库原理
  • SQL语言
  • SQL - MySQL
  • NoSQL - Redis
  • NoSQL - ElasticSearch
  • 算法基础
  • 常见算法
  • 领域算法
  • 分布式算法
  • 数据结构与算法
  • 计算机网络
  • 操作系统
  • 计算机组成
  • 开发
  • 测试
  • 架构基础
  • 分布式系统
  • 微服务
  • 中间件
  • 概念
  • 理论
  • 架构设计原则
  • 设计模式
  • 协议
  • 技术选型
  • 编码规范
  • 流水线构建 - CI/CD
  • 知识点 - Linux
  • 网站 - Nginx
  • 容器化 - Docker
  • 容器编排 - Kubernetes
  • 服务网格 - Service Mesh Istio
  • 常用快捷键 - Shortcut
  • 工具使用 - Tools
  • 开源项目
  • 学习项目
  • 个人项目
  • 项目开发
  • 项目Idea
  • 并发
  • 部署
  • 分布式
  • 知识
  • 问题
  • 编程语言与技术
  • 系统与架构
  • 软件开发实践
  • 数据处理与应用设计
  • 个人
  • 产品
  • 团队
  • 知识体系
  • Vue
关于
  • 概念

    • 概念 - 概述
    • 概念 - 计算机专有名词
    • 概念 - 正向代理和反向代理
    • 概念 - 云网络
    • 概念 - rest api
    • 概念 - 脑裂
  • 理论

    • 事务理论 - ACID
    • 分布式理论 - CAP
    • 分布式理论 - BASE
  • 架构设计原则

    • 架构设计原则 - 合适、简单、演化
    • 架构设计原则 - 高内聚、低耦合
    • 架构设计原则 - 正交四原则
    • 架构设计原则 - SOLID详解
    • 架构设计原则 - 分层架构MVC
    • 架构设计原则 - DDD领域驱动设计:贫血模型和充血模型
    • 架构设计原则 - DDD领域驱动设计
  • 设计模式

    • 创建型模式 - Create model

      • 创建型模式 - 单例模式(Singleton)
      • 创建型模式 - 工厂模式(Factory)
      • 创建型模式 - 抽象工厂(Abstract Factory)
      • 创建型模式 - 生成器(Builder)
      • 创建型模式 - 原型模式(Prototype)
    • 结构型模式 - Structural model

      • 结构型模式 - 外观(Facade)
      • 结构型模式 - 适配器(Adapter)
      • 结构型模式 - 桥接(Bridge)
      • 结构型模式 - 组合(Composite)
      • 结构型模式 - 装饰(Decorator)
      • 结构型模式 - 享元(Flyweight)
      • 结构型模式 - 代理(Proxy)
    • 行为型模式 - Behavioral model

      • 行为型模式 - 责任链(Chain Of Responsibility)
      • 行为型模式 - 策略(Strategy)
      • 行为型模式 - 模板模式(Template)
      • 行为型模式 - 命令模式(Command)
      • 行为型模式 - 观察者(Observer)
      • 行为型模式 - 访问者(Visitor)
      • 行为型模式 - 状态(State)
      • 行为型模式 - 解释器(Interpreter)
      • 行为型模式 - 迭代器(Iterator)
      • 行为型模式 - 中介者(Mediator)
      • 行为型模式 - 备忘录(Memento)
  • 协议

    • 协议 - Http
    • 协议 - SNMP
    • 协议 - NETCONF
    • 协议 - TLS和SSL
    • 协议 - Http-wiki
    • 协议 - TCP/IP
    • 协议 - Https常见的认证模式
  • 技术选型

    • 技术选型 - 常用的技术框架
    • 技术选型 - 如何写一个自己的项目
    • 技术选型 - 基于drogon实现用户中心后端
  • 编码规范

    • 编码规范 - Google C++ Style Guide
    • 编码规范 - 编程风格
    • 编码规范 - 头文件包含规范
    • 编码规范 - 常用编码命名规则
    • 编码规范 - 编码命名规范

概念 - 脑裂

  • 产生条件
  • 解决方法

参考资料

  • wiki百科概念

wiki百科概念

Split-brain is a computer term, based on an analogy with the medical Split-brain syndrome. It indicates data or availability inconsistencies originating from the maintenance of two separate data sets with overlap in scope, either because of servers in a network design, or a failure condition based on servers not communicating and synchronizing their data to each other. This last case is also commonly referred to as a network partition.

High-availability clusters usually use a heartbeat private network connection which is used to monitor the health and status of each node in the cluster.

Approaches for dealing with split-brain:

  1. The optimistic approaches simply let the partitioned nodes work as usual; this provides a greater level of availability, at the cost of sacrificing correctness. Once the problem has ended, automatic or manual reconciliation might be required in order to have the cluster in a consistent state. One current implementation for this approach is Hazelcast, which does automatic reconciliation of its key-value store.[3]

  2. The pessimistic approaches sacrifice availability in exchange for consistency. Once a network partitioning has been detected, access to the sub-partitions is limited in order to guarantee consistency. A typical approach, as described by Coulouris et al.,[4] is to use a quorum-consensus approach. This allows the sub-partition with a majority of the votes to remain available, while the remaining sub-partitions should fall down to an auto-fencing mode. One current implementation for this approach is the one used by MongoDB replica sets.[5] And another such implementation is Galera replication for MariaDB and MySQL.[6]

  3. Modern commercial general-purpose HA clusters typically use a combination of heartbeat network connections between cluster hosts, and quorum witness storage. The challenge with two-node clusters is that adding a witness device adds cost and complexity (even if implemented in the cloud), but without it, if heartbeat fails, cluster members cannot determine which should be active. In such clusters (without quorum), if a member fails, even if the members normally assign primary and secondary statuses to the hosts, there is at least a 50% probability that a 2-node HA cluster will totally fail until human intervention is provided, to prevent multiple members becoming active independently and either directly conflicting or corrupting data.

产生条件

  • 分区数据因通信或同步原因,产生双主或多主的场景。

解决方法

  1. 乐观的方法:

    • 以牺牲正确性为代价,让分区节点照常工作,即提供了更高级别的可用性。等到分区恢复后,可能需要自动或手动调节,以使集群处于一致状态。(Hazelcast就是采用该方法,它对其键值存储进行自动调节)
  2. 悲观的方法:

    • 以牺牲可用性换取一致性。一旦检测到网络分区,就限制对子分区的访问,以保证一致性。可以采用投票选举方式(quorum-consensus approach)。这允许具有多数投票权的分区保持可用,而剩余的子分区应降至自动隔离模式(auto-fencing mode)。(MongoDB副本集使用;MariaDB和MySQL的Galera复制)
  3. 现代商用HA集群:

    • 使用集群主机之间的心跳网络连接和仲裁见证存储。
    • 添加仲裁节点,增加额外成本和复杂性
    • 没有仲裁,当心跳网络中断,集群无法确定应该存活。

补充:

仲裁(Quorum):法定数量,预先规定具有投票权的节点或见证(Witness)的数量;

Last Updated:
Contributors: klc407073648
Prev
概念 - rest api