分布式基础概念

集群、分布式、SOA、微服务的概念及区别

集群：

不同服务器部署同一套应用服务对外提供访问，实现服务的负载均衡或者互备(热备，主从等)，指同一种组件的多个实例，形成的逻辑上的整体。单个节点可以提供完整服务。集群是物理形态

分布式：

服务的不同模块部署在不同的服务器上，单个节点不能提供完整服务，需要多节点协调提供服务(也可以是相同组件部署在不同节点、但节点间通过交换信息协作提供服务)，分布式强调的是工作方式

SOA:

面向服务的架构，一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用

• 中心化实现：ESB(企业服务总线)，各服务通过 ESB 进行交互，解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。很重，有一定的逻辑，可以解决一些公用逻辑的问题

• 去中心化实现：微服务

微服务：

微服务：在 SOA 上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成

服务单一职责

轻量级通信：去掉 ESB 总线，采用 restapi 通信

简述 CAP 理论

• 数据一致性(consistency)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency)

• 服务可用性(availability)：所有读写请求在一定时间内得到响应，可终止、不会一直等待

• 分区容错性(partition-tolerance)：在网络分区的情况下，被分隔的节点仍能正常对外服务

如果选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

反证：

如果 CAP 三者可同时满足，由于允许 P 的存在，则一定存在节点之间的丢包，如此则不能保证 C

因为允许分区容错，写操作可能在节点 1 上成功，在节点 2 上失败，这时候对于 Client 1 (读取节点 1)和 Client 2(读取节点 2)，就会读取到不一致的值，出现不一致的情况。如果要保持一致性，写操作必须同时失败，也就是降低系统的可用性。

简述 Base 理论

cap 理论的一种妥协，由于 cap 只能二取其一，base 理论降低了发生分区容错时对可用性和一致性的要求

1. 基本可用：允许可用性降低（可能响应延长、可能服务降级），

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

3. 最终一致性：节点数据同步可以存在时延），但在一定的期限后必须达成数据的一致，状态变为最终状态

数据一致性模型有哪些

强一致性：

当更新操作完成之后，任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。

弱一致性：

系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间，我们称这段时间为“不一致性窗口”

最终一致性：

最终一致性是弱一致性的特例，强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。到达最终一致性的时间，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

最终一致性模型根据其提供的不同保证可以划分为更多的模型，包括因果一致性和会话一致性等。

因果一致性：

要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。

进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程 A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值。

在微博或者微信进行评论的时候，比如你在朋友圈发了一张照片，朋友给你评论了，而你对朋友的评论进行了回复，这条朋友圈的显示中，你的回复必须在朋友之后，这是一个因果关系，而其他没有因果关系的数据，可以允许不一致。

会话一致性：

将对系统数据的访问过程框定在了一个会话当中，约定了系统能保证在同一个有效的会话中实现“读己之所写”的一致性，就是在你的一次访问中，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。实际开发中有分布式的 Session 一致性问题，可以认为是会话一致性的一个应用。

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或关注微信公众号【码上遇见你】。