update docs

zengkaimin · Feb 9, 2020 · c810b0b · c810b0b
1 parent 0997161
commit c810b0b
Show file tree

Hide file tree

Showing 3 changed files with 220 additions and 2 deletions.
diff --git a/assets/eddx/redis哨兵.eddx b/assets/eddx/redis哨兵.eddx
diff --git a/docs/nosql/HBase.md b/docs/nosql/HBase.md
@@ -0,0 +1,143 @@
+# HBase
+
+<!-- TOC depthFrom:2 depthTo:3 -->
+
+- [简介](#简介)
+- [基础](#基础)
+- [原理](#原理)
+  - [数据模型](#数据模型)
+  - [HBase 架构](#hbase-架构)
+- [HBase 和 RDBMS](#hbase-和-rdbms)
+- [API](#api)
+- [附录](#附录)
+  - [命令行](#命令行)
+- [更多内容](#更多内容)
+  - [扩展阅读](#扩展阅读)
+  - [参考资料](#参考资料)
+
+<!-- /TOC -->
+
+## 简介
+
+HBase 是建立在 HDFS 基础上的面向列的分布式数据库。
+
+- HBase 参考了谷歌的 BigTable 建模，实现的编程语言为 Java。
+- 它是 Hadoop 项目的子项目，运行于 HDFS 文件系统之上。
+
+HBase 适用场景：实时地随机访问超大数据集。
+
+在 [CAP 理论](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)中，HBase 属于 CP 类型的系统。
+
+## 基础
+
+[HBase 维护](hbase-ops.md)
+
+## 原理
+
+### 数据模型
+
+HBase 是一个面向列的数据库，在表中它由行排序。
+
+HBase 表模型结构为：
+
+- 表（table）是行的集合。
+- 行（row）是列族的集合。
+- 列族（column family）是列的集合。
+- 列（row）是键值对的集合。
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551164163369.png!zp)
+
+HBase 表的单元格（cell）由行和列的坐标交叉决定，是有版本的。默认情况下，版本号是自动分配的，为 HBase 插入单元格时的时间戳。单元格的内容是未解释的字节数组。
+
+行的键也是未解释的字节数组，所以理论上，任何数据都可以通过序列化表示成字符串或二进制，从而存为 HBase 的键值。
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551164224778.png!zp)
+
+### HBase 架构
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551164744748.png!zp)
+
+和 HDFS、YARN 一样，HBase 也采用 master / slave 架构：
+
+- HBase 有一个 master 节点。master 节点负责将区域（region）分配给 region 节点；恢复 region 节点的故障。
+- HBase 有多个 region 节点。region 节点负责零个或多个区域（region）的管理并相应客户端的读写请求。region 节点还负责区域的划分并通知 master 节点有了新的子区域。
+
+HBase 依赖 ZooKeeper 来实现故障恢复。
+
+#### Regin
+
+HBase 表按行键范围水平自动划分为区域（region）。每个区域由表中行的子集构成。每个区域由它所属的表、它所含的第一行及最后一行来表示。
+
+**区域只不过是表被拆分，并分布在区域服务器。**
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551165887616.png!zp)
+
+#### Master 服务器
+
+区域分配、DDL(create、delete)操作由 HBase master 服务器处理。
+
+- master 服务器负责协调 region 服务器
+  - 协助区域启动，出现故障恢复或负载均衡情况时，重新分配 region 服务器
+  - 监控集群中的所有 region 服务器
+- 支持 DDL 接口（创建、删除、更新表）
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551166513572.png!zp)
+
+#### Regin 服务器
+
+区域服务器运行在 HDFS 数据节点上，具有以下组件
+
+- `WAL` - Write Ahead Log 是 HDFS 上的文件。WAL 存储尚未持久存储到永久存储的新数据，它用于在发生故障时进行恢复。
+
+- `BlockCache` - 是读缓存。它将频繁读取的数据存储在内存中。至少最近使用的数据在完整时被逐出。
+- `MemStore` - 是写缓存。它存储尚未写入磁盘的新数据。在写入磁盘之前对其进行排序。每个区域每个列族有一个 MemStore。
+- `Hfiles` - 将行存储为磁盘上的排序键值对。
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551166602999.png!zp)
+
+#### ZooKeeper
+
+HBase 使用 ZooKeeper 作为分布式协调服务来维护集群中的服务器状态。Zookeeper 维护哪些服务器是活动的和可用的，并提供服务器故障通知。集群至少应该有 3 个节点。
+
+![img](http://dunwu.test.upcdn.net/cs/bigdata/hbase/1551166447147.png!zp)
+
+## HBase 和 RDBMS
+
+| HBase                                               | RDBMS                                      |
+| --------------------------------------------------- | ------------------------------------------ |
+| HBase 无模式，它不具有固定列模式的概念;仅定义列族。 | RDBMS 有它的模式，描述表的整体结构的约束。 |
+| 它专门创建为宽表。 HBase 是横向扩展。               | 这些都是细而专为小表。很难形成规模。       |
+| 没有任何事务存在于 HBase。                          | RDBMS 是事务性的。                         |
+| 它反规范化的数据。                                  | 它具有规范化的数据。                       |
+| 它用于半结构以及结构化数据是非常好的。              | 用于结构化数据非常好。                     |
+
+## API
+
+Java API 归纳总结在这里：[Hbase Java API](hbase-api-java.md)
+
+## 附录
+
+### 命令行
+
+HBase 命令行可以参考这里：[HBase 命令行](hbase-cli.md)
+
+## 更多内容
+
+### 扩展阅读
+
+- [HBase 命令](hbase-cli.md)
+- [HBase 配置](hbase-ops.md)
+
+### 参考资料
+
+#### 官方
+
+- [HBase 官网](http://hbase.apache.org/)
+- [HBase 官方文档](https://hbase.apache.org/book.html)
+- [HBase 官方文档中文版](http://abloz.com/hbase/book.html)
+- [HBase API](https://hbase.apache.org/apidocs/index.html)
+
+#### 文章
+
+- [Bigtable: A Distributed Storage System for Structured Data](https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/bigtable-osdi06.pdf)
+- https://mapr.com/blog/in-depth-look-hbase-architecture/
diff --git a/docs/nosql/redis/redis-sentinel.md b/docs/nosql/redis/redis-sentinel.md
@@ -1,4 +1,4 @@
-# Redis 哨兵
+# v Redis 哨兵
 
 Redis 哨兵（Sentinel）是 Redis 的**高可用性**（Hight Availability）解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
 
@@ -54,7 +54,15 @@ Sentinel 模式下 Redis 服务器主要功能的使用情况：
 
 > **Sentinel 向 Redis 服务器发送 `PING` 命令，检查其状态**。
 
-默认情况下，Sentinel 会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他 Sentinel ）发送 `PING` 命令，并通过实例返回的 `PING` 命令回复来判断实例是否在线。
+默认情况下，**每个** `Sentinel` 节点会以 **每秒一次** 的频率对 `Redis` 节点和 **其它** 的 `Sentinel` 节点发送 `PING` 命令，并通过节点的 **回复** 来判断节点是否在线。
+
+- **主观下线**
+
+**主观下线** 适用于所有 **主节点** 和 **从节点**。如果在 `down-after-milliseconds` 毫秒内，`Sentinel` 没有收到 **目标节点** 的有效回复，则会判定 **该节点** 为 **主观下线**。
+
+- **客观下线**
+
+**客观下线** 只适用于 **主节点**。如果 **主节点** 出现故障，`Sentinel` 节点会通过 `sentinel is-master-down-by-addr` 命令，向其它 `Sentinel` 节点询问对该节点的 **状态判断**。如果超过 `` 个数的节点判定 **主节点** 不可达，则该 `Sentinel` 节点会判断 **主节点** 为 **客观下线**。
 
 ### 获取服务器信息
 
@@ -95,8 +103,74 @@ Sentinel 对 `__sentinel__:hello` 频道的订阅会一直持续到 Sentinel 与
 
 所有在线 Sentinel 都有资格被选为 Leader。
 
+每个 `Sentinel` 节点都需要 **定期执行** 以下任务：
+
+（1）每个 `Sentinel` 以 **每秒钟** 一次的频率，向它所知的 **主服务器**、**从服务器** 以及其他 `Sentinel` **实例** 发送一个 `PING` 命令。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce61df44c4d?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（2）如果一个 **实例**（`instance`）距离 **最后一次** 有效回复 `PING` 命令的时间超过 `down-after-milliseconds` 所指定的值，那么这个实例会被 `Sentinel` 标记为 **主观下线**。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce61dc739de?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（3）如果一个 **主服务器** 被标记为 **主观下线**，那么正在 **监视** 这个 **主服务器** 的所有 `Sentinel` 节点，要以 **每秒一次** 的频率确认 **主服务器** 的确进入了 **主观下线** 状态。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce647a39535?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（4）如果一个 **主服务器** 被标记为 **主观下线**，并且有 **足够数量** 的 `Sentinel`（至少要达到 **配置文件** 指定的数量）在指定的 **时间范围** 内同意这一判断，那么这个 **主服务器** 被标记为 **客观下线**。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce647c2583e?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（5）在一般情况下， 每个 `Sentinel` 会以每 `10` 秒一次的频率，向它已知的所有 **主服务器** 和 **从服务器** 发送 `INFO` 命令。当一个 **主服务器** 被 `Sentinel` 标记为 **客观下线** 时，`Sentinel` 向 **下线主服务器** 的所有 **从服务器** 发送 `INFO` 命令的频率，会从 `10` 秒一次改为 **每秒一次**。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce6738a30db?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（6）`Sentinel` 和其他 `Sentinel` 协商 **主节点** 的状态，如果 **主节点** 处于 `SDOWN` 状态，则投票自动选出新的 **主节点**。将剩余的 **从节点** 指向 **新的主节点** 进行 **数据复制**。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce676a95a54?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+（7）当没有足够数量的 `Sentinel` 同意 **主服务器** 下线时， **主服务器** 的 **客观下线状态** 就会被移除。当 **主服务器** 重新向 `Sentinel` 的 `PING` 命令返回 **有效回复** 时，**主服务器** 的 **主观下线状态** 就会被移除。
+
+
+
+![img](https://user-gold-cdn.xitu.io/2018/8/22/16560ce6759c1cb3?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+> 注意：一个有效的 `PING` 回复可以是：`+PONG`、`-LOADING` 或者 `-MASTERDOWN`。如果 **服务器** 返回除以上三种回复之外的其他回复，又或者在 **指定时间** 内没有回复 `PING` 命令， 那么 `Sentinel` 认为服务器返回的回复 **无效**（`non-valid`）。
+
 ## 六、故障转移
 
+在选举产生出 Sentinel Leader 后，Sentinel Leader 将对已下线的主服务器执行故障转移操作。操作含以下三个步骤：
+
+1. 选出新的主服务器
+2. 修改从服务器的复制目标
+3. 将旧的主服务器变为从服务器
+
 ## 参考资料
 
 - **官网**
@@ -107,3 +181,4 @@ Sentinel 对 `__sentinel__:hello` 频道的订阅会一直持续到 Sentinel 与
   - [《Redis 设计与实现》](https://item.jd.com/11486101.html)
 - **文章**
   - [渐进式解析 Redis 源码 - 哨兵 sentinel](http://www.web-lovers.com/redis-source-sentinel.html)
+  - [深入剖析Redis系列(二) - Redis哨兵模式与高可用集群](https://juejin.im/post/5b7d226a6fb9a01a1e01ff64)