分布式系统中的CAP、ACID、BASE概念
2024-09-01 14:59:26
CAP
分布式系统中，这三个特性只能满足其中两个。
- 一致性（Consistency）：分布式中一致性又分强一致性和弱一致性，强一致性主浊任何时刻任何节点看到的数据都是一样的，弱一致性一* * 般实现的是最终一致性。
- 可用性（Availability）：集群在任何时间内都正常使用
- 分区容错性（Partition Tolerance）：某一部分集群坏掉，另一部分仍能正常工作。
对于二选一模型
- CA模型，在分布式系统中不存在，因为舍弃P，意味着放弃分布式系统。比如单机版本的MySQL，如果MySQL考虑主备或集群部署时，它必须考虑P
- CP模型，舍弃了可用性，一定会读取到最新的数据，不会读取到旧数据。一是因为消息丢失、延迟过高发生了网络分区，就影响用户的体验和业务的可用性。例如Etcd，Consul和Hbase
- AP模型，舍弃了一致性，实现了服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误，但会读到旧数据。比如Cassandra 和 DynamoDB。
ACID
一致性强，但是伸缩性差
- 原子性（Atomicity）：要么全部完成，要么全部失败
- 一致性（Consistency）：事务开始和完成时，数据必须保持一致的状态，数据库的完整性约束没有被破坏。比如A给B转账，不论转账事务是否成功，两者存款的总额不变
- 隔离性（Isolation）：多个事务并发访问时，事务之间是隔离的，一个事务不能影响到其他事务的结果 ，不能看到其他事务运行时中间某个时刻的数据。
- 持久性（Durability）：事务完成后，该事务对数据库所作的更改便持久地保存在数据库中，并不会被回滚
关于二阶段提交协议和TCC
- 二阶段提交。
分成提交请求阶段（投票阶段）和提交执行阶段（完成阶段）。
第一个阶段，每个参与者投票表决事务是放弃还是提交
第二个阶段，事务的每个参与者都执行最终统一的决定 - TCC
Tty（预留）、Confirm（确认），Cancel（撤销）
核心思想是针对每一个操作都要注册一个与基对应的确认操作和补偿操作（撤销操作）
BASE
一致性弱，伸缩性强
基本可用（Basic Availability）：分布式系统出现故障时，允许损失部分可用性，保证核心可用。
软状态（Soft-state）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有3个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性(（Eventual Consistency）：指所有副本经过一定时间后，最终能达到一致的状态
ACID：大家在买同一本书的过程中，每个用户的购买请求都把库存锁住，等减完库存，把锁释放，后续的人才能进行购买。于是我们同是时间不可能有多个用户下单，订单流程要有排队的情况，这样就不能做出性能比较高的系统来
BASE：大家可以同时下单，这个时间不需要真正的去分配库存，然后系统异步地处理订单，而且是批量的处理。因为下单的时候没有扣减库存，所以有可能会有超卖的情况。而后台的系统在处理订单时，发现库没有了，才会告诉用户你没有购买成功。
BASE和ACID代表两种截然相反的设计理念，ACID注重一致性，是传统关系型数据库（MySQL）的设计思路，BASE关注高可用，大多数分布式事务适合BASE.
最新文章
- MySQL 相关总结
- iOS之UICollectionView详解
- linux 查看系统信息
- [16]APUE：套接字
- plsql修改表报错：ORA-25150
- 有向图寻找(一个)奇环 -- find an oddcycle in directed graph
- C#监控USB接口
- LoadRunner中web_custom_request 和 web_submit_data的差别
- HBase之表空间
- MVC linq To SQL更新数据库操作
- python杂记-5(装饰器)
- 利用PyCharm进行Python远程调试
- 每天一个linux命令(44)--ss命令
- iOS 上线因iPv6被拒，查询服务器是否支持iPv6，mac设置iPv6网络，手机测试iPv6
- 一张表搞清楚php is_null、empty、isset的区别
- web框架开发-Django的Forms组件
- python面向对象学习（二）基本语法
- Android studio新建文件出现setContentView(R.layout.activity_main);中的R标红错误解决方法
- gitbook editor教程
- 网页图表Highcharts实践教程之外层图表区