文章目录
- 一、分布式
- 概念
- 分布式锁
- 二、Zookeeper
- 概念
- 数据模型
- 基本操作和事件通知
- Zookeeper的一致性
- 三、Docker
- 概念
- 四、K8S
- 概念
- 架构
一、分布式
概念
单机结构
集群结构
分布式结构
分布式结构(即微服务结构)
就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在分布式结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间通过RPC
方式通信。
分布式锁
-
多线程并发
情况下,如何保证一个代码块在同一时间只能由一个进程访问?
可用
锁
来保证。比如java的synchronized语法,可保证在同一个JVM进程内的多个线程同时执行
- 如果在分布式的集群环境
(多进程)
中,如何保证不同节点的线程同步执行?
这就需要用到
分布式锁
。实现有很多,比如Memcached分布式锁(add命令),Redis分布式锁(setnx命令),Zookeeper分布式锁
(顺序临时节点),Chubby(Paxos一致性算法)。
二、Zookeeper
概念
Zookeeper是一个
分布式协调服务
,可以在分布式系统中共享配置、协调锁资源、提供命名服务,服务注册和发现
数据模型
/
动物
猫
仓鼠
植物
荷花
松树
Zookeeper的数据模型很像数据结构当中的树,也很像文件系统的目录。
树是由节点所组成,Zookeeper的数据存储也同样是基于节点,这种节点叫做
Znode
。但是,不同于树的节点,Znode的引用方式是
路径引用
,类似于文件路径:/动物/仓鼠
包括
包括
包括
包括
Znode
data
ACL
child
Znode_1
Znode_2
stat
data:Znode存储的数据信息。
ACL:访问权限,即哪些人或哪些IP可以访问本节点。
child:当前节点的子节点引用,类似于二叉树的左右孩子。
stat:包含各种元数据,比如事务ID、版本号、时间戳、大小等等。
基本操作和事件通知
- Zookeeper提供了一些简单的API和触发器机制,下面列出常用API
create:创建节点
delete:删除节点
exists:判断节点是否存在
getData:获取一个节点的数据
setData:设置一个节点的数据
getChildren:获取一个节点下的所有子节点
- Zookeeper客户端在请求
读操作
(exists,getData,getChildren)的时候,可以选择是否设置Watch
,请求Watch的客户端会接收到异步通知
具体交互过程如下:
- 客户端调用getData方法,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。
- 当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。
Zookeeper的一致性
- 身为分布式系统协调服务,为了防止单机挂掉的情况,Zookeeper维护了一个集群
Server
Client_1
Client_2
Client_3
Zookeeper Service集群是
一主多从
结构。在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。
在读取数据时,直接读取任意从节点
- 为了保证主从节点的数据一致性,Zookeeper采用了
ZAB
协议,这种协议非常类似于一致性算法Paxos和Raft。
ZAB,即Zookeeper Atomic Broadcast. 有效解决了Zookeeper的集群崩溃恢复以及主从同步的问题
ZAB协议所定义的三种节点状态:
- Looking :选举状态。
- Following :Follower节点(从节点)所处的状态。
- Leading :Leader节点(主节点)所处状态。
最大ZXID
最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。
- ZAB的崩溃恢复分成三个阶段:
- Leader election:选举阶段。根据自己的服务器ID和最新事务ID向其他节点发起投票。若某个节点得到半数以上,则成为准leader,状态变为Leading。其他节点的状态变为Following。
- Discovery:发现阶段。用于在从节点中发现最新的ZXID和事务日志。这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。
- Synchronization:同步阶段。把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。自此,故障恢复正式完成。
- ZAB是如何实现写入数据的?
Leader Follower 1. Propose 2. ACK 3. Commit Leader Follower
Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的
单调一致性
。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。
- 客户端发出写入数据请求给任意Follower。
- Follower把写入数据请求转发给Leader。
- Leader采用二阶段提交方式,先发送Propose广播给Follower。
- Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。
- Leader接到
半数
以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。
三、Docker
概念
Docker
镜像`Image`
容器`Container`
仓库`Repository`
- 在容器技术之前,业界的网红是
虚拟机
。虚拟机技术的代表,是VMWare
和OpenStack
。 - Docker是一种轻量级的虚拟化的
容器技术
特性 | 虚拟机 | 容器 |
隔离级别 | 操作系统级 | 进程级 |
隔离策略 | Hypervisor | CGroups |
系统资源 | 5~15% | 0~5% |
启动时间 | 分钟级 | 秒级 |
镜像存储 | GB-TB | KB-MB |
集群规模 | 上百 | 上万 |
高可用策略 | 备份 容灾 迁移 | 弹性 负载 动态 |
- 需要注意,Docker本身并不是容器,它是
创建容器的工具
,是应用容器引擎
。
- Build, Ship and Run
- Build once,Run anywhere
四、K8S
概念
就在Docker容器技术被炒得热火朝天之时,大家发现,如果想要将Docker应用于具体的业务实现,是存在困难的——编排、管理和调度等各个方面,都不容易。于是,人们迫切需要一套管理系统,对Docker及容器进行更高级更灵活的管理。就在这个时候,K8S出现了。
- K8S,就是
基于容器的集群管理平台
,它的全称,是kubernetes。
Kubernetes 是一个自动化部署、伸缩和操作应用程序容器的开源平台。
使用 Kubernetes,你可以快速、高效地满足用户以下的需求:
- 快速精准地部署应用程序
- 即时伸缩你的应用程序
- 无缝展现新特征
- 限制硬件用量仅为所需资源
我们的目标是培育一个工具和组件的生态系统,以减缓在公有云或私有云中运行的程序的压力。
架构
一个K8S系统,通常称为一个K8S集群(Cluster)。这个集群主要包括两个部分:
一个Master节点(主节点)
一群Node节点(计算节点)