update 中间件之Zookeeper

Author: leelovejava

README.md

@@ -491,30 +491,55 @@
 
 - [114、实施灰度发布的时候，网关是可以灰度了，可是Dubbo服务如何进行灰度呢？](/docs/03/114.md)
 
-- [115、除了常见服务注册中心之外，你觉得Redis能作为服务注册中心吗?以及怎么做？]()
-
-- [116、你能不能说说SSO单点登录常见的技术方案,到底如何实现多个系统的单点登录？]()
+- [115、除了常见服务注册中心之外，你觉得Redis能作为服务注册中心吗?以及怎么做？](/docs/03/115.md)
 
 ### 中间件系统 
-- [117、在2020年的技术行业里,怎么可能没有各种中间件系统的面试连环炮？]()
 
-- [118、别光说Zookeeper那么浅显的东西,说说你对它整体架构设计的理解？]()
+- [116、我们一般到底用ZooKeeper来干什么事儿？](/docs/03/116.md)
+
+- [117、有哪些开源的分布式系统中使用了ZooKeeper？](/docs/03/117.md)
+
+- [118、为什么我们在分布式系统架构中需要使用 ZooKeeper 集群？](/docs/03/118.md)
+
+- [119、ZooKeeper为了满足分布式系统的需求要有哪些特点？](/docs/03/119.md)
+
+- [120、为了满足分布式系统的需求，ZooKeeper的架构设计有哪些特点？](/docs/03/120.md)
+
+- [121、ZooKeeper集群的三种角色：Leader、Follower、Observer](/docs/03/121.md)
+
+- [122、客户端与ZooKeeper之间的长连接和会话是什么？](/docs/03/122.md)
+
+- [123、ZooKeeper的数据模型：znode和节点类型](/docs/03/123.md)
+
+- [124、ZooKeeper最核心的一个机制：Watcher监听回调](/docs/03/124.md)
+
+- [125、一个关键的问题：zk到底通过什么协议在集群间进行数据一致性同步？](/docs/03/125.md)
+
+- [126、ZAB的核心思想介绍：主从同步机制和崩溃恢复机制](/docs/03/126.md)
+
+- [127、从zk集群启动到数据同步再到崩溃恢复的ZAB协议流程](/docs/03/127.md)
+
+- [128、采用了2PC两阶段提交思想的ZAB消息广播流程](/docs/03/128.md)
+
+- [129、停一下脚步：ZooKeeper到底是强一致性还是最终一致性？](/docs/03/129.md)
+
+- [130、ZAB协议下一种可能存在的数据一致性问题](/docs/03/130.md)
 
-- [119、那我接着问问,Zookeeper在作为服务注册中心的时候,是强一致性的吗？]()
+- [131、崩溃恢复时选举出来的Leader是如何跟其他Follower进行同步的？](/docs/03/131.md)
 
-- [120、Zookeeper会把你写进去的数据存储在磁盘上吗?它是怎么存储的？]()
+- [132、对于需要丢弃的消息是如何在ZAB协议中进行处理的？](/docs/03/132.md)
 
-- [121、你们系统有哪些定时任务?如何用多台机器执行大量的定时任务？]()
+- [133、现在再来看看ZooKeeper的Observer节点是用来干什么的？](/docs/03/133.md)
 
-- [122、你了解过Quartz定时任务技术如何在集群中执行的吗？]()
+- [134、ZooKeeper为什么只能是小集群部署？为什么适合读多写少场景？](/docs/03/134.md)
 
-- [123、你了解过很流行的ElasticJob吗?它是如何实现分布式任务调度的？]()
+- [135、一清二楚：再次回头对ZooKeeper特性的总结](/docs/03/135.md)
 
 ### 系统架构优化与设计
 
-- [124、一个身经百战的互联网面试官,对高并发、高可用与高性能会发出什么样的连环炮？]()
+- [136、一个身经百战的互联网面试官的系统设计优化连环炮发问！](/docs/03/136.md)
 
-- [125、说说高并发场景下的数据库连接池应该如何进行优化？]()
+- [137、说说高并发场景下的数据库连接池应该如何进行优化？](/docs/03/137.md)
 
 ### 开源框架
 

docs/03/115.md

@@ -0,0 +1,13 @@
+# 115、除了常见服务注册中心之外，你觉得Redis能作为服务注册中心吗？
+
+![redis作为服务注册中心](images/115/01.png)
+
+redis里的hash数据结构，类似map的数据结构
+
+ 
+
+约定好，你的服务注册的key都是：service_ORDER，service_PRODUCT，scan扫描指定的前缀开头的所有的key，一次性把注册表里的几十个到几百个服务都给扫描出来，获取到一个完整的注册表
+
+ 
+
+基于Redis还可以做分布式服务注册中心，Redis Cluster，做一个集群

docs/03/116.md

@@ -0,0 +1,58 @@
+# 116、我们一般到底用ZooKeeper来干什么事儿？
+ZooKeeper顶尖高手课程：从实战到源码
+
+ 
+
+Kafka里面大量使用了ZooKeeper进行元数据管理、Master选举、分布式协调，Canal也是一样，ZooKeeper进行元数据管理，Master选举实现HA主备切换
+
+ 
+
+HDFS，HA也是基于ZK来做的
+
+ 
+
+6周的，zk核心原理，zk集群部署、运维和管理，zk实战开发，zk在hdfs、kafka、canal源码中的运用的分析，两周的时间研究zk的核心的内核源码和底层原理
+
+ 
+
+《001_我们一般到底用ZooKeeper来干什么事儿？》
+
+ 
+
+Java架构的课，分布式架构中，分布式锁，Redis分布式锁，ZooKeeper分布式锁
+
+ 
+
+分布式锁：运用于分布式的Java业务系统中
+
+ 
+
+元数据管理：Kafka、Canal，本身都是分布式架构，分布式集群在运行，本身他需要一个地方集中式的存储和管理分布式集群的核心元数据，所以他们都选择把核心元数据放在zookeeper中的
+
+ 
+
+分布式协调：如果有人对zk中的数据做了变更，然后zk会反过来去通知其他监听这个数据的人，告诉别人这个数据变更了，kafka有多个broker，多个broker会竞争成为一个controller的角色
+
+ 
+
+如果作为controller的broker挂掉了，此时他在zk里注册的一个节点会消失，其他broker瞬间会被zk反向通知这个事情，继续竞争成为新的controller
+
+ 
+
+这个就是非常经典的一个分布式协调的场景，有一个数据，一个broker注册了一个数据，其他broker监听这个数据
+
+ 
+
+Master选举 -> HA架构
+
+ 
+
+HDFS，NameNode HA架构，部署主备两个NameNode，只有一个人可以通过zk选举成为Master，另外一个backup
+
+ 
+
+Canal，HA
+
+ 
+
+ZooKeeper，分布式协调系统，封装了分布式架构中所有核心和主流的需求和功能，分布式锁、分布式集群的集中式元数据存储、Master选举、分布式协调和通知

docs/03/117.md

@@ -0,0 +1,62 @@
+# 117、有哪些开源的分布式系统中使用了ZooKeeper
+Canal、Kafka、HDFS，学习过的这些技术都用了ZooKeeper，元数据管理，Master选举
+
+ 
+
+ZooKeeper，他主要是提供哪些功能，满足哪些需求，使用在哪些场景下，最后一句话总结，ZooKeeper到底是为什么而生的，定位是什么？
+
+ 
+
+三类系统
+
+ 
+
+第一类：分布式Java业务系统，分布式电商平台，大部分的Java开发的互联网平台，或者是传统架构系统，都是分布式Java业务系统，Dubbo、Spring Cloud把系统拆分成很多的服务或者是子系统，大家协调工作，完成最终的功能
+
+ 
+
+ZooKeeper，用的比较少，分布式锁的功能，而且很多人会选择用Redis分布式锁
+
+ 
+
+第二类：开源的分布式系统
+
+ 
+
+Dubbo，HBase，HDFS，Kafka，Canal，Storm，Solr
+
+ 
+
+分布式集群的集中式元数据存储、Master选举实现HA架构、分布式协调和通知
+
+ 
+
+Dubbo：ZooKeeper作为注册中心，分布式集群的集中式元数据存储
+
+HBase：分布式集群的集中式元数据存储
+
+HDFS：Master选举实现HA架构
+
+Kafka：分布式集群的集中式元数据存储，分布式协调和通知
+
+Canal：分布式集群的集中式元数据存储，Master选举实现HA架构
+
+ 
+
+第三类：自研的分布式系统
+
+ 
+
+HDFS，面向的超大文件，切割成一个一个的小块儿，分布式存储在一个大的集群里
+
+ 
+
+分布式海量小文件系统：NameNode的HA架构，仿照HDFS的NameNode的HA架构，做主备两个NameNode，进行数据同步，然后自动基于zk进行热切换
+
+ 
+
+在很多，如果你自己研发类似的一些分布式系统，都可以考虑，你是否需要一个地方集中式存储分布式集群的元数据？是否需要一个东西辅助你进行Master选举实现HA架构？进行分布式协调通知？
+
+ 
+
+如果你在自研分布式系统的时候，有类似的需求，那么就可以考虑引入ZooKeeper来满足你的需求

docs/03/118.md

@@ -0,0 +1,36 @@
+# 118、为什么我们在分布式系统架构中需要使用 ZooKeeper 集群？
+ZooKeeper，功能和定位，满足的需求
+
+使用ZooKeeper去满足自己需求的项目都有哪些
+
+ 
+
+分布式集群的集中式元数据存储，Master选举实现HA架构，分布式协调和通知
+
+ 
+
+我们写一个类似ZK的系统，单机版本，就是部署在一台机器上面，里面提供了一些功能，比如说允许你在里面存储一些元数据，支持你进行Master选举，支持你分布式协调和通知，也可以做到
+
+ 
+
+单机版本的系统，万一挂掉了怎么办？
+
+ 
+
+集群部署，部署一个集群出来，多台机器，保证高可用性，挂掉一台机器，都可以继续运行下去
+
+ 
+
+3台机器
+
+ 
+
+我现在要进行元数据的存储，我向机器01写了一条数据，机器01应该怎么把数据同步给其他的机器02和机器03呢？
+
+ 
+
+自己写一个类似ZK的系统？不可能单机版本吧？肯定得集群部署保证高可用吧？一旦集群了之后，数据一致性怎么保证？多麻烦！
+
+ 
+
+你的分布式架构中有需求，干脆就直接用工业级，久经考验的zookeeper就可以了，bug很少，功能很全面，运用在很多工业级的大规模的分布式系统中，HDFS、Kafka、HBase

docs/03/119.md

@@ -0,0 +1,29 @@
+# 119、ZooKeeper为了满足分布式系统的需求要有哪些特点？
+
+![分布式协调和通知](/docs/03/images/119/01.png)
+
+ZooKeeper肯定是一套系统，这个系统可以存储元数据，支持Master选举，可以进行分布式协调和通知
+
+ 
+
+集群部署：不可能单机版本
+
+ 
+
+顺序一致性：所有请求全部有序
+
+ 
+
+原子性：要么全部机器都成功，要么全部机器都别成功
+
+ 
+
+数据一致性：无论连接到哪台ZK上去，看到的都是一样的数据，不能有数据不一致
+
+ 
+
+高可用：如果某台机器宕机，要保证数据绝对不能丢失
+
+ 
+
+实时性：一旦数据发生变更，其他人要实时感知到

docs/03/120.md

@@ -0,0 +1,53 @@
+# 120、为了满足分布式系统的需求，ZooKeeper的架构设计有哪些特点？
+
+![分布式协调和通知](/docs/03/images/120/01.png)
+
+为了实现需要的一些特性，ZooKeeper的架构设计需要有哪些特点？
+
+ 
+
+集群化部署：3~5台机器组成一个集群，每台机器都在内存保存了zk的全部数据，机器之间互相通信同步数据，客户端连接任何一台机器都可以
+
+ 
+
+树形结构的数据模型：znode，树形结构，数据模型简单，纯内存保存
+
+ 
+
+数据结构就跟我们的文件系统是类似的，是有层级关系的树形的文件系统的数据结构
+
+ 
+
+znode可以认为是一个节点而已
+
+ 
+
+create /usr/local/uid
+
+create /usr/local/test_file
+
+ 
+
+uid：可以写入一些数据的值，比如说hello world
+
+test_file：也可以写入一些数据的值
+
+ 
+
+顺序写：集群中只有一台机器可以写，所有机器都可以读，所有写请求都会分配一个zk集群全局的唯一递增编号，zxid，保证各种客户端发起的写请求都是有顺序的
+
+ 
+
+数据一致性：任何一台zk机器收到了写请求之后都会同步给其他机器，保证数据的强一致，你连接到任何一台zk机器看到的数据都是一致的
+
+ 
+
+高性能：每台zk机器都在内存维护数据，所以zk集群绝对是高并发高性能的，如果你让zk部署在高配置物理机上，一个3台机器的zk集群抗下每秒几万请求没有问题
+
+ 
+
+高可用：哪怕集群中挂掉不超过一半的机器，都能保证可用，数据不会丢失，3台机器可以挂1台，5台机器可以挂2台
+
+ 
+
+高并发：高性能决定的，只要基于纯内存数据结构来处理，并发能力是很高的，只有一台机器进行写，但是高配置的物理机，比如16核32G，写入几万QPS，读，所有机器都可以读，3台机器的话，起码可以支撑十几万QPS

docs/03/121.md

@@ -0,0 +1,13 @@
+# 121、ZooKeeper集群的三种角色：Leader、Follower、Observer
+
+![ZooKeeper集群的三种角色](/docs/03/images/121/01.png)
+
+通常来说ZooKeeper集群里有三种角色的机器
+
+ 
+
+集群启动自动选举一个Leader出来，只有Leader是可以写的，Follower是只能同步数据和提供数据的读取，Leader挂了，Follower可以继续选举出来Leader，Observer也只能读但是Observer不参与选举
+
+ 
+
+Observer这个东西，再往后讲点，分析清楚了别的东西以后，Observer我们会回过头来讲解的

docs/03/122.md

@@ -0,0 +1,13 @@
+# 122、客户端与ZooKeeper之间的长连接和会话是什么？
+
+![客户端与ZooKeeper之间的长连接和会话](/docs/03/images/122/01.png)
+
+zk集群启动之后，自己分配好角色，然后客户端就会跟zk建立连接，是TCP长连接
+
+ 
+
+把我们的Java架构课程里的网络那块的东西，自研的分布式海量小文件存储系统的项目，我们手写了大量的底层的网络通信的代码
+
+ 
+
+也就建立了一个会话，就是session，可以通过心跳感知到会话是否存在，有一个sessionTimeout，意思就是如果连接断开了，只要客户端在指定时间内重新连接zk一台机器，就能继续保持session，否则session就超时了

docs/03/123.md

@@ -0,0 +1,45 @@
+# 123、ZooKeeper的数据模型：znode和节点类型
+
+![ZooKeeper的数据模型：znode和节点类型](/docs/03/images/123/01.png)
+
+核心数据模型就是znode树，平时我们往zk写数据就是创建树形结构的znode，里面可以写入值，就这数据模型，都在zk内存里存放
+
+ 
+
+有两种节点，持久节点和临时节点，持久节点就是哪怕客户端断开连接，一直存在
+
+ 
+
+临时节点，就是只要客户端断开连接，节点就没了
+
+ 
+
+还有顺序节点，就是创建节点的时候自增加全局递增的序号
+
+ 
+
+大家去看一下，之前Java架构的分布式锁里，有一个zk锁的源码分析，curator框架，zk分布式锁的实现，在里面就是基于zk的临时顺序节点来实现的，加锁的时候，是创建一个临时顺序节点
+
+ 
+
+zk会自动给你的临时节点加上一个后缀，全局递增的，编号
+
+ 
+
+如果你客户端断开连接了，就自动销毁这个你加的锁，此时人家会感知到，就会尝试去加锁
+
+ 
+
+如果你是做元数据存储，肯定是持久节点
+
+ 
+
+如果你是做一些分布式协调和通知，很多时候是用临时节点，就是说，比如我创建一个临时节点，别人来监听这个节点的变化，如果我断开连接了，临时节点消失，此时人家会感知到，就会来做点别的事情
+
+ 
+
+顺序节点，在分布式锁里用的比较经典
+
+ 
+
+每个znode还有一个Stat用来存放数据版本，version（znode的版本），cversion（znode子节点的版本），aversion（znode的ACL权限控制版本）