分布式事务理论
business（下单）远程调用库存（storage）,保存订单（order），扣减积分（account），只有这三个步骤全部成功，我们的下订单才算成功。
如果是单体应用，我们将三处代码全部写在一个系统里面，而且我们全部连向的是一个数据库，这样的话我们使用本地事务就可以控制，只要有一个失败则全体回滚。
但是正是由于我们分布式系统的出现，由于我们业务太大，我们不可能将业务全写到一个系统里面，我们就拆分成了好多微服务，比如库存服务、订单服务、用户账户服务，而且每个服务还是连自己的数据库，操作自己的数据，还互相没有关系，
分布式系统之间部署还可能不在一块儿，库存服务在1号机器，订单服务在2号机器，用户账户服务在3号机器，这样我们想要完成下单逻辑，就需要远程调用这三个机器的各个方法，但由于我们分布式系统中经常会出现异常，
机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失…
分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。
分布式事务出现的原因，就是节点之间互相的状态不能同步，包括网络状况互相感知不到。
cap定理（cap和base都是理论）
CAP 原则又称 CAP 定理，指的是在一个分布式系统中
-
一致性（Consistency）：
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） -
可用性（Availability）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） -
分区容错性（Partition tolerance）
多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。
分区容错的意思是，区间（服务器之间）通信可能失败。
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
原因是：
123三台机器，我们让三个节点都保存a数据，这就满足了一致性
假设我们不是由于节点故障而是通信故障，13之间的网线断了，我们保存数据肯定只给某一个机器发了请求，1号机器让23同步，因为13之间网线断了，死活连不上，此时就发生了分区错误，
分区错误之后，假设我们想让它满足可用性，我们让3号机器恢复，比如我们负载均衡去3号机器读数据，但由于3号之前通信故障，数据没有同步过来，读到的数据自然就不一样了，所以一满足可用性就发现又不一致了。想要满足一致性，就必须让3号机器不能访问，不能访问就不可用了。所以一致性和可用性只能二选一。
在分布式系统中分区容错必须满足，因为网络肯定会出现问题；那么一致性与可用性就只能二选一，满足可用的话就得容忍业务能访问到不一致的数据，满足一致的话，就不能让整个集群可用了，如果让整个集群可用的话，数据就会不一致。
如何取舍
对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.99999%（N 个 9），即保证P 和 A，舍弃 C（一致性）。
base理论
是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。
BASE 是指
-
基本可用（Basically Available）
-
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
-
响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
-
功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
-
-
-
软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。 -
最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。 -
强一致性、弱一致性、最终一致性
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性
分布式事务解决方案
2PC
- 基于XA协议的两阶段提交(2PC)
- 二阶段提交2PC（Two phase Commit）是指，在分布式系统里，为了保证所有节点在进行事务提交时保持一致性的一种算法。
- 实现思路
有两个角色：协调者 和 参与者
（1）投票阶段：参与者将操作结果通知给协调者
（2）提交阶段：协调者收到参与者的通知后，根据参与者结果决定最终提交还是回滚
- 举例说明
甲 乙 丙 丁会议
- 缺陷：
1 强一致性
2 协调者单点故障问题
3 丢失消息
TCC
- TCC不是强一致性，保证最终一致性
本地消息表
- 执行流程：
- 订单系统，添加一条订单和一条消息，在一个事务里提交。
- 订单系统，使用定时任务轮询查询状态为未同步的消息表，发送到 MQ，如果发送失败，就重试发送。
- 库存系统，接收 MQ 消息，修改库存表，需要保证幂等操作。
- 如果修改成功，调用 RPC 接口修改订单系统消息表的状态为已完成或者直接删除这条消息。
- 如果修改失败，可以不做处理，等待重试。
- 订单系统中的消息有可能由于业务问题会一直重复发送，所以为了避免这种情况可以记录一下发送次数，当达到次数限制之后报警，人工接入处理；库存系统需要保证幂等，避免同一条消息被多次消费造成数据一致。
订单系统中的消息有可能由于业务问题会一直重复发送，所以为了避免这种情况可以记录一下发送次数，当达到次数限制之后报警，人工接入处理；库存系统需要保证幂等，避免同一条消息被多次消费造成数据一致。
todo 这篇文章的知识感觉需要重新消化或者整理感觉
第一，高端技术人才在适合的工作岗位，一定会显出他的价值来，然后在价值体系去评价他。我们可以设一个高端投诉平台，大家有问题就写邮件到这个平台，人力资源去听他倾诉，做成纪要报给有关部门帮助他调整。我们可以安排一些人际理解力强、熟悉华为流程、善于沟通、善于团结人的老员工，到导师部去听群众的声音，调节矛盾。
任正非
