分布式高可用常用解决方案
- 多节点多副本，分布在不同服务器或者数据中心
- 自动故障转移，例如redis cluster当主节点故障以后按照分布式协议自动更换主节点到一个活跃的副本上
- 负载均衡
- 实时或者定期状态同步：例如主从复制
- 健康检查和监控
- 分布式事务：分布式锁、分布式事务保障数据一致性的协议（2PC、TCC、SAGA等）
- 灾难恢复和备份：定期备份和灾难恢复策略
数据最终一致性方案
- 分布式事务常见协议（解决方案）（2PC、TCC、淘宝的TXC）
2PC：先通知slave，slave执行事务回复：可提交/not ok，master收到了所有可的回复就通知执行完成事务释放锁，否则发出回滚指令
3PC：加了一个预确认，先问slave行不行，都行了再通知slave执行事务等待回复，收到了slave已执行待提交的回复再通知执行，完成事务释放锁。
TCC：try confirm cancel：先预留资源（例如库存预扣减/订单待支付）；确认资源，执行实际业务操作（库存扣减，订单完成）；前两步出错就cancel，释放预留资源，回滚已经执行的操作（取消预扣除，订单标记为取消）。
TXC：taobao transaction constructor：两阶段，try和confirm 先获取资源执行事务但是不提交；预操作成功就确认事务，执行实际操作并释放，如果失败就回滚。
- 最终一致性协议：CAP（Consistency一致性、availablity可用性、partition- tolerance分区容错性）常见为实现AP，保障最终一致性；或者基于Quorum的复制协议；还有一个CRDTs（冲突自由复制数据类型）Conflict-free Replicated Data Types，是一种数据结构，节点不加锁独立更新，更新后节点之间互相交换和合并来达到一致，有点像Gossip协议
- 补偿事务：回滚
- 乐观锁_版本控制：保证并发一致：OLAP/OLTP等数据库系统的MVCC（多版本并发控制），mySQL的innoDb就用了MVCC实现高效的并发控制，没用锁，就是用版本号，所以效率高。
- 数据副本和同步：如使用CQRS（Command Query Responsibility Segregation）模式将数据写入和读取操作分离，这是一种设计模式（应用层面），类比MYSQl集群的主从复制（数据层面）。
- 一致性哈希算法（那个圆圈）：在处理数据分布和路由时使用一致性哈希算法，可以减少节点变更时的数据一致性问题。
- 分区容错-共识性算法/协议：Raft协议(选leader，其他slave都是日志复制)、paxos协议（有点复杂）、Gossip协议（定期交换数据并合并，不断传播更新，达成最终一致，适用于社交网络这种大规模动态变化的场景）
- 定时任务保证延迟一致性
2PC/3PC和Raft共识算法的区别
3PC关注的是确保分布式事务在所有参与者间原子性地提交或回滚；而Raft关注的是在可能出现故障的分布式系统中保持一致的状态机副本，适用于那些需要高可用性、容错性以及成员节点动态变化的分布式系统。
在数据变动不频繁的场景中，2PC或3PC可能更适用；
在需要快速、通用的共识决策的系统中（成员动态变化），Raft和Paxos是很好的选择（raft更简单，适用性更广）。
常见案例：Raft：ETCD（服务发现/键值存储）、集群管理和选举
2PC：分布式数据库管理系统
2PC/3PC和TCC协议的区别
2PC/3PC关注的是在分布式数据库系统中如何避免事务提交时的单点故障。（偏协议级别）
TCC的主要应用是在跨服务调用的业务分布式事务，它更侧重业务逻辑层面，由应用逻辑控制整个事务流程，适用于需要长时间业务交互的分布式系统。（业务级别）
分割脑问题
分割脑（Split-Brain）问题是指在一个分布式系统（尤其是在集群环境中）中发生的一种情况，其中系统的不同部分由于网络分区或通信故障等原因失去了彼此的联系，但系统的各个部分依然继续独立运作。这可能导致不同部分的系统做出相互矛盾的决策，从而出现数据不一致性或冲突的情况。
分割脑问题的表现
数据不一致：不同的系统分区可能会处理相同的数据请求，并可能对同一数据做出不同的更新，导致数据不再一致。
服务冲突：假设两个系统分区都认为自己是主节点（或领导节点），那么它们可能会同时尝试对外提供服务，这会导致外部系统或客户端收到矛盾的信息或数据。
资源竞争：资源（如文件、数据库等）可能会被不同的分区同时修改，造成资源损坏或丢失重要信息。
解决分割脑问题的策略
心跳检测：通过定期的心跳消息来监测集群中的节点是否存活，帮助发现网络分区情况。
脑裂仲裁机制：引入第三方仲裁（如仲裁磁盘、仲裁节点等），在出现网络分割时由仲裁方决定哪一部分是“有效”的，而其他部分则需要停止提供服务或转为备用模式。
分布式锁：通过分布式锁确保在任何时候只有一个分区（或节点）可以操作特定的资源或数据。
容错和一致性协议：如Paxos、Raft等一致性协议，帮助集群中的节点即使在少部分节点无法通信的情况下，也能达成一致的决策。
多数派原则（Quorum）：只有当超过半数的节点达成一致时，操作才会执行。这确保了在出现脑裂情况时，只有能够与多数节点通信的那一部分才能继续运行。
总结
分割脑是分布式系统设计时需要考虑和防范的重要问题之一，忽视它可能导致系统运行不稳定、数据不一致等一系列问题。通过恰当的设计和预防措施，可以减轻甚至避免分割脑问题带来的影响。
CQRS和集群主从复制的区别
CQRS（Command Query Responsibility Segregation，命令查询责任分离）模式与分布式系统中主节点（Master）负责写操作、子节点（Slave）负责读操作的架构解决方案在某些方面有相似之处。它们都采用了分离读写操作的策略以提升系统性能和可伸缩性，但它们的设计理念和应用场景有所不同。
CQRS模式
CQRS是一种设计模式，在这种模式下，系统被分为两部分：负责处理命令（写操作）的部分和负责处理查询（读操作）的部分。CQRS经常和事件溯源（Event Sourcing）结合使用，其中对数据的更改以事件序列的形式进行存储，这些事件易于追踪和复制。CQRS可以实现在不同的模型上优化读写操作，比如查询模型可以进行非常专化的索引和缓存优化，而命令模型则可以侧重事务安全和完整性。
主节点负责写，子节点负责读的架构
这种模式通常出现在分布式数据库系统中，比如MySQL主从复制、MongoDB复制集或其他数据库技术。在这样的设置中，主节点承担所有的写负载，并将数据的更改同步给一个或多个子节点。子节点提供读服务，从而分散读取请求的压力。主从架构可以提升读取操作的性能，因为他们可以在多个子节点上并行处理。另外，如果主节点发生故障，某个子节点可以被提升为新的主节点以保持系统的可用性。
不同之处
尽管在表面上CQRS模式和分布式数据库中的主从读写分离似乎类似，它们的不同之处在于：
- 设计目的：
CQRS通常是在应用层实施，向外提供更细粒度的数据处理控制。
主从读写分离则主要关注数据库层面，提高数据库操作的性能和可用性。 - 复杂性与一致性：CQRS可以处理复杂的业务逻辑，通过分离命令和查询来应对需求变化。
主从架构重点在于保障数据一致性的同时处理并发读写操作。 - 应用场景：CQRS适用于业务逻辑复杂，对读写分离需求高的应用。
主从读写分离主要适用于需要扩展读操作，同时维护高数据一致性的数据库系统。
主从架构案例
一些流行的数据库系统和相关解决方案实现了主从架构。例如：
- MySQL复制：通过binlog将写操作从主服务器复到从服务器。
- PostgreSQL流复制：使用WAL（Write-Ahead Logging）来同步主节点到从节点的数据。
- MongoDB复制集：选举一个主节点进行写操作，并将更改同步到多个从节点。
使用主从架构的目标是提高读取性能，为写操作提供一致性和持久性，同时在某些设定中，也可以从从节点晋升新主节点以实现故障转移。CQRS和主从架构，尽管它们在某些方面功能相似，但它们分别解决了应用层和数据层的不同问题。
8089
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
