分布式事务02 CAP定理

分布式事务 02 CAP定理

CAP

一句话概括

分布式系统中，网络故障、服务瘫痪仍然能保持数据的一致性

CAP

• Consistency（一致性）
  • 说明：写操作之后的读操作，必须返回该值
  • 情景：
    1. 举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。
    2. 用户的读操作就会得到 v1。这就叫一致性。
    3. 问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。
• Availability（可用性）
  • 说明：只要收到用户的请求，服务器就必须给出回应。（高可用）
  • 情景：用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。
• Partition tolerance（分区容错性）
  • 【分区】的定义：在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域,这就是分区。
  • 说明：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。
  • 情景：比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信:G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到.

CAP技术实现的困难

• CAP

  无法满足

  • 情景：整个系统由两个节点配合组成，之间通过网络通信，当节点 A 进行更新数据库操作的时候，需要同时更新节点 B 的数据库（这是一个原子的操作）。
  • 思考：
    • 上面这个系统怎么满足 CAP 呢？C：当节点A更新的时候，节点B也要更新，A：必须保证两个节点都是可用的，P：当节点 A,B 出现了网络分区，必须保证对外可用。
    • 可见，根本完成不了，只要出现了网络分区，A 就无法满足，因为节点 A 根本连接不上节点 B。如果强行满足 C 原子性，就必须停止服务运行，从而放弃可用性 C。

• CA

  • 满足原子和可用，放弃分区容错。说白了，就是一个整体的应用，不是分布式应用了。

• AP

  • 满足可用性和分区容错，当出现分区，同时为了保证可用性，必须让节点继续对外服务，这样必然导致失去原子性。

• CP

  • 满足原子和分区容错，也就是说，要放弃可用。当系统被分区，为了保证原子性，必须放弃可用性，让服务停用。

Zookeeper的CAP

Zookeeper是CP的：保证数据一致，牺牲可用性

• 情景：
  • client1注册给server1,server1同步给server2，server2作为leader广播给其他follower，只有整个过程都成功，client1才会收到注册成功的消息
  • leader重启或者网路故障，会导致重新选举leader,选举期间服务不可注册，牺牲了可用性
  • 整体选举成功，系统恢复注册，因此在复杂网络架构下，leader故障易引发雪崩，所以很多大型分布式系统可能不适合用Zookeeper

Eureka的CAP

Eureka是AP的：保证高可用，注册上就好

• 情景：
  • client1注册给server1,server1即返回给client1注册成功的提示，后续将同步其余server（均为异步的同步操作）

值得反思的面经

小火鸡，你的简历有dubbo/思博林可劳德的经验，说说CAP?

1. 什么是CAP定理， CAP技术有什么困难？
2. 什么是分区容错性？
3. zookeeper/eureka怎么实现的CAP(他们的CAP有什么区别)?
4. 你的项目、你的公司哪些项目AP？哪些CP?为啥?