周大豆

分布式理论（CPA/BASE）和分布式服务Dubbo

分布式分为分布式缓存（Redis）、分布式锁（Redis 或 Zookeeper）、分布式服务（Dubbo 或 SpringCloud）、分布式服务协调（Zookeeper）、分布式消息队列（Kafka 、RabbitMq）、分布式 Session 、分布式事务、分布式搜索（Elasticsearch）等

今天主要就了解两个知识点：分布式理论（CAP/BASE）和分布式服务（Dubbo或者SpringCloud）

第一个问题：分布式有哪些理论？

CAP 理论

CAP 理论，任何一个分布式系统都无法同时满足 Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求。最多只能满足其中两项。而 Partition tolerance（分区容错性）是必须的，因此一般是 CP ，或者 AP。

C - Consistency

一致性是值写操作后读操作可以读到最新的数据状态,当数据分布在多个节点上时,从任意节点读取到的数据都是最新的.

A - Availability

可用性是指任何操作都可以得到响应的结果,且不会出现响应超时或响应错误。

P - Partition tolerance

分布式系统的各个节点部署在不同的子网中, 不可避免的会出现由于网络问题导致节点之间通信失败,此时仍可以对外提供服务, 这个就是分区容错性。

举例说明：有用户向N1发送了请求更改了数据，将数据库从V0更新成了V1。由于网络断开，所以N2数据库依然是V0，

如果这个时候有一个请求发给了N2，但是N2并没有办法可以直接给出最新的结果V1，这个时候该怎么办呢？

这个时候无法两种方法，一种是将错就错，将错误的V0数据返回给用户。第二种是阻塞等待，等待网络通信恢复，N2中

的数据更新之后再返回给用户。显然前者牺牲了一致性，后者牺牲了可用性。

舍弃A(可用性)，保留CP(一致性和分区容错性)

一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。

舍弃C(一致性)，保留AP(可用性和分区容错性)

这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。

舍弃P(分区容错性)，保留CA(一致性和可用性)

如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在的。

为什么会出现BASE理论

CAP定理只能三选二

CAP 理论表明，对于一个分布式系统而言，它是无法同时满足 Consistency(强一致性)、Availability(可用性) 和 Partition tolerance(分区容忍性) 这三个条件的，最多只能满足其中两个。

分区容错必须选

对于互联网来说，由于网络环境是不可信的，所以分区容错性（P）必须满足

为了用户体验，先选可用性

现在只能在一致性和可用性之间做选择，大部分情况下，大家都会选择牺牲一部分的一致性来保证可用性，因为你不返回给用户数据，这体验也太差了，宁可拒绝服务也不能说能访问却没有数据，当然，严格场景下，比如支付场景，强一致性是必须要满足，这另说。

但是放弃了一致性的系统又失去了存在的意义

好了，我们只能放弃一致性，但是我们真这样做了，将一致性放弃了，现在这个系统返回的数据你敢信吗？没有一致性，系统中的数据也就从根本上变得不可信了，那这数据拿来有什么用，那这个系统也就没有任何价值，根本没用。

如上所述，由于我们三者都无法抛弃，但CAP定理限制了我们三者无法同时满足，这种情况，我们会选择尽量靠近CAP定理，即尽量让C、A、P都满足，在此大势所趋下，出现了BASE定理。

BASE 理论

BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性

Basically Available(基本可用)：

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。

响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用看的搜索结果可能要1秒，2秒甚至3秒（超过3秒用户就接受不了了）

Soft state（软状态）：

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。

软状态是相对原子性来说的

原子性（硬状态） -> 要求多个节点的数据副本都是一致的,这是一种"硬状态"

软状态（弱状态） -> 允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟

Eventually consistent（最终一致性）：

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

弱一致性

和强一致性相对

系统并不保证连续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后， 不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会 尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。

BASE和ACID的区别与联系

参考ACID维基百科

ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

隔离性：数据库允许多个并发事务同时对齐数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

ACID是传统数据库常用的设计理念, 追求强一致性模型。

BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

ACID和BASE代表了两种截然相反的设计哲学。

总的来说，BASE 理论面向大型高可用可扩展的分布式系统，与ACID这种强一致性模型不同，常常是牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。虽然两者处于【一致性-可用性】分布图的两级，但两者并不是孤立的，对于分布式系统来说，往往依据业务的不同和使用的系统组件不同，而需要灵活的调整一致性要求，也因此，常常会组合使用ACID和BASE。

分布式服务（dubbo）

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

工作原理：

Provider：暴露服务方称之为“服务提供者”。

Consumer：调用远程服务方称之为“服务消费者”。

Registry：服务注册与发现的中心目录服务称之为“服务注册中心”。

Monitor：统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。

注册中心只是在服务提供者向注册中心提供某一个服务，然后当消费者提供需要某个请求的时候，注册中心在提交了的服务里面查找并返回给消费者，消费者拿到之后和提供者进行调用和业务逻辑的处理，注册中心只是扮演了一个传递的作用，并没有实质性的作用，具体的功能调用是消费者和服务提供者之间的互相作用和配合。

所以dubbo是Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。

所谓SOA也好，分布式服务框架也好，不是服务消费者从中间件（一般都是Zookeeper）上去拿数据，而是服务消费者从中间件上拿到可用的服务生产者的集群地址，再从集群地址中选出一个进行直连。

dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，不适合传输大数据量的服务比如文件、视频等，除非请求量很低。