4.3 HBase实现原理

Posted 2023-05-13

参考技术A

用于连接每个客户端，即客户端可调用所提供的这些函数访问HBase的数据

充当管家，主要作用：

a) 获知整个集群中哪些Region服务器在工作、哪些有故障
b) 一个表会被分为多个Region，每个Region被分配到哪个Region服务器由Master服务器决定

一整张表会被分为多个Region，它们由Region服务器负责维护和管理。

2006年以前常设计为100-200MB，现在一般配置为1~2GB。具体设计应取决于单台服务器的处理能力（存取速度、内存等）。
前面提到过一个Region增大到一定程度会被Master服务器拆分成多个小Region。但在存储方面，一个完整的Region（拆分前的）不会被存储到不同的Region服务器上。

三层寻址对应了三层表：
(1) -ROOT-表 ：存储元数据表，即.MEAT.表的信息。它被“写死”在ZooKeeper文件中，是唯一的、不能再分裂的
(2) .META.表 ：存储用户数据具体存储在哪些Region服务器上。它会随存储数据的增多而分裂成更多个。
(3) 用户数据表 ：具体存储用户数据。它是最底层的、可分裂的

HBase采用 三级寻址 ：
(1) ZooKeeper找到-ROOT-表地址
(2) -ROOT-表中找到需要的.META.表地址
(3) .META.表找到所需的用户数据表地址
(4) 最后从用户数据表取出目标数据

另外，为了加速寻址，客户端会 缓存已查数据的位置信息 （在客户端自己的缓存中），下次取相同的数据就可以快速访问。——但随Region的更新，缓存记录可能失效。对于这个问题，HBase采用惰性解决机制，即首先使用缓存的位置，如果在那个位置查不到目标数据，则按三级寻址重新查询，再更新缓存。

假设一个Region最大128MB（注意-ROOT-、.META.、用户表都是以Region形式存储的），一条映射条目大小1KB：

Reference:
https://www.icourse163.org/learn/XMU-1002335004#/learn/content?type=detail&id=1214310125&cid=1217922282

Docker的底层原理实现（二十）

参考技术A Docker 采用了 C/S 架构，包括客户端和服务端。Docker 守护进程 （ Daemon ）作为服务端接受来自客户端的请求，并处理这些请求（创建、运行、分发容器）。

客户端和服务端既可以运行在一个机器上，也可通过 socket 或者 RESTful API 来进行通信。

命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的 应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。

不同用户的进程就是通过 pid 命名空间隔离开的，且不同命名空间中可以有相同 pid。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的命名空间。同时由 于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。

有了 pid 命名空间, 每个命名空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端 口。网络隔离是通过 net 命名空间实现的， 每个 net 命名空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将 容器中的虚拟网卡同 host 上的一个 Docker 网桥 docker0 连接在一起。

容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication - IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 命名空间中的进程间交互，因此需要在 IPC 资源申请时加入命名空间信息，每个 IPC 资源有一个唯一的 32 位 id。

类似 chroot，将一个进程放到一个特定的目录执行。mnt 命名空间允许不同命名空间的进程看到的文件结构不同，这样每个命名空间中的进程所看到的文件目录就被隔离开了。同 chroot 不同，每个命名空间中的容器在 /proc/mounts 的信息只包含所在命名空间的 mount point。

UTS("UNIX Time-sharing System") 命名空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非主机上的一个进程。

每个容器可以有不同的用户和组 id, 也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。

控制组（cgroups）是 Linux 内核的一个特性，主要用来对共享资源进行隔离、限制、审计 等。只有能控制分配到容器的资源，才能避免当多个容器同时运行时的对系统资源的竞争。

联合文件系统（UnionFS）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。

联合文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父 镜像），可以制作各种具体的应用镜像。

另外，不同 Docker 容器就可以共享一些基础的文件系统层，同时再加上自己独有的改动层， 大大提高了存储的效率。

Docker 中使用的 AUFS（AnotherUnionFS）就是一种联合文件系统。 AUFS 支持为每一个 成员目录（类似 Git 的分支）设定只读（readonly）、读写（readwrite）和写出（whiteoutable）权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。

Docker 目前支持的联合文件系统包括 OverlayFS, AUFS, Btrfs, VFS, ZFS 和 Device Mapper。

最初，Docker 采用了 LXC 中的容器格式。从 0.7 版本以后开始去除 LXC，转而使用自行开 发的 libcontainer ，从 1.11 开始，则进一步演进为使用 runC 和 containerd 。

Docker 的网络实现其实就是利用了 Linux 上的网络命名空间和虚拟网络设备（特别是 veth pair）。

首先，要实现网络通信，机器需要至少一个网络接口（物理接口或虚拟接口）来收发数据包；此外，如果不同子网之间要进行通信，需要路由机制。

Docker 中的网络接口默认都是虚拟的接口。虚拟接口的优势之一是转发效率较高。 Linux 通 过在内核中进行数据复制来实现虚拟接口之间的数据转发，发送接口的发送缓存中的数据包 被直接复制到接收接口的接收缓存中。对于本地系统和容器内系统看来就像是一个正常的以 太网卡，只是它不需要真正同外部网络设备通信，速度要快很多。

Docker 容器网络就利用了这项技术。它在本地主机和容器内分别创建一个虚拟接口，并让它 们彼此连通（这样的一对接口叫做 veth pair ）。

Docker 创建一个容器的时候，会执行如下操作：

完成这些之后，容器就可以使用 eth0 虚拟网卡来连接其他容器和其他网络。可以在 docker run 的时候通过 --net 参数来指定容器的网络配置：