<br/>

<div align="center">

<img src="pictures/芽.png"/>

<br>

<div align="center"> <a href = "https://blog.csdn.net/m0_37809146"> 欢迎关注我的博客：https://blog.csdn.net/m0_37809146</a> </div>

首先对于一个分布式系统而言，网络分区是不可避免的，不可能永远不出现网络故障，所以分区容错性 P 必须要保证。假设一个分布式系统中出现了网络分区，如下：

假设用户 1 向节点 1 上增加了 10 个数据，但节点 1 和节点 2 之间因为网络分区而无法进行数据同步，碰巧用户 2 此时发起了查询请求，此时有两种处理方案：

+ **保证 CP ，放弃 A**：这种情况下如果发生了网络分区故障，此时节点间的数据就无法同步。因此在故障修复前都需要放弃对外提供服务，直至网络恢复，数据到达一致为止。

+ **保证 AP ，放弃 C**：这种情况相当于放弃一致性。具体而言，是放弃数据的强一致性，但保证数据的最终一致性。因为不论是什么系统，数据最终都需要保持一致，否则整个系统就无法使用。在这种策略下，在某个短暂的时间窗口内会存在数据不一致的情况。

下图体现了 Docker 和传统虚拟化方式的差异：传统虚拟机技术是虚拟出一套硬件后，再在其上运行一个完整操作系统，之后可以在该系统上运行所需的应用进程；而 Docker 容器内的应用进程则是直接运行于宿主的内核，容器没有自己的内核，也没有进行硬件虚拟，因此要比传统虚拟机更为轻便。

Docker 使用 client-server 架构， Docker 客户端将命令发送给 Docker 守护进程，后者负责构建，运行和分发 Docker 容器。 Docker 客户端和守护程序使用 REST API，通过 UNIX 套接字或网络接口进行通信。核心概念如下：

Docker 提供了大量命令用于管理镜像、容器和服务，命令的统一使用格式为：`docker [OPTIONS] COMMAND` ，其中 OPTIONS 代表可选参数。需要注意的是 Docker 命令的执行一般都需要获取 root 权限，这是因为 Docker 的命令行工具 docker 与 docker daemon 是同一个二进制文件，docker daemon 负责接收并执行来自 docker 的命令，它的运行需要 root 权限。所有常用命令及其使用场景如下：

这里为了观察到启动效果，所以使用交互的方式启动，实际部署时可以使用`-d`参数来后台启动，输出如下：

HTTPS （Hyper Text Transfer Protocol over SecureSocket Layer，超文本传输安全协议）是在 HTTP 的基础上通过 SSL/TLS 层来进行传输加密和身份认证，从而保证通讯的安全性。除此之外它的报文结构、请求方法等都完全沿用 HTTP 原有的模式，因此可以很方便地将原有 HTTP 服务转换为 HTTPS 服务。

HTTPS 的公钥可以由任意的客户端持有，但私钥只能由服务器持有，因此所有经过公钥加密的数据只能由对应的服务器解密。

对称加密算法采用同一个密钥来进行信息的加密和解密，因此也被称为单密钥加密算法，其加解密速度都比较快。HTTPS 会在握手阶段采用非对称加密算法来生成对称加密所需的密钥，而之后的过程，因为要涉及到大量业务信息的传输，故都采用对称加密来提升性能。

HTTPS 会为需要传输的数据生成摘要信息，然后将经过会话密钥加密后的摘要和数据传送给服务器。服务器进行解密后，首先需要使用同样的摘要算法为数据生成摘要，并与客户端传送过来的摘要进行比较；如果一致，则证明数据没有被篡改。

由于非对称性加密比较耗时，因此只会对返回数据的摘要进行加密。当客户端收到服务器的响应时，首先尝试使用公钥对加密后的摘要进行解密，如果解密失败，则表示是其他伪装服务器返回的；如果解密成功，则继续对数据的完整性进行校验。

经过以上步骤，数据的传输已经相当安全了，但此时还是无法抵御中间人攻击：

简单来说，中间人攻击就是服务器传递给客户端的公钥可能被攻击者替换，进而丧失数据安全的一种攻击方式：

顶级的 CA 机构有 Symantec、Comodo、GeoTrust、DigiCert，但是通常它们并不支持给厂商颁发证书，而是授权给中间厂商，由中间厂商再颁发给应用厂商。从而形成 CA 认证链：

就 CA 证书类型而言，其分为以下三类：

通过点击浏览器上锁图标可以查看对应网站的证书状态，示例如下：

除了以上三种证书外，你还可以使用 Openssl 生成自签名证书，但由于自签名证书并不在整个认证链上，所以其通常不被浏览器所信任，访问时会出现以下警告：

以 `TLS v1.2` 版本中采用 ECDHE 算法的握手过程为例，其具体流程如下：

1. TLS/SSL 协议是基于 TCP/IP 协议的，因此需要先等待 TCP 三次握手完成；

5. 之后服务器还会发送一个 `Server Key Exchange` 消息，里面包含了进行 ECDHE 算法所需的各种参数 `Server Params` ：

​

6. 客户端按照密码套件的要求，也生成一个 `Client Params`，并通过 `Client Key Exchange` 消息发送给服务器；

​

12. 除此之外，服务器还会返回一个 `New Session Ticket` 消息，其内容如下：

打开位于 bin 目录下的 `jconsole` 程序后，它会自动扫描当前主机上的所有 JVM 进程：

选中需要监控的进程后，点击连接，即可进入监控界面。监控界面包含了 *概览*、*内存*、*线程*、*类*、*VM 概要*、*MBean* 六个选项卡。其中概览界面显示的是 *内存*、*线程*、*类* 等三个选项卡界面的概览信息，如下所示：

点击死锁选项卡则可以看到造成死锁的线程：

打开位于 bin 目录下的 `jvisualvm` 程序， 它会自动扫描当前主机上的所有 JVM 进程：

在线程界面可以查看所有线程的状态，如果出现死锁，该界面还会进行提示：

在 Profiler 界面，可以进行 CPU 和 内存的性能分析。要开始性能分析，需要先选择 **CPU** 或 **内存** 按钮中的一个，VisualVM 将会开始记录应用程序执行过的所有方法：如果是进行的是 CPU 执行时间分析，将会统计每个方法的执行次数、执行耗时；如果是内存分析，则会统计每个方法关联的对象数以及这些对象所占的空间。想要结束性能分析，点击停止按钮即可：

Visual GC 面板默认是不显示的，需要通过插件进行扩展。它会实时监控虚拟机的状态，在功能上类似于 jstat 命令：

在主界面，点击 **工具 => 插件** ，可以打开插件面板。右击插件选项或者点击安装按钮即可完成对应插件的安装：

之后在使用 VisualVM 进行远程连接时，配置如下：

需要注意的是这里的端口号是配置的 `Dcom.sun.management.jmxremote.port` 的值，而不是 Java 程序的端口号。连接完成后，即可查看到对应进程的监控状态。