1.cap理论
1.单点故障(Single Point Failure)
是指在系统中某个组件一旦失效，这会让整个系统无法工作，而不出现单点故障，单点不影响整体，这就是分布式系统的设计目标之一
2.无状态
是因为无状态的服务才能满足部分机器宕机不影响全部，可以随时进行扩展的需求
一个分布式系统只能满足cap理论中的两个
一致性: “所有节点同事看到相同的数据” 即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，等同于所有节点拥有数据的最新版本
可用性: “任何时候，读写都是成功的” 即服务一直使用，而且是正常响应时间，比如系统稳定性已经做到3个9，4个9，即99.9%、99.99%，这里的N个9就是对可用性的一个描述，叫做SLA，即服务水平协议
分区容忍性: “当部分节点出现消息丢失或者分区故障时分布式系统仍然能够继续运行”即系统容忍网络出现分区 且在遇到某个节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务
在cap理论中无法同时满足三者。
反证: 假如分区容忍性存在，则可能某些网络节点出现故障，故会导致某些服务的数据读取不一致，未及时更新。
CP和AP架构的取舍：
CAP理论关注的是在绝对情况下
工程上，可用性和一致性并不是完全对立
我们关注的往往是如何保持相对一致性的前提下，提高系统的可用性
业务上对一致性的要求会直接反应在系统设计中，典型的就是CP和AP结构
CP架构: 放弃可用性，追求一致性和分区容错性
Zookeeper就是采用了CP一致性
Zookeeper是一个分布式的服务框架，主要是用来解决分布式集群中应用系统的协调和一致性问题
AP架构:放弃强一致性，追求分区容错性和可用性
Eureka是SpringCloud微服务技术栈中的服务发现组件
Eurela的各个节点都是平等的，几个节点挂掉不影响正常节点的工作
剩余的节点依旧可以提供注册和查询服务，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性
分布式事务是什么？
分布式事务关注的是分布式场景下如何处理事务
是指事务的参与者、支持事务操作的服务器、存储等资源分别位于分布式系统的不同节点之上
分布式事务是一个业务操作，是由多个细分操作完成的
而这些细分操作又分布在不同的服务器上
事务，是这些操作要么全部成功执行，要么全部不执行
数据库事务的特性：
分布式事务产生的原因:
分布式事务是伴随着系统拆分出现的
分布式系统解决了海量数据服务对扩展性的要求，但是增加了架构上的复杂性
分布式事务解决方案:
1) 2PC提交协议:
两阶段提交(2PC)是非常经典的强一致性、中心化的原子提交协议，在各种事务和一致性的解决方案中，都能看到两段提交的应用
2).3PC阶段提交
三阶段移交协议是在2PC之上扩展的提交协议
主要是为了解决两阶段提交协议的阻塞问题，从原来的两个阶段扩展为三个阶段，增加了超时机制
3).TCC分段提交
TCC是一个分布式事务的处理模型
将事务过程拆分为Try、Confirm/Cancel两个阶段
在保证强一致性的同时，最大限度提高系统的可伸缩性与可用性已知有如下4张表
若有收获，就点个赞吧
0 人点赞
