小明转账1000给小张：小明-=1000 => 小张+=1000，这个 （事务）是一个不可分割的整体，如果小明-1000后出现问题，那么1000得退给小明
C：一致性（Consistent）
小明转账1000给小张，必须保证小明+小张的总额不变（假设不受其他转账(事务)影响）
I：隔离性（Isolated）
小明转账给小张的同时，小潘也转钱给了小张，需要保证他们相互不影响（主要是并发情况下的隔离）
D：持久性（Durable）
小明转账给小张银行要有记录，即使以后扯皮也可以拉流水账【事务执行成功后进行的持久化（就算数据库之后挂了也能通过Log恢复）】
2.2.CAP概念CAP是分布式系统需要考虑的三个指标，数据共享只能满足两个而不可兼得：
C：一致性（Consistency）
所有节点访问同一份最新的数据副本（在分布式系统中的所有数据备份，在同一时刻是否同样的值）
eg:分布式系统里更新后，某个用户都应该读取最新值
A：可用性（Availability）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
eg:分布式系统里每个操作总能在一定时间内返回结果（超时不算【网购下单后一直等算啥？机房挂几个服务器也不影响】）
P：分区容错性（Partition Toleranc）
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
eg:分布式系统里，存在网络延迟（分区）的情况下依旧可以接受满足一致性和可用性的请求
CA代表：传统关系型数据库
如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果（会严重的影响系统的扩展性）
作为一个分布式系统，放弃P，即相当于放弃了分布式，一旦并发性很高，单机服务根本不能承受压力。像很多银行服务，确确实实就是舍弃了P，只用高性能的单台小型机保证服务可用性。（所有NoSQL数据库都是假设P是存在的）
CP代表：Zookeeper、Redis（分布式数据库、分布式锁）
相对于放弃“分区容错性“来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待数据一致（等待数据一致性期间系统无法对外提供服务）
AP代表：DNS数据库（IP和域名相互映射的分布式数据库，联想修改IP后为什么TTL需要10分钟左右保证所有解析生效）
反DNS查询：https://www.cnblogs.com/dunitian/p/5074773.html
放弃强一致，保证最终一致性。所有的NoSQL数据库都是介于CP和AP之间，尽量往AP靠，（传统关系型数据库注重数据一致性，而对海量数据的分布式处理来说可用性和分区容错性优先级高于数据一致性）eg：
不同数据对一致性要求是不一样的，eg：
用户评论、弹幕这些对一致性是不敏感的，很长时间不一致性都不影响用户体验
像商品价格等等你敢来个看看？对一致性是很高要求的，容忍度铁定低于10s，就算使用了缓存在订单里面价格也是最新的（平时注意下JD商品下面的缓存说明，JD尚且如此，其他的就不用说了）
传统关系型数据库一般都是使用悲观锁的方式，但是例如秒杀这类的场景是hou不动，这时候往往就使用乐观锁了（CAS机制，之前讲并发和锁的时候提过），上面也稍微提到了不同业务需求对一致性有不同要求而CAP不能同时满足，这边说说主要就两种：