分布式理论知识

本章介绍后端常用到的分布式理论知识,包括 cap,base理论,一致性协议算法等。

一致性模型

弱一致性(最终一致性):

  • DNS(Domain Name System)
  • Gossip

强一致性:

  • 主从同步(一致性高,可用性低)
    • master 接受写清球
    • master 复制日志到 slave
    • master 等待直到所有从库返回。
  • Paxos
  • Raft (multi-paxos)
  • ZAB (multi-paxos)

最终一致性根据业务场景可以分为五种:

  • 因果一致性(causal consistency)。因果一致性指的是:如果节点A在更新完某个数据后通知了节点B,那么节点B之后对该数据的访问和修改都基于节点A更新后的值, 而和节点A无因果关系的节点C的数据访问则没有这样的限制。例如,电商业务里的下单和支付就属于这一种。
  • 读己之所写(read your writes)。读己之所写指的是:当节点A更新一个数据后,它总是能访问到自身更新过的最新值,而不会看到旧值。 这也是因果一致性的一种,只不过是单个事件的内部逻辑,而因果一致性可能是多个事件的因果关系。例如,支付系统扣款完成之后再刷新余额就属于这一种。
  • 会话一致性(session consistency)。会话一致性指的是:将对系统数据的访问过程限定在一个会话当中,系统能保证在同一个有效的会话中实现“读己之所写”的一致性。 也就是说,执行更新操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。会话一致性是读己之所写的延伸和扩展。例如,找回密码的操作分为很多步骤,每个步骤都依赖前一个步骤是否成功,所有前置步骤全部按照次序完成才允许修改密码。
  • 单调读一致性(monotonic read consistency)。单调读一致性指的是:如果一个节点从系统中读取出一个数据项的某个值,那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。 例如,多机房间用户授权token的同步,只要一个新的token已通过数据同步存储下来了,后面允许存储的token就不应该比这个token更早。这样读取到的token一定是用户更新的授权信息。
  • 单调写一致性(monotonic write consistency)。单调写一致性指的是:一个系统要能够保证来自同一个节点的写操作被顺序地执行。 例如,用户多次修改订单信息,那么通过消息队列进行分发最终落地数据库修改时,需要保障用户的操作是按照时间先后顺序被执行的。 基于Kafka的单分区可以保障数据有序,但是这种方式性能有限,也可考虑将每个信息都带上时间戳,再依据时间戳的先后顺序覆盖写入。

Paxos

Bacic Paxos

角色:

  • Client: 系统外部角色,请求发起者。(民众)
  • Proposer: 接收 client 请求,向集群踢出提议(propose)。(议员)
  • Accpetor(Voter): 提议投票和接收者,只有在形成法定人数(Quorum,一般为majority多数派)时,提议才会被接受。(过会)
  • Learner: 提议接受者, backup,备份。对一群一致性无影响。(记录员)

阶段:

  • 1a: Prepare: Proposer提出一个提案编号N,此 N 大于这个 proposer 之前踢出的编号。请求 Accpetor的quorum接
  • 1b: Promise: 请求 N 大于此 Acceptor 之前接受的任何提案编号则接受,否则拒绝
  • 2a: Accept: 如果达到了多数派,Proposer 会发出 accept 请求(包含N)和提案内容
  • 2b: Accepted: 如果Acceptor在此期间没有接收到任何编号大于N的提案,则接受此提案内容,否则忽略

潜在问题:活锁(liveness)或dueling。解决方案,随机超时

难实现,效率低(2轮RPC),活锁

Multi Paxos

新概念,Leader: 唯一的Proposer,所有请求都需要经过此 Leader

Fast Paxos