真没想到，这篇文章能让我看懂HBase

你的名字 2021-08-29 23:55 295阅读 0赞

## 前言 ##

> 只有光头才能变强。

> **文本已收录至我的GitHub精选文章，欢迎Star**：[https://github.com/ZhongFuCheng3y/3y][https_github.com_ZhongFuCheng3y_3y]

在我还不了解分布式和大数据的时候已经听说过**HBase**了，但对它一直都半知不解，这篇文章来讲讲吧。

在真实生活中，最开始听到这个词是我的一场面试，当年我还是个『小垃圾』，现在已经是个『大垃圾』了。

面试官当时给了一个场景题问我，具体的题目我忘得差不多了，大概就是考试与试题的一个场景，问我数据库要如何设计。

我答了关系型数据库的设计方案，他大概说：**这个场景比较复杂多变，为什么不考虑一下HBase这种NoSQL的数据库来存储呢**？

我就说：“**对对对，可以的**” （虽然我当时不知道HBase是什么，但是**气势一定要有**，你们说是不是）

![format_png][]

最后面试官还是给我发了offer，但我没去，原因就是离家太远了。

## 一、介绍HBase ##

> [Apache][] HBase™ is the [Hadoop][] database, a distributed, scalable, big data store.
> 
> HBase is a type of “NoSQL” database.

Apache HBase 是 Hadoop 数据库，一个分布式、可伸缩的**大数据存储**。

HBase是依赖Hadoop的。为什么HBase能存储海量的数据？**因为HBase是在HDFS的基础之上构建的，HDFS是分布式文件系统**。

## 二、为什么要用HBase ##

截至到现在，三歪已经学了不少的组件了，比如说分布式搜索引擎「Elasticsearch」、分布式文件系统「HDFS」、分布式消息队列「Kafka」、缓存数据库「Redis」等等…

**能够处理数据的中间件(系统)，这些中间件基本都会有持久化的功能**。为什么？如果某一个时刻挂了，那**还在内存但还没处理完的数据**不就凉了？

Redis有AOF和RDB、Elasticsearch会把数据写到translog然后结合FileSystemCache将数据刷到磁盘中、Kafka本身就是将数据顺序写到磁盘…

这些中间件会实现持久化（像HDFS和MySQL我们本身就用来存储数据的），为什么我们还要用HBase呢？

**虽然没有什么可比性**，但是在学习的时候总会有一个疑问：「既然已学过的系统都有类似的功能了，那为啥我还要去学这个玩意？」

三歪是这样理解的：

*  MySQL？MySQL数据库我们是算用得最多了的吧？但众所周知，MySQL是**单机**的。MySQL能存储多少数据，取决于那台服务器的硬盘大小。以现在互联网的数据量，很多时候MySQL是没法存储那么多数据的。
    
     *  比如我这边有个系统，一天就能产生1TB的数据，这数据是不可能存MySQL的。（如此大的量数据，我们现在的做法是先写到Kafka，然后落到Hive中）
 *  Kafka？Kafka我们主要用来处理消息的（解耦异步削峰）。数据到Kafka，Kafka会将数据持久化到硬盘中，并且Kafka是分布式的（很方便的扩展），理论上Kafka可以存储很大的数据。但是Kafka的数据我们**不会「单独」取出来**。持久化了的数据，最常见的用法就是重新设置offset，做「回溯」操作
 *  Redis？Redis是缓存数据库，所有的读写都在内存中，速度贼快。AOF/RDB存储的数据都会加载到内存中，Redis不适合存大量的数据（因为内存太贵了！）。
 *  Elasticsearch？Elasticsearch是一个分布式的搜索引擎，主要用于检索。理论上Elasticsearch也是可以存储海量的数据（毕竟分布式），我们也可以将数据用『索引』来取出来，似乎已经是非常完美的中间件了。
    
     *  但是如果我们的数据**没有经常「检索」的需求**，其实不必放到Elasticsearch，数据写入Elasticsearch需要分词，无疑会浪费资源。
 *  HDFS？显然HDFS是可以存储海量的数据的，它就是为海量数据而生的。它也有明显的缺点：不支持随机修改，查询效率低，对小文件支持不友好。

> 上面这些技术栈三歪都已经写过文章了。学多了你会发现它们的持久化机制都差不太多，有空再来总结一下。

![format_png 1][]

文中的开头已经说了，HBase是基于HDFS分布式文件系统去构建的。换句话说，HBase的数据其实也是存储在HDFS上的。那肯定有好奇宝宝就会问：**HDFS和HBase有啥区别阿**？

HDFS是文件系统，而HBase是数据库，其实也没啥可比性。「**你可以把HBase当做是MySQL，把HDFS当做是硬盘。HBase只是一个NoSQL数据库，把数据存在HDFS上**」。

> 数据库是一个以某种**有组织的方式存储的数据集合**。

扯了这么多，那我们为啥要用HBase呢？HBase在HDFS之上提供了**高并发的随机写和支持实时查询**，这是HDFS不具备的。

我一直都说在学习某一项技术之前首先要了解它能干什么。如果仅仅看上面的”对比“，我们可以发现HBase可以以**低成本**来**存储海量**的数据并且支持高并发随机写和实时查询。

但HBase还有一个特点就是：**存储数据的”结构“可以地非常灵活**（这个下面会讲到，这里如果没接触过HBase的同学可能不知道什么意思）。

## 三、入门HBase ##

听过HBase的同学可能都听过「列式存储」这个词。我最开始的时候觉得HBase很难理解，就因为它这个「列式存储」我一直理解不了它为什么是「列式」的。

在网上也有很多的博客去讲解什么是「列式」存储，它们会举我们现有的数据库，比如MySQL。存储的结构我们很容易看懂，就是一行一行数据嘛。

![format_png 2][]

转换成所谓的列式存储是什么样的呢？

![format_png 3][]

可以很简单的发现，无非就是把**每列抽出来，然后关联上Id**。这个叫列式存储吗？**我在这打个问号**。

转换后的数据**从我的角度来看**，数据还是一行一行的。

这样做有什么好处吗？很明显以前我们一行记录多个属性(列)，有部分的列是空缺的，但是我们还是需要空间去存储。现在把这些列全部拆开，有什么我们就存什么，这样**空间就能被我们充分利用**。

这种形式的数据更像什么？明显是`Key-Value`嘛。那我们该怎么理解HBase所谓的列式存储和`Key-Value`结构呢？走进三歪的小脑袋，一探究竟。

### 3.1 HBase的数据模型 ###

在看HBase数据模型的时候，其实最好还是不要用「关系型数据库」的知识去理解它。

> In HBase, data is stored in tables, which have rows and columns. This is a terminology overlap withrelational databases (RDBMSs), **but this is not a helpful analogy**.

HBase里边也有表、行和列的概念。

*  表没什么好说的，就是一张表
 *  一行数据由**一个行键**和**一个或多个相关的列以及它的值**所组成

好了，现在比较抽象了。在HBase里边，定位一行数据会有一个唯一的值，这个叫做行键(**RowKey**)。而在HBase的列不是我们在关系型数据库所想象中的列。

HBase的列（**Column**）都得归属到列族（**Column Family**）中。在HBase中用列修饰符（**Column Qualifier**）来标识每个列。

**在HBase里边，先有列族，后有列**。

什么是列族？可以简单理解为：列的属性**类别**

什么是列修饰符？**先有列族后有列，在列族下用列修饰符来标识一列**。

还很抽象是不是？三歪来画个图：

![format_png 4][]

我们再放点具体的值去看看，就更加容易看懂了：

![format_png 5][]

这张表我们有两个列族，分别是`UserInfo`和`OrderInfo`。在UserInfo下有两个列，分别是`UserInfo:name`和`UserInfo:age`，在`OrderInfo`下有两个列，分别是`OrderInfo:orderId`和`OrderInfo:money`。

`UserInfo:name`的值为：三歪。`UserInfo:age`的值为24。`OrderInfo:orderId`的值为23333。`OrderInfo:money`的值为30。这些数据的主键(RowKey)为1

上面的那个图看起来可能不太好懂，我们再画一个我们比较熟悉的：

![format_png 6][]

HBase表的每一行中，列的组成都是**灵活**的，**行与行之间的列不需要相同**。如图下：

![format_png 7][]

![format_png 8][]

换句话说：**一个列族下可以任意添加列，不受任何限制**

数据写到HBase的时候都会被记录一个**时间戳**，这个时间戳被我们当做一个**版本**。比如说，我们**修改或者删除**某一条的时候，本质上是往里边**新增**一条数据，记录的版本加一了而已。

比如现在我们有一条记录：

![format_png 9][]

现在要把这条记录的值改为40，实际上就是多添加一条记录，在读的时候按照时间戳**读最新**的记录。在外界「看起来」就是把这条记录改了。

![format_png 10][]

### 3.2 HBase 的Key-Value ###

HBase本质上其实就是`Key-Value`的数据库，上一次我们学`Key-Value`数据库还是Redis呢。那在HBase里边，Key是什么？Value是什么？

我们看一下下面的HBase`Key-Value`结构图：

![format_png 11][]

Key由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳–版本）+KeyType（类型）组成，而Value就是实际上的值。

对比上面的例子，其实很好理解，因为我们修改一条数据其实上是在原来的基础上增加一个版本的，那我们要**准确定位**一条数据，那就得（RowKey+Column+时间戳）。

KeyType是什么？我们上面只说了「修改」的情况，你们有没有想过，如果要删除一条数据怎么做？实际上也是增加一条记录，只不过我们在KeyType里边设置为“Delete”就可以了。

### 3.3 HBase架构 ###

扯了这么一大堆，已经说了HBase的数据模型和Key-Value了，我们还有一个问题：「为什么经常会有人说HBase是列式存储呢？」

其实HBase更多的是「**列族存储**」，要谈列族存储，就得先了解了解HBase的架构是怎么样的。

我们先来看看HBase的架构图：

![format_png 12][]

1、**Client**客户端，它提供了访问HBase的接口，并且维护了对应的cache来加速HBase的访问。

2、**Zookeeper**存储HBase的元数据（meta表），无论是读还是写数据，都是去Zookeeper里边拿到meta元数据**告诉给客户端去哪台机器读写数据**

3、**HRegionServer**它是处理客户端的读写请求，负责与HDFS底层交互，是真正干活的节点。

总结大致的流程就是：client请求到Zookeeper，然后Zookeeper返回HRegionServer地址给client，client得到Zookeeper返回的地址去请求HRegionServer，HRegionServer读写数据后返回给client。

![format_png 13][]

### 3.4 HRegionServer内部 ###

我们来看下面的图：

![format_png 14][]

前面也提到了，HBase可以存储海量的数据，HBase是分布式的。所以我们可以断定：**HBase一张表的数据会分到多台机器上的**。那HBase是怎么切割一张表的数据的呢？用的就是**RowKey**来切分，其实就是表的**横向**切割。

![format_png 15][]

说白了就是一个**HRegion**上，存储HBase表的一部分数据。

![format_png 16][]

HRegion下面有**Store**，那Store是什么呢？我们前面也说过，一个HBase表首先要定义**列族**，然后列是在列族之下的，列可以随意添加。

**一个列族的数据是存储**在一起的，所以一个列族的数据是存储在一个Store里边的。

看到这里，其实我们可以认为HBase是基于列族存储的（毕竟物理存储，一个列族是存储到同一个Store里的）

![format_png 17][]

Store里边有啥？有`Mem Store、Store File、HFile`，我们再来看看里边都代表啥含义。

![format_png 18][]

HBase在写数据的时候，会先写到`Mem Store`，当`MemStore`超过一定阈值，就会将内存中的数据刷写到硬盘上，形成**StoreFile**，而`StoreFile`底层是以`HFile`的格式保存，`HFile`是HBase中`KeyValue`数据的存储格式。

所以说：`Mem Store`我们可以理解为内存 buffer，`HFile`是HBase实际存储的数据格式，而`StoreFile`只是HBase里的一个名字。

回到HRegionServer上，我们还漏了一块，就是`HLog`。

![format_png 19][]

这里其实特别好理解了，我们写数据的时候是先写到内存的，为了防止机器宕机，内存的数据没刷到磁盘中就挂了。我们在写`Mem store`的时候还会写一份`HLog`。

这个`HLog`是顺序写到磁盘的，所以速度还是挺快的（是不是有似曾相似的感觉）…

稍微总结一把：

*  HRegionServer是真正干活的机器（用于与hdfs交互），我们HBase表用RowKey来横向切分表
 *  HRegion里边会有多个Store，每个Store其实就是一个列族的数据（所以我们可以说HBase是基于列族存储的）
 *  Store里边有Men Store和StoreFile(HFile)，其实就是先走一层内存，然后再刷到磁盘的结构

### 3.5 被遗忘的HMaster ###

我们在上面的图会看到有个**Hmaster**，它在HBase的架构中承担一种什么样的角色呢？**读写请求都没经过Hmaster呀**。

![format_png 20][]

那HMaster在HBase里承担什么样的角色呢？？

> `HMaster` is the implementation of the Master Server. The Master server is responsible for monitoring all RegionServer instances in the cluster, and is the interface for all metadata changes.

HMaster会处理 HRegion 的分配或转移。如果我们HRegion的数据量太大的话，HMaster会对拆分后的Region**重新分配RegionServer**。（如果发现失效的HRegion，也会将失效的HRegion分配到正常的HRegionServer中）

HMaster会处理元数据的变更和监控RegionServer的状态。

## 四、RowKey的设计 ##

到这里，我们已经知道RowKey是什么了。不难理解的是，我们肯定是要保证RowKey是**唯一**的，毕竟它是行键，有了它我们才可以唯一标识一条数据的。

在HBase里边提供了三种的查询方式：

1.  全局扫描
2.  根据一个RowKey进行查询
3.  根据RowKey过滤的**范围**查询

### 4.1 根据一个RowKey查询 ###

首先我们要知道的是RowKey是会按**字典序**排序的，我们HBase表会用RowKey来横向切分表。

无论是读和写我们都是用RowKey去定位到HRegion，然后找到HRegionServer。这里有一个很关键的问题：**那我怎么知道这个RowKey是在这个HRegion上的**？

HRegion上有两个很重要的属性：`start-key`和`end-key`。

我们在定位HRegionServer的时候，实际上就是定位我们这个RowKey在不在这个HRegion的`start-key`和`end-key`范围之内，如果在，说明我们就找到了。

这个时候会带来一个问题：由于我们的RowKey是以字典序排序的，如果我们对RowKey没有做任何处理，那就有可能存在**热点数据**的问题。

举个例子，现在我们的RowKey如下：

java3y111
    java3y222
    java3y333
    java3y444
    java3y555
    aaa
    bbb
    java3y777
    java3y666
    java3y...

`Java3yxxx`开头的RowKey很多，而其他的RowKey很少。如果我们有多个`HRegion`的话，那么存储`Java3yxxx`的HRegion的数据量是最大的，而分配给其他的HRegion数量是很少的。

关键是我们的查询也几乎都是以`java3yxxx`的数据去查，这会导致某部分数据会集中在某台HRegionServer上存储以及查询，而其他的HRegionServer却很空闲。

如果是这种情况，我们要做的是什么？对**RowKey散列**就好了，那分配到HRegion的时候就比较均匀，少了热点的问题。

> HBase优化手册：
> 
> 建表申请时的预分区设置，对于经常使用HBase的小伙伴来说,HBase管理平台里申请HBase表流程必然不陌生了。
> 
> ‘**给定split的RowKey组例如:aaaaa,bbbbb,ccccc;或给定例如:startKey=00000000,endKey=xxxxxxxx,regionsNum=x**’
> 
> **第一种方式**:
> 
> > 是自己指定RowKey的分割点来划分region个数.比如有一组数据RowKey为\[1,2,3,4,5,6,7\],此时给定split RowKey是3,6,那么就会划分为\[1,3),\[3,6),\[6,7)的三个初始region了.如果对于RowKey的组成及数据分布非常清楚的话,可以使用这种方式精确预分区.
> 
> **第二种方式** :
> 
> > 如果只是知道RowKey的组成大致的范围,可以选用这种方式让集群来均衡预分区,设定始末的RowKey,以及根据数据量给定大致的region数,一般建议region数最多不要超过集群的rs节点数,过多region数不但不能增加表访问性能,反而会增加master节点压力.如果给定始末RowKey范围与实际偏差较大的话,还是比较容易产生数据热点问题.
> 
> **最后:生成RowKey时,尽量进行加盐或者哈希的处理,这样很大程度上可以缓解数据热点问题.**

### 4.2根据RowKey范围查询 ###

上面的情况是针对通过RowKey单个查询的业务的，如果我们是根据RowKey范围查询的，那没必要上面那样做。

HBase将RowKey设计为字典序排序，如果不做限制，那很可能类似的RowKey存储在同一个HRegion中。那我正好有这个场景上的业务，那我查询的时候不是快多了吗？**在同一个HRegion就可以拿到我想要的数据了**。

举个例子：我们会间隔几秒就采集直播间热度，将这份数据写到HBase中，然后业务方经常要把主播的一段时间内的热度给查询出来。

我设计好的RowKey，将该主播的一段时间内的热度都写到同一个HRegion上，拉取的时候只要访问一个HRegionServer就可以得到全部我想要的数据了，那查询的速度就快很多。

## 最后 ##

最后三歪再来带着大家回顾一下这篇文章写了什么：

1.  HBase是一个NoSQL数据库，一般我们用它来存储海量的数据（因为它基于HDFS分布式文件系统上构建的）
2.  HBase的一行记录由一个RowKey和一个或多个的列以及它的值所组成。先有列族后有列，列可以随意添加。
3.  HBase的增删改记录都有「版本」，默认以时间戳的方式实现。
4.  RowKey的设计如果没有特殊的业务性，最好设计为散列的，这样避免热点数据分布在同一个HRegionServer中。
5.  HBase的读写都经过Zookeeper去拉取meta数据，定位到对应的HRegion，然后找到HRegionServer

## 各类知识点总结 ##

> 下面的文章都有对应的**原创精美**PDF，在持续更新中，可以来找我催更~

*  [92页的Mybatis][92_Mybatis]
 *  [129页的多线程][129]
 *  [141页的Servlet][141_Servlet]
 *  [158页的JSP][158_JSP]
 *  [76页的集合][76]
 *  [64页的JDBC][64_JDBC]
 *  [105页的数据结构和算法][105]
 *  [142页的Spring][142_Spring]
 *  [58页的过滤器和监听器][58]
 *  [30页的HTTP][30_HTTP]
 *  [42页的SpringMVC][42_SpringMVC]
 *  Hibernate
 *  AJAX
 *  Redis
 *  …

#### 涵盖Java后端所有知识点的开源项目（已有8K+ star）： ####

*  [GitHub][https_github.com_ZhongFuCheng3y_3y]
 *  [Gitee访问更快][Gitee]

如果大家想要**实时**关注我更新的文章以及分享的干货的话，微信搜索**Java3y**。

PDF文档的内容**均为手打**，有任何的不懂都可以直接**来问我**（公众号有我的联系方式）。

![format_png 21][]

![format_png 22][]

![aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA2dE5iUndseTFnYjBuenBuOHo3ZzMwZ28wZ29rYnAuZ2lm][]

**我是三歪，一个想要变强的男人，感谢大家的点赞收藏和转发，下期见。**

[https_github.com_ZhongFuCheng3y_3y]: https://github.com/ZhongFuCheng3y/3y
[format_png]: /images/20210827/eaa5d2f96ced464eb61d61d18a92bac0.png
[Apache]: https://www.apache.org/
[Hadoop]: https://hadoop.apache.org/
[format_png 1]: /images/20210827/831ac51ec5734954b44382357fe74970.png
[format_png 2]: /images/20210827/c68bcedfb0c54508b3ac79c9f94eafee.png
[format_png 3]: /images/20210827/21c96c379bfb4135aff9ef3c24b3bcef.png
[format_png 4]: /images/20210827/daed4879ba8047eb98866626558bbb60.png
[format_png 5]: /images/20210827/c3b84048c85f451ca25d74e36f821d9c.png
[format_png 6]: /images/20210827/e5c8005279354fea9a9615fdfb071587.png
[format_png 7]: /images/20210827/3c6170fe679144b381d92162a1cf56b8.png
[format_png 8]: /images/20210827/66fe8b0fbd7c4c23b4852f06648ee2f1.png
[format_png 9]: /images/20210827/8886630e66664ec6a57f433d3ae9bae2.png
[format_png 10]: /images/20210827/77d415e0dabf410ab110288503744b3c.png
[format_png 11]: /images/20210827/412280b071994b4aa56562753a3f3172.png
[format_png 12]: /images/20210827/9ed129ead1864c8686611f68f53d3466.png
[format_png 13]: /images/20210827/a7f06e1cce4f4ba09107e0364bd58b7f.png
[format_png 14]: /images/20210827/0038666dc2244b1cb2250aa4430e6528.png
[format_png 15]: /images/20210827/5c6a648aa00947e0b71ff066298f88c4.png
[format_png 16]: /images/20210827/cec80e0173964e4a9a980135a77fa543.png
[format_png 17]: /images/20210827/659d7000d57f497b9407c141d8be3136.png
[format_png 18]: /images/20210827/0160f42eda6140daa027c288c30718b1.png
[format_png 19]: /images/20210827/857f779df14445e99dff35c4ba170e09.png
[format_png 20]: /images/20210827/413766c9ac624f6d9e0a29a8abc7ad09.png
[92_Mybatis]: https://mp.weixin.qq.com/s/0_zTBooRV4RTWQa8VOwiWg
[129]: https://mp.weixin.qq.com/s/r7IrmvBxG5W0hswfcgFjcQ
[141_Servlet]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486798&idx=1&sn=ce900e97a495ffd681cd0ad9b78aa5ca&chksm=ebd74c4fdca0c559d0a32a3f3ddb3f579d3a16b47f70234c46ac2e5df315e7df90f93d1715b9&token=1109491988&lang=zh_CN#rd
[158_JSP]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486854&idx=1&sn=fd77a6225b898b69c4f0e1a7e66cf105&chksm=ebd74c87dca0c5910a923a443ea6f694dd554b68df8cc00506570555b9cf7718a2ef2a058754&token=1109491988&lang=zh_CN#rd
[76]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486873&idx=1&sn=ce0752f481336ffba9b8f44265b2550e&chksm=ebd74c98dca0c58ee04162d7e5d07fd36c8ec1b32460a8a2396168a9fc5885a208810f0916f2&token=1109491988&lang=zh_CN#rd
[64_JDBC]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486905&idx=1&sn=67fcd0558cfbdf6cd36de98cbd93afaf&chksm=ebd74cb8dca0c5ae052e6d216ed13458a9a17fa1b0f245bf740379b1d4b04b4e55fcbfb5adb4&token=1109491988&lang=zh_CN#rd
[105]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486831&idx=1&sn=0d4b05e10d66eda1129f43348a8e3952&chksm=ebd74c6edca0c5786a5109a131d0501ef6bd02077e5ce1ad75d906cf3612a320d1098163e2d0&token=1109491988&lang=zh_CN#rd
[142_Spring]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247487013&idx=1&sn=f0d8c292738eb49bcd09cb2f6458dc69&chksm=ebd74f24dca0c632fa3ef8f205a2dd5c96531f78a68eae805e15b84de0b59774196a188aed14&token=306734573&lang=zh_CN#rd
[58]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247487054&idx=1&sn=25f92798050d092027931e2ae0379e90&chksm=ebd74f4fdca0c6595bc795fd00354cf683d4593550cdd38ba7103893dd622606fc8f55fe6631&token=306734573&lang=zh_CN#rd
[30_HTTP]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247487071&idx=1&sn=511459730b3114fc77c60b82b54159b8&chksm=ebd74f5edca0c648c9b0c572fbc7fdbc26179ddcd7c45de37c06b6a2906a8ffc207f145b66f2&token=480724592&lang=zh_CN#rd
[42_SpringMVC]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247487665&idx=1&sn=cffb9d634a8b770562557b72a833e591&chksm=ebd751b0dca0d8a604d89b1e3c5d1728f35b752368f5a878311066cbc09ff8a5905ad05690c7&token=634601022&lang=zh_CN#rd
[Gitee]: https://gitee.com/zhongfucheng/Java3y
[format_png 21]: /images/20210827/6e8cad49946641daa77000b93a4d6741.png
[format_png 22]: /images/20210827/c1af7ee99c904e02b446e3c957e81c93.png
[aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA2dE5iUndseTFnYjBuenBuOHo3ZzMwZ28wZ29rYnAuZ2lm]: /images/20210827/25b339cad8e847068bd7b7ed93c08c62.png

发表评论取消回复

表情：

评论列表（有 0 条评论，295人围观）

还没有评论，来说两句吧...

相关阅读

相关 B树？这篇文章彻底看懂了！

前言索引，相信大多数人已经相当熟悉了，很多人都知道 MySQL 的索引主要以 B+ 树为主，但是要问到为什么用 B+ 树，恐怕很少有人能把前因后果讲述完整。本文就来从头

绝地灬酷狼/ 2023年06月12日 11:26/ 0 赞/ 26 阅读

相关看了这篇文章，我终于搞懂了强化学习！

对大脑的工作领域，我们知之甚少，但是我们知道的是，大脑能够通过反复尝试来学习知识。当我们做了合适的选择时，大脑就会给我们奖励，但当我们做了错误的抉择时，大脑就会惩罚我们。如果我

缺乏、安全感/ 2022年11月27日 01:00/ 0 赞/ 292 阅读

相关这篇文章让你搞懂 SpringMVC 国际化！

松哥之前写过 Spring Boot 国际化的问题，不过那一次没讲源码，这次咱们整点源码来深入理解下这个问题。国际化，也叫 i18n，为啥叫这个名字呢？因为国际化英文是 i

清疚/ 2022年10月08日 11:10/ 0 赞/ 285 阅读

相关看完这篇文章，我奶奶都懂了https的原理

Http存在的问题上过网的朋友都知道，网络是非常不安全的。尤其是公共场所很多免费的wifi，或许只是攻击者的一个诱饵。还有大家平时喜欢用的万能钥匙，等等。那我们平时

爱被打了一巴掌/ 2022年01月24日 00:15/ 0 赞/ 325 阅读

相关看完这篇文章，我奶奶都懂了https的原理

> 本文在个人技术博客同步发布，详情[可猛戳][Link 1] Http存在的问题上过网的朋友都知道，网络是非常不安全的。尤其是公共场所很多免费的wifi，或许只

迷南。/ 2022年01月19日 03:21/ 0 赞/ 279 阅读

相关看完这篇文章，我奶奶都懂了https的原理

Http存在的问题上过网的朋友都知道，网络是非常不安全的。尤其是公共场所很多免费的wifi，或许只是攻击者的一个诱饵。还有大家平时喜欢用的万能钥匙，等等。那我们平时

旧城等待，/ 2021年09月19日 15:06/ 0 赞/ 422 阅读

相关真没想到，疫情让我实现了远程办公的夙愿

![1179389-78315859f7dd1257.png][] 昨天晚上，公号后台收到了一位读者小武的多条留言（内容大致如下），竟然让我心有戚戚焉。 > 二哥，真没想到

骑猪看日落/ 2021年09月12日 01:18/ 0 赞/ 293 阅读

相关真没想到，这篇文章能让我看懂HBase

前言 > 只有光头才能变强。 > 文本已收录至我的GitHub精选文章，欢迎Star：[https://github.com/ZhongFuCheng3y/3y][ht

你的名字/ 2021年08月29日 23:55/ 0 赞/ 296 阅读

相关不懂 Zookeeper？来看看这篇文章

![1803089889.png][] 开源Linux 长按二维码加关注~ ![undefined][] ![format_png][] 高并发分布式开发技术体系

水深无声/ 2021年07月26日 11:47/ 0 赞/ 532 阅读

相关真没想到，疫情让我实现了远程办公的夙愿

![format_png_pic_center][] 昨天晚上，公号后台收到了一位读者小武的多条留言（内容大致如下），竟然让我心有戚戚焉。 > 二哥，真没想到，疫情让我实现

系统管理员/ 2021年05月12日 11:49/ 0 赞/ 444 阅读