大数据、人工智能、区块链、边缘打算、微做事 ，但是这么多前沿技能的底层全部依赖于分布式
分布式的核心：拆
微做事和分布式 的差异
横向拆分：jsp/servlet ， service，dao 在不同层面的拆分，纵向拆分：根据业务逻辑拆成独立的小项目
CAP理论任何一个分布式系统 都必须重点考虑的原则。
C:同等性（强同等性）：所有子节点中的数据 时候保持同等A：可用性：整体能用P:分区容错性 ：许可部分失落败CAP理论： 在任何分布式系统中，C\A\P不可能共存，只能存在两个。
根本知识： 一样平常而言，至少要担保P可行，由于分布式 常常会涌现 弱网环境。因此 就须要在C和A之间二选一。
举个例子：
当打算机A故障，分区容错性知足，如果同等性知足，那必须回滚，否则打算机B有数据，A没有，这样就不知够数据同等性。
BASE理论
BASE理论的目的： 为了填补CAP的不敷。
要理解的观点：
强同等性（时时刻刻同等、短韶光内同等）终极同等性（只要末了同等即可）软状态： 多个节点时，许可中间某个时候数据不一致。尽最大努力 近似的实现 CAP三者：终极同等性 代替强同等性C
BASE理论：首选知足A\P， 因此不能知足C。但是可以用 终极同等性 来代替C。
BASE：Basically Available 基本可用
分布式缓存缓请安题缓存击穿：某一个热点数据过期，造成大量用户要求直奔DB的征象。
办理:
监控线程提前设置好韶光，担保热点数据在 高峰期 不过期缓存雪崩：大量缓存全部失落效 （给大量缓存设置了相同的过期韶光 ; 缓存做事器故障）办理：
合理分配缓存的过期韶光搭建缓存集群缓存穿透：恶意攻击。一样平常而言，不会缓存一些无意义的数据。但是如果恶意工具，就可以利用一些无意义的数据 反复发起要求。办理：
将无意义的数据也进行缓存，并且将过期韶光设置的相对短一些。
以上的实质都是“缓存失落效”，通用的办理方案：二级缓存（分布式缓存）一样平常而言，本地缓存 是一级缓存，分布式缓存是二级缓存。
同等性hashhash算法：映射
字符串、图片、工具 转换为 数字
hash(a.png ) 转换为 12312313
同等性hash最初用于办理分布式缓请安题
以上 将 数据 映射到 某个缓存做事器的做法 有一个问题： 当做事器个数发生改变时，缓存会失落效。
办理“做事器个数改变导致的问题”：同等性hash
hash偏斜问题
办理hash倾斜问题：虚拟节点
在换上天生多个 虚拟节点，后续 要求先找虚拟节点，然后再通过虚拟节点找到对应的真实节点
缓存同等性
最随意马虎想到，但也不推举的做法： 当DB更新后，急速更新缓存 ； 先删除缓存，在更新DB。
推举： 当DB更新后，急速删除缓存
剖析：（反例）
当DB更新后，急速更新缓存（不推举）
问题：
如果线程A先更新，线程B后更新，终极的结果 可能是A的结果。缘故原由：线程的实行速率可能不一致。
推举： 当DB更新后，急速删除缓存 。由于：对付删除来说，没有速率的先后问题（没有速率不一致的问题）
（这种推举的办法，仍旧会存在 一个 极小概率 的缺点情形）
以上便是这个推举办法的一个缺点情形，但发生的概率是极小的：1.发生在“缓存失落效”的条件下 2.发生的条件：写线程的速率 要 快于 读线程，基本不可能。
问：这个 极小的缺点情形，能否避免？
答：能！
以上缺点发生的大条件：读操作 和写操作 交叉实行，办理思路：让二者 不要交叉。 加锁，或者读写分离。 但是一样平常建议，不用办理。
能否调换顺序：删除缓存 , 再DB更新后
反例：
以上出错的条件：写慢，读快。因此发生的概率较大。
分布式锁分布式锁：数据库的唯一约束、redis、Zookeeper
在架构开拓： 没有最好，只有比较得当的。
利用Zookeeper实现分布式锁zookeeper:分布式折衷框架， 组成构造是 一个颗树（类似于DOM树）
树种包含很多叶节点，在分布式锁中利用的 叶节点类型： 临时顺序节点。
zookeeper供应了以下两种支持：
监听器：可以监听某个节点的状态，当状态发生改变时 则触发相应的事宜临时节点的删除机遇：当客户端与访问的临时节点 断开连接时锁：同一个韶光内，只能有一个线程/进程访问
分布式事务
本地事务：一个事务对付一个数据库连接。（事务：连接 = 1： 1）
凡是不符合上述1:1关系的，都不能利用本地事务，举例如下（以下都无法利用本地事务）：
1.单节点中存在多个数据库实例。在本地 建立了2个数据库： 订单数据库、支付数据库。
下单操作 = 订单数据库+支付数据库
2.分布式系统中，支配在不同节点上的多个做事访问同一个数据库。
通过以上两点解释：本地事务的利用性 十分有限。
分布式事务实现示例
下单操作 = 订单数据库 +支付数据库做事器A： 下单操作 ， 订单数据库做事器B: 支付数据库仿照分布式事务：下单操作
begin transaction:
1.实行 订单数据库;
2.实行 支付数据库
commit/rollback ;
以上，在分布式环境中存在问题：
begin transaction:
1.在本地（做事器A） 实行 订单数据库;
2.远程调用做事器B上的 支付数据库
commit/rollback ;
以上的缺点情形：如果本地的订单做事 成功、远程的支付也成功，但是在 相应时由于网络等问题 无法相应，就会让用户以为 下单失落败。
以上，本地事务无法操作的情形，就可以利用分布式事务。
利用2PC实现分布式事务2pc：2 phase commit ，由一个折衷者 和多个 参与者组成 （类似master-slave构造）
折衷者： 事务管理器,TM
参与者： 资源管理器,RM
两阶段指的是：
准备阶段(Prepare阶段)：当事务开始时，折衷者向所有的参与者发送 Prepare，要求实行事务。参与者吸收到后，要么赞许，要么谢绝。如果赞许，就会在本地实行事务，记录日志，但是不提交。
提交阶段（commit阶段）：如果所有的参与者都赞许，折衷者再次给全部参与者发送 提交要求。否则进行回滚。
总体思路： 将一个任务（多个步骤） 进行2步操作： 1.要求各个节点实行 ； 2.如果大家都赞许，要求一起提交
2pc缺陷：1.分布式事务在实行期间是壅塞式的，因此会带来延迟 2.如果折衷在第“5”步碰着弱网环境，可能造成一部分节点 没有commit的情形。 3.中央化架构，单点灾害。
其他分布式事务办理方案：三阶段提交，利用TCC实现分布式事务，利用行列步队实现分布式事务
把稳：如果要严格的担保事务同等性：paxos算法。 google chubby作者
分布式认证 &分布式授权认证办法：系统自己开拓 、 三方平台
系统自己开拓：分布式认证
三方平台：分布式授权 （SSO单点认证）
分布式授权： OAuth2.0授权协议 ，该协议的流程如下：
提示：发展史上， OAuth2.0 不兼容 OAuth1.0
作者：长勺
原文链接：https://blog.csdn.net/qq_41620020/article/details/106010665
