Zookeeper学习之分布式介绍

快来打我* 2024-04-18 16:19 54阅读 0赞

最开始的系统，由于用户量的稀少以及业务场景的简单，所以开始的时候，我们只需要一个系统，就可以满足我们的业务需求，同时，这样也可以减少节点以及成本；这种也被成为单一应用架构。

但是随着用户量以及业务复杂地的增长，很显然，在单一应用的情况下，单纯增加机器，也并不能很好的解决我们的问题，所以，将应用拆分为几个不同的应用，也就是分为了不同的业务线，这样就能很好的提高我们的效率。这就叫做垂直应用架构。

随着垂直应用的不断增多，系统交互也随之增多，我们又开始把核心业务独立出来（例如我们分离出来一个订单系统和一个用户系统，这样我们就不需要用户系统自己去查询订单表了，而是可以通过RPC来请求订单系统），逐渐形成稳定的服务中心，这也就是我们现在说的分布式服务架构。

# 什么是分布式 #

首先，我们要区分开几个概念，集群，分布式。

相同的项目，才叫集群；不同的项目，叫做分布式。

下面就是定义，也是市面上最广泛的一个定义：

> 分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。

这就相当于什么呢，就是在用户层面来说，我使用的只是一个系统，而并不知道这个可能是由多个系统组成的。

# 分布式挑战之Session #

虽然分布式看起来很好，但是也确实有个很大的问题摆在我们面前，那就是session怎么办？

由于是不同的服务器，所以，session是一个很大的问题，当然 聪明的人们也有着各种解决办法。

## 1、session粘滞 ##

使用Ngnix的IP\_Hash负载均衡，使得系统ip请求过来的都能落在一台服务器上，但是，一旦有服务器挂掉，就会导致Session过期。

## 2、Session复制 ##

将当前机器的session广播复制到所有机器上面，但是会带来一定的网络开销。

## 3、缓存集中处理 ##

将session保存至缓存中，例如Redis，当我们需要的时候，就去缓存中读取，开源方案：Spring Session；我们也可以自己实现，主要就是重写HttpServletRequrstWrapper中的getSession()

# 分布式挑战之数据一致性 #

从集中型应用架构改造为分布式架构我们要解决的很重要的一点，就是要保证数据的一致性！！！

CAP是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足以下3个属性：

> **一致性(Consistency)                  **： 客户端知道一系列的操作都会同时发生(生效)**（强一致性）**  
> **可用性(Availability)                     **： 每个操作都必须以可预期的响应结束（服务一致可用，且是正常响应时间）  
> **分区容错性(Partition tolerance)** ： 即使出现单个组件无法可用，操作依然可以完成（即使节点服务挂机，仍能保持整体                                                              系统正常运转）

下面我们来解释一下，为什么说无法同时满足这三个属性。

如果我们要求保证系统一致性，那么我们就很难保证可用性，因为我们在修改了一条记录之后，为了保证客户端请求集群中的其他项目，获得的数据能保持一致，相应的应用，就一定需要进行相关的操作，使得即使有请求进来，我们也暂时不能响应数据，而是要保证数据一致性后再响应。

所以C和A之间是无法共存的。

至于我们现实中是使用CP还是AP就是要看具体的应用场景了，对于金融支付方面，我们自然要保持数据的一致性，即使放弃可用性，但是对于其他的例如社交新闻媒体网站，即使稍微放弃一致性，也是没有太大的影响的。

CAP理论还有个延伸，那就是BASE理论，核心思想是在无法做到强一致性的前提下，但可以采用其他合适的方法，取得最终一致性。

有了理论，那我我们如何实现呢？

## 1、分布式事务 ##

例如，我们进行银行转账，假如中途出现异常，我们就必须保证我们的财产不会丢失，也就是此次转账事务回滚。

对于分布式事务也有了很多分布式事务框架以及理论。

**理论：**

> **1、两段式提交方案（2PC）**
> 
> 两阶段提交协议(Two Phase Commitment Protocol)中，涉及到两种角色：
> 
> 一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
> 
> 多个事务参与者（participants）：即本地事务执行者
> 
> 总共处理步骤有两个
> 
> （1）投票阶段（voting phase）：协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。参与者将告知协调者自己的决策：同意（事务参与者本地事务执行成功，但未提交）或取消（本地事务执行故障）；
> 
> （2）提交阶段（commit phase）：收到参与者的通知后，协调者再向参与者发出通知，根据反馈情况决定各参与者是否要提交还是回滚；
> 
> 如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的
> 
> **2、三段式提交方案（3PC）**
> 
> 三阶段提交协议就是两段式的升级版。
> 
> （1）发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
> 
> （2）事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
> 
> （3）响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
> 
> **3、TCC** 
> 
> 将事务提交分为 Try - Confirm - Cancel 3个操作。
> 
> 其和两阶段提交有点类似，Try为第一阶段，Confirm - Cancel为第二阶段，是一种应用层面侵入业务的两阶段提交。
> 
> **4、Zab协议**
> 
> ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议），又称一致性协议。
> 
> 这个是zookeeper使用的分布式协议，在以后的文章里面我可能会继续解释一下这个协议。

框架：Seata，也是我最近正在学习的一款分布式事务框架。

## 2、分布式锁 ##

分布式锁需要具备的条件：

> 1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；   
> 2、高可用的获取锁与释放锁；   
> 3、高性能的获取锁与释放锁；   
> 4、具备可重入特性；   
> 5、具备锁失效机制，防止死锁；   
> 6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们  “任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”

所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”**（BASE理论）**，只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证**一个方法在同一时间内只能被同一个线程执行**。

常见的实现分布式锁的方案分别有：

1、mysql

2、内存数据库（redis）

3、**zookeeper（唉，终于说到Zookeeper了）**

# **为什么要使用Zookeeper** #

由于单一应用拆分为分布式系统之后，系统的数据一致性我们就很难来保证，而zookeeper的诞生就可以帮助解决这一问题，同时zookeeper也可以用来解决分布式锁，定时任务等场景，所以自然Zookeeper就深受人们的喜爱了。