CAP And Transaction

- **CAP**

一、概述

- CAP原则又称CAP定理，指的是在一个分布式系统中，**一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）**。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

一致性	可用性	分区容错性
在分布式系统中的所有数据备份，在同一时刻是否同样的值，即写操作之后的读操作，必须返回该值。（分为弱一致性、强一致性和最终一致性）	在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）	当分布式系统中因为一些原因导致无法通信而分成多个分区，系统还能正常对外服务，以实际效果而言，分区相当于对通信的时限要求。系统 如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前 操作在C和A之间做出选择。

二、取舍策略
CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

2.1、CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，**这是违背分布式系统设计的初衷的**，其实这时候整个系统也不能算是一个分布式系统了。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

2.2、CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

2.3、 AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

- **事务**

1.定义
- 事务就是用户定义的一系列数据库操作，这些操作可以视为一个完成的逻辑处理工作单元，要么全部执行，要么全部不执行，是不可分割的工作单元。

2.事务的四大特性--ACID

- ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性.所以ACID就是这四大特性的缩写。

- **原子性（Atomicity）**
 原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
- **一致性（Consistency）**
事务前后数据的完整性必须保持一致。
- **隔离性（Isolation）**
事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
- **持久性（Durability）**
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

- 3.事务的传播