个人学习笔记

如：[^a]bc，表示匹配bc，但不匹配abc

匹配pattern并获取这一匹配。所获取的匹配可以从产生的Matches集合得到

匹配pattern但不获取匹配结果，也就是说这是一个非获取匹配，不进行存储供以后使用。
这在使用或字符“(|)”来组合一个模式的各个部分是很有用。
例如“industr(?:y|ies)”就是一个比“industry|industries”更简略的表达式。

xxx(?=pattern)

xxx(?!pattern)

(?<=pattern)xxx

(?<!pattern)xxx

在子模式内部前面添加“?:” （？：），即为非获取匹配

Windows 95 and Windows 98 are the successor.Then Windows 2000 and Windows Xp appeared.Windows Vista is the Latest version of the family.

Windows 95 Windows 98 Windows 2000 Windows Xp Windows Vista

[^win].*

Windows2008

dows2008

[w^n]

adin^dows

n
^
w

连接所有指定文件并将结果写到标准输出

显示文件，可以连接多个文件形成新文件

cat [选项] ... [文件]...

常用选项

1. cat > output.txt

2. cat >>output.txt

3. cat test.txt - command.txt

more

less

格式

常用选项

按Enter键向下逐行滚动 按空格键向下翻一屏、按b键向上翻一屏 文件末尾时more会自动退出，less 按q键退出

1.  less可以按键盘上下方向键显示上下内容,more不能通过上下方向键控制显示 2.  less不必读整个文件，加载速度会比more更快 3.  less退出后shell不会留下刚显示的内容,而more退出后会在shell上留下刚显示的内容

head

tail

格式

常用选项

按Enter键向下逐行滚动 按空格键向下翻一屏、按b键向上翻一屏 文件末尾时more会自动退出，less 按q键退出

head|tail -3 aa.txt

从文件或标准输入中，搜索匹配指定正则pattern的文本内容。
grep来自于英文词组“global search regular expression and print out the line”的缩写，意思是用于全面搜索的正则表达式，并将结果输出。人们通常会将grep命令与正则表达式搭配使用，参数作为搜索过程中的补充或对输出结果的筛选，命令模式十分灵活。

与之容易混淆的是egrep命令和fgrep命令。如果把grep命令当作是标准搜索命令，那么egrep则是扩展搜索命令，等价于“grep -E”命令，支持扩展的正则表达式。而fgrep则是快速搜索命令，等价于“grep -F”命令，不支持正则表达式，直接按照字符串内容进行匹配。

grep [选项] pattern 文件

-i 忽略大小写 -c 只输出匹配行的数量 -l 只列出符合匹配的文件名，不列出具体的匹配行 -n 列出所有的匹配行，显示行号 -h 查询多文件时不显示文件名 -s 不显示不存在、没有匹配文本的错误信息 -v 显示不包含匹配文本的所有行 -w 匹配整词 -x 匹配整行 -r 递归搜索 -q 禁止输出任何结果，已退出状态表示搜索是否成功 -b 打印匹配行距文件头部的偏移量，以字节为单位 -o 与-b结合使用，打印匹配的词据文件头部的偏移量，以字节为单位 -F 匹配固定字符串的内容 -E 支持扩展的正则表达式

搜索某个文件（/etc/passwd）中，包含某个关键词(root)的内容

搜索某个文件中，以某个关键词开头的内容

搜索多个文件中，包含某个关键词的内容

输出在某个（些）文件中，包含某个关键词行的数量

搜索某个文件中，不包含某个关键词的内容

搜索当前工作目录中，包含某个关键词内容的文件（-l 只列文件名），未找到则提示

搜索当前工作目录中，包含某个关键词内容的文件（-l 只列文件名），未找到不提示(-s)

递归搜索，不仅搜索指定目录，还搜索其内子目录内是否有关键词文件

搜索某个文件中，精准匹配到某个关键词的内容（搜索词应与整行内容完全一样才会显示 -x，有别于一般搜索）

判断某个文件中，是否包含某个关键词，通过返回状态值输出结果（0为包含，1为不包含,-q），方便在Shell脚本中判断和调用

搜索某个文件中，空行(正则表达式为^$)的数量

-type #根据文件类型 find /var/log -type f -name "*.log" ；find /var/log -type d
-name #根据文件名 find /var/log -type f -name "*.log"
-perm #根据文件权限 find /var/log -perm 600 -type f -name "*.log"
-user #根据文件所属主 find /var/log -user XD

列出/etc及子目录下的所有文件和目录

搜索当前目录（含子目录，以下同）中，所有文件名以my开头的文件。

搜索当前目录中，所有过去10分钟中更新过的普通文件。如果不加-type f参数，则搜索普通文件+特殊文件+目录。

搜索/etc目录下的.log文件

[root@linuxcool ~]# find / -name *.conf
/run/tmpfiles.d/kmod.conf
/etc/resolv.conf
/etc/dnf/dnf.conf
/etc/dnf/plugins/copr.conf
/etc/dnf/plugins/debuginfo-install.conf
/etc/dnf/plugins/product-id.conf
/etc/dnf/plugins/subscription-manager.conf

[root@linuxcool ~]# find /etc -size +1M
/etc/selinux/targeted/policy/policy.31
/etc/udev/hwdb.bin

[root@linuxcool ~]# find /home -user linuxprobe
/home/linuxprobe
/home/linuxprobe/.mozilla
/home/linuxprobe/.mozilla/extensions
/home/linuxprobe/.mozilla/plugins
/home/linuxprobe/.bash_logout
/home/linuxprobe/.bash_profile
/home/linuxprobe/.bashrc

[root@linuxcool ~]# find .
.
./.bash_logout
./.bash_profile
./.bashrc
./.cshrc
./.tcshrc
./anaconda-ks.cfg

[root@linuxcool ~]# find /var/log -iname "*.log"
/var/log/audit/audit.log
/var/log/rhsm/rhsmcertd.log
/var/log/rhsm/rhsm.log
/var/log/sssd/sssd.log
/var/log/sssd/sssd_implicit_files.log
/var/log/sssd/sssd_nss.log

[root@linuxcool ~]# find /var/log ! -name "*.log"
/var/log
/var/log/lastlog
/var/log/README

[root@linuxcool ~]# find . -mtime +7
./.bash_logout
./.bash_profile

[root@linuxcool ~]# find / -type d -perm 1777
/dev/mqueue
/dev/shm
/var/tmp

[root@linuxcool ~]# find / -type f -perm /a=x 
/boot/vmlinuz-4.18.0-80.el8.x86_64
/boot/vmlinuz-0-rescue-c8b04558503242459d908c6c22a2d481
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh

[root@linuxcool ~]# find / -name "*.mp4" -exec rm -rf {} \;

Eden

From Survivor （Survivor0 , S0）

To Survivor（Survivor1，S1）

如果两个对象互相引用，那么就意味着两个对象永久性的无法被回收?对象无法被回收，显然这种方法时不行的

1. 标记

2. 清除

这种回收算法：因为需要遍历所有的对象，所以是比较耗时的

标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程
序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
(1)标记和清除两个过程都比较耗时，效率不高
(2)会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存
   而不得不提前触发另一次垃圾收集动作。

复制算法

将内存分为大小相等的两块，每次我们只使用其中一块

当前正在使用的这一块使用完了之后，就会把LiveObject 对象移动到另外一半上，其他的被回收掉

子主题

不会产生内存碎片

有一半的内存空间l浪费

分代垃圾收集

标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，
  然后直接清理掉端边界以外的内存

有些对象生命周期比较长，短期内不会死亡

有些对象生命周期短，很快就会死亡而希望被快速回收

存放生命周期短，很快就会死亡而希望被快速回收的对象

特点

根据上述特点，对这块区域的要求

回收算法

回收机制

存放生命周期长，很长时间都不会死亡的对象

对象在新生代被创建后，若其生命周期比较长，就会被移动到老年代，因此老年代是存放生命周期比较长的对象的区域，对象回收周期比较长，不会被频繁GC，当老年代内存不足时，会触发Full GC

当老年代满时会触发MajorGC，只有CMS收集器会有单独收集老年代的行为，其他收集器均为Full GC。而针对新生代的Minor GC，各个收集器均支持。总之，单独发生收集行为的只有新生代，除了CMS收集器，都不支持老年代单独GC。

采用串行单线程方式完成GC任务，其中“Stop The World"简称STW，即垃圾回收的某个阶段会暂停整个应用程序的执行
F-GC的时间相对较长，频繁FGC会严重影响应用程序的性能。

一般客户端应用所需内存较小,不会创建太多的对象,而且堆内存不大,因此垃圾回收时间比较短,即使在这段时间停止一切用户线程,也不会感到明显停顿.

由于Serial收集器只有一条GC线程,避免了线程切换的开销.

ParNew由多条GC线程并行地进行垃圾清理.但清理过程仍然需要STW.但由于有多条GC线程同时清理,清理速度比Serial有一定的提升.

默认开启的收集线程数与CPU数量相同.

由于使用了多线程,因此适合CPU较多的服务器环境

和Serial相比,ParNew使用多线程的目的就是缩短垃圾收集时间,从而减少用户线程被停顿的时间.

良好的反应速度提升用户体验.

ParNew和Serial唯一区别就是使用了多线程进行垃圾回收,在多CPU的环境下性能比Serial会有一定程度的提升;但线程切换需要额外的开销,因此在单CPU环境中表现不如Serial,双CPU环境也不一定就比Serial高效.

ParNew收集器追求降低GC时用户线程的停顿时间,适合交互式应用,良好的反应速度提升用户体验.

Parallel Scavenge追求CPU吞吐量,能够在较短的时间内完成指定任务,因此适合不需要太多交互的后台运算.

吞吐量是指用户线程运行时间占CPU总时间的比例.

降低停顿时间的两种方式

-XX:GCTimeRadio

-XX:MaxGCPauseMillis
设置最大GC停顿时间.
Parallel Scavenge会根据这个值的大小确定新生代的大小.如果这个值越小,新生代就会越小,从而收集器就能以较短的时间进行一次回收;但新生代变小后,回收的频率就会提高,吞吐量也降下来了,因此要合理控制这个值.

-XX:+UseAdaptiveSizePolicy

HotSpot VM里多个GC有部分共享的代码。有一个分代式GC框架，Serial/Serial Old/ParNew/CMS都在这个框架内；在该框架内的young collector和old collector可以任意搭配使用，所谓的“mix-and-match”。

而ParallelScavenge（与G1）则不在这个框架内，而是各自采用了自己特别的框架，所以不能跟使用了那个框架的CMS搭配使用。

与Serial唯一的区别就是Serial Old工作在老年代,使用"标记-整理"算法;而Serial工作在新生代,使用"复制"算法.

由于在GC过程中没有使垃圾收集和用户线程并行执行,因此它们是追求吞吐量的垃圾收集器.

回收停顿时间比较短，对许多应用来说，快速响应比端到端的吞吐量更为重要。

吞吐量低

无法处理浮动垃圾,导致频繁Full GC

使用"标记-清除"算法产生碎片空间

漏标问题

由于G1的出现，CMS在Java 9中已被废弃。

是一个横跨新生代和老年代的垃圾回收器。实际上，它已经打乱了前面所说的堆结构，直接将堆分成极其多个区域。每个区域都可以充当Eden区、Survivor区或者老年代中的一个。它采用的是标记-压缩算法，而且和CMS一样都能够在应用程序运行过程中并发地进行垃圾回收。

虽然G1依然有分代内存划分，但抛弃了连续的分代，他们可以是一些不连续的Region集合，正因为这样，每一个Region区域的功能会发生变化，比如一个Region之前按是年轻代，在做完垃圾回收之后又变成了老年代。

G1能够针对每个细分的区域来进行垃圾回收。在每次GC发生时会根据「用户指定的期望停顿时间或默认的期望停顿时间」，优先从列表中选择「回收价值最大（优先回收死亡对象较多的区域）」Region区回收，这也是G1名字的由来。

和CMS相比，Gl具备压缩功能，能避免碎片向題，G1的暂停时间更加可控。性能总体还是非常不错的，G1是当今最前沿的垃圾收集器成果之一

可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收

追求停顿时间

多线程GC

面向服务端应用

不会产生内存空间碎片.

可对整个堆进行垃圾回收

并行与并发

分代收集

空间整合

可预测的停顿时间

没有分代概念,而是将Java堆划分为一块块独立的大小相等的独立内存块Region.当要进行垃圾收集时,首先估计每个Region中的垃圾数量,每次都从垃圾回收价值最大的Region开始回收,因此可以获得最大的回收效率.

G1将Java堆空间分割成了许多相同大小的区域，即region

可达性分析快，不需要扫描整个堆内存

能够针对每个细分的区域来进行垃圾回收

优先回收垃圾最多的区域

采用的是Mark-Copy ，有非常好的空间整合能力,不会产生大量的空间碎片

初始标记

并发标记

最终标记

筛选回收

minor gc

mixed gc

full gc

年轻代比例配置

大对象

一大优势在于可预测的停顿时间,能够个由用户指定「GC回收过程中的期望停顿时间」是G1的一大亮点，G1会尽可能快地在指定时间内完成垃圾回收任务

50%以上的堆被存活对象占用

对象分配和晋升的速度变化非常大

垃圾回收时间特别长，超过1秒

8GB以上的堆内存(建议值)

停顿时间是500ms以内

https://blog.csdn.net/qq_41931364/article/details/107040928

https://blog.csdn.net/a745233700/article/details/121724998

一款源自于JDK11的性能魔兽 - ZGC

是一款基于分区概念的内存布局GC器，这款GC器是真正意义上的不分代收集器，因为它无论是从逻辑上，还是物理上都不再保留分代的概念

ZGC也会把堆空间划分为一个个的Region区域，但ZGC中的Region区不存在分代的概念，仅仅只是简单的将所有Region区分为了大、中、小三个等级

使用读屏障、染色指针和内存多重映射等技术来实现的可并发的标记-整理算法的垃圾收集器。

由于不分代，ZGC中只存在一种GC类型，同时也不需要G1中Remembered Set这种概念存在，因为是单代的堆空间，所以每次回收都是扫描所有页面，不需要额外解决跨代引用问题。

ZGC主打的是超低延迟与吞吐量，在实现时，ZGC也会在尽可能堆吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾回收的停顿时间限制在10ms以内的低延迟

ZGC与GC收集器一样，也会存在「垃圾优先」的特性，在标记完成后，整个堆中会有很多分区可以回收，ZGC也会筛选出回收价值最大的页面来作为本次GC回收的目标。

基于64位指针实现的染色指针技术，最大支持16TB JVM

低延迟

ZGC不会因为堆空间的扩大而增大停顿时间

ZGC与之前的收集器还有一点很大的不同在于：ZGC标记的是指针而并非对象，但最终达到的效果是等价的，因为所有对象以及所有指针都会被遍历。

ZGC的不分代其实是它的缺点，因为对象都是满足朝生夕死的特性，ZGC不分代只是因为分代比较难实现。

ZGC最初是源于Azul System公司的C4(Concurrent Continuously Compacting Collector)收集器与PauselessGC，Java引入ZGC的目的主要有如下四点

ZGC的内存结构实际上被称为分页，源于Linux Kernel 2.6中引入了标准的大页huge page

也会把堆空间划分为一个个的Region区域，但ZGC中的Region区不存在分代的概念，它仅仅只是简单的将所有Region(ZGC实际不叫Region，而是叫ZPage)区分为了大、中、小三个等级

ZPage具有动态性

ZGC最大的问题是浮动垃圾

https://blog.csdn.net/weixin_45101064/article/details/123478022

在JDK11中推出ZGC后，JDK12马不停蹄的推出了ShenandoahGC收集器，它与G1、ZGC收集器一样，都是基于分区结构实现的一款收集器。

和ZGC对比

和G1比

ShenandoahGC核心-BrooksPointers转发指针

最大支持256TB JVM

退出当前session时zk服务器会自动向所有连接它的客户端发送子节点移除事件

一个HDFS文件由一个个块（Block）组成

每个块会设置N个副本

元数据维护类组件

数据存储类组件

写入流程

读取流程

HDFS擅长的场景是大文件顺序写、顺序读、随机读

不支持随机写以及多个客户端同时写一个文件

2B

1B

用于多版本控制

8B：时间戳的long值

值越大，排序越靠前

PUT/DELETE/Delete Column/Delete Family

1字节

无论PUT还是DELE，写入的都并非数据本身，而是操作记录，如PUT/DELETE一条rowid为1的记录

无论PUT还是DELE，落盘时都是Append操作，没有任何随机写操作

LSM对写入是极为友好的索引结构，能将磁盘的写入贷款利用到极致

但对读取操作非常不利，需要做多路归并(compact)

内存部分即MemStore

写入时，先写入MemStore

当MemStore写满（阈值可配）时，会flush到磁盘，生成一个数据块文件

由一个个独立的文件组成

每个文件是一个LSM块

随着不断写入磁盘，文件（数据块）数量越来越多

设定一个数组，长度为N，每个元素的值要么为0，要么为1

设定一个长度为N的数组和一个整数K

对于要存储的集合c中的每一个元素w

用于检索指定的元素m是否在集合c中

布隆过滤器占用占用极少的空间

可迅速给定某个（而非一批）元素m一定不在集合m中或可能在集合m中的判断，性能极高

若判断某个元素m一定不在集合中，就不需要进一步比对数据内容，可大大节省磁盘I/O，提高效率

每一个LSM文件（数据块）对应一个布隆过滤器

在Hbase 1.x中，用好可以对某些列设置不同的布隆过滤器，共有3种类型

对普通的scan操作，由于操作的是一批数据，rowkey不确定，因此无法利用布隆过滤器特性来提升扫描性能

HDFS擅长的场景是大文件顺序写、顺序读、随机读

不支持随机写以及多个客户端同时写一个文件

active master通常只有一个，当该active master发生异常时，zk会选举出一个slave master作为active master

hbase:meta记录整个hbase集群的Region信息

表定义

表分区（Region）及所在的RegionServer

zk通过心跳可感知到RS是否宕机，并在宕机后通知master进行宕机处理

Hbase对表进行各种管理操作（如alter操作）需要先对表上锁

zk集群的地址

默认为2181

表示zk与RS之间的会话超时时间

默认值:/hbase

meta-region-server

backup-masters

table

region-in-transition

table-block

master

balancer

namespace

hbaseid

online-snapshot

replication

split-WAL

recovering-regions

rs

MemStore（1）

HFile（*）

用户执行snapshot后，相关的snapshot元数据文件存储在该目录

主要用于hbase表的创建和删除操作

Master Procedure功能主要用于可恢复的分布式DDL操作

所有对HFile文件的删除操作都会将待删除文件临时放在该目录

进行snapshot或者升级时使用到的归档目录

Compaction删除HFile的时候，也会把旧的Hfile移动到这里

HFile文件在data目录下的完整路径为

.tabledesc

.tmp

.regioninfo

recovered.edits

admin.tableExists(TableName.valueOf(tableNameStr));

        TableDescriptorBuilder tableDesc = TableDescriptorBuilder.newBuilder(TableName.valueOf(tableName));

        List<ColumnFamilyDescriptor> colFamilyList = new ArrayList<>();
        for (String columnFamilys : list) {
            ColumnFamilyDescriptorBuilder c = ColumnFamilyDescriptorBuilder.newBuilder(Bytes.toBytes(columnFamilys));
            colFamilyList.add(c.build());
        }
        tableDesc.setColumnFamilies(colFamilyList);

        //创建表方式1：直接创建
        admin.createTable(tableDesc.build());
        //创建表方式2：预分区创建
        //  admin.createTable(tableDesc.build(), new RegionSplitter.HexStringSplit().split(splitNum));

            TableName table = TableName.valueOf(tableName);
            if (admin.tableExists(table)) {
                //先禁用后删除
                admin.disableTable(table);
                admin.deleteTable(table);
            }

    // 向表中添加一个列族
    public static void addColumnFamily(String myTableName, String colFamily) throws IOException {
        Admin admin = hbaseLocalTestingUtil.getHbaseAdmin();
        TableName tableName = TableName.valueOf(myTableName);
        if (admin.tableExists(tableName)) {
            ColumnFamilyDescriptor colFamilyDes = ColumnFamilyDescriptorBuilder.newBuilder(colFamily.getBytes()).build();
            admin.addColumnFamily(tableName, colFamilyDes);
        }
    }

    // 从表中移除一个列族
    public static void removeColumnFamily(String myTableName, String colFamily) throws IOException {
        Admin admin = hbaseLocalTestingUtil.getHbaseAdmin();
        TableName tableName = TableName.valueOf(myTableName);
        if (admin.tableExists(tableName)) {
            admin.deleteColumnFamily(tableName, colFamily.getBytes());
            System.out.println("remove " + colFamily + " successful!");
        }
    }

    /*put list数据*/
    public static boolean putList(String tablename, List<HbaseMessage> listMessage) {
        Table table = null;

        //用于存放失败数据
        List<Row> errorList = new ArrayList<Row>();
        try {
            table = connection.getTable(TableName.valueOf(tablename));
            ArrayList<Put> puts = new ArrayList<>();

            for (HbaseMessage message : listMessage) {

                Put put = new Put(Bytes.toBytes(message.getKVmessagr().get("ID").toString()));
                Map kVmessagr = message.getKVmessagr();
                Iterator iterator = kVmessagr.keySet().iterator();
                while (iterator.hasNext()) {
                    String key = iterator.next().toString();
                    put.addColumn(Bytes.toBytes(message.getCloumnFamil()), Bytes.toBytes(key), Bytes.toBytes(kVmessagr.get(key).toString()));
                }
                puts.add(put);
            }
            table.put(puts);

        } catch (IOException e) {
            e.printStackTrace();
           /*
            如果是RetriesExhaustedWithDetailsException类型的异常，
            说明这些数据中有部分是写入失败的这通常都是因为
             1：HBase集群的进程异常引起
            2：有时也会因为有大量的Region正在被转移，导致尝试一定的次数后失败
            */
            if (e instanceof RetriesExhaustedWithDetailsException) {
                RetriesExhaustedWithDetailsException ree =
                        (RetriesExhaustedWithDetailsException) e;
                int failures = ree.getNumExceptions();
                for (int i = 0; i < failures; i++) {
                    errorList.add(ree.getRow(i));
                }
            }
        } finally {
            if (table != null) {
                try {
                    table.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return true;
    }

    /*put单条数据*/
    public static boolean putRow(String tableName, String rowKey, String columnFamilyName, String qualifier,
                                 String value) {
        //用于存放失败数据
        List<Row> errorList = new ArrayList<Row>();

        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Put put = new Put(Bytes.toBytes(rowKey));
            put.addColumn(Bytes.toBytes(columnFamilyName), Bytes.toBytes(qualifier), Bytes.toBytes(value));
            table.put(put);
            table.close();
        } catch (IOException e) {
            e.printStackTrace();

            if (e instanceof RetriesExhaustedWithDetailsException) {
                RetriesExhaustedWithDetailsException ree =
                        (RetriesExhaustedWithDetailsException) e;
                int failures = ree.getNumExceptions();
                for (int i = 0; i < failures; i++) {
                    errorList.add(ree.getRow(i));
                }
            }
        }
        return true;
    }

/*判断rk数据是否存在*/
    public static boolean existsRowKey(String tableName, String rowkey) {
        boolean exists = false;
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Get get = new Get(Bytes.toBytes(rowkey));
            if (!get.isCheckExistenceOnly()) {
                //数据存在
                exists = table.exists(get);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        return exists;
    }

/*判断某条数据的某列是否存在*/
    public static boolean existsColumn(String tableName, String row, String family) {

        boolean exists = false;
        try {
            Get get = new Get(Bytes.toBytes(row));
            get.addFamily(Bytes.toBytes(family));
            Table table = connection.getTable(TableName.valueOf(tableName));
            exists = table.exists(get);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return exists;
    }

/*get查询某条某列数据：指定表，rowkey,列*/
    public static String getCell(String tableName, String rowKey, String columnFamily, String qualifier) {
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Get get = new Get(Bytes.toBytes(rowKey));
            //校验数据是否存在
            if (!get.isCheckExistenceOnly()) {
                get.addColumn(Bytes.toBytes(columnFamily), Bytes.toBytes(qualifier));
                Result result = table.get(get);
                byte[] resultValue = result.getValue(Bytes.toBytes(columnFamily), Bytes.toBytes(qualifier));
                return Bytes.toString(resultValue);
            } else {
                return null;
            }

        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

    /**
     * 指定rk get一条数据
     *
     * @param columnFamily 列簇
     */
    public static Map<byte[], byte[]> getCellFromRowKey(String tableName, String rowKey, String columnFamily) {
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Get get = new Get(Bytes.toBytes(rowKey));
            Result result = table.get(get);
            NavigableMap<byte[], byte[]> familyMap = result.getFamilyMap(Bytes.toBytes(columnFamily));

            return familyMap;
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

/**
     * 查询全表
     */
    public static ResultScanner getScanner(String tableName) {
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Scan scan = new Scan();
            return table.getScanner(scan);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }


    /**
     * 查询表中用过滤器指定数据
     *
     * @param tableName  表名
     * @param filterList 过滤器
     */

    public static ResultScanner getScanner(String tableName, FilterList filterList) {
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Scan scan = new Scan();
            scan.setFilter(filterList);
            return table.getScanner(scan);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

    /**
     * 检索表中根据rowkey范围指定数据
     *
     * @param tableName   表名
     * @param startRowKey 起始 RowKey
     * @param endRowKey   终止 RowKey
     * @param filterList  过滤器
     */

    public static ResultScanner getScanner(String tableName, String startRowKey, String endRowKey, FilterList filterList) {
        try {
            Table table = connection.getTable(TableName.valueOf(tableName));
            Scan scan = new Scan();
            scan.withStartRow(Bytes.toBytes(startRowKey));
            scan.withStopRow(Bytes.toBytes(endRowKey));
            scan.setFilter(filterList);
            return table.getScanner(scan);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

Scan scan = new Scan();
scan.withStartRow(Bytes.toBytes("def"));
scan.setFilter(new PrefixFilter(Bytes.toBytes("def")));

Scan scan = new Scan();
scan.withStartRow(Bytes.toBytes("def"));
scan.withStopRow(Bytes.toBytes("deg"));

重试策略

注意，get/put/delete等表操作称为一次API操作，一次API可能会有多次RPC重试，这个operation.timeout限制的是API操作的总超时。

1. 追加写入HLog（即WAL） p97-p98

2. 随机写入MemStore p98中

为了写数据期间实现读写一致性，需要一致性控制，采取的机制是MVCC (Multiversion Concurrency Control)

1. MemStore级别限制

2. Region级别限制

3. Region Server级别限制：

4. Region Server中HLog数量或内存占用空间限制

5. HBase定期刷新Memstore

6. 手动flush

7.数据更新操作引起

以Region为单位进行flush。
只要Region中有一个MemStore触发了flush，
则这个Region中的所有MemStore（无论是否写满）都需要flush

为了减少flush过程对读写的影响，HBase采用了类似
于两阶段提交的方式，将整个flush过程分为三个阶段

flush操作会阻塞用户的写请求，会对用户业务产生影响