前言
最近在工作之余看了一些分布式系统的博客和一点书本知识，从理论上了解了一些分布式系统的基本知识。给我最深的感觉就是所有的软件技术和架构都是随着业务的不断发展和底层技术的更新才有机会一步步的深入。特别是学习cap和base时，了解到分布式事务与传统DB事务ACID的区别（其实分布式事务和传统DB事务不是一个层面的东西但是感觉思想上还是有一些共同之处的）。现在的分布式系统也都是由最初的集中式系统一步步发展过来的。
在这里总结一下最近学的一些基础吧~~
集中式与分布式
很容易理解：
- 集中式：一台或多态住计算机组成中心节点，数据集中存储于中心节点上，并且系统所有的业务单元都集中部署在这个中心节点上，并在其上处理系统所有功能。
- 其实我的理解就是说所有的业务和逻辑都在这个中心节点上完成，其他的客户端就负责输入和输出就可以了。
- 分布式：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
- 这是经典的分布式著作《分布式系统概念与设计》中的定义。其实在我的理解里，就是把一个大的系统拆分成很多个业务模块，并部署在多台网络计算机上。就是把集中式的中心节点拆分为多个节点去完成单个中心节点的工作。
- 分布式系统的几个特点：
- 分布性：分布式系统的多个节点或者说多个模块在空间上是随意分布的。
- 对等性：系统模块的多个节点没有主从之分。其实这里我理解的没有主从之分并不是说完完全全没有主节点和从节点，而是在任何时候，如果有主节点，且主节点发生了不可用的情况下，能有一定的方法让别的节点去取代它，这样的话系统中就没有一个节点是所谓的特殊的，而所有的节点都是一样的可以互相替换的，这某种程度上应该就是分布式系统中的副本的概念。而副本的话应该是分为服务副本和数据副本的，因为服务和数据都可能会出现不可用的现象，所以必须要有副本去保持系统可用。
- 并发性：很好理解，分布式系统中程序的并发性操作和对数据的并发访问是很常见的。其实也因为并发性，如何做到高效准确也就成为了分布式系统的一个难题。
- 缺乏全局时钟：同样的，因为分布式系统部署在多台网络计算机上，由于网络的存在很难定义事务的先后顺序。也就是说分布式系统缺少全局的始终顺序控制。之前在学习的时候看到过分布式全局唯一ID可以解决部分问题，之后可以再看看总结一下。我目前了解的分布式全局ID的生成有UUID和SNOWFLAKE算法，但是具体的底层还不是很清楚。
- 故障总是会发生：分布式系统相较集中式系统更容易发生故障，且在系统设计时考虑到的西昌在实际中是一定会发生的，所以必须要解决。（当然，如果是业务或者需求允许的可以考虑一定程度的放宽。）
分布式系统的问题
进程或节点之间的通信异常
其实如在Zookeeper学习（一）中描述的一样，导致分布式系统通信异常的根本罪魁祸首就在于网络！因为网络本身就是不可靠的。与单机系统不同的是，由于分布式系统中网络通信的存在，会导致系统之间的调用存在相对较大的延迟（可达到内存访问延迟的百倍）。而且网络随时会出现波动的情况，因此消息丢失和延迟会变得很普遍。
网络分区
由于网络发生异常，导致分布式系统中部分节点之间的网络延时不断增大，导致所有节点中只有部分节点能互相正常通信，而其他的不能。这其实就是所谓的“脑裂”。最差的情况甚至会出现多个局部小集群的情况。
三态
三态即成功，失败，超时。
单机系统中调用服务成功失败很明显，但是在分布式系统中很明显，因为存在网络的因素，在调用服务失败的情况下可能并不一定是因为没有调用服务成功。
- 调用服务确实没有成功，网络请求没有发送到接收方。
- 调用服务成功，但是在返回响应时出现了消息丢失。
这时候就需要针对不同的业务进行处理了。结合我们之前做的业务，我们的系统中处理办法是回写时会让服务发送接收OK的标志，如果没有收到OK，那么就会一直发，因为回写的接收方在逻辑里支持删除不存在的元素（其实就是不删），只有收到了OK才会把回写的内容从Redis里删掉。这样就保证了回写一定会成功。
节点故障
很好理解，每一台机器都是会出问题的，如何保证在部分节点出现问题时整个系统仍然可用，是分布式系统里永恒不变的问题！
从ACID到CAP/BASE
ACID
ACID是传统数据库中事务的特征，即原子性，一致性，隔离性和持久性。
- 原子性：指事务必须是一个原子的操作单元。也就是说事务要么全部执行成功，要么不执行，如果执行过程中失败那么就回滚到最初的状态。
- 一致性：事务的执行不可以破坏数据库数据的完整性和一致性。也就是说事务在执行前后，数据库都必须处于一致性的状态。其实当初学数据库的时候一开始并不太理解为什么既然有原子性了，事务要么执行完要么不执行，为啥还会出现一致性的问题。后来才知道是因为多个事务并发执行的时候，很容易出现a事务做了x=1的操作，然后b事务又做了x=0的操作，就相当于b事务直接把a事务的操作给覆盖了，这就破坏了数据库的一致性。
- 隔离性：并发坏境中，事务是互相隔离的，一个事物的执行不能被其他事务干扰。这就是为了防止上面说的一致性的问题。而数据库里规定了4个隔离级别：
- 读未提交：会出现脏读，不可重复读，幻读问题。隔离级别最低。
- 读提交：解决脏读，但不可重复读，幻读还是会有。
- 可重复读：会存在幻读问题，但前两个问题不会有。
- 序列化：相当于事务顺序执行，不会有上述问题，但并发程度最低，效率也最低。
- mysql里利用了MVCC和锁的机制实现了隔离级别，但是这部分我也只是知道个大概，底层的实现原理还没有来得及深究，之前看了几篇博客记录下，之后深入学习Mysql的时候这部分要深入学习下。
- Mysql数据库事务的隔离级别和锁的实现原理分析
- [MySQL的四种事务隔离级别](https://www.cnblogs.com/huanongying/p/7021555.html)
- MySQL事务隔离级别的实现原理
- Mysql锁详解
- 持久性：一个事物一旦提交，它对数据库中对应数据的状态变更应该是永久性的。也就是说事务一旦成功结束，那么它对数据库所做的更新必须被永久保存下来。
CAP
CAP理论是针对分布式事务的一套理论。所谓分布式事务就是事物的参与者，支持十五的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务会涉及对多个数据源或业务系统的操作。
CAP指的是一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个基本要求，最多只能同时满足其中的两项。
- 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。也就是说，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然出于一致的状态。
- 分布式系统里，如果数据副本分布在不同分布式节点上，若对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应更新，那么如果系统是从第二个节点上读的数据，那么就会读到老数据，就出现了不一致的情况。
- 分布式系统的一致性和单机事务的一致性有很大的区别，之前自己一直能感觉到不一样但是很难用理论化的语言描述出来，ACID的C与CAP的C区别这篇博客介绍的非常非常好，可以看！！！
- 可用性：系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。有限的时间某种程度上指的是系统的反应时间不可以超过用户的忍耐程度，返回结果则值得是系统对于用户的请求必须要返回一个可以接受的结果。
- 分区容错性：分布式系统因为是依赖网络的，所以难免会出现遇到网络分区故障的时候，而这个时候仍然要保证能对外提供一致性和可用性的服务，除非整个网络瘫痪。
- 之前我一直分不清可用性和分区容错性的区别，感觉只要高可用了不就满足了容错性了么。。。但是参考了很多资料之后才发现分区容错性和可用性，一致性的关系更像是因果（不一定准确）的关系。正是因为分区的存在，所以在需要解决一致性和可用性的问题。
- CAP理论的P知乎上的这个回答是我认为解释的最通俗易懂的一篇。
- CAP里的P ，CAP, ACID ，分布式系统设计系列 -- 基本原理及高可用策略， 分布式CAP理论的理解， 这几篇都很好，可以参考。
BASE
BASE = Basically Available + Soft state + Eventually consistent。
- 基本可用：分布式系统出现不可预知故障时，允许损失部分可用性。
- 响应时间损失。0.5s-->2s
- 功能损失。双十一淘宝扛不住了把评论服务先降级掉。
- 弱状态：允许系统数据存在中间状态，并认为该中间状态的存在不会影响系统整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
- 最终一致性：系统中所有数据副本，在经过一段时间同步后，最终能打到一个一致的状态。
- 最终一致性实际上是一种特殊的弱一致性。
- 因果一致性（Casual Consistency）：A进程更新完后通知B，那么B对该数据项的访问应该能获取到A更新后的最新值，且B如果要更新该数据，必须基于进程A更新后的值。
- 读己写（Read you writes）：A更新一个数据向后，自己总是能访问到更新过的最新值。是一种特殊的因果一致性。
- 会话一致性（Session Consistency）：对系统数据的访问过程狂顶在一个绘画中，系统能保证在同一个有效的会话中实现Read your writes。即更新操作后，客户端能在同一个绘画中适中读取到该数据项的最新值。
- 单调读一致性（Monotonic read consistency）：如果一个进程从系统中读取出一个数据项的某一个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
- 单调写一致性（Monotonic write consistency）：一个系统需要能够保证同一个进程的写操作被顺序执行。
- 数据库的主备一般都采用最终一致性的策略。有两种方式去实现，即同步和异步。同步的方式就是事务完成后主备之间数据就会进行同步，异步的方式备数据库的更新会有一定时间的延迟，但是效率会更高一些。