场景三分布式系统中的CAP准则 CAP&Base 理论详情与案例分享

CAP理论详情

CAP原理

• 一致性（Consistency）
• 可用性（Availability）
  在集群中的一部分节点故障后，集群整体能否还能响应用户端的读写请求

• 分区容忍性（Partion-tolerance）
  分区容忍性可以了解为系统在存在网络分区的情况下依然可以接受请求
  CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个需求，三个要素中最多只能同时满足两点。
  Oracle系统是CA系统，没有分布式的支持
  MySQL主从同步是AP系统

  image.png

分布式数据系统

image.png

最终一致性

• 牺牲一致性，并不是完全不论数据的一致性，否则数据是混乱的
• 通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性
• “客户感知到的一致性”的时间窗口取决于数据复制到一致状态的时间
• 关系型数据库，要求升级过的数据能被后续的访问都能看到，这是强一致性

• 经过一段时间后要求能访问到升级后的数据，则是最终一致性

  image.png

分享案例

最终一致性概念初期，很多公司接受有困难，比方银行。
由于淘宝、支付宝的快速响应是假的，行为并未真正完成前就给客户进行了响应，客户感受为速度很快，但银行的系统是等到行为真正完成才给客户响应，所以客户感受系统很慢、体验很差，银行需要的是强一致性。
微信红包案例，一点抢红包，显示成功了，但是进入零钱后，有时候会发现零钱中红包没有到账，这就是一个最终一致性的案例。红包强调的是交互过程，对零钱到账的感知会弱少量。
订单系统，你下完订单后，会急切希望在自己的订单列表中看到订单，以避免重复下单，所以这个过程客户对一致性的感知时间会很短。

• CA系统很容易满足客户需求，单体架构

  image.png

• 系统演进1 系统拆分
  下单系统和查询订单系统的优先级是不一样的，下单系统优先级最高，查询订单系统优先级会低少量，允许降级解决。而把这两者放在一起会由于低优先级的系统拖累高优先级系统。
  我们需要进行优化，将不同优先级的系统进行隔离。

  image.png

• 系统演进2 存储拆分
  系统拆分后，两个系统依然使用同一个数据库，这也会造成低优先级的系统拖累高优先级系统，我们需要对数据库也进行独立拆分

  image.png

  数据库实现主从复制，mysql的主从复制是异步的，这样客户下单后立即查询可能会由于异步起因没法查询到最新的结果，怎样解决呢？

  image.png

• 系统演进3 同步调用
  从库的数据字段使用的少于主库的数据库字段，主从复制方式白费存储，我们需要使用其余的实现方式，好像步写精简字段

  image.png

  我们拆分的初衷是什么？将不同优先级的系统分开，避免拖累强优先级系统，然而这种同步调用的方式又将强优先级系统与弱优先级系统耦合在一起，势必会造成拖累，所以这种方案依然不可行。

• 系统演进4 同步调用 不关心结果
  通过MQ实现补偿机制

  image.png
  image.png

• 其余系统视角
  商家后端、库房系统对订单的强一致性要求会弱少量

  image.png

  问题MQ假如丢消息怎样解决？
  架构基点：
  我们所有的可用性都是基于MQ不会丢消息、MQ的消息可以及时送达，所以我们这个架构的基点就是我们信任MQ。
  如何看待补偿机制中客户感知受损的情况，后续揭秘。

（下午）

Base理论详情

Base原理

image.png

有损设计
目的：是保证大部分客户的访问体验。
100%是绝对不存在的，99.9%三个九已经是很不错的效果了。

微信摇一摇

微信摇一摇案例，现场讲解
每分钟200*2亿次调用，都放到服务端交互不显示，我们需要将一部分行为放在用户端进行解决

小结

image.png