Zookeeper深入原理

一、集群搭建

1前置 *** 作

若克隆已有的es虚拟机，一定要清空一下文件：

2配置集群，修改elasticsearchyml

# 配置集群名称，保证每个节点的名称相同，如此就能都处于一个集群之内了

clustername: imooc-es-cluster

# 每一个节点的名称，必须不一样

nodename: es-node1

# >

关于集群限流的功能，官方文档写的非常详细: 集群流控官方文档
官方文档中有demo，但是隐藏了太多细节，且依赖了nacos，我这里自己写了一个demo。

demo地址: >

用于连接每个客户端，即客户端可调用所提供的这些函数访问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:
>