23 | 想成为架构师，你必须掌握的CAP细节

精选留言(44)

• 

  luop

  结合这两期对 CAP 的学习和思考，谈下个人的理解。
  
  设计分布式系统的两大初衷：横向扩展（scalability）和高可用性（availability）。“横向扩展”是为了解决单点瓶颈问题，进而保证高并发量下的「可用性」；“高可用性”是为了解决单点故障（SPOF）问题，进而保证部分节点故障时的「可用性」。由此可以看出，分布式系统的核心诉求就是「可用性」。这个「可用性」正是 CAP 中的 A：用户访问系统时，可以在合理的时间内得到合理的响应。
  
  为了保证「可用性」，一个分布式系统通常由多个节点组成。这些节点各自维护一份数据，但是不管用户访问到哪个节点，原则上都应该读取到相同的数据。为了达到这个效果，一个节点收到写入请求更新自己的数据后，必须将数据同步到其他节点，以保证各个节点的数据「一致性」。这个「一致性」正是 CAP 中的 C：用户访问系统时，可以读取到最近写入的数据。
  
  需要注意的是：CAP 并没有考虑数据同步的耗时，所以现实中的分布式系统，理论上无法保证任何时刻的绝对「一致性」；不同业务系统对上述耗时的敏感度不同。
  
  分布式系统中，节点之间的数据同步是基于网络的。由于网络本身固有的不可靠属性，极端情况下会出现网络不可用的情况，进而将网络两端的节点孤立开来，这就是所谓的“网络分区”现象。“网络分区”理论上是无法避免的，虽然实际发生的概率较低、时长较短。没有发生“网络分区”时，系统可以做到同时保证「一致性」和「可用性」。
  
  发生“网络分区”时，系统中多个节点的数据一定是不一致的，但是可以选择对用户表现出「一致性」，代价是牺牲「可用性」：将未能同步得到新数据的部分节点置为“不可用状态”，访问到这些节点的用户显然感知到系统是不可用的。发生“网络分区”时，系统也可以选择「可用性」，此时系统中各个节点都是可用的，只是返回给用户的数据是不一致的。这里的选择，就是 CAP 中的 P。
  
  分布式系统理论上一定会存在 P，所以理论上只能做到 CP 或 AP。如果套用 CAP 中离散的 C/A/P 的概念，理论上没有 P 的只可能是单点（子）系统，所以理论上可以做到 CA。但是单点（子）系统并不是分布式系统，所以其实并不在 CAP 理论的描述范围内。

  作者回复: 写的非常好👍👍

  2018-08-24

   1

   132
• 

  空档滑行

  一个电商网站核心模块有会员，订单，商品，支付，促销管理等。
  对于会员模块，包括登录，个人设置，个人订单，购物车，收藏夹等，这些模块保证AP，数据短时间不一致不影响使用。
  订单模块的下单付款扣减库存操作是整个系统的核心，我觉得CA都需要保证，在极端情况下牺牲P是可以的。
  商品模块的商品上下架和库存管理保证CP,搜索功能因为本身就不是实时性非常高的模块，所以保证AP就可以了。
  促销是短时间的数据不一致，结果就是优惠信息看不到，但是已有的优惠要保证可用，而且优惠可以提前预计算，所以可以保证AP
  现在大部分的电商网站对于支付这一块是独立的系统，或者使用第三方的支付宝，微信。其实CAP是由第三方来保证的，支付系统是一个对CAP要求极高的系统，C是必须要保证的，AP中A相对更重要，不能因为分区，导致所有人都不能支付
  

  作者回复: 分析思路很清晰

  2018-06-20

  

   39
• 

  飞

  独家解读啊，赞

  2018-06-19

  

   16
• 

  乘风

  老师 你上面说redis集群是互联且数据共享，但按官网上说redis集群后，每个主节点的数据是不一致的，也不存在共享数据，现在对cap中指的分布式系统(互联且数据共享)还是不太明白，谢谢老师

  作者回复: 这里的共享是指同一份数据在多个节点都有，但并不一定在所有节点都有，简单理解有数据复制的系统就是CAP应用的场景。
  
  一份数据在多个节点有但不是所有节点都有，这是非对称集群；例如ES
  所有数据在所有节点都有，这是对称集群，例如zookeeper

  2018-11-30

  

   6
• 

  文竹

  电商网站核心功能有用户、产品、订单、支付、库存，相应的数据有用户、产品、订单、支付、库存。
  
  对于用户数据，选择CP。因为用户注册后，可能几分钟后重新登录，所以需要满足一致性；在网络出现分区时，因为需要满足一致性而暂时不能提供写服务，所以无法满足可用性；对于分区容错性，只要能返回一个合理的响应就能满足，这一点能很好满足。
  
  对于产品数据，无需满足一致性，所以选择AP。
  对于订单数据，业务需要满足一致性，所以选择CP。
  对于支付数据，业务需要满足一致性，所以选择CP。
  对于库存数据，业务需要满足一致性，所以选择CP。
  

  作者回复: 思路很清晰👍👍

  2018-08-21

  

   5
• 

  feifei

  电商网站要做高可用架构，就必须先确定业务模块，我没有过电商的经验，就说说我的理解，电商主要有商品，用户，交易，这3快核心
  
  商品，商户发布某商品或者修改商品，用户查看商品，不需要非常强的一致性，即可以一部分用户先看到，可以使用最终一致性，满足可用性和容错性，可以使用发布队列，进行发布
  
  用户，有普通的用户，商户这2种用户，用户模块的功能都是注册和登录，需要保证一致性，不能出现用户注册成功了，却不能登录。为了将宕机影响控制在最小，以用户进行分布，针对单节点可以使用数据库的主从，从节点分担读压力
  
  交易，由于交易系统有强一致性要求，用户的交易要只能成功或者失败，有强事务的处理，考虑交易量大的问题，也按照用户进行分布，单节点采用数据库的集群，数据的多分写入
  
  这是我的一个初步设计，还请老师指点，谢谢

  作者回复: 大概思路就是这样，按照业务分析

  2018-06-20

  

   5
• 

  正是那朵玫瑰

  老师有个疑问，像电商这样的系统，有订单系统和库存系统，创建订单会调用库存系统，这两个系统是互联的，但是并没有数据共享，但超时的情况下，会造成订单数据和库存数据状态不一致，这种算不算cap讨论范畴呢？

  作者回复: 不算，CAP的应用范围已经明确了：互联，共享数据。
  这种情况下的不一致靠对账，人工修复等方式解决

  2018-08-25

  

   4
• 

  zhouwm

  CAP理论延时问题：因为延时无法避免意味着完美CP场景不存在。—— 这个说法有问题，一致性是从外部使用者的角度去看的（黑盒），只要在回复应答前保障数据已经同步到其他节点，后续请求能得到新数据就是一致的，etcd就是完美cp，zk其实也能算完美cp。延时问题是系统设计的时候要考虑的点

  作者回复: 不会的，zk是顺序一致性，保证不了完美cp，raft为了可理解而简化了异常处理，某些场景下会丢失数据

  2018-07-24

  

   4
• 

  Leon Wong

  我理解CA和CP不是系统的整体设计，而是具体业务点的设计权衡，一种tradeoff ，表现形式是分布式系统在检测到网络分区发生的时候，是倾向于一致性C或是可用性A。而CA对应到的场景是不考虑分区容错的场景，数据有可能在整个分布式系统里只存一份(如果引入多副本相当于引入分区问题)，那么就会有单点故障的风险，只能通过将数据分散存储在不同服务器的做法来降低风险的影响面。
  
  可见每一个设计都有优势，也有弊端，我们需要根据具体场景去做tradeoff……

  作者回复: 架构设计就是判断和选择😀

  2018-06-21

  

   4
• 

  王磊

  系统架构中考虑p和不考虑p，对外表现是什么?例如对于考虑p的系统，当p发生时，它还是functon的?发生分区意味着节点间不再联通，数据不再共享，要么为了c回复错误，此时丢了a; 要么为了a，但可能会返回过期数据，丢了c。所以考虑了p比没考虑p的系统到底带来额外什么好处?

  作者回复: 考虑P的系统在分区场景下还能提供部分业务

  2018-06-19

  

   4
• 

  zhouwm

  cap的c指的是线性一致性还是顺序一致性？如果把zk改成读写请求都通过master的话，是否就算完美CP了？因为延时对外不可见。raft在什么情况下丢数据，我理解的丢数据指的是给了请求者正确应答后，写入的数据没保存好，理论上不应该出现的（如果是磁盘缓存导致的，有可能），k8s之类的用etcd也是基于raft的，如果会丢数据都无法保证的话，坑有点大，应该不会有人用吧

  作者回复: CAP的C是严格意义上的绝对一致性，因为不考虑复制延时。
  
  zk全部走master就不符合CAP的CP定义了，因为CAP是要求各个节点都可以提供读写操作，而不是只做备份复制
  
  Raft论文中对于leader切换时可能覆盖日志给了一个详细的案例，这个案例不常见，发生概率非常小，而且只覆盖一条数据

  2018-07-31

  

   3
• 

  肖一林

  在开源的分布式系统中，通常可以让用户配置，选择是CP还是AP，比如kafka，每种消息都可以选择配置。这就是CAP理论对数据粒度的控制。老师归纳的非常好。

  作者回复: 掌握了理论，看具体各种系统实现就比较容易理解了

  2018-06-20

  

   3
• 

  xiao皮孩。。

  理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

  作者回复: 是的👍👍

  2019-04-02

   1

   2
• 

  我的名字叫浩仔丶

  老师，请教下P是什么时机才会触发分区呢？

  作者回复: 断网，网线断也可以，网卡坏也可以，交换机故障也可以

  2018-06-28

  

   2
• 

  godtrue

  电商系统，首先回想一下，我觉得涉及的东西相当庞杂，如果以是否对用户可见来划分，对用户可见的部分有账户管理、商品搜索管理、订单管理等，主要涉及用户登录，商品搜索列表页，商品详情页，商品结算页，商品支付页，订单列表页，订单详情页，售后商品页等。用户不可见的主要是商品的采购管理，商品的仓储管理，订单的物流管理，订单的退换货，订单的备件管理等，当然，还有秒杀、夺宝岛、时效等。根据CAP理论P不可避免，我们只能根据业务情况去权衡是选择C还是A，我觉得只要和钱不直接挂钩的为了系统的高可用性都会选择A，保证系统的可用性，数据一致性采用最终一致性，而和钱直接挂钩比如：支付，我觉得就应该选择C啦！即使提示支付失败牺牲点用户的体验，也不要造成用户的误会。
  不过，这些情况发生的概率比较小，可能我们的系统相对用户感知度小，经过几次大促都没有出现什么特别大的问题。如果有问题，我们也会保A的，系统都不可用了，那比出现可弥补的错误要严重的多。

  作者回复: 分析思路很好

  2019-08-30

  

   1
• 

  胖胖的程序猿

  怎么理解共享数据，假如A,B两个不同服务相连，并且公用同一个数据库表，这个是否算共享，是否算CAP范围。看上篇是要节点间发生数据复制情况才在cap范围，那一般是中间件系统才会有节点数据复制，web应用一般都不会有数据复制吧

  作者回复: 你说的这个不算，分布式节点通过复制来共享数据才算

  2019-04-03

  

   1
• 

  姜华梁taric

  老师，互联与共享数据，怎么理解，可以举一个实例嘛

  作者回复: memcache集群不互联不共享数据，redis集群互联且共享数据

  2018-11-19

  

   1
• 

  阿巍-豆夫

  老师，我一直很困惑，在cp的架构中，如果一旦发生分区，怎么保证c呢？ 连个节点网络都不可达了，怎么可能保证一致性呢？ ap我能理解为很好实现。

  作者回复: 直接不允许写，或者分区节点不提供服务，参考Paxos或者Zookeeper

  2018-09-19

  

   1
• 

  海军上校

  选择ap后，节点2如何感知到分区存在，然后返回错误的～不太懂

  作者回复: 心跳也可以，别人通知它也可以，取决于不同的架构方式，你看看高可用集群的架构模式

  2018-07-25

  

   1
• 

  jacy

  只从电商网站的核心业务分析，不考虑登录注册等业务，商品信息显示可细分为关键商品信息（如价格，库存）和非关键信息（商品介绍，用户评论），可按以前提到的分表分库的方法进行信息切割，对关键信息采用ca,非关键信息采用ap,最终达到base即可。

  作者回复: 思路正确，区分不同数据

  2018-06-27

  

   1