分布式系统基础知识（二）

桃扇骨 2021-12-16 05:43 429阅读 0赞

一、**一致性（以数据为中心）**：

一致性模型实质是进程和数据存储之间的一个约定，在没有全局时钟的情况下，在执行读操作要返回最后一次写操作之后的结果，是十分困难的。

1、严格一致性：

任意读操作都要读到最新写结果。依赖于绝对的全局时钟，分布式系统中实现这种模型代价过大，实际系统运用有限基本不能做到。

2、持续一致性：

3、顺序一致性

4、因果一致性

5、入口一致性

二、一致性（以客户为中心）

客户只关心数据最终是否会一致，如果最终一致那就是一致的。

以客户为中心的一致性分为以下几类：

1、单调读一致性：

意思就是说你用A进程读取一个文件的时候，那么你换一个B进程在读取的时候也要读到该文件之前的样子或者更新的版本

2、单调写一致性：

和单调读类似的，就是你在写一个文件的时候，然后做了进程的切换，你要保证写操作必须要传播到新的进程上，还拒还来说就是要在任何地方至少和上一次写一样新的数据。

3、读写一致性：

是说进程对数据X的写操作，进程无论到任何副本上都应该能被后续读操作看到这个写操作的影响，也就是说，写操作总是在同一个进程执行的后续读操作之前完成，而不管这个后续读操作发生在什么位置。

4、写读一致性：

就是读操作后面的写操作基于至少和上一次读出来一样新的值。

三、容错性

分布式系统区别于集中式系统的一个特性是它容许部分失效。

容错一可靠的系统紧密相关，可靠的系统需要满足以下需求：

可用性： 系统在给定时刻可以正确的工作。

可靠性： 指系统可以无故障的连续运行。

安全性：指系统在出现故障的情况下能正确操作而不会造成任何灾难。

可维护性：发生故障的系统被维护的难易程度。

容错意味着系统发生了故障，还能正常提供服务。

故障分类：

暂时故障：只发生一次，然后消失，不在重复该故障。

间歇故障：发生，消失不见，在发生，如此反复

持久故障：直到故障组件被修复之前持续存在的故障

分布式系统典型故障模式：

崩溃性故障：服务器停机，但是在停机之前工作正常。

遗漏性故障：服务器不能响应到来的请求：1、服务器不能接收到来的消息2、服务器不能发送消息。

定时性故障：服务器对请求响应的过快或者过慢。

响应性故障：服务器对请求以错误的方式进行了响应。

任意性故障：服务器可能在任意的时间产生任意类型的故障。

使用冗余来掩盖故障：

如果系统是容错的，它能做的最好的事情就是对其他进程隐藏故障的发生，关键技术是使用冗余来掩盖故障、又三种可能：信息冗余、时间冗余、物理冗余。

信息冗余：添加额外的位，可以使得错乱的位恢复正常，

时间冗余：执行一个动作，如果需要就再次执行。使用事务就是这种方法的一个例子，如果一个事务终止，那么它就可以无害的重新执行，TCP/IP协议中的重传机制也是一个例子。

物理冗余：通过添加额外的装备或者进程使系统作为一个整体来容忍部分组件的失效或故障成为可能。

分布式提交：

在分布式系统中，事务往往包含多个参与者的活动，单个参与者的活动是能够保证原子性的，而保证多个参与者之间原子性则需要通过两阶段提交或者三阶段提交算法实现。

a、两阶段提交（2PC）：

2PC过程涉及协调者和参与者。协调者可以看做事务的发起者，同时也是事务的一个参与者，对于一个分布式事务来说，一个事务是涉及多个参与者的，2PC具体过程如下：

第一阶段【准备阶段】：

\-1、协调者节点向所有的参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应；

\-2、参与者节点执行所有事务操作，并将所有Undo信息和Redo信息写入日志【注意：若成功这里其实每个参与者已经执行了事务操作】；

\-3、各参与者节点响应响应协调者发起的询问，如果参与者节点的事务操作实际执行成功，则它返回一个”统一消息“，如果参与者节点的事务操作执行失败，则它返回一个”中止“消息。

第二阶段【提交阶段】：

如果协调者收到参与者的失败消息或者超时，直接给每个参与者发送回滚消息【Rollback】；否则发送提交【Commit】信息；参与者根据提交者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源【注意：必须在最后阶段释放所资源】。

⭕️、当协调者节点从所有参与者节点处获得的响应消息都为”同意“的时候：

\--1、协调者节点向所有参与者节点发出”正式提交“的请求；

\--2、参与者节点正式完成操作，并释放在整个事务期间内占用的资源；

\--3、参与者节点向协调者节点发送”完成“消息。

⭕️、如果任意参与者节点在第一阶段返回的响应消息为”中止“，或者协调者节点在第一阶段的询问在超时之前无法获取所有参与者节点的响应消息时：

\--1、协调者节点向所有参与者节点发送”回滚操作【rollback】“的请求；

\--2、参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源；

\--3、参与者节点向协调者节点发送”回滚完成“的消息；

\--4、协调者节点收到所有参与者节点反馈的”回滚完成“消息后，取消事务；

\--5、协调者节点收到所有参与者节点反馈的”完成“消息，完成事务。

不管最后结果如何，第二阶段都会结束当前事务。

2PC优缺点如下：

【优点】：原理简单，实现方便；

【缺点】：**同步阻塞问题**。执行过程中，所有参与节点都是事务阻塞型的。**单点故障。**由于协调者的重要性一旦协调者发生故障，参与者会一直阻塞下去，尤其在第二阶段，如果协调者故障，那么所有的参与者都还处于锁定事务资源的状态中，而无法继续完成事务操作。**数据不一致**。在阶段二中，当协调者向参与者发送commit请求后，发生局部网络故障，或者发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了commit请求，而在这部分参与者接收到commit请求后就会执行commit操作，但是其他未接到commit消息的则无法执行事务提交，于是整个分布式系统出现了数据不一致的问题。**两阶段无法解决的问题**。协调者在发出commit之后宕机，那么及时协调者通过选举协议选出了新的协调者，这条事务的状态也是不确定的，没有人知道事务是否被已经提交。

为了解决如上的问题提出了三阶段提交\---------------------------------------------------------------------------------------------------------------

b、三阶段提交【3PC】：

2PC的升级版本，改动点如下：

引入超时机制，在协调者和参与者中都引入超时机制；

在一二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与者节点的状态是一致的【也就是将2PC的准备阶段再次拆分为「CanCommit、PreCommit」】。

所以3PC变成了这样-----【CanCommit 、PreCommit  、 DoCommit】。

CanCommit阶段：

CanCommit阶段其实和2PC的准备阶段很像，协调者向参与者发送commit请求，参与者如果可以提交就返回Yes，否则返回No。

⭕️、事务询问：协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，然后开始等待参与者的响应。

⭕️、响应反馈：参与者接受到CanCommit请求后，正常情况下认为自身可以执行顺利执行事务，则返回Yes，否则返回No。

PreCommit阶段：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70][]

doCommit阶段：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 2][]

c、Paxos算法

四、CAP理论：  
            CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

CAP常见模型：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 3][]

2、牺牲可用（CP模型）

牺牲可用意味着一旦系统中出现分区这样的错误，系统直接就停止服务。

CP模型常见的例子：

分布式数据库，分布式锁定、绝大部分协议；

实现方式：悲观锁、少数分区不可用。

3、牺牲一致性（AP模型）

AP模型常见例子：Coda、Web缓存、DNS；

实现方式：到期/租赁、解决冲突、乐观。

CAP的意义：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 4][]

CAP最新进展：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 5][]

五、安全

计算机的安全性包括：认证和访问控制两个部分。

安全机制包括：加密、身份验证、授权、审计。

加密是计算机的基础，加密将数据转换为一种攻击者不能理解的形式，身份验证用于检验用户、客户服务器等所申明的身份。对一个客户进行身份验证之后，有必要检查是否授予客户执行请求操作的权限。审计工具用于追踪各个客户的访问内容以及访问形式。

密码与数字签名：

加密包括使用密钥对数据进行编码，从而使偷听者无法方便的阅读这些数据，经过加密的数据称为密文，原始的数据称为明文，从密文到明文的过程称为解密。

加密算法：

如果利用可用资源进行系统分析后无法攻破系统，那么这种加密算法是计算安全的。

目前有两种常用的加密类型：私钥加密和公钥加密。除了加密整条消息，两种加密类型都可以用来对一个文档进行数字签名。使用足够长的密钥密码被破解的难度就会越大，系统也就越安全，但是解密的成本也会很高。

1、对称加密：

指的是加密和解密算法都使用相同密钥的加密算法。该算法特点就是算法公开、计算体量小、加密速度快、加密效率高，不足之处就是双方使用相同的密钥安全性得不到保证。

常见的对称加密算法：DES、3DES、TDEA、BlowFish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等。

2、使用对称密钥加密的数字签名：

有两种对文档进行数字签名的基本方法：a、利用私钥加密法：数字签名也称为消息摘要或数字摘要，它是一个唯一对应一个消息或者文本的固定长度的值。由单向Hash加密函数作用而成。保证了消息的完整性，消息摘要采用单向Hash函数将加密的明文摘要成一串128bit的密文。这一串密文称为数字指纹。

消息摘要算法：MD2、MD4、MD5、SHA-1、SHA-256、RIPEMD128、RIPEMD160等。

3、非对称加密(公钥加密)：

非对称加密由两个密钥组成：包括公开密钥【公钥】和私有密钥【私钥】。如果消息使用公钥加密，那么需要使用相应的私钥才可以解密这些信息。如果信息使用私钥加密那么通过使用其对应的公钥解密这些信息。

非对称加密安全性更好，缺点是加密和解密花费时间长、速度慢、只适合对少量数据加密。

非对称加密算法主要有： RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法。）

安全通道：

1、SSL/TLS

SSL【Secure Sockets Layer，安全套接字层】实在网络上应用最广泛的加密协议实现，SSL使用结合加密过程来提供网络的安全通信。

SSL 提供了一个安全的增强标准TCP/IP套接字用于网络通信协议。在标准的TCP/IP协议栈的传输层和应用层之间添加了安全套接字层。SSL应用程序中最常用的是HTTP，这个是网络网页协议。

2、SSL握手过程

只验证服务器的SSL握手过程，验证服务器和客户端的SSL握手过程，恢复原有会话的SSL握手过程。

3、HTTPS

基于SSL安全连接的HTTP协议。

4、在Tomcat中配置SSL/TLS 以支持HTTPS

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 7][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 8][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 9][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 10][]

5、SSL VPN

SSLVPN 是以SSL为基础的VPN技术。

访问控制：

访问控制是指按用户身份及其所归属的某项定义组来限制用户对某些信息项的访问，活限制对某些控制功能的使用的一项技术。

访问控制的功能：

防止非法的主体进入受保护的网络资源；

允许合法用户访问受保护的网络资源；

防止合法的用户对受保护的网络资源进行非授权的访问。

**防火墙**：

防火墙指的是一个由软件和硬件设备组合而成在内部网和外部网之间、专用网和公用网之间的界面上构造的保护屏障。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 11][]

**堡垒机**：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 12][]

拒绝服务：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 13][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 14][]

**访问控制的模型**：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 15][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70]: /images/20211214/9f7f41ecb28142d2b0c34c36757f28dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 1]: /images/20211214/3501ed2eabb14c6e8ef50f78027b1f2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 2]: /images/20211214/ccc699c9920f4bc6934c332e0cf22c0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 3]: /images/20211214/50d4a9019d2747519e6f1d90b66683bb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 4]: /images/20211214/2615243b2b094ff7a60329819456c3d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 5]: /images/20211214/510f0c9f3b49456da491b741203fbc41.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 6]: /images/20211214/d17c59f262ce418bb7bdf0bc89288a91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 7]: /images/20211214/48201357aff746fcb2a5a54b06f2607e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 8]: /images/20211214/a925651e701942fdbf0dcd0b2139b37a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 9]: /images/20211214/3bc034c6439b445b8c6b9dc4e28ae607.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 10]: /images/20211214/98b87abd85204b1087dfacf9ebc367b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 11]: /images/20211214/330499bad766401ab04bfefa665fad1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 12]: /images/20211214/d4e094a1c71c478ca68d7d4fbf34dfbf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 13]: /images/20211214/08e58f44a6c14cb7b08a6d1dabfc889e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 14]: /images/20211214/dcbfd14a73f14452937e9717dc53b9ab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lhbmd6YWlMZUhlSGU_size_16_color_FFFFFF_t_70 15]: /images/20211214/1aac8ba452e44036b68827364b8d3f85.png