1. ACID

原子性(Atomicity)、一致性(Consistency)、隔离性(isolation)、永久性(durability)

  • Atomicity(原子性):一个事务(transaction)中的所有操作,或者全部完成,或者全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被恢复(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。即,事务不可分割、不可约简。
  • Consistency(一致性):在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束触发器)、级联回滚等。
  • Isolation(隔离性):数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。
  • Durability(持久性):事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

来自wiki:https://zh.wikipedia.org/wiki/ACID

2. CAP

CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:[1][2]

  • 一致性(Consistency) (等同于所有节点访问同一份最新的数据副本)
  • 可用性Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
  • 分区容错性Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择[3]。)

根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。

来自wiki:https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

  • 一致性:在分布式系统中数据往往存在多个副本,一致性描述的是这些副本中的数据在内容和组织上的一致。
  • 可用性:可用性描述了系统对用户的服务能力,所谓可用是指在用户容忍的时间范围内返回用户期望的结果。
  • 分区容错性:分布式系统通常由多个节点构成,由于网络是不可靠的,所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性,即网络分区,分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。

对于一个分布式系统而言,我们要始终假设网络是不可靠的,因此分区容错性是对一个分布式系统最基本的要求,我们的切入点更多的是尝试在可用性和一致性之间寻找一个平衡点,但这也并非要求我们在系统设计时一直建立在网络出现分区的前提之上,然后对一致性和可用性在选择时非此即彼。

传统对于 CAP 理论的理解认为在设计分布式系统时必须满足 P,然后在 C 和 A 之间进行取舍,这是片面的,实际中网络出现分区的可能性还是比较小的,尤其是目前网络环境正在变得越来越好,甚至许多系统都拥有专线的支撑,所以在网络未出现分区时,还是应该兼顾 A 和 C;另外就是对于一致性、可用性,以及分区容错性三者在度量上也应该有一个评定范围,最简单的以可用性来说,当有多少占比请求出现响应超时才可以被认为是不满足可用性,而不是一出现超时就认为是不可用的;最后我们需要考虑的一点就是分布式系统一般都是一个比较大且复杂的系统,我们应该从更小的粒度上对各个子系统进行评估和设计,而不是简单的从整体上武断决策。

分布式事务的实现并不是无解的,比如两阶段提交(2PC:Two-Phrase Commit)和三阶段提交(3PC:Three-Phrase Commit)都给我们提供了思路,但是如何保证数据的强一致性,并对外提供高可用的服务还是相当棘手的,因此很多分布式系统对于数据强一致性都敬而远之。

3. RSM

副本是一致性的最大敌人,一旦有了副本,就有可能出现副本间不同步的情况。异步写的方式顶多只能做到最终一致性,所以必须同步写。写主之后,同步完其它节点从才返回结果。不过写所有节点太慢了,而且挂掉节点时可用性有问题。

在raft出来之前,号称工业上唯一只有一种一致性协议的实现,就是paxos。然而paxos即难懂,又难实现。无论对于教育还是工程角度都它妈蛋疼的要死,还它妈的统治了业界这么多年。强势安利一波raft。

4. 其他

1、元数据怎么管理

etcd

2、数据复制, 日志复制, 有哪些实现方法呢?

做数据同步操作时,一般是找到快照点,将快照的数据发过去,之后再从放这个点之后的日志数据。回放日志就可以增量同步了,不过增量同步也有不爽的,中间断了太多就需要重新全量。最蛋疼的问题是,增量同步只能做最终一致性。主挂了切到从,丢一段时间的数据。

results matching ""

    No results matching ""