1：分布式

分布式系统是多个处理机通过通信线路互联而构成的松散耦合的系统。从系统中某台处理机来看，其余的处理机和相应的资源都是远程的，只有它自己的资源才是本地的。至今，对分布式系统的定义尚未形成统一的见解。

一般认为，分布式系统应具有以下四个特征：

分布性

分布式系统由多台计算机组成，它们在地域上是分散的，可以散布在一个单位、一个城市、一个国家，甚至全球范围内。整个系统的功能是分散在各个节点上实现的，因而分布式系统具有数据处理的分布性。

自治性

分布式系统中的各个节点都包含自己的处理机和内存，各自具有独立的处理数据的功能。通常，彼此在地位上是平等的，无主次之分，既能自治地进行工作，又能利用共享的通信线路来传送信息，协调任务处理。

并行性

一个大的任务可以划分为若干个子任务，分别在不同的主机上执行。

全局性

分布式系统中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。同时，还应当有全局的保护机制。系统中所有机器上有统一的系统调用集合，它们必须适应分布式的环境。在所有CPU上运行同样的内核，使协调工作更加容易。

2 CAP定理

CAP 定理：在分布式系统中， Consistency、 Availability、Partition tolerance。在CAP中， C、 A二者不可兼得！

对于一个分布式系统来说，CAP三项只可能满足两项，即要么 CP 强一致性，要么 AP强可用性。对于分布式系统，出现网络分区是不可避免的，因此系统必须具备分区容错性。但其并不能同时保证一致性与可用性。

一致性（C）

分布式系统中多个主机之间是否能够保持数据一致的特性。

当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态。

可用性（A）

系统提供的服务必须一直处于可用的状态对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应。

分区容错性（P）

分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一致性和可 用性的服务。

抛开事实谈论点都是耍流氓。

3 常见服务CAP特性分析

1. MySQL是CP还是AP？

默认情况下：MySQL是单体

主从同步：

场景1：单点问题【容错】，读写(主)，从同步【既不是CP也不是AP】

场景2：数据并发能力，写(主)，读是在从【AP】

分库分表：扩容与性能优化

可C可A，至于需要C还是需要A，看具体需求

2. Redis是CP还是AP？

默认情况下：Redis单体

主从复制：可C可A，至于需要C还是需要A，看具体需求

Sentinel模式：哨兵模式与CAP没有一点关系

集群模式：扩容与性能优化

3. ElasticSearch是CP还是AP？

默认情况下：与生俱来支持分布式的，单体

既不是CP也不是AP：

前提是针对索引库来说，因为索引的数据【TB，分片10GB】并不需要共识

很多节点，ES内部服务列表【Naming List】，每个节点元数据一致性、可用性较高，低分区容错性系统【脑裂绝对是使用不当造成】

可C可A，至于需要C还是需要A，看具体需求

4. Nacos是CP还是AP？

默认是AP的，可以手动切换为CP！

数据：服务列表

5. Eureka是CP还是AP？

AP

数据：服务列表

6. Zookeeper 是CP还是AP？

CP

数据：目录

C --> A

4 BASE 理论

BASE是Basically Available、 Soft state和 Eventually consistent三个短语的简写。 BASE理论是分布式 系统中，CAP 定理对于一致性与可用性权衡的结果。

核心思想是：即使无法做到强一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系

统达到最终一致性。而且满足基本可用条件，及存在软状态的可能性。

1. Basically Available

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。响应时间的损失、功能上的损失读写不报错

2. Soft state

允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性

允许系统主机间进行数据同步的过程存在一定延时 其实就是一种灰度状态，过渡状态

3. Eventually consistent

强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。