Compare commits
10 Commits
4fd325f312
...
3898939aca
| Author | SHA1 | Date | |
|---|---|---|---|
|
3898939aca | ||
|
|
6625699c37 | ||
|
13fa7d5e5d | ||
|
34ad3befc3 | ||
|
|
185520374c | ||
|
|
1f6a8110ee | ||
|
|
d590f37654 | ||
|
|
6795c2b00a | ||
|
|
2b5bd142ab | ||
|
16465d7e30 |
@ -98,10 +98,10 @@ object ScalaApp extends App {
|
||||
// 4.tail 和 head 可以结合使用
|
||||
list.tail.head
|
||||
|
||||
// 5.返回列表中的最后一个元素 与 head 相反
|
||||
// 5.返回列表中除了最后一个元素之外的其他元素；与 tail 相反 这里输出 List(hadoop, spark)
|
||||
list.init
|
||||
|
||||
// 6.返回列表中除了最后一个元素之外的其他元素 与 tail 相反 这里输出 List(hadoop, spark)
|
||||
// 6.返回列表中的最后一个元素 与 head 相反
|
||||
list.last
|
||||
|
||||
// 7.使用下标访问元素
|
||||
@ -542,4 +542,4 @@ object ScalaApp extends App {
|
||||
2. 凯.S.霍斯特曼 . 快学 Scala(第 2 版)[M] . 电子工业出版社 . 2017-7
|
||||
|
||||
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
|
||||
@ -123,7 +123,7 @@ Zookeeper 采用 ACL(Access Control Lists) 策略来进行权限控制，类似
|
||||
|
||||
### 4.1 ZAB协议与数据一致性
|
||||
|
||||
ZAB 协议是 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。通过该协议，Zookeepe 基于主从模式的系统架构来保持集群中各个副本之间数据的一致性。具体如下：
|
||||
ZAB 协议是 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。通过该协议，Zookeeper 基于主从模式的系统架构来保持集群中各个副本之间数据的一致性。具体如下：
|
||||
|
||||
Zookeeper 使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用原子广播协议将数据状态的变更以事务 Proposal 的形式广播到所有的副本进程上去。如下图：
|
||||
|
||||
@ -153,7 +153,7 @@ Leader 服务会为每一个 Follower 服务器分配一个单独的队列，然
|
||||
|
||||
## 五、Zookeeper的典型应用场景
|
||||
|
||||
### 5.1数据的发布/订阅
|
||||
### 5.1 数据的发布/订阅
|
||||
|
||||
数据的发布/订阅系统，通常也用作配置中心。在分布式系统中，你可能有成千上万个服务节点，如果想要对所有服务的某项配置进行更改，由于数据节点过多，你不可逐台进行修改，而应该在设计时采用统一的配置中心。之后发布者只需要将新的配置发送到配置中心，所有服务节点即可自动下载并进行更新，从而实现配置的集中管理和动态更新。
|
||||
|
||||
@ -207,4 +207,4 @@ Zookeeper 还能解决大多数分布式系统中的问题：
|
||||
|
||||
|
||||
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
|
||||
@ -48,7 +48,7 @@ export PATH=$HIVE_HOME/bin:$PATH
|
||||
|
||||
**1. hive-env.sh**
|
||||
|
||||
进入安装目录下的 `conf/` 目录，拷贝 Hive 的环境配置模板 `flume-env.sh.template`
|
||||
进入安装目录下的 `conf/` 目录，拷贝 Hive 的环境配置模板 `hive-env.sh.template`
|
||||
|
||||
```shell
|
||||
cp hive-env.sh.template hive-env.sh
|
||||
@ -181,4 +181,4 @@ Hive 内置了 HiveServer 和 HiveServer2 服务，两者都允许客户端使
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/hive-beeline-cli.png"/> </div>
|
||||
|
||||
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
|
||||
@ -56,6 +56,41 @@ NameNode 实现主备切换的流程下图所示：
|
||||
5. ActiveStandbyElector 在主备选举完成后，会回调 ZKFailoverController 的相应方法来通知当前的 NameNode 成为主 NameNode 或备 NameNode。
|
||||
6. ZKFailoverController 调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法将 NameNode 转换为 Active 状态或 Standby 状态。
|
||||
|
||||
#### 1.3.1 自动触发主备选举
|
||||
NameNode 在选举成功后，会在 zk 上创建了一个 /hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点，而没有选举成功的备 NameNode 会监控这个节点，通过 Watcher 来监听这个节点的状态变化事件，ZKFC 的 ActiveStandbyElector 主要关注这个节点的 NodeDeleted 事件（这部分实现跟 Kafka 中 Controller 的选举一样）。
|
||||
|
||||
如果 Active NameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时， ZKFailoverController 会主动删除当前在 Zookeeper 上建立的临时节点 /hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock，这样处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 NodeDeleted 事件。收到这个事件之后，会马上再次进入到创建 /hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点的流程，如果创建成功，这个本来处于 Standby 状态的 NameNode 就选举为主 NameNode 并随后开始切换为 Active 状态。
|
||||
|
||||
当然，如果是 Active 状态的 NameNode 所在的机器整个宕掉的话，那么根据 Zookeeper 的临时节点特性，/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换。
|
||||
|
||||
#### 1.3.2 HDFS 脑裂问题
|
||||
在实际中，NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应，因此，也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode 会切换到 Active 状态，这种情况，可能会导致整个集群会有同时有两个 NameNode，这就是脑裂问题。
|
||||
|
||||
脑裂问题的解决方案是隔离（Fencing），主要是在以下三处采用隔离措施：
|
||||
|
||||
第三方共享存储：任一时刻，只有一个 NN 可以写入；
|
||||
DataNode：需要保证只有一个 NN 发出与管理数据副本有关的删除命令；
|
||||
Client：需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的响应。
|
||||
关于这个问题目前解决方案的实现如下：
|
||||
|
||||
ActiveStandbyElector 为了实现 fencing，会在成功创建 Zookeeper 节点 hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 从而成为 Active NameNode 之后，创建另外一个路径为 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 的持久节点，这个节点里面保存了这个 Active NameNode 的地址信息；
|
||||
Active NameNode 的 ActiveStandbyElector 在正常的状态下关闭 Zookeeper Session 的时候，会一起删除这个持久节点；
|
||||
但如果 ActiveStandbyElector 在异常的状态下 Zookeeper Session 关闭 (比如前述的 Zookeeper 假死)，那么由于 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会回调 ZKFailoverController 的方法对旧的 Active NameNode 进行 fencing。
|
||||
在进行 fencing 的时候，会执行以下的操作：
|
||||
|
||||
首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态；
|
||||
如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施。
|
||||
Hadoop 目前主要提供两种隔离措施，通常会选择第一种：
|
||||
|
||||
sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；
|
||||
shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离。
|
||||
只有在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调 ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始对外提供服务。
|
||||
|
||||
NameNode 选举的实现机制与 Kafka 的 Controller 类似，那么 Kafka 是如何避免脑裂问题的呢？
|
||||
|
||||
Controller 给 Broker 发送的请求中，都会携带 controller epoch 信息，如果 broker 发现当前请求的 epoch 小于缓存中的值，那么就证明这是来自旧 Controller 的请求，就会决绝这个请求，正常情况下是没什么问题的；
|
||||
但是异常情况下呢？如果 Broker 先收到异常 Controller 的请求进行处理呢？现在看 Kafka 在这一部分并没有适合的方案；
|
||||
正常情况下，Kafka 新的 Controller 选举出来之后，Controller 会向全局所有 broker 发送一个 metadata 请求，这样全局所有 Broker 都可以知道当前最新的 controller epoch，但是并不能保证可以完全避免上面这个问题，还是有出现这个问题的几率的，只不过非常小，而且即使出现了由于 Kafka 的高可靠架构，影响也非常有限，至少从目前看，这个问题并不是严重的问题。
|
||||
|
||||
### 1.4 YARN高可用
|
||||
|
||||
@ -513,5 +548,5 @@ yarn-daemon.sh start resourcemanager
|
||||
[Hadoop NameNode 高可用 (High Availability) 实现解析](https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/index.html)
|
||||
|
||||
|
||||
|
||||
[hdfs架构详解(防脑裂fencing机制值得学习)](https://www.cnblogs.com/lushilin/p/11239908.html)
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
|
||||
@ -53,7 +53,7 @@ server.3=127.0.0.1:2289:3389
|
||||
|
||||
> 如果是多台服务器，则集群中每个节点通讯端口和选举端口可相同，IP 地址修改为每个节点所在主机 IP 即可。
|
||||
|
||||
zookeeper02 配置，与 zookeeper01 相比，只有 `dataLogDir`、`dataLogDir` 和 `clientPort` 不同：
|
||||
zookeeper02 配置，与 zookeeper01 相比，只有 `dataDir`、`dataLogDir` 和 `clientPort` 不同：
|
||||
|
||||
```shell
|
||||
tickTime=2000
|
||||
@ -154,7 +154,7 @@ wget https://www-eu.apache.org/dist/kafka/2.2.0/kafka_2.12-2.2.0.tgz
|
||||
tar -xzf kafka_2.12-2.2.0.tgz
|
||||
```
|
||||
|
||||
>这里 j 解释一下 kafka 安装包的命名规则：以 `kafka_2.12-2.2.0.tgz` 为例，前面的 2.12 代表 Scala 的版本号（Kafka 采用 Scala 语言进行开发），后面的 2.2.0 则代表 Kafka 的版本号。
|
||||
>这里解释一下 kafka 安装包的命名规则：以 `kafka_2.12-2.2.0.tgz` 为例，前面的 2.12 代表 Scala 的版本号（Kafka 采用 Scala 语言进行开发），后面的 2.2.0 则代表 Kafka 的版本号。
|
||||
|
||||
### 2.2 拷贝配置文件
|
||||
|
||||
@ -239,4 +239,4 @@ bin/kafka-topics.sh --describe --bootstrap-server hadoop001:9092 --topic my-repl
|
||||
|
||||
|
||||
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
<div align="center"> <img src="https://gitee.com/heibaiying/BigData-Notes/raw/master/pictures/weixin-desc.png"/> </div>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user