「这是我参与11月更文挑战的第1天，活动详情查看：2021最后一次更文挑战」。
前言
事务对于我们程序来说至关重要，我们应该去理解掌握它，而不是在工作项目中添加一个
@Transaction注解就草草了事。
事务是什么？
大白话就是在做一件事情的时候要么一路到底，一条道走到黑，最后成功。在成功之前任意一个环节出错了，就得重头再来，之前的所有记录都要清除不作数。不要对我下一次去做这件事产生影响。这让我想起了我们小时候玩的小霸王游戏机的游戏。死了就得重头来过，没有读档，所以导致很多游戏也没能打通关。扯远了，回到正题。官方点的定义：事务是以一种可靠的、一致的方式，访问和操作数据库的程序单元
事务四原则
- Atomicity
原子性 - 最小执行单元，要么执行，要么不执行 - Consistency
一致性 - 能量守恒，总量不变 - Isolation
隔离性 - 信息彼此独立，互补干扰 - Durability
持久性 - 不会轻易丢失
CAP定理
- Consistency 一致性
- Availability 可用性
- Partition tolerance 容错性
Consistency 一致性
当我们部署了两个相同的服务节点来缓解压力的时候，就必须要考虑数据存储在不同的服务节点上时要保证数据的一致，不然就会导致，每次访问不同的节点会的得到不一样的结果。
Availability 可用性
不管是哪个服务节点，在收到客户端请求后，必须在合理的时间内做出响应。
Partition tolerance 容错性
- 当服务出现故障时，也必须正常提供服务。
- 所以我们可以通过添加多个服务节点，做负载均衡，一个服务挂掉了，另一个顶上去。 那么问题来了，多个节点下要满足一致性C，资源在做同步的时候就需要锁定服务资源，此事服务必然不可用。这是就无法做到可用性A在合理的时间内给出响应。两者必然互斥。
如何取舍？
线上的项目，容错性P是必须要保证的，无法避免，那么我们只能可用性A和一致性C中进行取舍。在分布式系统中通常可用性A高于一致性C
分布式通常都是满足AP原则，所以会导致一致性难题。
分布式事务是解决一致性的一种解决方案，通常是保证“最终一致性”
一致性分类
- 强一致性 - 数据必须完全一致，中间过程不可见，同步完成
- 弱一致性 - 允许部分一致性，中间过程可见，异步完成
- 最终一致性 - 过一段时间后，保证数据完全一致
总结
分布式系统不可能
100%保证一致性，都只是尽可能的保证成功率
