zookeeper与分布式系统

1.1. 分布式系统基础知识

   一个tomcat打天下的时代，不能说彻底淘汰了，在一个管理系统，小型项目中还常用，这并不过度，出于成本的考虑，这反而值得提倡。

   

1.1.1.   分布式系统是什么

分布式系统：一个硬件或软件组件分布在不一样的网络计算机上，彼此之间仅仅经过消息传递进行通讯和协调的系统

 

这是分布式系统，在不一样的硬件，不一样的软件，不一样的网络，不一样的计算机上，仅仅经过消息来进行通信与协调

 

这是他的特色，更细致的看这些特色又能够有：分布性、对等性、并发性、缺少全局时钟、

故障随时会发生。

 

1.1.1.1. 分布性

既然是分布式系统，最显著的特色确定就是分布性，从简单来看，若是咱们作的是个电商项目，整个项目会分红不一样的功能，专业点就不一样的微服务，好比用户微服务，产品微服务，订单微服务，这些服务部署在不一样的tomcat中，不一样的服务器中，甚至不一样的集群中，整个架构都是分布在不一样的地方的，在空间上是随意的，并且随时会增长，删除服务器节点，这是第一个特性

1.1.1.2. 对等性

对等性是分布式设计的一个目标，仍是以电商网站为例，来讲明下什么是对等性，要完成一个分布式的系统架构，确定不是简单的把一个大的单一系统拆分红一个个微服务，而后部署在不一样的服务器集群就够了，其中拆分完成的每个微服务都有可能发现问题，而致使整个电商网站出现功能的丢失。

好比订单服务，为了防止订单服务出现问题，通常状况须要有一个备份，在订单服务出现问题的时候能顶替原来的订单服务。

这就要求这两个（或者2个以上）订单服务彻底是对等的，功能彻底是一致的，其实这就是一种服务副本的冗余。

还一种是数据副本的冗余，好比数据库，缓存等，都和上面说的订单服务同样，为了安全考虑须要有彻底同样的备份存在，这就是对等性的意思。

1.1.1.3. 并发性

并发性其实对咱们来讲并不模式，在学习多线程的时候已经或多或少学习过，多线程是并发的基础。

但如今咱们要接触的不是多线程的角度，而是更高一层，从多进程，多JVM的角度，例如在一个分布式系统中的多个节点，可能会并发地操做一些共享资源，如何准确并高效的协调分布式并发操做。

后面实战部分的分布式锁其实就是解决这问题的。

1.1.1.4. 缺少全局时钟

在分布式系统中，节点是可能反正任意位置的，而每一个位置，每一个节点都有本身的时间系统，所以在分布式系统中，很难定义两个事务纠结谁先谁后，缘由就是由于缺少一个全局的时钟序列进行控制，固然，如今这已经不是什么大问题了，已经有大把的时间服务器给系统调用

1.1.1.5. 故障随时会发生

任何一个节点均可能出现停电，死机等现象，服务器集群越多，出现故障的可能性就越大，随着集群数目的增长，出现故障甚至都会成为一种常态，怎么样保证在系统出现故障，而系统仍是正常的访问者是做为系统架构师应该考虑的。

 

1.1.2. 大型网站架构图回顾

知道什么是分布式系统，接下来具体来看下大型网站架构图，这个图在前面分布式架构演进应该已经讲过，首先整个架构分红不少个层，应用层，服务层，基础设施层与数据服务层，每一层都由若干节点组成，这是典型的分布式架构，后面一大把的时间就是系统的学习里面的每个部分

 

 

 

那么zookeeper在其中又是扮演什么角色呢，若是能够把zk扮演成交警的角色，而各个节点就是马路上的各类汽车（汽车，公交车），为了保证整个交通（系统）的可用性，zookeeper必须知道每一节点的健康状态（公交车是否出了问题，要派新的公交【服务注册与发现】），公路在上下班高峰是否拥堵，在某一条很窄的路上只容许单独一个方向的汽车经过【分布式锁】。

 

若是交通警察是交通系统的指挥官，而zookeeper就是各个节点组成分布式系统的指挥官。

 

1.1.2.1. 分布式系统协调“方法论”

 

1.1.2.1.1. 分布式系统带来的问题

若是把分布式系统和平时的交通系统进行对比，哪怕再稳健的交通系统也会有交通事故，分布式系统也有不少须要攻克的问题，好比：通信异常，网络分区，三态，节点故障等。

 

1.1.2.1.1.1. 通讯异常

通信异常其实就是网络异常，网络系统自己是不可靠的，因为分布式系统须要经过网络进行数据传输，网络光纤，路由器等硬件不免出现问题。只要网络出现问题，也就会影响消息的发送与接受过程，所以数据消息的丢失或者延长就会变得很是广泛。

1.1.2.1.1.2. 网络分区

网络分区，其实就是脑裂现象，原本有一个交通警察，来管理整个片区的交通状况，一切井井有理，忽然出现了停电，或者出现地震等天然灾难，某些道路接受不到交通警察的指令，可能在这种状况下，会出现一个零时工，片警零时来指挥交通。

 

但注意，原来的交通警察其实还在，只是通信系统中断了，这时候就会出现问题了，在同一个片区的道路上有不一样人在指挥，这样必然引擎交通的阻塞混乱。

 

这种因为种种问题致使同一个区域（分布式集群）有两个相互冲突的负责人的时候就会出现这种精神分裂的状况，在这里称为脑裂，也叫网络分区。

1.1.2.1.1.3. 三态

三态是什么？三态其实就是成功，与失败之外的第三种状态，固然，确定不叫变态，而叫超时态。

在一个jvm中，应用程序调用一个方法函数后会获得一个明确的相应，要么成功，要么失败，而在分布式系统中，虽然绝大多数状况下可以接受到成功或者失败的相应，但一旦网络出现异常，就很是有可能出现超时，当出现这样的超时现象，网络通信的发起方，是没法肯定请求是否成功处理的。

1.1.2.1.1.4. 节点故障

这个其实前面已经说过了，节点故障在分布式系统下是比较常见的问题，指的是组成服务器集群的节点会出现的宕机或“僵死”的现象，这种现象常常会发生。

 

1.1.2.1.2. CAP理论

前面花费了很大的篇幅来了解分布式的特色以及会碰到不少会让人头疼的问题，这些问题确定会有必定的理论思想来解决问题的。

接下来花点时间来谈谈这些理论，其中CAP和BASE理论是基础，也是面试的时候常常会问到的

 

首先看下CAP，CAP其实就是一致性，可用性，分区容错性这三个词的缩写

 

1.1.2.1.2.1. 一致性

一致性是事务ACID的一个特性【原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）】，学习数据库优化的时候deer老师讲过。

 

这里讲的一致性其实大同小异，只是如今考虑的是分布式环境中，仍是不单一的数据库。

 

在分布式系统中，一致性是数据在多个副本之间是否可以保证一致的特性，这里说的一致性和前面说的对等性其实差很少。若是可以在分布式系统中针对某一个数据项的变动成功执行后，全部用户均可以立刻读取到最新的值，那么这样的系统就被认为具备【强一致性】。

 

1.1.2.1.2.2. 可用性

可用性指系统提供服务必须一直处于可用状态，对于用户的操做请求老是可以在有限的时间内访问结果。

这里的重点是【有限的时间】和【返回结果】

为了作到有限的时间须要用到缓存，须要用到负载，这个时候服务器增长的节点是为性能考虑；

为了返回结果，须要考虑服务器主备，当主节点出现问题的时候须要备份的节点能最快的顶替上来，千万不能出现OutOfMemory或者其余500，404错误，不然这样的系统咱们会认为是不可用的。

1.1.2.1.2.3. 分区容错性

分布式系统在遇到任何网络分区故障的时候，仍然须要可以对外提供知足一致性和可用性的服务，除非是整个网络环境都发生了故障。

不能出现脑裂的状况

 

 

 

1.1.2.1.2.4. 具体描述

来看下CAP理论具体描述：

一个分布式系统不可能同时知足一致性、可用性和分区容错性这三个基本需求，最多只能同时知足其中的两项

 

 

 

TIPS：不可能把全部应用所有放到一个节点上，所以架构师的精力每每就花在怎么样根据业务场景在A和C直接寻求平衡；

1.1.2.1.3. BASE理论

根据前面的CAP理论，架构师应该从一致性和可用性之间找平衡，系统短期彻底不可用确定是不容许的，那么根据CAP理论，在分布式环境下必然也没法作到强一致性。

 

BASE理论：即便没法作到强一致性，但分布式系统能够根据本身的业务特色，采用适当的方式来使系统达到最终的一致性；

 

1.1.2.1.3.1. Basically Avaliable  基本可用

当分布式系统出现不可预见的故障时，容许损失部分可用性，保障系统的“基本可用”；体如今“时间上的损失”和“功能上的损失”；

e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理；

 

1.1.2.1.3.2. Soft state 软状态

其实就是前面讲到的三态,既容许系统中的数据存在中间状态，既系统的不一样节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性；

e.g：12306网站卖火车票，请求会进入排队队列；

1.1.2.1.3.3. Eventually consistent 最终一致性

全部的数据在通过一段时间的数据同步后，最终可以达到一个一致的状态；

e.g：理财产品首页充值总金额短时不一致；

 

1.2. Zookeeper简介

1.2.1. Zookeeper简介（what）

ZooKeeper致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力的分布式协调服务，是雅虎公司建立，是Google的Chubby一个开源的实现，也是Hadoop和Hbase的重要组件。

 

1.2.1.1. 设计目标

l 简单的数据结构：共享的树形结构，相似文件系统，存储于内存；

l 能够构建集群：避免单点故障，3-5台机器就能够组成集群，超过半数正常工做就能对外提供服务；

l 顺序访问：对于每一个读请求，zk会分配一个全局惟一的递增编号，利用这个特性能够实现高级协调服务；

l 高性能：基于内存操做，服务于非事务请求，适用于读操做为主的业务场景。3台zk集群能达到13w QPS；

 

1.2.2. 哪些常见须要用到ZK（why）

数据发布订阅

负载均衡

命名服务

Master选举

集群管理

配置管理

分布式队列

分布式锁

 

1.2.3. 为何要学习zookeeper？（why）

互联网架构师必备技能

高端岗位必考察的知识点

zk面试问题全解析

l Zookeeper是什么框架

l 应用场景

l Paxos算法& Zookeeper使用协议

l 选举算法和流程

l Zookeeper有哪几种节点类型

l Zookeeper对节点的watch监听通知是永久的吗？

l 部署方式？集群中的机器角色都有哪些？集群最少要几台机器

l 集群若是有3台机器，挂掉一台集群还能工做吗？挂掉两台呢？

l 集群支持动态添加机器吗？