CAP_写给自己看的

Consistency (一致性)

简单的说就是在分布式环境中，用于存储相同数据的多个节点中所保存的数据是否完全相同，如果完全相同就是一致，否则就是不一致。

• 白话: 多个节点都存储相同的数据,无论何时访问都返回相同的数据
• 例如: 数据库主从 强一致同步这种就可以看成强一致性

一致性的种类

• 强一致性 所有服务节点上的数据都是一致的
• 弱一致性 比如小明更新V0到V1,可以容忍小华读取的时候是V0
• 最终一致性 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。比如小明更新V0到V1，可以使得小华在一段时间之后读取的时候是V0。

业务场景一致性的触发的点

(这些场景都可以丰富出一些解决方案)
session一致性
DB主从一致性
DB双主一致性
DB与Cache一致性
数据冗余一致性
消息时序一致性
分布式事务一致性
库存扣减一致性
关于一致性的文章的解决方案如下链接

Availbility (可用性)

系统一直处于可用状态,每次请求都返回数据,而不是出错或超时的异常,但不保证获得的数据是最新的
如何实现可用性:

• 各节点的同步数据的时候,为保证可用性不能加锁,能容忍拿到的是旧数据也没事儿
• 哪怕旧数据也拿不到,给个兜底数据也行啊,就是别让系统出现超时或异常

Partition tolerance分区容错性

分布式系统一定有多个节点,节点这前有网络分区故障时,仍然能够对外提供 可用性 或一致性
(如果是一个分布式系统,分区容错性一定有的,否则系统就是单机版了)
白话: 网络出现分区,仍然能够提供服务 比如主库与从库之前同步,同步时出现了网络故障 各自仍然能够提供服务如果 你要一致性 你就得死等同步完了 才可以访问(舍可用性) 如果你要可用性,那你就得忍受主从数据不一致的苦恼
就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

场景

要PC舍A

即要分区容错性,一致性 而舍充可用性
这个通常是账务场景时要CP舍A 忍受强一制同步延时
比如 钱 ,商品数量,商品价格, 如果这些关键信息不保证一致性,而保证可用性,就会出现 不同时间访问的不同节点数据返回的值不同,特别是余额 这就大发了 ,你每次看支付宝的余额不同多要命啊
银行两个客户转账服务 A账户减100,B账户多100
try commit cancel 即TCC 在应用端开发三个接口保证强一制性
try–进入中间态 commit提交成功 cancel提交回滚 即要强一致性(最终一致性都不行必须是强一致性),而不是可用性

要PA舍C

• 即要分区容错性,可用性,舍充一致性
  12306,你看到的是还有一张票,你填好了信息准备买的时候发现系统提示你没票了 你点系统时,系统也没挂可用的,就是余票不太准即牺牲缓存与库之前同步的一致性,

• 发布一张网页到CDN，多个服务器有这张网页的副本。后来发现一-个错误，需要更新网页,这时只能每个服务器都更新一遍。一般说，网页的更新不是特别强调-致性。短时期内，-些用户拿到老版本，另一些用户拿到新版本，问题不会特别大。当然，所有人最终都会看到新版本。所以，这个场合就是可用性高于一致性。

链式

应用宕机 commit的后面的动作无法执行
rollback的后面的动作无法执行
数据库宕机 commit的后面的动作无法执行
rollback的后面的动作无法执行
即会产生事务一致性问题