分布式篇(CAP)

我是hope啊
185 阅读4分钟

发展历程

  • 入口级负载均衡

    • 网关负载均衡
    • 客户端负载均衡

  • 单应用架构

    • 应用服务和数据服务分离
    • 应用服务集群
    • 应用服务中心化SAAS

  • 数据库主备读写分离

    • 全文搜索引擎加快数据统计
    • 缓存集群缓解数据库读压力
    • 分布式消息中间件缓解数据库写压力
    • 数据库水平拆分适应微服务
    • 数据库垂直拆分解决慢查询

  • 划分上下文拆分微服务

    • 服务注册发现（Eureka、Nacos）
    • 配置动态更新（Config、Apollo）
    • 业务灰度发布（Gateway、Feign）
    • 统一安全认证（Gateway、Auth）
    • 服务降级限流（Hystrix、Sentinel）
    • 接口检查监控（Actuator、Prometheus）
    • 服务全链路追踪（Sleuth、Zipkin）

CAP

  • 一致性（2PC、3PC、Paxos、Raft）

    • 强一致性：数据库一致性，牺牲了性能

      • ACID：原子性、一致性、隔离性、持久性

    • 弱一致性：数据库和缓存，延迟双删、重试

    • 单调读一致性：缓存一致性，ID或者IP哈希

    • 最终一致性：边缘业务，消息队列

  • 可用性（多级缓存、读写分离）

    • BASE 基本可用：限流导致响应速度慢、降级导致用户体验差

      • Basically Availabe 基本可用
      • Soft state 软状态
      • Eventual Consistency 最终一致性

  • 分区容忍性（一致性Hash解决扩缩容问题）

一致性

XA方案

2PC协议：两阶段提交协议，P是指准备阶段，C是指提交阶段

  • 准备阶段：询问是否可以开始，写Undo、Redo日志，收到响应
  • 提交阶段：执行Redo日志进行Commit，执行Undo日志进行Rollback

3PC协议：将提交阶段分为CanCommit、PreCommit、DoCommit三个阶段

CanCommit：发送canCommit请求，并开始等待

PreCommit：收到全部Yes，写Undo、Redo日志。超时或者No，则中断

DoCommit：执行Redo日志进行Commit，执行Undo日志进行Rollback

区别是第二步，参与者自身增加了超时，如果失败可以及时释放资源

Paxos算法

如何在一个发生异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致

参与者（例如Kafka）的一致性可以由协调者（例如Zookeeper）来保证，协调者的一致性就只能由Paxos保证了

Paxos算法中的角色：

  • Client：客户端、例如，对分布式文件服务器中文件的写请求。
  • Proposer：提案发起者，根据Accept返回选择最大N对应的V，发送[N+1,V]
  • Acceptor：决策者，Accept以后会拒绝小于N的提案，并把自己的[N,V]返回给Proposer
  • Learners：最终决策的学习者、学习者充当该协议的复制因素
//算法约束
P1:一个Acceptor必须接受它收到的第一个提案。
//考虑到半数以上才作数，一个Accpter得接受多个相同v的提案
P2a:如果某个v的提案被accept，那么被Acceptor接受编号更高的提案必须也是v
P2b:如果某个v的提案被accept，那么从Proposal提出编号更高的提案必须也是v
//如何确保v的提案Accpter被选定后，Proposal都能提出编号更高的提案呢
针对任意的[Mid,Vid]，有半数以上的Accepter集合S，满足以下二选一：
  S中接受的提案都大于Mid
  S中接受的提案若小于Mid，编号最大的那个值为Vid

image-20210112225118095

面试题：如何保证Paxos算法活性

假设存在这样一种极端情况，有两个Proposer依次提出了一系列编号递增的提案，导致最终陷入死循环，没有value被选定

  • 通过选取主Proposer，规定只有主Proposer才能提出议案。只要主Proposer和过半的Acceptor能够正常网络通信，主Proposer提出一个编号更高的提案，该提案终将会被批准。
  • 每个Proposer发送提交提案的时间设置为一段时间内随机，保证不会一直死循环

ZAB算法

Raft算法

Raft 是一种为了管理复制日志的一致性算法

Raft使用心跳机制来触发选举。当server启动时，初始状态都是follower。每一个server都有一个定时器，超时时间为election timeout（一般为150-300ms），如果某server没有超时的情况下收到来自领导者或者候选者的任何消息，定时器重启，如果超时，它就开始一次选举。

Leader异常：异常期间Follower会超时选举，完成后Leader比较彼此步长

Follower异常： 恢复后直接同步至Leader当前状态

多个Candidate： 选举时失败，失败后超时继续选举

  • [ 萱儿AXW ]
avatar
文章
阅读
粉丝