ZooKeeper

一.集群与分布式

集群：将一个任务部署在多个服务器，每个服务器都独立完成该任务。列如：饭店后有三个厨师，它们每个人都会洗菜，切菜和炒菜，即使饭店同时来了很多客人也能轻松应对，这就是集群。

分布式：将一个任务拆分成若干个子任务，由若干个服务器分别完成这些子任务，每个服务器只能完成某个特地的子任务。例如：饭店后期由三个厨师，洗菜，切菜和炒菜三个子任务分别由每个人独立完成，一个洗菜，一个人切菜，一个炒菜，这就是分布式

从概念上就可以看出两者最主要的区别就是分布式是将一种业务拆分成多个子业务部署在多台服务器上，进而对外提供服务；而集群就是将多台服务器组合在一起提供同一种服务。

集群强调在多台服务器位置集中，并且容易统一管理；而分布式没有具体要求，不论放置在哪个位置，只要通过网络连接起来就行。
集群是一种物理形态，即多台服务器在一起提供一种服务；而分布式是一种工作方式，即一个程序或业务分解到多台服务器分别完成

二.技术架构演变

1.单一应用架构

单体应用就是将应用程序的所有功能都打成一个独立的单元，当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本

特点：

1.所有的功能集成在一个项目过程中

2.所有的功能打一个war包部署的服务器

3.应用与数据库分开部署

4.通过部署应用集群和数据库集群来提高系统的性能

优点

1.开发简单：一个IDE就可以快速构建单体应用

2.便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；

3.易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；

4.整个项目就一个 war 包，Tomcat 安装好之后，应用扔上去就行了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。

缺点

妨碍持续交付：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
不够灵活：随着项目的逐渐变大，整个开发流程的时间也会变得很长，即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
受技术栈限制：项目变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能；
可靠性差：某个环节出现了死循环，导致内存溢出，会影响整个项目挂掉；
伸缩性差：系统的扩容只能针对应用进行扩容，不能做到对某个功能进行扩容，扩容后必然带来资源浪费的问题；
技术债务：假设我的代码库中有一个混乱的模块结构。此时，我需要添加一个新功能。如果这个模块结构清晰，可能我只需要 2 天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以我需要 4 天时间。多出来的这两天就是债务利息。随着时间推移、人员变动，技术债务必然也会随之增多。

2.垂直架构

特点

1.以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分成一个一个单体结构项目；
2.项目与项目之间存在数据冗余，耦合性较大，比如上图中三个项目都存在用户信息；
3.项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点

1.开发成本低，架构简单；
2.避免单体应用的无限扩大；
3.系统拆分实现了流量分担，解决了并发问题；
4.可以针对不同系统进行扩容、优化；
5.方便水平扩展，负载均衡，容错率提高；
6.不同的项目可采用不同的技术；
7.系统间相互独立。

缺点

1.系统之间相互调用，如果某个系统的端口或者 IP 地址发生改变，调用系统需要手动变更；
2.垂直架构中相同逻辑代码需要不断的复制，不能复用；
3.系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3.SOA 面向服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

特点

1.基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务；
2.各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信；
3.使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。

优点

1.将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性；
2.可以针对不同服务的特点制定集群及优化方案；
3.采用 ESB 减少系统中的接口耦合。

缺点

1.系统与服务的界限模糊，不利于开发及维护；
2.虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护；
3.抽取的服务的粒度过大，系统与服务之间耦合性高；
4.涉及多种中间件，对开发人员技术栈要求高；
5.服务关系复杂，运维、测试部署困难。

4.微服务架构

特点

1.将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务；
2.微服务中每一个服务都对应唯一的业务能力，遵循单一原则；
3.微服务之间采用 RESTful 等轻量协议传输。

优点

1.团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
2.技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
3.前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
4.数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
5.服务拆分粒度更细，有利于资源重复利用，提高开发效率；
6.一个团队的新成员能够更快投入生产；
7.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
8.可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
9.适用于互联网时代，产品迭代周期更短。

缺点

1.微服务过多，服务治理成本高，不利于系统维护；
2.分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
3.微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
4.多服务运维难度，随着服务的增加，运维的压力也在增大；
5.测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。

三.CAP

     如今，对于多数大型互联网应用，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。
     解决了分区容错性，随之而来又产生了新的问题，那就是如何在保证了数据安全（一致，不易丢失）的同时，又让我们的分布式环境满足可用性呢？这就是著名的 CAP 原则。

      CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定理。CAP 三者不可兼得。

** 1.取舍策略**

CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。

CP without A：如果不要求 A（可用），相当于每个请求都需要在服务器之间保持强一致，而 P（分区）会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库。对于分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP without C：要高可用并允许分区，则需放弃一致性。一旦产生分区，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

2.Base理论

   CAP 理论已经提出好多年了，难道真的没有办法解决这个问题吗？也许可以做些改变。比如 C 不必使用那么强的一致性，可以先将数据存起来，稍后再更新，实现所谓的 “最终一致性”。

   这个思路又是一个庞大的问题，同时也引出了第二个理论 BASE 理论。

BASE：全称 Basically Available（基本可用），Soft state（软状态），和 Eventually consistent（最终一致性）三个短语的缩写，来自ebay 的架构师提出。

BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

2.1Basically Available（基本可用）

  基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）。需要注意的是，基本可用绝不等价于系统不可用。

1.响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
2.功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

2.2Soft state（软状态）

     软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本数据同步的延时就是软状态的体现。

2.3 Eventually consistent（最终一致性）

    系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。

四.数据的一致性

强一致性：要求无论更新操作实在哪一个副本执行，之后所有的读操作都要能获得最新的数据。
弱一致性：用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。
最终一致性：是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。

五.Paxos算法

Paxos算法是Leslie Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。
Paxos在1990年提出，被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的
Paxos算法解决的问题是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。
传统节点间通信存在着两种通讯模型：共享内存（Shared memory）、消息传递（Messages passing），Paxos是一个基于消息传递的一致性算法。

1.Paxos算法-拜占庭将军问题