场景三分布式系统中的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。
如何看待补偿机制中用户感知受损的情况，后续揭秘。