1.1. 是什么

简单来说，用户增长（User Growth/UG）的根本目的是为了扩大产品的用户群，为企业带来收入和利润增长，进而实现商业成功。

由业产研、数据等多部门协同，围绕产品的三个阶段（产品前的分析、产品中的运营、产品后的突破），实现用户的拉新、促活、留存、变现、裂变的高效率、低成本的增长体系

1.2. 用户增长的三个阶段

1. 产品出现之前的用户增长：洞察用户需求，找到驱动用户增长的根本因素
2. 产品生命周期内的用户增长：有了产品之后，快速引爆用户增长
3. 突破产品生命周期的用户增长：开启用户增长的第二曲线

通过对于上面三个阶段的不断循环，不断开创app新的增长曲线

2. 如何实现用户增长

2.1. 建目标

2.1.1. 第一步：找到产品的核心价值

核心价值可以理解为，产品使用时有眼前一亮的感觉的时刻，说明用户真正发现了产品的核心价值 -- 产品为何存在、他们为何需要它以及他们能从中获得什么的时刻。正是在“啊哈时刻”，用户认识到了这个产品对他们来说为什么不可或缺

可以考虑用如下手段挖掘：

1. 不可或缺性调查：向产品的活跃用户询问如果无法继续使用产品的“失望”程度，是否存在完全可替代的竞品等。
2. 衡量用户留存率：如果留存率不稳定或者留存率非常低，说明产品仍然没有核心用户群。
3. 实地到访客户

2.1.2. 第二步：明确增长杠杆

增长杠杆：识别与增长相关的关键因素以及衡量指标，明确发力点和方向

明确过程可以大致划分如下：

1. 详细的数据调研：在建立基本增长等式并确定北极星指标之前，前提是能够收集用户行为数据并衡量产品表现和实验结果。没有科学全面的数据分析能力支撑，所有对产品表现和实验结果的假设都是无从验证的。因此首先需要整合所有的数据资源，对用户整个体验过程进行明确的跟踪（每个环节都有不同的指标，见1.2）。
2. 建议基本增长等式：基本增长等式（fundamental growth equation）是一个汇总了所有与增长相关的关键因素的简单等式，这些因素共同驱动企业的增长。基本增长等式是增长杠杆的集合，注意每个产品或企业的等式很可能是不相同的。

例如 eBay 的等式如下：

发布物品的卖家数量 x 发布物品的数量 x 买家数量 x 成功交易数量 = 总商品增长数量

一句话总结下：

增长等式可以简单理解为产品中不同用户角色的关键（核心）行为，例如HK钱包而言，最核心的业务行为就是用户支付，商户入驻等，那么增长杠杆明显就是：用户支付 x 入驻商户数

1. 确定“北极星指标”

建立基本增长等式后，为了缩小关注范围，最好能够选择一个关键的能够决定最终成败的指标，用以指导后续所有的增长活动。增长黑客们一般将这样的指标称为“北极星指标”，意味着这个指标会向北极星一样指引团队持续关注长期可持续的用户增长，不会被一个短期增长手段蒙蔽双眼。

北极星指标应该能够精准捕捉到企业为用户创造的核心价值。要确定这个指标，可以关注基本增长等式中与“产品核心价值”最密切相关的变量。

简单来说就是两个点：

1. 反映业务价值
2. 容易沟通
3. 顺应业务阶段

例如：HK钱包的“北极星指标”指标就可以为用户TPV

2.2. 定模型

2.2.1. 用户增长的生命周期

AARRR 模型（又称海盗模型、增长黑客模型），它从生命周期的角度描述了用户进入平台需经历的五个环节：

1. 拉新：用户从不同渠道来使用你的产品 -- 拉新/推广

2. 1. 日新增用户数（DNU）
   2. 用户获客成本：所有推广运营费用总和与新获取用户的数量的比值

3. 促活：用户在你的产品上体验到了核心价值 -- 促活

4. 1. 日活/月活
   2. 日均使用市场

5. 留存：用户回来继续不断的使用你的产品 -- 留存

6. 1. 留存率（Retention Ratio）：某段时间内新增用户数，经过一段时间后，仍然使用的用户占新增用户的比率。一般关注次日留存率、三日留存率、七日留存率等
   2. 流失率（Churn Ratio）：某段时间范围内流失的用户数量，除以这段时间开始时的用户总数即为流失率。注意不同产品对“流失”的定义是不同的。

7. 变现：用户在你的产品上发生了可使你收益的行为

8. 1. 付费率（PUR）：付费用户数占活跃用户的比例。
   2. 平均用户收入（ARPU）：统计时间内，活跃用户产生的平均收入，一般以月计算

9. 裂变：用户通过你的产品，推荐引导他人来使用你的产品 -- 人传人

10. 1. K 因子：自传播、病毒式传播中的重要指标，K = 每个用户发出的邀请数 x 接受到邀请的人转化为新用户的转化率。如果 K > 1，用户会像滚雪球一样增大；当 K < 1 时，用户群到一定规模时就会停止自传播增长

2.2.2. 不断进行策略的AB实验

3. 总结

从上述可以知道，创建一个新产品，例如AI Alisa，本质上是要用户来用，需要用户来获利的，因此完整的用户增长过程是公司内，推动一些事项的基础。

那么上面两个章节讲述了用户增长的周期，以及如何实现用户增长，再回顾用户增长的三个阶段：

1. 定目标：产品出现之前的用户增长，洞察用户需求，找到驱动用户增长的根本因素（第一步：找到产品核心价值+ 第二步：明确增长杠杆）
2. 建模型：产品生命周期内的用户增长：有了产品之后，快速引爆用户增长（结合生命周期 + 第三步：不断进行策略的AB实验）
3. 突破产品生命周期的用户增长：开启用户增长的第二曲线

那么周期的划分和实现增长路径两者有什么关系呢？周期的划分是对所有产品的用户增长过程的用户生命周期的抽象划分，而每个阶段都是用户增长的一个环节，每个环节的结果都决定的用户增长的好坏。那增长路径的实现方案，更多的是指导如何挖掘增长点，明确增长目标和手段，应用于不同的增长阶段作为指导或者方向，因此我们可以先明确增长路径，再看如何在各个周期的阶段进行发力。

4. 实践举例

4.1. 语音搜索

step-1 ：定目标：明确增长杠杆

通过数据分析，搜索产品本质是提供入口完成内容分发，因此搜索的增长等式：

搜索人数UV * 搜索次数PV * 搜索结果点击率CTR = 内容分发点击总数

为什么是内容分发点击总数而不是搜索结果点击率作为北极星指标，因为由增长等式可以知道，搜索结果点击率只是增长等式的一个因素，但是最终是为内容分发点击总数服务，例如只有转化率很高，但搜索人数UV、搜索次数PV很低，那么对端内的业务其实没有多大的助力

因此能够得到搜索的“北极星指标” = 内容分发点击总数

备注：这里的搜索指的是点击搜索按钮，走到结果搜索结果页面的简称

step-2 ：建立增长模型，从增长模型的不同环节去找与“语音搜索”相关的价值，其实就是看针对“北极星指标”，在增长模型的哪个环节，“语音搜索可以提升价值

此时，我们可以通过不同阶段的用户增长的周期去提供角度进行分析，通过不同的环节去进行发力，提升整体的“北极星指标”：

拉新：通过不同方式，吸引用户使用搜索，例如底纹词、热词等，提升搜索UV

促活：通过活动运营，例如积分任务等，让用户每天都进行搜索，提升搜索UV/PV

留存：通过长期运营活动，例如积分签到等，促进用户留存，提升搜索PV

变现：搜索广告、搜索能力商业化等，提升搜索转化率

裂变：搜索口令，提升搜索UV/PV

其中通过拉新环节的用户漏斗进行分析，我们发现搜索转化漏斗中发现用户在搜前到搜结果的过程中，发现不少用户在搜前页产生了流失，通过基于流失用户的分层分析，发现按照年龄分层后，流失的用户中大于40岁的用户较多，也就是大龄用户较多，然后基于香港app使用现状发现，存在较多的大龄用户在文字生成方面，习惯于使用语音，那么语音功能的如果能通过优化拉新的路径，减少中间流失，其实也是变向提升了搜索的““北极星指标”

距离度量（召回匹配）
余弦距离
● 定义：余弦距离是通过计算两个向量夹角的余弦值来衡量它们的方向差异。余弦值的范围是 ([-1, 1])，两个向量方向完全相同，余弦值为 1；方向完全相反，余弦值为 -1；相互垂直时，余弦值为 0。
● 公式：对于两个 n 维向量 (\vec=(A_1,A_2,\cdots,A_n)) 和 (\vec=(B_1,B_2,\cdots,B_n))，它们的余弦相似度 (\text(\vec,\vec)) 计算公式为： (\text(\vec,\vec)=\frac{\vec\cdot\vec}{|\vec||\vec|}=\frac{\sum_A_iB_i}{\sqrt{\sum_A_i2}\sqrt{\sum_B_i^{2}}) 余弦距离通常定义为 (1 - \text(\vec,\vec))。
● 特点：余弦距离主要关注向量的方向，而不考虑向量的长度。这使得它在文本挖掘、信息检索等领域非常有用，因为在这些场景中，文档的长度可能不同，但只要它们的关键词分布相似，就可以认为它们是相似的。
● 使用场景
○ 信息检索：当用户在搜索引擎中输入关键词进行查询时，搜索引擎会将用户输入的关键词表示为一个向量，然后计算该向量与索引中每个文档向量的余弦距离。例如，用户搜索 “人工智能在医疗领域的应用”，搜索引擎会找到与该查询向量余弦距离较小的文档，这些文档通常与用户的查询主题相关度较高，然后将它们作为搜索结果返回给用户。
○ 文本分类：假设有一个已经标注好类别的文本数据集，如分为 “科技”“娱乐”“体育” 等类别。对于一篇新的待分类文本，将其表示为向量后，计算它与每个类别中代表性文本向量的余弦距离。新文本与哪个类别向量的余弦距离最小，就将其归为该类别。例如，一篇关于 “量子计算的最新研究进展” 的文章，通过计算余弦距离，它与 “科技” 类别中的文本向量更相似，因此会被分类到 “科技” 类别中
点积距离
● 定义：点积是两个向量对应元素乘积之和。点积的结果是一个标量，它反映了两个向量在方向上的一致性程度以及向量的长度信息。
● 公式：对于两个 n 维向量 (\vec=(A_1,A_2,\cdots,A_n)) 和 (\vec=(B_1,B_2,\cdots,B_n))，它们的点积 (\vec\cdot\vec) 计算公式为： (\vec\cdot\vec=\sum_}A_iB_i) 在一些情况下，为了将点积转换为距离度量，可以使用负点积或者进行归一化处理。
● 特点：点积考虑了向量的长度和方向，当两个向量的长度较长且方向相似时，点积的值会较大。在深度学习中，点积常用于计算神经网络中的权重和输入的乘积。
● 使用场景
○ 全连接层：在神经网络的全连接层中，输入向量与权重矩阵进行点积运算。例如，一个具有多个神经元的全连接层，每个神经元都有一组权重。假设输入是一个表示图像特征的向量，通过与每个神经元的权重向量进行点积，再加上偏置项，得到该神经元的输出。这个过程可以看作是对输入特征进行加权求和，从而实现对图像特征的提取和转换。
○ 注意力机制：在一些自然语言处理任务中，如机器翻译、文本摘要等，注意力机制会使用点积来计算查询向量与键向量之间的相似度得分。例如，在翻译句子时，通过计算当前单词与源语言句子中各个单词的点积得分，来确定当前单词对源语言中不同部分的注意力权重，从而更准确地生成翻译结果
欧式距离
● 定义：欧氏距离是最常见的距离度量方式，它表示在欧几里得空间中两个点之间的直线距离。在向量空间中，欧氏距离衡量了两个向量之间的绝对差异。
● 公式：对于两个 n 维向量 (\vec=(A_1,A_2,\cdots,A_n)) 和 (\vec=(B_1,B_2,\cdots,B_n))，它们的欧氏距离 (d(\vec,\vec)) 计算公式为： (d(\vec,\vec)=\sqrt{\sum_(A_i - B_i)2})
● 特点：欧氏距离直观地反映了向量之间的空间距离，距离越小表示两个向量越相似。它在许多领域都有广泛应用，如聚类分析、模式识别等。
● 使用场景
○ 地理信息系统（GIS）：在地图应用中，需要计算两个地理位置之间的距离。例如，要计算从北京天安门（经纬度：39.915°N，116.397°E）到上海东方明珠塔（经纬度：31.248°N，121.498°E）的距离。可以将经纬度坐标看作是二维平面上的点，使用欧氏距离公式计算它们之间的直线距离（实际应用中可能需要考虑地球的曲率等因素进行修正，但欧氏距离提供了一个基本的计算方法）。
○ 机器人导航：机器人在一个已知的物理空间中移动，需要知道自己与目标物体或地点的距离。例如，机器人要前往房间内的一个特定位置，它通过传感器获取自身位置和目标位置的坐标信息，然后使用欧氏距离来计算从当前位置到目标位置的距离，以便规划移动路径
例如，在文本相似度计算中，余弦距离更合适；在衡量物理空间中两点的距离时，欧氏距离更常用；而点积则在神经网络等领域发挥着重要作用

稀疏检索/稠密检索
稀疏检索
● 基本概念：稀疏检索基于词袋模型，将文档和查询表示为稀疏向量。在这种表示中，向量的维度通常对应于整个词汇表中的单词，而向量的元素值表示该单词在文档或查询中出现的频率或其他相关统计信息（如 TF - IDF 值）。由于大多数文档只包含词汇表中一小部分单词，所以这些向量中大部分元素为零，呈现出稀疏的特点。
● 检索过程：常见的稀疏检索方法包括基于倒排索引的检索，倒排索引记录了每个单词在哪些文档中出现以及出现的位置等信息，通过查找倒排索引可以快速找到包含查询词的文档，然后再计算这些文档与查询的相似度进行排序。
● 优点：稀疏检索的优点是索引结构简单，易于理解和实现，能够快速地对大规模文档集合进行索引和检索。同时，它对于处理精确匹配的查询非常有效，能够准确地找到包含特定关键词的文档。
● 缺点：然而，稀疏检索也存在一些局限性。它过于依赖单词的精确匹配，对于语义相似但用词不同的查询和文档可能无法准确检索到。而且，由于只考虑了单词的出现频率等简单统计信息，忽略了单词之间的语义关系和上下文信息，所以在处理复杂的语义查询时效果可能不太理想

稠密检索
● 基本概念：稠密检索将文档和查询映射为低维的稠密向量，这些向量中的每个元素都有实际的数值，且通常通过深度学习模型等方式学习得到。与稀疏向量不同，稠密向量能够捕捉到文本的语义信息，将文本中的语义特征表示为向量空间中的向量，使得语义相似的文本在向量空间中的距离更近。
● 检索过程：在检索时，同样通过计算查询向量与文档向量之间的相似度（如余弦相似度、欧式距离等）来衡量文档与查询的相关性。由于稠密向量包含了更丰富的语义信息，所以能够更好地处理语义复杂的查询。例如，一些基于深度学习的稠密检索模型会将查询和文档同时输入到模型中，通过模型的编码器将它们分别编码为稠密向量，然后计算向量之间的相似度得分，根据得分对文档进行排序。
● 优点：稠密检索的主要优点是能够更好地处理语义信息，对于语义相似但表述不同的查询和文档有更好的检索效果。它能够利用深度学习模型学习到文本的深层语义特征，从而提高检索的准确性和召回率，尤其在处理复杂的自然语言查询时表现更优。
● 缺点：不过，稠密检索也有一些缺点。训练深度学习模型来生成稠密向量通常需要大量的标注数据和计算资源，训练过程较为复杂和耗时。而且，稠密向量的索引和检索过程相对稀疏检索来说更复杂，需要使用一些专门的向量索引结构和算法来提高检索效率。

是一个分布式的、面向列存储的 NoSQL数据库，基于 Google 的 Bigtable 设计，用于处理海量的结构化数据。HBase 架构的独特性使其在大数据领域得到了广泛应用，主要用来存储非结构化和半结构化的松散数据

HBase 最早由 Apache Hadoop 的开发者开发，用于解决在 Hadoop 分布式文件系统（HDFS）上存储和检索大量数据时面临的挑战。传统的关系型数据库在处理大规模数据时效率低下，难以扩展。而 HBase 作为一个 NoSQL 数据库，提供了对大量数据的高效读写操作，并且具有高度的扩展性。

项目需求是构建一个可以处理数十亿条记录的大规模数据存储系统，要求系统能够承载高并发的读写请求，同时在数据量急剧增长的情况下，系统性能不会显著下降。HBase 的设计正是为此类需求量身定制。

2. HBase数据检索与存储

模块	职责
HBase Client	HBase Client 为用户提供了访问 HBase 的接口，可以通过元数据表来定位到目标数据的 RegionServer，另外 HBase Client 还维护了对应的 cache 来加速 Hbase 的访问，比如缓存元数据的信息
HMaster	HMaster 是 HBase 集群的主节点，负责整个集群的管理工作，主要工作职责如下分配Region：负责启动的时候分配Region到具体的 RegionServer；负载均衡：一方面负责将用户的数据均衡地分布在各个 Region Server 上，防止Region Server数据倾斜过载。另一方面负责将用户的请求均衡地分布在各个 Region Server 上，防止Region Server 请求过热维护数据：发现失效的 Region，并将失效的 Region 分配到正常的 RegionServer 上，并且在Region Sever 失效的时候，协调对应的HLog进行任务的拆分。
Region Server	直接对接用户的读写请求，干活的节点，每一个Region server大约可以管理1000个region，处理对这些HRegion的IO请求，也就是说客户端直接和HRegionServer打交道，主要职责如下管理 HMaster 为其分配的 Region；负责与底层的 HDFS 交互，存储数据到 HDFS；负责 Region 变大以后的拆分以及 StoreFile 的合并工作。
Region（table）	Region Server 包含多个Region。每一个 Region 都有起始 RowKey 和结束 RowKey，代表了存储的Row的范围，保存着表中某段连续的数据。一开始Region可能只有一个，随着数据增多（StoreFile变大,默认256M），进行Region的水平切分，分成了多个Region。当 Region 很多时，HMaster 会将 Region 保存到其他 Region Server 上
HLog（WAL）	每个Region Server会有一个HLog，负责记录着数据的操作日志，当HBase出现故障时可以进行日志重放、故障恢复。例如故障时MemStore没有写会磁盘
Store（列蔟）	一个 Region 包含多个 Store ，每个 Store 都对应一个 Column Family, Store 包含 MemStore 和 StoreFile
MemStore（Store的内存存储）	数据的写操作会先写到 MemStore 中，当MemStore 中的数据增长到一个阈值（默认64M）后。Region Server 会启动 flasheatch 进程将 MemStore 中的数据写人 StoreFile 持久化存储，每次写入后都形成一个单独的 StoreFile。找数据会先从MemStore开始找，找不到才去StoreFile
StoreFile（HFile）	StoreFile底层是以 HFile 的格式保存。HBase以Store的大小来判断是否需要切分Region
HFile是HBase中KeyValue数据的存储格式，是hadoop的二进制格式文件。一个StoreFile对应着一个HFile。而HFile是存储在HDFS之上的
Zookeeper	HBase 通过 ZooKeeper 来完成选举 HMaster、监控 Region Server、维护元数据集群配置等工作，主要工作职责如下选举Master：如果 HMaster 异常，则会通过选举机制（写入节点成功的节点作为HMaster）产生新的 HMaster 来提供服务监控Region Server: 通过 ZooKeeper 来监控 Region Server 的状态，当Region Server 有异常的时候，通过回调的形式通知 HMaster 有关Region Server 上下线的信息维护元数据和集群配置信息
HDFS	为 HBase 提供底层数据存储服务，同时为 HBase提供高可用的支持

3. HBase数据模型与操作

3.1. 数据模型

基本存储单位是表（Table），表由行（Row）和列族（Column Family）组成。每个列族可以包含多个列（Column），而列的数据通过时间戳（Timestamp）进行版本控制

Cell

{ RowKey, ColumnFamily: ColumnQualifier, TimeStamp}

唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存贮

3.2. 主要操作

HBase 提供了丰富的 API 进行数据操作，包括 Put、Get、Delete 和 Scan。Put 用于写入数据，Get 用于读取数据，Delete 用于删除数据，Scan 用于批量读取数据。

1. Put：将数据写入表中。
2. Get：根据行键读取数据。
3. Delete：删除指定行或列的数据。
4. Scan：遍历表中的数据。

3.2.1. 写流程

1. 获取meta表信息：客户端先访问zookeeper，获取Meta表位于那个region server，根据根据请求的信息（namespace:table/rowkey）,在meta表中查询出目标数据位于哪个region server的哪个region中，然后缓存在客户端中
2. 与目标数据的region server进行通讯
3. 将数据写入到WAL中
4. 将数据写入到对应的memstore中，
5. 向客户端发送写入成功的信息
6. 等达到memstore的刷写时机后，将数据刷写到HFILE中

更新操作：并没有真正更新原有数据，而是使用时间戳属性实现了多版本；

删除操作：没有真正删除原有数据，只是插入了一条标记为"deleted"标签的数据，而真正的数据删除发生在系统异步执行Major Compact的时候

3.2.2. 读流程

1. 获取meta表信息：客户端先访问zookeeper，获取Meta表位于那个region server，根据根据请求的信息（namespace:table/rowkey）,在meta表中查询出目标数据位于哪个region server的哪个region中，然后缓存在客户端中
2. 请求对应region server
3. 分别在Block Cache（读缓存），MemStore和 Store File查询目标数据，并将查到的数据进行**合并，**此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）
4. 将从文件中查询到的数据块缓存到block cache
5. 将合并后的数据返回给客户端

API操作主要划分如下：

1. GET
2. SCAN - 一般HBase会根据设置条件将一次大的scan操作拆分为多个RPC请求，每个RPC请求称为一次next请求，每次只返回规定数量的结果，类似于ES的search-after。每次可以设置setBatch(条数)、setMaxResultSize(数据量大小)

3.2.2.1. Scan查询详细流程

Scan查询大致分为下述四个流程

1. Client-Server读取交互逻辑
2. HBase的scan框架
3. HBase过滤淘汰不符合条件的HFile
4. 从HFile中读取待查找Key

3.2.2.1.1. Client-Server读取交互逻辑

Client首先会从ZooKeeper中获取元数据hbase:meta表所在的RegionServer，然后根据待读写rowkey发送请求到元数据所在RegionServer，获取数据所在的目标RegionServer和Region（并将这部分元数据信息缓存到本地），最后将请求进行封装发送到目标RegionServer进行处理。

HBase Client端与Server端的scan操作并没有设计为一次RPC请求，这是因为一次大规模的scan操作很有可能就是一次全表扫描，扫描结果非常之大，通过一次RPC将大量扫描结果返回客户端会带来至少两个非常严重的后果：

•大量数据传输会导致集群网络带宽等系统资源短时间被大量占用，严重影响集群中其他业务。

•客户端很可能因为内存无法缓存这些数据而导致客户端OOM。

实际上HBase会根据设置条件将一次大的scan操作拆分为多个RPC请求，每个RPC请求称为一次next请求，每次只返回规定数量的结果。下面是一段scan的客户端示例代码：

3.2.2.1.2. HBase的scan框架

Scan中，会根据startRowKey、endRowKey查询多个Region server

RegionServer接收到客户端的get/scan请求之后做了两件事情：

1. 首先构建scanner iterator体系；
2. 然后执行next函数获取KeyValue，并对其进行条件过滤

3.2.2.1.2.1. scanner iterator体系

Scanner的核心体系包括三层Scanner：RegionScanner，StoreScanner，MemStoreScanner和StoreFileScanner。三者是层级的关系：

• 一个RegionScanner由多个StoreScanner构成。一张表由多少个列簇组成，就有多少个StoreScanner，每个StoreScanner负责对应Store的数据查找。
• 一个StoreScanner由MemStoreScanner和StoreFileScanner构成。每个Store的数据由内存中的MemStore和磁盘上的StoreFile文件组成。相对应的，StoreScanner会为当前该Store中每个HFile构造一个StoreFileScanner，用于实际执行对应文件的检索。同时，会为对应MemStore构造一个MemStoreScanner，用于执行该Store中MemStore的数据检索。

需要注意的是，RegionScanner以及StoreScanner并不负责实际查找操作，它们更多地承担组织调度任务，负责KeyValue最终查找操作的是StoreFileScanner和MemStoreScanner。三层Scanner体系可以用图表示。

3.2.2.1.3. HBase过滤淘汰不符合条件的HFile

通过不同的scanner进行查找，过滤HFile->根据Key在HFile进行读取数据，最终产出一个keyValue（Cell）的优先队列（小顶堆），next的查询模式就是基于这个优先队列（Key ValueScanner）进行keyValue的查找，并最终从HFile中读取到数据

其中keyValue的优先队列的生成过程如下

1. 过滤淘汰部分不满足查询条件的StoreScanner，可以先基于用户查询中的TimeRange，Rowkey Range过滤以及布隆过滤器过滤部份HFile

2. 1. TimeRange（时序数据）：StoreFile中元数据有一个关于该File的TimeRange属性[ miniTimestamp, maxTimestamp ]，如果待检索的TimeRange与该文件时间范围没有交集，就可以过滤掉该StoreFile；另外，如果该文件所有数据已经过期，也可以过滤淘汰
   2. Rowkey Range：因为StoreFile中所有KeyValue数据都是有序排列的，所以如果待检索row范围[ startrow，stoprow ]与文件起始key范围[ f irstkey，lastkey ]没有交集，比如stoprow < firstkey或者startrow > lastkey，就可以过滤掉该StoreFile
   3. 布隆过滤器：主要根据Bloom Block，待检索的rowkey获取对应的Bloom Block并加载到内存（通常情况下，热点Bloom Block会常驻内存的），再用hash函数对待检索rowkey进行hash，根据hash后的结果在布隆过滤器数据中进行寻址，即可确定待检索rowkey是否一定不存在于该HFile

3. 每个Scanner seek到startKey。这个步骤在每个HFile文件中（或MemStore）中seek扫描起始点startKey（下文：从HFile中读取待查找Key）。如果HFile中没有找到starkKey，则seek下一个KeyValue地址，这个过程会比较复杂。

4. KeyValueScanner合并构建最小堆。将该Store中的所有StoreFileScanner和MemStoreScanner合并形成一个heap（最小堆）

5. 最后，执行最终读取，例如执行next函数获取KeyValue并对其进行条件过滤

6. 1. 检查该KeyValue的KeyType是否是Deleted/DeletedColumn/DeleteFamily等，如果是，则直接忽略该列所有其他版本，跳到下列（列簇）。
   2. 检查该KeyValue的Timestamp是否在用户设定的Timestamp Range范围，如果不在该范围，忽略。
   3. 检查该KeyValue是否满足用户设置的各种filter过滤器，如果不满足，忽略。
   4. 检查该KeyValue是否满足用户查询中设定的版本数，比如用户只查询最新版本，则忽略该列的其他版本；反之，如果用户查询所有版本，则还需要查询该cell的其他版本。

注意，其中一个KeyValue其实就是一个cell = {rowKey,colounm family,timeStamp,value}

3.2.2.1.3.1. 各种Filter过滤器

在HBase里，Scan 的 Filter 支持多种过滤操作，以下为你详细介绍：

\1. 比较过滤器

• SingleColumnValueFilter：此过滤器用于筛选特定列族和列限定符的值，它依据比较运算符和比较器来判定是否保留该行。示例代码如下：

SingleColumnValueFilter filter = new SingleColumnValueFilter(    Bytes.toBytes("cf"),    Bytes.toBytes("column"),    CompareOperator.EQUAL,    new BinaryComparator(Bytes.toBytes("value")));scan.setFilter(filter);

• RowFilter：按照行键对数据进行过滤，同样借助比较运算符和比较器来实现。示例如下：

RowFilter rowFilter = new RowFilter(    CompareOperator.EQUAL,    new BinaryComparator(Bytes.toBytes("rowkey")));scan.setFilter(rowFilter);

• FamilyFilter：用于筛选特定列族的数据，通过比较运算符和比较器达成。示例如下：

FamilyFilter familyFilter = new FamilyFilter(    CompareOperator.EQUAL,    new BinaryComparator(Bytes.toBytes("cf")));scan.setFilter(familyFilter);

• QualifierFilter：该过滤器可筛选特定列限定符的数据，利用比较运算符和比较器完成。示例如下：

QualifierFilter qualifierFilter = new QualifierFilter(    CompareOperator.EQUAL,    new BinaryComparator(Bytes.toBytes("column")));scan.setFilter(qualifierFilter);

\2. 组合过滤器

• FilterList：能够把多个过滤器组合起来使用，支持 MUST_PASS_ALL（所有过滤器都必须通过）和 MUST_PASS_ONE（只要有一个过滤器通过即可）两种组合方式。示例如下：

FilterList filterList = new FilterList(FilterList.Operator.MUST_PASS_ALL);filterList.addFilter(filter1);filterList.addFilter(filter2);scan.setFilter(filterList);

\3. 专用过滤器

• PageFilter：用于实现分页功能，可指定每页返回的行数。示例如下：

PageFilter pageFilter = new PageFilter(10); // 每页返回 10 行scan.setFilter(pageFilter);

• PrefixFilter：按照行键的前缀进行过滤，只返回行键以指定前缀开头的行。示例如下：

PrefixFilter prefixFilter = new PrefixFilter(Bytes.toBytes("prefix"));scan.setFilter(prefixFilter);

• ColumnPrefixFilter：根据列限定符的前缀来筛选数据，只返回列限定符以指定前缀开头的列。示例如下：

ColumnPrefixFilter columnPrefixFilter = new ColumnPrefixFilter(Bytes.toBytes("prefix"));scan.setFilter(columnPrefixFilter);

• FirstKeyOnlyFilter：仅返回每行的第一个键值对，常用于快速统计行数。示例如下：

FirstKeyOnlyFilter firstKeyOnlyFilter = new FirstKeyOnlyFilter();scan.setFilter(firstKeyOnlyFilter);

这些过滤器能让你在HBase中精准地筛选数据，以满足不同的业务需求。

3.2.2.1.3.2. 其他API

时间处理HBase的Scan操作中是有与时间相关的过滤器的，下面为你详细介绍：

\1. TimestampsFilter

该过滤器允许你指定一系列时间戳，只有当单元格的时间戳与指定的时间戳相匹配时，才会返回该单元格。以下是Java代码示例：

import org.apache.hadoop.hbase.TableName;import org.apache.hadoop.hbase.client.*;import org.apache.hadoop.hbase.filter.TimestampsFilter;import org.apache.hadoop.hbase.util.Bytes;import java.io.IOException;import java.util.ArrayList;import java.util.List;public class TimeStampFilterExample {    public static void main(String[] args) throws IOException {        // 创建连接        Connection connection = ConnectionFactory.createConnection();        // 获取表        Table table = connection.getTable(TableName.valueOf("your_table_name"));        // 创建Scan对象        Scan scan = new Scan();        // 指定时间戳列表        List<Long> timestamps = new ArrayList<>();        timestamps.add(1609459200000L);         timestamps.add(1609545600000L);         // 创建TimestampsFilter        TimestampsFilter filter = new TimestampsFilter(timestamps);        scan.setFilter(filter);        // 执行扫描        ResultScanner scanner = table.getScanner(scan);        for (Result result : scanner) {            // 处理结果            System.out.println(result);        }        // 关闭资源        scanner.close();        table.close();        connection.close();    }}

在这个示例中，我们创建了一个**TimestampsFilter**，并指定了两个时间戳。只有时间戳与这两个值相匹配的单元格才会被返回。

\2. 在Scan对象中直接设置时间范围

除了使用过滤器，你还可以在**Scan**对象中直接设置时间范围，只有时间戳在该范围内的单元格才会被返回。示例代码如下：

import org.apache.hadoop.hbase.TableName;import org.apache.hadoop.hbase.client.*;import org.apache.hadoop.hbase.util.Bytes;import java.io.IOException;public class TimeRangeScanExample {    public static void main(String[] args) throws IOException {        // 创建连接        Connection connection = ConnectionFactory.createConnection();        // 获取表        Table table = connection.getTable(TableName.valueOf("your_table_name"));        // 创建Scan对象        Scan scan = new Scan();        // 设置时间范围        long startTime = 1609459200000L;         long endTime = 1609545600000L;         scan.setTimeRange(startTime, endTime);        // 执行扫描        ResultScanner scanner = table.getScanner(scan);        for (Result result : scanner) {            // 处理结果            System.out.println(result);        }        // 关闭资源        scanner.close();        table.close();        connection.close();    }}

在上述代码里，我们使用**setTimeRange**方法设置了一个时间范围，只有时间戳在这个范围内的单元格才会被返回。

3.2.2.1.4. 从HFile中读取待查找Key

最后根据KevValue去HFIle中查找具体数据，查询流程如下：

3.2.3. MemStore刷写

MemStore触发刷写的场景如下：

1. 单一MemStore超大小128M：某个MemStore的大小达到了hbase.hregion.memstore.flush.size（默认值 128M），其所在 region 的所有 memstore (对应的列簇)都会刷写，当达到128 * N 还没有刷写，此时会拒绝写入。

两个相关参数的默认值如下：

hbase.hregion.memstore.flush.size=128M(默认)

hbase.hregion.memstore.block.multiplier=4(默认)

1. memstore总大小超过堆内存：当 region server 中 memstore 的总大小达到java_heapsize(应用的堆内存)*hbase.regionserver.global.memstore.size时

hbase.regionserver.global.memstore.size=0.4（默认值）

1. 定时刷写：到达自动刷写的时间，也会触发 memstore flush，默认时1h
2. WAL文件超大：WAL 文件的数量超过 hbase.regionserver.maxlogs，region 会按照时间顺序依次进行刷写

3.2.4. 数据合并（StoreFile Compaction）

为什么需要执行数据合并？

由于MemStore每次刷写都会生成一个新的HFile，同一个字段的不同版本(timestamp)和不同类型(Put/Delete)有可能分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清除掉过期和删除的数据，会进行StoreFile Compaction

Compaction分为两种

1. Minor Compaction：会将临时的若干较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据
2. Major Compaction：会将一个Store下的所有HFile合并为一个大HFile，并且会清理掉过期和删除的数据

3.2.5. 数据拆分

默认情况下，每个 Table 起初只有一个 Region，随着数据的不断写入，Region 会自动进行拆分。刚拆分时，两个子 Region 都位于当前的 Region Server，但处于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的 Region Server

拆分时机：

1. Region中总Store大小超限制：hbase.hregion.max.filesize，该 Region 就会进行拆分（0.94 版本之前）。
2. Region中某个Store下所有StoreFile大小超限

4. HBase的扩展性和高可用

HBase 的架构设计使其具备良好的扩展性和高可用性。

相关文档：

https://cloud.tencent.com/developer/article/2184702

https://cloud.tencent.com/developer/article/2448014

• 信息保密问题：网络报文中的信息可能会泄露，例如身份证等信息 - 加密
• 信息篡改问题：网络报文被篡改，例如转账接受人 - 签名
• 通信对象认证问题：和你通信的人可能是被劫持的对象 - 签名

2.加密：对称加密 / 非对称加密

2.0.什么是加密

注意加密也一定需要能解密出来。

组成：一般密码系统通常由 明文 + 密钥 + 算法组成，明文 + 密钥是原材料，算法是配方，结果就是产出密文

密码算法要考虑的关键因素是让破解者难以通过明文、密文、以及其他信息推断出密钥或者缩小密钥的范围，从而暴力破解出密钥

2.1.对称加密

对称密码指加密和解密使用同样的密钥，就是加密方和解密方都要持有同样的密钥，性能高

由于对称加密需要双方持有同一密钥，因此就会引发出如何确定同一密钥，也就是密钥配送问题，如何协商出一致的秘钥

解决方案：

• 事先共享密钥（邮件等安全通道）
• 密钥分配中心
• Diffie-Hellman密钥交换
• 非对称加密

2.2.非对称加密

非对称密码指加密和解密使用不同密钥。

非对称加密需要4个密钥。通信双方各自准备一对公钥和私钥。其中公钥是公开的，由信息接受方提供给信息发送方。公钥用来对信息加密。私钥由信息接受方保留，用来解密。既然公钥是公开的，就不存在保密问题。也就是说非对称加密完全不存在密钥配送问题！你看，是不是完美解决了密钥配送问题？

但是，非对称加密过程容易产生中间人问题，中间人攻击指的是在通信双方的通道上，混入攻击者。他对接收方伪装成发送者，对放送放伪装成接收者。

他监听到双方发送公钥时，偷偷将消息篡改，发送自己的公钥给双方。然后自己则保存下来双方的公钥。

如此操作后，双方加密使用的都是攻击者的公钥，那么后面所有的通信，攻击者都可以在拦截后进行解密，并且篡改信息内容再用接收方公钥加密。而接收方拿到的将会是篡改后的信息。实际上，发送和接收方都是在和中间人通信

和对称加密相比较，非对称加密有如下特点：

1、非对称加密解决了密码配送问题

2、非对称加密的处理速度只有对称加密的几百分之一。不适合对很长的消息做加密。

2.2.1.如何解决公钥的传输解决中间人问题 - 证书解决

那么实际在通信双边的公钥传输过程中，如何明确拿到的公钥就是正确的呢，因此我们是不是就需要验证对端的身份合法？因此引出了证书

2.3.证书

证书是能够证明你身份的文件，类似于身份证，证书包括如下几个部分：

• 身份证姓名：对应证书的公钥所有者
• 身份证号：通信方公钥
• 身份证签发机关：证书颁发者
• 身份证有效期限：证书有效期
• 身份证防伪条纹：认证机构对公钥的签名

工作机制

大致流程可以概述为：

1. 对端在认证机构（CA）注册自己的公钥
2. CA使用自己的机构私钥对证书进行签名，生成证书
3. 接收端使用CA的公钥对证书进行验签

其中又会涉及到机构的合法性，此时又会引入证书链，也就是有更高级的证书机构对证书机构进行背书，最终会到根CA

3.签名

我们通过加密来保障了内容的隐私性，那假设我们发出去的报文被劫持方劫持并篡改，再使用公钥进行发送，此时会发生篡改的问题。接收人是无法识别的。这里就需要使用电子签名来保证信息的完整性（来源方正确+信息没有被篡改，例如我能知道我收到的这个信息是肯德基、麦当劳商户发起的）

如何确保来源方正确：对端用自己的私钥加签，服务端用对端的公钥进行签名的验证，如果能通过则验证对端是来源合法。（当然此时也会出现中间人问题，一样用证书解决）

如何确保报文没有被篡改：当然我们可以直接对原报文进行加密生成签名，但是由于考虑到性能，我们基于报文生成一个较短的单向散列函数值，并基于单向散列值进行签名的生成，由于散列函数存在同样的报文生成的散列函数唯一的特性，因此其实散列函数就能代表一段报文。

散列函数：

1. 计算出的散列值是固定的，并且短。
2. 不同的消息，散列值不同。
3. 计算的速度要快。信息很长的时候，也要保证快速计算。

应用redis缓存时，会发生如下问题：

• 缓存和数据库中数据不一致
• 缓存雪崩
• 缓存击穿
• 缓存穿透

1.缓存和数据库中数据不一致

数据一致性包含两种情况：

• 第一种：缓存中有数据，且数据和数据库中一致
• 第二种：缓存中没有数据，且数据库的数据是最新的

1.1.发生场景

根据缓存的三种类型，来详细讲解下不一致可能出现的情形

（1）读缓存

• 新增操作：新增数据，数据会直接写入到数据库，不涉及缓存操作，因此不会出现不一致的情形，且数据符合一致性的第一种情形

• 删改操作：既要更新数据库，也需要删除缓存中的数据。两个操作如果无法保住原子性，则会出现数据不一致的问题

  如下图：

  

• 并发场景下的数据不一致

  • 情况一：先删除缓存，再更新数据库

    写+读：线程A删除缓存后，由于网络延迟还没有更新到库，此时线程B读取数据发现缺失，从库读出再同步入缓存，此时A才写入库，造成了缓存存在数据，但是数据不一致的情形

    

  • 情况二：先更新数据库值，再删除缓存

    写+读:线程A删完库和删除缓存之间，存在其他线程发出读请求，这个时候的读请求由于缓存还没删除，所以读到了值并返回，但是这个场景对业务影响较小

    

  （2）读写缓存-直写场景

  针对这种缓存类型的数据不一致的问题，大致与读场景相同，其实二者的区别也就是写请求的处理，读写缓存针对写请求是同步缓存，而读缓存是删除缓存，因此读写缓存场景下，新增的不一致的类型包括：新增请求，并发下的写写（执行顺序导致）请求

  • 新增操作：新增数据库和新增缓存需要保证原子性，因此可以用重试解决

  • 并发场景下的数据不一致：在读缓存的两个情形上多了个写写类型

    • 情况一：先更新缓存，再更新数据库

      写+读：不会影响业务，更新了缓存之后，其余请求会直接读缓存，对业务无影响

      写+写：线程A与线程B同时写数据D，缓存中的写顺序是AB、数据库写顺序是BA，导致不一致

    • 情况二：先更新数据库值，再删除缓存

      写+读：有部分请求会读到缓存的老数据，但是对业务系统短暂影响

      写+写：与情况一的写+写情形一致

写+读场景下，如果缓存不存在怎么办？

可能的问题：假设写请求W，读请求R

虽然这种场景会出现问题，不过由于读取缓存+写入读取的数据入缓存的耗时比更新DB的耗时小的多，因此发生的概率极低，不过不排除R线程由于GC导致STW中断

1.2.如何解决数据不一致

（1）重试机制

通过引入消息队列或者代码中手写重试代码，如果重试之后仍然失败则抛错

（2）针对并发场景下的读缓存的

先删除缓存，再更新数据库：

• （写+读）延迟双删：线程A再更新完数据库之后，再sleep一会再删除缓存一次，具体sleep时间更新线程读数据+写缓存的时间（其实就是上述线程B的耗时）

先更新数据库，再更新缓存：

• （写+读）对业务系统短暂影响，无需特殊处理

（3）针对并发场景下的读写缓存的

先更新缓存，再更新数据库：

• （读+写）由于对业务的影响都不大，因此无需特殊处理
• （写+写）写请求进来时，针对同一个资源的修改操作，先加分布式锁，这样同一时间只允许一个线程去更新数据库和缓存，没有拿到锁的线程把操作放入到队列中，延时处理

先更新数据库，再更新缓存

• （读+写）由于对业务的影响都不大，因此无需特殊处理
• （写+写）同上写+写

写+写其实就是更新覆盖的场景，上述解决措施采取的悲观锁，这里其实也可以采取乐观锁的方式

1.3.先更新库还是先更新缓存的取舍

先总结下表：

建议优先更新库再删除缓存，好处如下：

• 先删除缓存再更新库，可能会导致数据缺失给数据库带来压力
• 先删除缓存再删库解决办法的延迟双删的sleep时间不好把握

2.缓存雪崩

2.1.概念：

大量的请求无法在缓存中进行处理，进而请求向数据库，导致数据库压力激增

2.2.发生场景及解决措施

• 第一种场景：缓存中大量数据同时失效，导致大量请求无法处理直接请求数据库

  

  解决措施：

  （1）过期时间设置一个浮动值，当然这是得在业务场景运行的情况下

  （2）服务降级：服务降级是指针对不同类型的数据采取不同的处理方式，针对请求？。

  • 当业务应用访问的是非核心数据（例如电商商品属性）时，暂时停止从缓存中查询这些数据，而是直接返回预定义信息、空值或是错误信息；

  • 当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。

    

  • 第二种场景：redis实例发生宕机，无法处理请求，会导致大量请求打向数据库

    解决措施：

    （1）业务系统中实现服务熔断：就是发生缓存雪崩的时候，为了方式业务系统崩溃，业务系统调用缓存接口时，缓存客户端发现redis实例宕机了，则拒绝所有的请求并返回直至恢复。虽然这样可以保证数据库的正常运行，但是这样对业务影响比较大。

    （2）限流：针对熔断的改进就是限流了，允许少量请求进入，减轻数据库的压力

    （3）提前预防：构建redis的高可用集群，方式不可用的风险

3.缓存击穿

3.1.概念

热点数据失效后，针对该热点数据的大量请求打向数据库，与缓存雪崩的区别在于雪崩是大量请求失效，而击穿是热点数据缓存失效。

3.2.解决措施：

1.设置key永不过期

2.数据缺失从数据库同步入缓存的过程上分布式（非阻塞）锁，保证同步过程中只有一个请求去同步，其余请求直接拒绝

4.缓存穿透

4.1.概念

要访问的数据既不在缓存中也不在数据库中，此时大量请求会同时请求缓存及数据库，这个时候会同时给缓存和数据库带来压力

4.2.解决措施

（1）缓存空值或缺省值：针对数据缺失的数据存储空值或缺省值入redis

（2）前端预防，针对请求进行校验

（3）使用布隆过滤器快速判断数据是否存在，避免从数据库中查询数据是否存在，减轻数据库压力

布隆过滤器：

布隆过滤器由一个初始值都为0的bit数组和N个哈希函数组成，用于快速判断数据是否存在。当我们想快速判断数据是否存在是，可以通过判断布隆过滤器的标记进行判断，标记流程如下：

• 数据针对N个哈希函数进行计算得到N个哈希值
• 再将N个哈希值对bit数据的长度取模。将取模后的值对应的下标置为1

如果数据存在，判断时再走一遍标记的流程，查看bit数组中这N个位置上的bit值。只要这N个bit值有一个不为1，这就表明布隆过滤器没有对该数据做过标记，则代表数据不存在，无需查找后端缓存和数据库

协同策略

概念

• u-user：用户
• i-item：内容
• g-tag：标签

各种概念：

• 2i：计算item-item相似度，用于相似推荐、相关推荐、关联推荐；
• u2i：基于矩阵分解、协同过滤的结果，直接给u推荐i；
• u2u2i：基于用户的协同过滤，先找相似用户，再推荐相似用户喜欢的item；
• u2i2i：基于物品的协同过滤，先统计用户喜爱的物品，再推荐他喜欢的物品；
• u2tag2i：基于标签的泛化推荐，先统计用户偏好的tag向量，然后匹配所有的Item，这个tag一般是item的标签、分类、关键词等tag；

比较

基于用户（特征）协同过滤2u

基本思想：当召回用户A的候选集时，可以先找到和他有相似兴趣的其他用户，然后把那些用户喜欢的、而用户A没有未交互的物品作为候选集

**其中相似度的计算公式可以概括为：**用户u和用户v，令N(u)表示用户u曾经有过正反馈（例如点击）的物品集合，令N(v) 为用户v曾经有过正反馈的物品集合，相似度=uv用户相似的物品集合/uv所有的物品集合和

例如香港首页feed为你推荐场景：正反馈可能为 ->

除了针对候选集进行0 1有无的推荐外，更应该进一步优化的是针对每个候选集的物品进行score（价值）计算，换句话说，两个用户对冷门物品采取过同样的行为更能说明他们兴趣的相似度，因此，我们可以基于物品的流行度对热门物品进行一定的惩罚，价值可以为自定义，例如售卖券的价值=10，小程序的价值=20

基于余弦相似度

大概步骤：

1. 先统计当前用户相似度的用户后
2. 算法会给用户推荐和他兴趣最相似的K个用户喜欢的

基于物品协同过滤2i

**基本思想：**给用户推荐那些和他们之前喜欢的物品相似的物品。比如，该算法会因为你购买过《数据挖掘导论》而给你推荐《机器学习》。不过，ItemCF算法并不利用物品的内容属性计算物品之间的相似度，它主要通过分析用户的行为记录计算物品之间的相似度。该算法认为，物品A和物品B具有很大的相似度是因为喜欢物品A的用户大都也喜欢物品 B。一切都是基于用户行为去推荐item

**其中相似度的计算公式可以概括为：**喜欢item1并且喜欢item2的人数占了喜欢item1的百分比

相似度 =（ N（Item1）交N（item2））/N（Item1）

这里我们按照喜欢吃这个行为计算相似度举例，例如喜欢西瓜=100w，喜欢吃菠萝并喜欢吃西瓜的人数=50W，那么喜欢吃西瓜和喜欢吃菠萝的相似度=50/100=0.5，值越接近1相似度越高

大概步骤：

1. 计算物品之间的相似度
2. 根据物品的相似度和用户的历史行为给用户生成召回候选集

该算法也会有一个问题，就是针对热门item，假设按照喜欢这个行为作为相似度的考虑，假设有一个热门商品大多数用户都喜欢，这样会导致这个热门商品和大部分商品相似度都很高，因此这里会导致热门商品会经常被推荐。

那么我们是不是可以不让每个用户的行为的贡献度都一样呢？例如：

假设有这么一个用户，他是开书店的，并且买了当当网上80%的书准备用来自己卖。那么， 他的购物车里包含当当网80%的书。假设当当网有100万本书，也就是说他买了80万本。从前面 对ItemCF的讨论可以看到，这意味着因为存在这么一个用户，有80万本书两两之间就产生了相似度。这个用户虽然活跃，但是买这些书并非都是出于自身的兴趣，而且这些书覆 盖了当当网图书的很多领域，所以这个用户对于他所购买书的两两相似度的贡献应该远远小于一个只买了十几本自己喜欢的书的文学青年。因此，我们要对这样的用户进行一定的惩罚，John S. Breese在论文1中提出了一个称为IUF(Inverse User Frequence)，即用户活跃度对数的 倒数的参数，他也认为活跃用户对物品相似度的贡献应该小于不活跃的用户

结论

为什么需要keepalive？

如果建立TCP连接之后，如果由于某些异常原因，导致连接已经损坏。但是此时双端仍然在维持该连接，此时则会浪费资源，已经在使用时产生报错

连接损坏如何定义？

1. 对端异常“崩溃”
2. 对端在，但是处理不过来
3. 对端在，但是网络请求不可达

2.如何设计keepalive

3.为什么应用层需要keepalive

原因如下：

1. 协议分层，各层关注点不同：传输层关注是否通，应用层关注是否可服务，例如虽然连接是ok的，但是可能对端应用无法提供正常服务
2. TCP 层的 keepalive 默认关闭，且经过路由等中转设备 keepalive 包可能会被丢弃，传输层的调整会影响全部应用
3. TCP的keepalive时间太长

4.什么是Idle检测

Idle检测只是负责对连接的诊断、分析并作出不同的行为，主要用于判断连接是否空闲or连接是否异常，从而来决定是否采取keepalive，有助于减少keepalive的次数

其中Idle状态分为如下三种:

1. readerIdleTime：读超时时间，当前端一段时间未收到对端消息
2. writerIdleTime：写超时时间，当前端一段时间未向对端发送消息
3. allIdeTime：所有类型（当前端既没有传也没有收到数据）的超时时间

/** * An {@link Enum} that represents the idle state of a {@link Channel}. */public enum IdleState {    /**     * No data was received for a while.     */    READER_IDLE,    /**     * No data was sent for a while.     */    WRITER_IDLE,    /**     * No data was either received or sent for a while.     */    ALL_IDLE}

5.如何使用TCP keepalive和Idle检测

Server 端开启 TCP keepalive

bootstrap.childOption(ChannelOption.SO_KEEPALIVE,true) bootstrap.childOption(NioChannelOption.of(StandardSocketOptions.SO_KEEPALIVE), true)

提示：.option(ChannelOption.SO_KEEPALIVE,true) 存在但是无效

开启不同的 Idle 检测:

ch.pipeline().addLast("idleCheckHandler", new IdleStateHandler(0, 20, 0, TimeUnit.SECONDS)); 

6.Idle检测类包的功能概览

4.读Idle检测的原理

io.netty.handler.timeout.IdleStateEvent：ReaderIdleTimeoutTask

5.写Idle检测原理和ObserverOutput用途

io.netty.handler.timeout.IdleStateHandler：WriterIdleTimeoutTask

其中observeOutput的用处如下，用于写Idle检测判断条件的选择，true-写空闲判断中的写是指有写意向则算写 false-写空闲的判断中的写是指写成功

private boolean hasOutputChanged(ChannelHandlerContext ctx, boolean first) {    if (observeOutput) {        //正常情况下，false，即写空闲的判断中的写是指写成功，但是实际上，有可能遇到几种情况：        //（1）写了，但是缓存区满了，写不出去；（2）写了一个大“数据”，写确实在“动”，但是没有完成。        //所以这个参数，判断是否有“写的意图”，而不是判断“是否写成功”。        // We can take this shortcut if the ChannelPromises that got passed into write()        // appear to complete. It indicates "change" on message level and we simply assume        // that there's change happening on byte level. If the user doesn't observe channel        // writability events then they'll eventually OOME and there's clearly a different        // problem and idleness is least of their concerns.        if (lastChangeCheckTimeStamp != lastWriteTime) {            lastChangeCheckTimeStamp = lastWriteTime;            // But this applies only if it's the non-first call.            if (!first) {                return true;            }        }        Channel channel = ctx.channel();        Unsafe unsafe = channel.unsafe();        ChannelOutboundBuffer buf = unsafe.outboundBuffer();        if (buf != null) {            int messageHashCode = System.identityHashCode(buf.current());            long pendingWriteBytes = buf.totalPendingWriteBytes();            if (messageHashCode != lastMessageHashCode || pendingWriteBytes != lastPendingWriteBytes) {                lastMessageHashCode = messageHashCode;                lastPendingWriteBytes = pendingWriteBytes;                if (!first) {                    return true;                }            }            long flushProgress = buf.currentProgress();            if (flushProgress != lastFlushProgress) {                lastFlushProgress = flushProgress;                if (!first) {                    return true;                }            }        }    }    return false;}

假设我发送一个消息ABC DEF两块消息，此时接收方不一定是通过两个包就接收到两块消息，可能产生的情况有下述几种

例如：

1. 一个包内包含ABCDEF的信息，这种叫做粘包
2. 也可能分为三个包AB、CD、EF，这种叫做半包

换个角度理解

收发角度来看：一个发送可能会被多次接收，多个发送可能会被一次接收

传输角度来看：一个发送可能占用多个传输包，多个发送可能共用一个传输包

那么会什么会出现粘包和半包现象呢？

2.为什么TCP会出现粘包和半包

总结为一句话：TCP是流式协议，消息无边界

UDP 像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一个签收，所以无粘包、半包问题

粘包的主要原因：

• 发送方每次写入数据 < 套接字缓冲区大小
• 接收方读取套接字缓冲区数据不够及时

半包的主要原因：

• 发送方每次写入数据 > 套接字缓冲区大小
• 发送的数据大于协议的 MTU（Maximum Transmission Unit，最大传输单元），必须拆包

3.解决粘包和半包问题的几种常见方法

4.Netty对三种常用封帧方式的支持

其中固定长度和分割符的方式编码比较简单，因此netty并没有创建具体的类去实现

5.Netty处理粘包、半包的源码

5.1.解码核心工作流程

5.2.解码中两种数据积累器的区别

5.3.三种解码器的常用额外控制参数有哪些

6.二次解码

6.1.什么是二次解码

一次解码负责通过新增长度信息等方式解决粘包、半包的问题，二次解码负责将数据按照一定的编码方式（JSON、XML等）进行序列化及反序列化（例如将报文数据反序列化为Java对象）

6.2.选择编解码方式的要点

6.3.Protobuf 简介与使用

Protobuf 是一个灵活的、高效的用于序列化数据的协议。

相比较 XML 和 JSON 格式，Protobuf 更小、更快、更便捷。

Protobuf 是跨语言的，并且自带了一个编译器（protoc），只需要用它进行编译，可

以自动生成 Java、python、C++ 等代码，不需要再写其他代码。

6.4.netty二次解码的源码

使用示例：io.netty.example.worldclock.WorldClockClientInitializer

/* * Copyright 2012 The Netty Project * * The Netty Project licenses this file to you under the Apache License, * version 2.0 (the "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at: * *   http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the * License for the specific language governing permissions and limitations * under the License. */package io.netty.example.worldclock;import io.netty.channel.ChannelInitializer;import io.netty.channel.ChannelPipeline;import io.netty.channel.socket.SocketChannel;import io.netty.handler.codec.protobuf.ProtobufDecoder;import io.netty.handler.codec.protobuf.ProtobufEncoder;import io.netty.handler.codec.protobuf.ProtobufVarint32FrameDecoder;import io.netty.handler.codec.protobuf.ProtobufVarint32LengthFieldPrepender;import io.netty.handler.ssl.SslContext;public class WorldClockClientInitializer extends ChannelInitializer<SocketChannel> {    private final SslContext sslCtx;    public WorldClockClientInitializer(SslContext sslCtx) {        this.sslCtx = sslCtx;    }    @Override    public void initChannel(SocketChannel ch) {        ChannelPipeline p = ch.pipeline();        if (sslCtx != null) {            p.addLast(sslCtx.newHandler(ch.alloc(), WorldClockClient.HOST, WorldClockClient.PORT));        }        p.addLast(new ProtobufVarint32FrameDecoder());        p.addLast(new ProtobufDecoder(WorldClockProtocol.LocalTimes.getDefaultInstance()));        p.addLast(new ProtobufVarint32LengthFieldPrepender());        p.addLast(new ProtobufEncoder());        p.addLast(new WorldClockClientHandler());    }}

1.三种经典IO

• 阻塞同步IO（BIO）
• 非阻塞同步IO（NIO）
• 非阻塞异步IO（AIO）

详细可看：https://0522-isniceday.top/archives/ji-suan-ji-wang-luo--i-o-mo-xing#more

2.Netty对三种IO的支持

相关api如下：

3.Netty为什么仅仅支持NIO

• 为什么不建议（deprecate）阻塞 I/O（BIO/OIO）?

  连接数高的情况下：阻塞 -> 耗资源、效率低

• 为什么删掉已经做好的 AIO 支持？

  • Windows 实现成熟，但是很少用来做服务器
  • Linux 常用来做服务器，但是 AIO 实现不够成熟
  • Linux 下 AIO 相比较 NIO 的性能提升不明显

4.三种IO分别采取的开发模式

其中NIO采取的就是我们下文所要详细讲述的Reactor模式

Thread-Per-Connection相当于就是为每一个连接分配一个线程去处理，但是这里会受到C10K的约束

代码如下：

package com.linwuee.netty.reactor;import java.net.ServerSocket;import java.net.Socket;/** * @Auther: zhang_yx * @Date: 2021/9/21 15:04 */public class ThreadPerConnection {    public static void main(String[] args) {        new Thread(new Server()).start();    }}class Server implements Runnable{    @Override    public void run() {        try {            ServerSocket serverSocket = new ServerSocket(8080);            while (!Thread.interrupted()){                //这里会阻塞                final Socket socket = serverSocket.accept();                new Thread(new Runnable() {                    @Override                    public void run() {                        System.out.println(Thread.currentThread().getId());                        //TODO 获得已连接套接字，去处理请求                    }                }).start();            }        }catch (Exception e){            System.out.println(e);        }    }}

5.NIO的三种Reactor模型的实现

5.1.Reactor是什么

Reactor可以看做一种设计模式，它要求主线程（IO处理单元）只负责监听文件描述符（fd）是否有事件发生，有的话就立即将该事件通知工作线程（handler）。主线程不做除了监听事件之外的任何操作，读写数据，客户端的请求等均在工作线程中完成。其中主线程往往是阻塞在某一个调用上，并监听。

其中Reactor模式，是处理并发IO比较常见的模式，使用同步非阻塞IO实现。其会将要处理的IO事件放到一个IO多路复用器中，同时主线程阻塞在该多路复用器（select、poll、epoll）上，直到有IO事件准备就绪了，多路解复用器从阻塞处返回，将准备好的IO事件分发到事件处理器（工作线程handler）中

Reactor是基于非阻塞同步IO+事件驱动技术（或+线程池）的一种并发模型

Reactor模式通过poll、epoll等IO分发技术实现的一个无限循环的事件分发程序。获取到一个已连接事件之后，会触发添加监听更多的读写事件

其中可总结为：注册感兴趣的事件 -> 扫描是否有感兴趣的事件发生 -> 事件发生后做出相应的处理

其中事件如下，其中

• 客户端的套接字：连接、读、写事件
• 服务端的监听套接字：获得连接事件
• 服务端的已连接套接字：读、写事件

5.2.Reactor模型详细设计

• Handle：描述符，或者文件句柄，代表操作的资源，例如socketfd。其中会注册到Synchronous Event Demultiplexer(同步事件多路解复用器)中，进行监听Handle上发生的事件，如：Connect，Read，Write，Close等事件（一个handle会有多个事件）；
• Synchronous Event Demultiplexer(同步事件多路解复用器)：该组件阻塞等待被监听的事件集，等待事件发生，一般使用IO复用技术实现，如select、poll、epoll；
• Reactor：类似于程序门面，持有Event Handler，包含注册、删除Event Handler，其中也持有了Synchronous Event Demultiplexer去执行事件的监听，然后根据发生事件的文件描述符和事件类型交给不同的Event Handler去处理
• Event Handler：事件处理器，处理具体的IO事件，对IO事件作出具体的响应

其中通过类图也大概能够看出流程很简单，大概如下：

1. 注册Event Handler（如果是网络IO框架，这一步对应创建监听套接字，并且把监听套接字事件处理器注册到Reactor中），其实相当于创建Acceptor，单线程下的Reactor，多路复用器承担了Acceptor的职责
2. Reactor调用多路复用器中的监听方法，阻塞获取handles（例如已连接套接字），此时可将handle关联Event Handler并注册入Reactor中，方便该handle产生事件时能够找到handler执行（所以也说handler是回调方法）
3. 获得监听事件并将事件交给对应的Event Handler去执行（每个Handle都关联了一个Handler）

现在针对上述流程，也会产生一个问题，就是说当handler执行事件的处理逻辑时，会阻塞多路复用器中的监听方法，因此此时可将事件的处理丢入线程池中取异步执行。

5.3.Reactor模型的三种实现

上面我们说了，事件的再handler中的处理流程可能会阻塞多路复用器的调用，因此可将事件处理丢入线程池去异步执行

5.3.1.单线程版本的Reactor

上述我们所讲的Reactor流程就是单线程版本的实现，其中多路复用器承担了Acceptor的职责，大概流程如下：

• Accept接收新连接，把新连接IO读写事件注册到同步事件多路解复用器；
• 执行dispatch调用多路解复用器阻塞等待IO事件；
• 分发事件到特定的Handler中处理，测试会阻塞dispatch流程；

当描述符可读的时候，才会去执行read，想要往socket写数据的时候，统一先写到输出缓冲区，等到感知到可写事件的时候，再统一把输出缓冲区的数据写到网卡即可，从而避免了读和写的阻塞。

我们需要明白，多路复用器本质就是将往内核的多次IO操作，通过channel一次完成

单线程版本中的Handler处理会阻塞Reactor的Event Loop线程的IO轮训，为此，我们可以把Handler丢到单独的线程池中进行处理

5.3.2.主从版本的Reactor

单线程版本存在的问题主要是Reactor可能因为Event Handler处理速度太占用CPU时间，并且会阻塞dispatch流程，因此可能会影响连接套接字不能及时通过Reactor注册到Synchronous Event Demultiplexer中进行IO轮训

因此我们可以将监听套接字（handle）与已连接套接字（handle）交给不同的Reactor模型去监听，因此就有了主从模式

主Reactor线程只负责执行dispatch阻塞等待监听套接字的连接事件，当有套接字连接之后，随机选择一个Sub-Reactor，把已连接套接字的IO读写事件注册到选择的sub-Reactor线程中

Sub-Reactor线程负责阻塞等待已连接套接字的IO事件的到来，并且调用IO事件的Event Handler处理IO读写事件。这样就实现了IO的高效分发

但是，不管主从Reactor，其中内部对于事件的处理仍然会阻塞dispatch的执行，因此我们还有单线程+主从模式结合线程池的实现

5.3.3.单线程的Reactor+线程池（多线程）

在read到了数据之后，compute这些操作都是业务需要去处理的，因此可将这些内容交给线程池去具体执行，从而加快了时间处理速度

5.3.4.主从的Reactor+线程池（多线程）

同理

5.Netty关于Reactor的实现

我们始终需要明白，单线程，指的是针对socketfd具体事件的处理是单线程的，存在阻塞dispatch的情况

动机：条件表达式通常有2种表现形式。

第一：所有分支都属于正常行为。

第二：条件表达式提供的答案中只有一种是正常行为，其他都是不常见的情况

这2类条件表达式有不同的用途。如果2条分支都是正常行为，就应该使用形如if-else的条件表达式；

如果某个条件极其罕见，就应该单独检查该条件，并在该条件为真时立刻从函数中返回。这种单独检查也称“卫语句”。

针对秒杀场景，除了将库存等相关信息通过缓存增大吞吐之外，还可以采取将库存记录进行分片到不同的库表，来减少单条记录串行导致吞吐很低的场景

状态机

为什么要有状态机去梳理状态

1. 清晰知道状态的变更流程
2. 状态机的每个状态可以用来标识某个阶段的一致性状态，例如：预申请状态

开发：

• 在分布式事物的场景下，存有状态的流水记录需要在本地事物中去进行插入，并且流水状态变更所在的本地事物中，执行的内容就是与流水记录相关的数据的一致性状态变更为流水状态变更后的另一个一致性状态，这样的好处在于，当通过流水记录的状态，我们能够明确知道与流水相关的业务记录的数据处于何种阶段

操作流水

在操作之前先起本地事物插入流水数据

目的：为了保证数据不丢失，类似于Zk的事务请求先落log、habase、es的WAL

关于核对

核对分类

1. 一致性核对
2. 准确性核对

核对场景

1. 跨团队协作，一个业务场景涉及到多个库表
2. 库表进行了字段或者枚举的调整

举例：

在用户初次绑卡发奖场景，绑卡记录和信息存储在会员库，发奖存储在营销库，此时核对就需要监控营销发奖了，用户绑卡库中的卡号是否是只有一条且是刚绑定的卡（卡号是否匹配肯定有流水进行记录）

资损分析

场景识别

**一致性：**站点体系内部系统之间、系统内部多表之间，站点与商户，站点与渠道的数据一致性；包括状态、金额、币种、条数等。

正确性：资损相关业务正确性：资损五大类内部逻辑计算产出的，不能借由一致性核对的，均需要做正确性核对。包含：业务准入（涉及资损风险的错误码） 、业务决策（涉及资损风险的逻辑分支）、专家经验（根据业务特性总结，非代码逻辑）

• UTC：Coordinated Universal Time－ 世界协调时间，零时区
• CST：4个不同的时区时间
  1. Central Standard Time (USA) UT-6:00
  2. Central Standard Time (Australia) UT+9:30
  3. China Standard Time UT+8:00
  4. Cuba Standard Time UT-4:00
• GMT：「格林威治标准时间」(Greenwich Mean Time，简称G.M.T.)
• PST：太平洋标准时间

关系：

UTC=GMT

CST=UTC/GMT +8=PST+8+8

CST=CET+7

UTC=PST+8

目前阿里的服务器统一采取的UTC时区，不带有任何地区标识

地时

时间由两个维度进行标识：时间值+时区

地球处于某一自转状态时对应的时间为地时，地时由时间值和时区组成，即(时间值，时区)二维坐标。地球某一自转状态时，不同时区的时间值不相同，但地时为同一个。地时有多种表达方式，每一个时区都对应一种表达方式，但都是等价的。
例如，(8:00,UTC+01),(9:00,UTC+02),(10:00,UTC+03),(11:00,UTC+04)
这4个地时为等价地时，同一地时在不同时区的转换称为地时的等价转换或恒定转换，将地时转化为相同时区称为地时的共区化。地时只能在相同时区下才能比较，这称为地时的同区比较

因此，对于时间的判断或传递。需要传入时区以及时间值，创建时间也需要包含时区信息，如果未包含，则时间信息无效

业务可能涉及的时区分类：

服务器的系统时间

它影响应用中new Date的值和date toString展示的时区标志，注意Date自身不包含时区标志，它本质上只是个时间戳，toString时仅仅取服务器系统时区作为date的时区标志

sessionTimeZone

它为应用与db会话时所定的时区，db根据这个时区来判断所接收到date的时区。

<bean id="db_config_shareipayment" class="com.alipay.zdatasource.LocalTxDataSourceDO">        <property name="jndiName" value="ShareipaymentDataSource"/>        <property name="connectionURL" value="jdbc:mysql://ipaymydev.devdb.alipay.net:3306/share_ipayment"/>        <property name="driverClass" value="com.mysql.jdbc.Driver"/>        <property name="connectionProperties">            <map>                <entry key="sessionTimeZone" value="PST"/>            </map>        </property>    </bean>

数据库的系统时区

sql生成的时间的出生时区。如sql中使用set gmt_modified=sysdate()

时区问题解决

1. 采取时间戳，因为不同时区的时间戳值一致，缺点主要是时间戳只能用到204X年

2. 确定时区，恒定转换

   在进行时间比较，都需要确定两者的时区一致，或者进行时间的返回渲染页面，也需要确保返回的时间和端的时区一致，以及时间的传递需要保证时间值+时区都穿

洛杉矶时间

洛杉矶时间会涉及冬令时和夏令时的变动，需要注意

其中蚂蚁的SOFA的技术栈也可以了解一下，主要也是应用于金融领域：https://www.sofastack.tech/

最后，内网的技术大佬和优质的技术文章实在是太多了，因此给我学习其他技术并进行梳理的时间越来越少了（主要是公司的内网的很多知识不能传到博客 T.T）

2023-03-21更新

状态良好，初代机继续前进，鸟哥的linux私房菜快点撸完啊，不想只会写业务呀。。。

7.公司Redis的部署模式
8.Mybatis的dao是否可以重载
不能进行重载。。。。

2021-06-08
深圳灰度科技
一面：
1.自我介绍（这一次要好多了）
2.全篇八股文。。。我都不想吐槽了，结果还和我说大小周、994
。。。
反正全部都是八股文，重点是还是他妈面了一个多小时

二面：
1.基本就是聊天了，谈谈开发啥的
人非常nice，聊起来很轻松

2021-06-08
湖南拓维
1.自我介绍
2.项目介绍
3.最近解决的两个问题：死锁的排查及解决、慢接口查询方案
4.ArrayList的相关实现
比上一家靠谱多了。。。至少不会问你八股文。。。。

2021-06-15
芒果tv（挂了）
1.自我介绍什么的
2.排序算法有哪些
3.快速排序是不是稳定的
4.java的Compator.compara底层采取的排序算法是什么
5.平时用过哪些数据库，MySQL的索引有哪些分类
6.讲下linux的grep的使用
这里直接就没让我过。。。。不知道为什么，问的问题也不太多，难道是我开头就说我不想转golang？

2021-09-03
深圳知学云科技
1.MySQL排序如果不加order by会怎么样
2.MySQL调优的一些问题，也就explain、stack_trace去整就好
3.spring的bean的生命周期
4.spring的父子容器的关系
5.B+和B-树的区别
无语，面试挺顺利但是没下文。。

2021-09-06
阿里-蚂蚁
技术面->交叉部门主管面->主管面->hr
1h40min
一面
算法题：
1.实现一个队列
2.队列可能存在哪些并发问题
3.能不能通过代码来使其线程安全

1.自我介绍。。
2.基本没有问八股文，全部都是围绕你的项目发起提问，主要是问你项目相关的问题，
例如
健康检查如果避免手动配置，有没有办法能够做到自动配置
threadLocal在mock组件里面如何使用的，你认为你写的mock组件会不会有什么问题，以及如何优化等等等相关问题
如果让你实现一个从发起支付到结束的请求的全链路监控，你会如何设计等等很多设计的问题

二面：
50min
这轮面试也是基本讨论你的项目，然后八股文的内容很少问，大部分是给场景让你实现的过程或者讨论你的项目细节的时候，会问到一些相关知识
1.实现一个线程池，你会怎么做？讲下思路
2.用户重复发起支付请求，如何处理？要求采取分布式缓存（分布式锁）、或者不采取分布式缓存使用底层db的方式实现（其实就是幂等性，当时我也没看过幂等性的解决方案，就采取第一种是将互斥量存入db，采取effectrow是否等于1的形式来取锁，还有就是唯一索引+ON DUPLICATE KEY UPDATE的方式）
3.还聊了很多项目细节巴拉巴拉，这块偏向于聊天了感觉，感觉这轮更像主管面

三面：
50min
这轮基本全是八股文，估计前面两轮没有考察八股文，放在这里考察了
1.JVM运行时内存的划分
2.一个对象从创建到销毁的内存变化
3.JVM一个对象什么时候会从新生代晋升到老年代
4.Hashmap讲一下
5.hash的扩容机制，如果hashmap扩容之后还是不够怎么办（mmp，JDK集合类包底下偏偏hashmap的源码没有全部都看完，直接不敢回答这个）
6.数据库的隔离级别
7.讲下幻读并讲下如何解决
8.倒排索引讲一下
9.动态代理的实现讲一下
10.消息队列针对消费端的pull模式和push模式各有什么优缺点
大概就这些吧，也不记得漏了没，说我普通话不好，扎心了。。。

2021-09-08
浩鲸
45min
一面：
这个面经我很多就不记得了，因为也是很多八股文，记一下我还记得的
1.如何排查连接池中异常的连接池信息（我说通过服务端grep端口，看下那个傻逼ip连的多）
2.锁相关的问题，还是那样，老东西（JUC底下的几个工具类和源码、锁相关的管程模型、互斥量、忙等待和阻塞巴拉巴拉够你说20分钟）
3.JVM的相关问题，不记得了，反正也是基本概念

二面：
人事面，纯聊天，傻逼公司不建议面

2021-09-09
京东（深圳）
50min
一面：
1.JVM一个对象占用的空间大概多大？
2.JVM是否有过调优经验？
3.用过哪些工具类或linux上的工具？说下用法和好处
4.JVM什么时候会发生内存泄漏
5.Redis如何保证高可用
6.聊了下项目和实现细节，并问了下mock组件可能会存在内存泄漏的风险点
7.JVM的垃圾回收器
8.redis的源码有没有看过？讲下redis的skiplist，会不会写c++代码
9.网络IO、多路复用相关
10.JUC锁相关，问了下对于锁的理解

二面:

记录这个文档的时候还没有二面。。。因为已经拿了蚂蚁的offer了，不过京东最后也是过了，深圳的一个中间件团队，不知道最后裁员没有。。。薪资说在我蚂蚁的基础上+2k，不过还是拒绝了

1.网络分层

1.1.OSI7层模型

1.2.TCP/IP四层模型

可以发现，TCP/IP体系少了表示层和会话层，数据链路层和物理层用链路层取代。

• 应用层：将数据传输给具体的应用：最高层，应用层的任务是通过应用进程间交互来实现特定网络应用。主要负责把应用程序中的用户数据传达给另一台主机或同一主机上的其他应用程序。这是所有应用程序协议的运行层，如SMTP、FTP、SSH、HTTP等；
• 传输层：通用的数据传输服务：负责向两个主机中的进程之间的通信提供通用的数据传输服务。UDP是基本的传输层协议，提供了不可靠的无连接数据报传输服务；
• 网络层：寻址和路由功能：负责为分组交换网上的不同主机提供通信服务。该层定义了寻址和路由功能，主要协议是IP协议(Internet Protocol)，它定义了IP地址，它在路由中的功能是将数据报传输到充当IP路由器的下一个主机，该主机更接近最终数据目的地；
• 链路层：负责处理与传输媒介的相关细节：也称为数据链路层或者网络接口层，通常包括操作系统中设备驱动程序和计算机对应的网络接口卡

1.3.数据包的封装与分用

​

1.4.协议簇

2.物理层

有哪些通信交互方式？单工、半双工通信、全双工通信？

单工通信，又称为单向通信，只有一个方向的通信，如无线电广播，电视广播；

半双工通信，又称为双向交替通信，双方都可以收发信息，只能交替进行；

全双工通信，又称为双向同时通信，双方可以同时发送和接收数据。

3.数据链路层

3.1.数据帧格式

前导：用在发送方和接收方之间同步时钟和bit流；

SFD：帧开始界定符，只有一个byte，内容固定为：10101011 (0xAB)；

DST：目标MAC地址；

SRC：源MAC地址；

长度或类型：0800时，表示IP数据报，0806表示ARP请求/应答，0835表示RARP请求/应答；

FCS：帧检验序列，用于数据帧的差错检测；

3.2.ARP

通过ip地址获取目标的mac地址

3.3.交换机

为什么需要交换机？

集线器（hub）：局域网中，一台机器发送信息，会通过hub将消息以广播的形式给其他局域网内的机器，

交换机：但是hub会有一个缺点，就是会把不属于某台机器的消息也发送给他，因此能不能只给需要的主机发送消息呢？

因此有了交换机，当一台电脑A向交换机发送数据时，交换机会把电脑A的IP和MAC地址记住，保存到一个转发表中，如果转发表中暂时找不到目标IP地址的MAC地址，那么首先还是会广播消息，最终转发表会记录所有请求过交换机的电脑IP和MAC。当然，转发表也是有过期时间的

IP地址与MAC：

IP地址相当于是收货地址，是会改变的，mac地址相当于网卡的唯一标识，也就是你的主机的身份证，因此网络上发送数据不可能只指定身份证，而需要执行邮寄地址

4.网络层

前面我们将的数据链路层，其实只能在局域网内进行通信，因为都是通过MAC地址进行传达信息的，要想跨局域网，那么就得用到IP地址了，这就是网络层要做的事情了。

首先我们来介绍下网络的一个协议：ICMP协议。

4.1.ICMP协议

ICMP：用于获取包发送途中的异常探测，诊断信息，以及发送途中经过的路由器、往返时间。IP协议是无法支持这些的

ICMP并不为IP网络提供可靠性，它只是用于反馈各种故障和配置信息。丢包不会触发ICMP

4.1.1.格式

ICMP报文是在IP数据报内部传输的，格式如下：

而ICMP报文的格式如下：

• 类型有15个不同的值，描述特定类型的ICMP报文；
• 某些ICMP报文还是用代码字段的值来进一步描述不同的条件；
• 校验和字段用于ICMP报文的差错检查。

4.1.2.查询报文

有关信息采集和配置的ICMP报文，ping就是采取的ICMP查询报文

4.1.2.1.PING

ping请求的处理流程：

ping程序是用到了网络层的ICMP协议，不经过传输层

ping失败的原因：

1. IP输入错误
2. 网络配置不正确，如错误的子网掩码
3. 防火墙阻止了ping
4. 硬件故障

4.1.3.差错报文

差错报文是有关IP数据报传递的ICMP报文，要是发送IP数据包中途产生了异常，那么就会响应ICMP报文

但是不是所有情况都会响应ICMP差错报文，如以下场景：

• ICMP差错报文不会产生另一个ICMP差错报文；
• 目的地址是广播地址或者多播地址的IP数据报不会产生差错报文；
• 作为链路层广播的数据报不会产生差错报文；
• 源地址不是单个主机(源地址为零地址、环回地址、广播地址或者多波地址)的数据报不会产生差错报文；

4.2.traceroute程序

traceroute工具用于确定从发送者到目的地路径上的路由器。

traceroute主要是通过故意设置特殊的TTL，来达到追踪目的地路径上的路由器的功能。

TTL运行原理

TTL：是 Time To Live的缩写，该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。每经过一个路由器，TTL就会减一，然后再把IP包转发出去，如果TTL减到0了，路由器就会丢弃收到的TTL=0的IP包，并向IP包的发送者发送一个ICMP差错报文，类型为11，代码为0：传输期间生存时间为0。

4.3.网关和路由器

4.3.1.IP协议

IP是TCP/IP协议簇中最核心的协议，所有TCP、UDP、ICMP等数据都以IP数据包格式传输

4.3.1.1.IP协议特点

1. IP协议是不可靠的传输协议：传输出现异常时，IP层都会丢弃数据包，并且可能会响应一个ICMP差错消息给发送端，而任何要求的可靠性必须由上层如TCP协议来提供；
2. IP协议是无连接的：每个数据报相互独立，可以不按照发送顺序接受，不用维护连接状态等

4.3.1.2.IP数据报格式

• 版本：协议版本号，指明IPv4还是IPv6；
• 头部长度：最长60个字节；
• 服务类型：包含3bit优先权子字段(已被忽略)，4bit TOS子字段(分别代表最小时延、最大吞吐量、最高可靠性和最小费用)和1bit未用位但必须置0；
• 总长度：指的是整个IP数据报的长度，单位字节；
• 标识符：唯一地标识主机发送的每一份数据报，通常每发送一个数据报就+1；
• 标志：主要用于IP分片；
• 分片偏移：主要用于IP分片；
• 生存期：设置数据报可以经过最多的路由器数；
• 协议：主要表明IP数据是什么协议，用于对数据报进行分用；
• 头部校验和：校验数据报是否正确；
• 源IP地址：发送IP数据报的IP地址；
• 目的IP地址：IP数据报目的IP地址；
• 选项：可选数据；
• IP数据：具体的IP数据；

4.3.2.路由器

路由器一般充当一个网关，属于三层设备。其会把MAC头和IP头取下来根据内容进行处理。路由器有5个网口，分别可以连接5个局域网，每个网口有和局域网的IP地址相同的网段，每个网口都是对应局域网的网关，5个网口中一般包含一个外网网口，外网网口用于连接到WAN上。

路由器除了具有交换机的功能外，更拥有路由表作为发送数据包时的依据，在有多种选择的路径中选择最佳的路径。

一层设备、二层设备、三层设备分别有什么区别？

路由器是属于OSI第三层的产品，交換机是OSI第二层的产品。

第二层的产品功能在于，将网络上各个电脑的MAC地址记在MAC地址表中，当局域网中的电脑要经过交换机去交换传递数据时，就查询交换机上的MAC地址表中的信息，将数据包发送给指定的电脑，而不会像第一层的产品（如集线器）每台在网络中的电脑都发送。

而路由器除了有交换机的功能外，更拥有路由表作为发送数据包时的依据，在有多种选择的路径中选择最佳的路径。此外，并可以连接两个以上不同网段的网络，而交换机只能连接两个。路由表存储了（向前往）某一网络的最佳路径、该路径的“路由度量值”以及下一个（跳路由器）

网关地址一般是网段的第一个或者第二个，如192.168.23.0/24这个网段，网关地址可能是192.168.23.1/24或者192.168.23.2/24。

NAT网关：在不同的局域网中，私有IP地址是会重复的，而我们要访问公网的时候，一定要分配一个共有IP地址，所以，我们在访问公网的时候，需要路由器帮忙把私有IP变为共有IP，这种叫做NAT网关，普通内网之间的通信用到的称为转发网关。

4.3.2.1.转发网关

主机A要访问主机B，流程如下：

• 主机A发现要访问的主机B不是在同一个网段（是一个网段则直接通过ARP获得目标id的mac地址，将包发送出去即可，怎么判断同一个网段呢？需要 CIDR 和子网掩码），准备先找到网关，把消息发给网关，网关地址是192.168.1.1，主机A通过ARP获取到了网关的MAC地址，然后发送如下数据包：

  • SRC MAC: 主机A的MACDST MAC: 路由器A的192.168.1.1网口的MACSRC IP : 192.168.1.3DST IP : 192.168.3.4

• 路由器A的192.168.1.1网口接收包之后，准备把包转发出去。而路由器A中的路由表中匹配到了，要想发送给192.168.3.4/24，需要从192.168.2.1这个网口出去，下一跳地址为192.168.2.2/24。路由器通过ARP拿到了下一跳192.168.2.2/24d的MAC地址，然后发送如下数据包：

  • SRC MAC: 路由器A的192.168.2.1网口的MACDST MAC: 路由器B的192.168.2.2网口的MACSRC IP : 192.168.1.3DST IP : 192.168.3.4

• 路由器B的192.168.2.2网口接收包之后，准备把包转发出去。路由器B中判断到目标IP在192.168.3.1这个网口所在的局域网，于是通过ARP拿到了192.168.3.4的MAC地址，然后发送如下数据包：

  • SRC MAC: 路由器B的192.168.3.1网口的MACDST MAC: 主机192.168.3.4网口的MACSRC IP : 192.168.1.3DST IP : 192.168.3.4

最终，主机B收到数据包。

可以发现在转发网关中，源IP和目的IP地址都是不会变的，因为整个内网不可能有冲突的IP。

但是，假如我们要访问外网，情况就不一样了，最终可能会请到到另一个局域网，另一个局域网的私有IP是可能跟我们所在的局域网一样的，为了避免冲突，于是就有了NAT网关。专门在把数据包发送出去之前，把IP改为公网IP。

3.2.2.2.NAT网关

现在假设主机A要访问另一个城市的主机B，这里为了演示NAT，我们把模型简化一下，假设路由器出去之后就是公网IP了，如下：

假设路由器A和路由器B都直接接入了互联网。

现在主机A想访问主机B：

• 由于是不同的局域网，主机A不会知道主机B的IP的，而主机B接入互联网的之后，领取到了一个互联网的IP，就是上图路由器WAN口的IP：203.0.113.103，所以主机B会把这个IP作为主机B的IP，最终发出如下IP数据包：

  • SRC MAC: 主机A的MACDST MAC: 路由器A的192.168.1.1网口的MACSRC IP : 192.168.1.3DST IP : 203.0.113.103

• 192.168.1.1网口接收到包之后，发现要想访问203.0.113.103，就要从203.0.113.102这个网口出去，发给路由器B，路由器B中判断到目标IP就是203.0.113.103这个网口，于是通过ARP拿到了203.0.113.103的MAC地址，然后发送如下数据包：

  • SRC MAC: 路由器A的203.0.113.102网口的MACDST MAC: 路由器B的203.0.113.103网口的MACSRC IP : 203.0.113.102DST IP : 203.0.113.103

  • 因为消息是要发到公网的，最终SRC IP会被NAT转化为公网的IP 203.0.113.102；

• 最终路由器B接收到消息，通过NAPT得到最终接收数据报的IP为当前局域网的192.168.1.3/24，最终把消息转发给了这个IP所在的主机B。

NAPT是如何把一个公网IP翻译为局域网IP的？

传统的NAT(traditional NAT)包括基本NAT(basic NAT)和网络地址端口转换(Network Address Port Translation, NAPT)。基本NAT只执行IP地址的重写，本质上是将私有地址改写为一个公共地址，这往往取自于一个由ISP提供的地址池或共有地址范围，这种NAT不是最流行的，因为无助于减少需要使用的IP地址数量。

比较流行的做法是使用NAPT，NAPT使用传输层标识符如TCP或者UDP端口，或者ICMP查询标识符来确定一个特定的数据报到底和NAT内部哪台私有主机相关联。

如果局域网两个端口号一样，那么NAPT会重写端口号，保证不一致。如下图，三个局域网的IP需要转换为公网IP，由于有两个的端口重复了，于是NAPT进行了端口重写：

两者主要的区别在于 IP 地址是否改变。不改变 IP 地址的网关，我们称为转发网关；改变 IP 地址的网关，我们称为NAT 网关。

3.3.路由策略

3.3.1.静态路由

**静态路由，其实就是在路由器上，配置一条一条规则。**这些规则包括：想访问 B站（它肯定有个网段），从 2 号口出去，下一跳是 IP2；想访问教学视频站（它也有个自己的网段），从 3 号口出去，下一跳是 IP3，然后保存在路由器里。

每当要选择从哪只手抛出去的时候，就一条一条的匹配规则，找到符合的规则，就按规则中设置的那样，从某个口抛出去，找下一跳 IPX。

3.3.2.动态路由

内网路由协议

基于链路状态算法实现的OSPF协议(Open Shortest Path First, 开放式最短路径优先)：主要用于数据中心内部，因此也成为内网路由协议(Interior Gateway Protocol，IGP)，关键是找到最短的路径。

OSPF是一种链路状态路由协议。可以将其视为网络的分布式地图。

外网路由协议

基于距离矢量算法实现的BGP协议(Border Gateway Protocol，外网路由协议)：距离矢量，就是每个路由器都保存一个路由表，路由表每行保存了下一跳的路由器，以及距离下一跳路由器的距离。也成为边界网关协议。

在BGP的世界中，每个路由域都称为自治系统或AS。BGP所做的工作通常是通过选择遍历最少自治系统的路由：最短的AS路径来帮助选择通过Internet的路径。

我们会把重点放在传输层以上，所以动态路由协议这部分我们暂时不做不深入研究。

4.传输层

4.1.UDP

UDP协议处理的事情比较少，类似于IP协议，数据可能丢失，包的顺序无法得到保证，UDP和后边介绍的TCP不一样，是无状态的。

• 源端口号：发送数据报方使用的端口号，用于标识发送进程；
• 目的端口号：接收数据包方使用的端口号，用于标识接收进程；
• UDP长度：UDP头部和UDP负载数据的字节长度；
• UDP校验和：UDP校验和覆盖UDP头部和UDP数据和一个伪头部(区别：IP头部校验和只覆盖IP头部)，伪头部衍生子IPv4头部字段的12个字节，或者衍生子IPv6头部字段的一个40字节的伪头部；
• 负载数据：具体的UDP数据。

UDP和TCP的端口号主要拿来区分哪个进程的数据包，TCP和UDP的端口号相同也没关系，因为两者是相互独立的。每个请求都有源IP、目标IP、源端口号、目标端口、协议五个元素来标识的，每个协议的端口池是完全独立的。在UDP/TCP协议中源端口和目的端口都只有16位，也就是说端口的取值范围为0~65535

4.1.2.UDP的特点

1. 数据可能丢失
2. 无状态，不需要像TCP那样建立连接
3. 没有拥塞机制。来一包就发一个

4.1.3.UDP使用场景

1. 需要资源少，在网络情况比较好的内网，或者对对包不敏感的场合。如DHCP和TFTP就是基于UDP的
2. 广播场景，不需要一对一建立连接，如DHCP
3. 需要时延低，允许丢包，不关注网络拥塞的场景，如视频直播这种流媒体，实时游戏，通信，物联网等领域

4.2.TCP

4.2.1.TCP的简述

1. TCP是面向连接的可靠的服务，面向连接是指TCP的两个应用程序必须在他们可交换数据之前，相互建立一个TCP连接
2. TCP提供了一种面向字节流的抽象概念，TCP不会自动插入记录标志或者消息边界，这意味着TCP没有限制应用程序的写范围。发送端分两次发10字节和30字节，接收端可能会以两个20字节的方式写入

4.2.2.TCP的数据报格式

如上图，头部深黄色部分为TCP特有的重点字段，后面TCP相关功能基本都是靠这些特有的字段来实现的。

• 源端口号和目的端口号：同UDP一样，主要用于区分数据应该转发给哪个应用；
• 序列号：这个序号为了解决乱序的问题，32位无符号数，满了后再从0开始
• 确认号：确认已经接收到了哪里，该值表示确认号的发送方期待接受的下一个序列号，该字段只有在ACK位字段被启用的情况下才有效，所以也成为ACK号或者ACK段
• 状态位：
  • ACK：回复状态，启用该状态的情况下，确认号有效，连接建立之后一般都是启用状态
  • SYN：发起一个连接
  • RST：重置连接，经常因为错误导致
  • FIN：结束连接，表示该报文的发送方已经结束向对方发送数据
  • CWR：拥塞窗口减小，发送方降低发送速率
  • ECE：ECN回显，发送方接收到了一个更早的拥塞通告；
  • URG：紧急，表示紧急指针字段有效，很少用到；
  • PSH：推送，表示接收方应该尽快给应用程序传送这个数据——没有被可靠的实现或用到；
• 窗口大小：流量的窗口大小，用于流量控制，通信双方各声明一个窗口，这个大小表明了自己当前的处理能力
• 校验和：覆盖了TCP的头部和数据，以及伪头部数据(与UDP使用的相似的伪头部进行计算)；
• 紧急指针：只有在UGE位启用的是偶才有效
• 选项：如最大段大小等其他的可选项；
• 数据：TCP数据报的数据内容。

4.2.3.TCP的特点

1. 保证数据顺序传输
2. 丢包重传，消息可靠
3. 连接维护
4. 流量控制，保证稳定
5. 拥塞控制，及时调整，最大程度保证传输正常进行

4.2.3.连接管理

4.2.3.1.TCP三次握手

• 第一次握手：主动连接方发送一个SYN报文段指明自己想要连接的端口号，以及客户端消息的初始化序列化ISN(c)；
• 第二次握手：服务器接收到消息后，也发送自己的SYN报文，包含了服务端的初始化序列号ISN(s)，并设置确认号ack=客户端序列号+1；
• 第三次握手：客户端应答服务器的SYN，将服务端的序列号+1作为ack返回给服务端。

总结一下：客户端与服务端利用SYN报文交换彼此的初始化序列号。在我们熟悉的Socket编程中，三次握手在执行connect的时候触发。

其中的ACK应答和递增的序列化是可靠性的保证。

为什么是三次握手，而不是两次或者四次？

如果是两次：

如果去除了客户端的第三次ACK报文，那么服务端就无法知道服务端发送给客户端的ACK报文是否得到相应，可能服务端就直接结束了请求，这个时候再传消息网络层就会收到一个ICMP目的不可达的差错报文。

如果客户端第一次SYN请求服务端没有ACK应答，那么会重发SYN，此时服务端可能会接收到两个SYN报文，但是并不会建立两个连接，因为会对SYN报文的序列号进行去重，

如果是四次：

因为如果建立连接的双方所发起的SYN报文都得到了响应，双方都知道对方接受了自己的请求，因此没有比较继续发包去确认了

4.2.3.2.TCP的四次挥手

连接的任何一方都可以发起关闭操作，此外，也支持双方同时关闭连接。在传统的情况下，负责发起关闭连接请求的通常是客户端。

这个流程又被称为四次挥手：

• 连接的主动关闭者发送一个FIN段请求关闭连接，携带了序列号seq=p，表明自己的当前序列号，并进入FIN_WAIT_1 状态
• 连接的被动关闭者进行了ACK回应，并发送ack=p+1表明自己已经接受到了FIN的请求，进入ClOSED-WAIT状态。主动关闭者接收到ACK之后，就进入FIN_WAIT_2 状态（此时如果被动关闭者不继续发送FIN连接，则主动关闭者会一直处于FIN_WAIT_2 状态，但是linux可以通过tcp_fin_timeout 设置一个超时时间）
• 连接的被动关闭者也发送一个FIN段请求关闭连接，携带了序列号seq=q，ack=p+1（ack和第二次挥手的一样），告诉主动关闭者已经准备好关闭连接，并进入LAST-ACK状态
• 最后连接的主动关闭者接收到了对方的FIN请求，也回应了一个ACK，表明自己已经成功接收到了被动关闭者发送的FIN，并进入TIME-WAIT等待2MSL之后才进入CLOSED状态

为什么要有TIME-WAIT?

因为可能主动关闭者可能对于被动关闭者的FIN请求的ACK包对方收不到，此时被动关闭者就会进行重试，而TIME-WAIT就是留了对方重试的时间，如果没有TIME-WAIT，由于端口复用，那么其重试的包可能发送给了另外一个程序，由于序列号的存在，新的程序肯定不会消费该包，并且会发送一个RET给对方，此时对方就明白早已断开连接。

等待的时间设为 2MSL，MSL是Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃

序列号

每个连接都要有不同的序号。这个序号的起始序号是随着时间变化的，可以看成一个 32 位的计数器，每 4ms 加一，如果计算一下，如果到重复，需要 4 个多小时，那个绕路的包早就死翘翘了，因为我们都知道 IP 包头里面有个 TTL，也即生存时间

A 要告诉 B，我这面发起的包的序号起始是从哪个号开始的，B 同样也要告诉 A，B 发起的包的序号起始是从哪个号开始的。为什么序号不能都从 1 开始呢？因为这样往往会出现冲突。

例如，A 连上 B 之后，发送了 1、2、3 三个包，但是发送 3 的时候，中间丢了，或者绕路了，于是重新发送，后来 A 掉线了，重新连上 B 后，序号又从 1 开始，然后发送 2，但是压根没想发送 3，但是上次绕路的那个 3 又回来了，发给了 B，B 自然认为，这就是下一个包，于是发生了错误。

4.2.4.数据传输

4.2.4.1.如何保证可靠传输：ACK+序列号

假设主机A通过TCP向主机B发送数据，当主机A的数据到达主机B时，主机B会发送一个确认应答消息ACK。主机A收到ACK之后，就知道自己的数据已经被对方接收了

4.2.4.2.窗口管理

TCP头部中，为了保证包的顺序问题以及丢包问题，我们重点可以关注了如下三个字段：

1. 序列号
2. 确认号
3. 窗口：表明自己的处理能力，代表着可用缓存的大小，以字节为单位

滑动窗口：TCP每个端的数据收发量都是通过滑动窗口来实现的，其中包括发送窗口和接收窗口

发送窗口：

• SND.WND：提供窗口的大小是由返回的ACK中的窗口大小字段来规定的
• SND.UNA：窗口左边界的值
• SND.UNA + SND.WND：记录窗口右边界的值
• SND.NEXT：记录下次发送的数据

窗口包含下面三个操作：

1. 关闭：窗口左边界左移，当已发送的数据得到ACK的时候，就会进行关闭
2. 打开：窗口右边界右移，当接收端处理了确认的数据之后，其窗口值就会变大，这个时候通过打开操作让提供窗口大小变大；
3. 收缩：窗口右边界左移，使得提供窗口大小减小

接收窗口结构：

如何保证包的顺序问题：

4.2.4.3.超时重传机制

关于如何解决包的丢失问题，有如下三种方案

1. 基于计时器的重传超时机制(Retransmission Ttimeout, RTO)
2. 基于反馈信息的快速重传机制
3. 带选择确认的重传SACK

基于计时器的重传超时机制(Retransmission Ttimeout, RTO)：

TCP发送数据时有一个重传计时器，如果计时器超时仍然没有接收到ACK信息，那么会进行重传操作

超时触发重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢

关于重传时间间隔的问题：

而TCP的基于计时器的重传策略是如果发生重试，可以有两种处理方式：

• 一种是基于拥塞控制机制，减小发送窗口大小；
• 另一种是超时时间间隔会一直加倍：每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍

重传时间需要讲到自适应重传算法，一种计算重传时间的算法，大致流程：

TCP通过采样RTT的时间，进行加权平均，算出一个值，最终得到一个估计的重传时间。

> 初始值：原始值> 测量之后：RTO = RTTs + 4*RTTd> (RTTs：加权平均值，RTTd：偏差值)>

基于反馈信息的快速重传机制：

当接收方收到一个序号大于下一个所期望的报文段时，就检测到了数据流中的一个间格，于是发送三个冗余的 ACK，客户端收到后，就在定时器过期之前，重传丢失的报文段。

例如，接收方发现 6、8、9 都已经接收了，就是 7 没来，那肯定是丢了，于是发送三个 6 的 ACK，要求下一个是 7。客户端收到 3 个，就会发现 7 的确又丢了，不等超时，马上重发。

带选择确认的重传SACK：

这种方式需要在 TCP 头里加一个 SACK 的东西，可以将缓存的地图发送给发送方。例如可以发送 ACK6、SACK8、SACK9，有了地图，发送方一下子就能看出来是 7 丢了

4.2.4.5.流量控制

流量控制总结为一句话就是，控制发送方发送窗口的窗口大小（该字段通过接收方的ACK包返回），如果接收方的消息处理不过来，可以减小发送方的窗口，如果接收方比较空闲，则可以增大发送方的窗口大小

如果接收方的包应用程序一直没有处理，最终会导致接收端没有更多空间来存储达到的数据，那么窗口右边界可能就不会打开了，最终接收的窗口大小变为0

此时，接收方会发送一个零窗口通告（TCP ZeroWindow），告知发送端不要再发送数据了，我已经处理不过来了，于是发送方就暂停发送数据了，等待接收端的窗口更新（TCP Window Update）通知

接收方为了防止发送方通知窗口更新的ACK消息丢失，会定时方式（TCP ZeroWindowProbe）请求，要求接收端返回TCP ZeroWindowProbeAck，看看是否窗口是否已经增加了

4.2.5.5.拥塞控制

流量控制通过滑动窗口实现，而拥塞控制则是通过拥塞窗口了，其本质也是为了避免丢包和超时重传

反映网络传输能力的变量称为拥塞窗口(congestion window)，记为cwnd。

可以理解为**滑动窗口是为接收方服务的，而拥塞窗口是为整个网络通道服务的，拥塞窗口大小又会受制于接收方滑动窗口大小，并且会因为网络原因进行调整。**因为网络通道中的任何一个环节都有可能影响整体的传输效率。

实际可用窗口大小：W为接收端滑动窗口awnd和拥塞窗口cwnd的较小者，W = min(cwnd, awnd)

那么发送方如何判断网络是不是满了呢？

对于TCP而言，整个网络路径对其都是一个黑盒，而TCP的拥塞控制主要用来避免丢包和超时重传，如果发生了这两种现象，就说明发送速度太快，要慢一点

那么发送方如何控制拥塞窗口的变化呢？

答案就是慢启动：

当TCP建立连接后，cwnd设置为1，当接收到1个ACK之后，cwnd加1，两个ACK就加2，可以看出这是指数级增长，涨到什么时候是个头呢？其中有一个阈值ssthresh （slow start threshhold）为65535 ，当超过这个值时，我们可能就需要调整我们cwnd的增长策略了，此时cwnd会调整为收到一个ack，增长1/8，收到8个ACK，cwnd才加1，此时增长的速度明显放缓

如果碰到了丢包和超时重传，拥塞窗口cwnd会如何变化？

两种方案：

1. 此时代表出现了拥塞，这个时候会将ssthresh 设为cwnd/2，cwnd重新设置为1，重新开始慢启动。这真是一旦超时重传，马上回到解放前。但是这种方式太激进了，将一个高速的传输速度一下子停了下来，会造成网络卡顿
2. 前面讲的快速重传算法，接收端发现丢了包时，，发送三次前一个包的 ACK，于是发送端就会快速的重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分。此时，cwnd减半为cwnd/2，shthresh = cwnd，并且此时一个ACK，cwnd还是增长1，然后往复。

但是单独依靠丢包和超时重传来判断拥塞也不太准确！？：

第一个问题是丢包并不代表着通道满了，也可能是管子本来就漏水。例如公网上带宽不满也会丢包，这个时候就认为拥塞了，退缩了，其实是不对的。

第二个问题是 TCP 的拥塞控制要等到将中间设备都填充满了，才发生丢包，从而降低速度，这时候已经晚了。其实 TCP 只要填满管道就可以了，不应该接着填，直到连缓存也填满。

为了优化这两个问题，后来有了TCP BBR 拥塞算法。它企图找到一个平衡点，就是通过不断的加快发送速度，将管道填满，但是不要填满中间设备的缓存，因为这样时延会增加，在这个平衡点可以很好的达到高带宽和低时延的平衡。

4.3.Socket编程

4.3.1.是什么

Socket是一个抽象层，主要是把TCP/IP复杂的操作抽象成几个简单的接口提供给应用层调用，进而实现应用进程在网络中通信。Socket主要是端到端之间的传输协议(网络层之上的协议)。

Socket是一种高层的抽象网络API，是一种端到端的通信，只能访问到端到端协议之上的网络层和传输层

4.3.2.基于TCP的Socket通信交互

• bind（）：TCP服务需要监听IP和端口：

  接受到的网络包，需要根据端口来找到应用程序，而ip是因为存在多个网卡，就会有多个ip，因此只能读取监听的ip上网卡的数据

• listen（）：当服务端有了 IP 和端口号，就可以调用 listen 函数进行监听，当调用这个函数之后，服务端就进入了这个状态，这个时候客户端就可以发起连接了（connect()），通过socket创建的套接字为主动套接字，在执行listen函数之后，指示内核应该接收指向该套接字的连接请求，并返回一个监听套接字

  以下是listen()[3]函数定义：

  #include <sys/types.h>          /* See NOTES */#include <sys/socket.h>int listen(int sockfd, int backlog);

  backlog是已连接队列和未完成连接队列的和

• accept（）：

  内核中，每个Socket维护两个队列：

  1. 已建立连接的队列，这时候连接三次握手已经完毕，处于 established 状态
  2. 还没有完全建立连接的队列，这个时候三次握手还没完成，处于 syn_rcvd 的状态

  服务端调用 accept 函数，拿出一个已经完成的连接进行处理。如果还没有完成已完成的连接，此时就需要服务器进入阻塞等待状态，直到获取客户端的已连接套接字并返回

  如下图，在调用accept()之后，阻塞等待客户连接到达，然后获取一个已连接套接字：

  

• connect（）：服务端等待的时候，客户端可以通过connect发起连接，内核会给客户端分配一个临时端口，一旦握手成功，服务端的accept就会返回另外一个socket（连接Socket，后续数据都是通过这个Socket进行传输）

监听的Socket和真正用来传输数据的Socket是两个，一个叫做监听Socket，一个叫做连接Socket

关于监听套接字和已连接套接字

注意，这里要区分好服务端的监听套接字和已连接套接字，服务端调用socket()返回的是监听套接字，bind()和listen()函数入参也是监听套接字。

一旦有客户端请求过来了于是产生了一个已连接套接字，后续和客户端的交互是通过这个已连接套接字进行的。监听套接字只负责监听客户端请求并获取和客户端的已连接套接字，其中每建立一个请求都会产生一个已连接套接字，但是监听套接字只会有一个。

Socket的本质：

内核中，Socket是一个文件，对应的就有文件描述符，每一个进程都有一个数据结构taskStruct，其中存储了进程级的文件描述符列表的指针file_struce，而文件描述符fd就是一个非负整数，是这个数组的下标，而数组存储了该fd指向系统级文件描述表（file_table）表项的指针，该表项就实际存储了inode的地址，但是该inode并不像其他文件一样存储在磁盘，而是存储在内存中，在这个 inode 中，指向了 Socket 在内核中的 Socket 结构

Socket结构中主要是两个队列：队列中存储的是一个缓存sk_buff，这个缓存中能够看到完整的包的结构（该结构就是TCP中的两个滑动窗口吗？），

1. 发送队列
2. 等待队列

4.3.3.基于UDP协议的Socket通信交互

UDP不需要listen以及accept，但是需要bind IP和端口，UDP 是没有维护连接状态的，因而不需要每对连接建立一组 Socket，而是只要有一个 Socket，就能够和多个客户端通信。也正是因为没有连接状态，每次通信的时候，都调用 sendto 和 recvfrom，都可以传入 IP 地址和端口。

4.3.4.服务器如何处理更多的请求

一个Socket处理的请求受限于什么呢？

1. 理论上的最大连接数

   {本机 IP, 本机端口, 对端 IP, 对端端口}其中只有对端ip和对端端口可以发生改变

   最大 TCP 连接数 = 客户端 IP 数×客户端端口数。对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

2. 文件描述符的限制

3. 内存的限制

因此针对该进程记录所有连接套接字socket的fd而言，如果单线程去处理所有的socket（fd list），那么可能会非常的慢

因此在资源有限的情况下，想要处理更多的请求，就需要降低每个项目所占用的资源

1. 方法一：将项目外包给其他公司（多进程方式）

   主要通过fork的方式实现，因为fork会复制父进程的进程级别的fd列表，因此fork出的子进程也可以去处理已建立连接的socket请求，但是采取fork方式过于麻烦

2. 方法二：将项目转包给独立的项目组（多线程方式）

   针对进程级别的fd列表，该方法会创建多个线程去处理socket的数据，例如一个连接socket就创建一个线程去处理，但是这种方式会受限于计算机的性能，一台机器无法创建很多进程或者线程。有个C10K，它的意思是一台机器要维护 1 万个连接，就要创建 1 万个进程或者线程，那么操作系统是无法承受的。如果维持 1 亿用户在线需要 10 万台服务器，成本也太高了

3. 方法三：一个项目组支撑（IO多路复用，一个线程维护多个Socket）

   将进程级别的文件描述符列表（也就是socket列表）的数据放在一个文件描述符集合fd_set中，然后通过select函数去监听这个集合是否发生了变化，一旦有变化那么就会依次查看每个文件描述符。那些有变化的文件描述符在fd_set对应的位设置为1，表示socket可读或者可写，从而可以进行读写操作，然后再调用 select，接着盯着下一轮的变化。但是这种方式采取的是轮询的方式去查看fd_set的改变情况，大大限制的socket的数量（ 通过FD_SETSIZE 限制）

4. 方法四：一个项目组支撑多个项目（IO 多路复用，从“派人盯着”到“有事通知”）

   将select的轮询改为事件通知机制会好很多，当socket发生变化的时候，主动通知项目组，然后项目组再根据然后项目组再根据项目进展情况做相应的操作。

   epoll函数：通过注册callback函数的方式，当某个fd发生变化时，就会主动通知

5.应用层

5.1.DNS解析

DNS服务器：

• 根DNS服务器：返回顶级域 DNS 服务器的 IP 地址
• 顶级域DNS服务器：返回权威 DNS 服务器的 IP 地址
• 权威DNS服务器：返回相应主机的 IP 地址

5.1.1.DNS解析流程

DNS 递归查询过程如下：

1. 先去本地缓存host文件查找
2. 如果没有再去请求本地DNS服务器，也就是网络服务商（ISP）的服务器
3. 本地DNS如果找不到则去请求根域名服务器，根域名服务器全球共有13套，不用于直接解析
4. 然后根域名服务器根据一级域名（.com、.cn等）转向顶级域名服务器，然后根据二级域名，例如163.com，让本地DNS服务器去寻找权威DNS域名服务器
5. 此时权威DNS域名服务器会将域名对应的IP地址告诉本地DNS服务器
6. 本地DNS服务器再将IP信息返回给客户端，再去建立连接

5.2.http协议

http是基于TCP协议的，因此需要先建立TCP连接，

目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样建立的 TCP 连接，就可以在多次请求中复用

5.2.1.http请求的构建

请求行：

• URL：例如 http://www.163.com
• 版本：HTTP 1.1
• 方法：
  1. GET
  2. POST
  3. PUT
  4. DELETE

首部（header）：首部是 key value，通过冒号分隔。这里面，往往保存了一些非常重要的字段。

• Accept-Charset：客户端可以接收的字符集
• Content-Type：正文的格式，例如JSON
• Cache-control：当客户端发送的请求中包含 max-age 指令时，如果判定缓存层中，资源的缓存时间数值比指定时间的数值小，那么客户端可以接受缓存的资源；当指定 max-age 值为 0，那么缓存层通常需要将请求转发给应用集群
• If-Modified-Since：如果服务器的资源在某个时间之后更新了，那么客户端就应该下载最新的资源；如果没有更新，服务端会返回“304 Not Modified”的响应，那客户端就不用下载了，也会节省带宽

5.2.2.HTTP 返回的构建

状态行：HTTP请求的结果

首部（header）：

实体：

5.3.https

http协议会有报文被截取的风险，因此我们需要针对报文进行加密，加密方式分为如下两种：

1. 对称加密

   双方都持有一个秘钥，然后双方都通过此秘钥进行加密解密，但是秘钥也需要在互联网上传播，因此也有被截取的风险，因此这个方法也不可靠

2. 非对称加密

   非对称加密是指私钥放在服务端，公钥放在客户端，客户端通过公钥加密的报文只能通过私钥去解密，但是服务端返回给客户端的报文也需要加密，此时只能够客户端也去持有一个公钥私钥，然后服务端通过客户端的秘钥去加密报文并返回，此时又会有一个问题，那就是客户端和服务端如何去获取对方的公钥呢？这也是数字证书解决的问题

5.3.1.数字证书

如果我创建了一个公钥私钥，服务端或者客户端如何能保证这个公钥是对的，会不会有黑客冒充给我公钥呢？

这个时候就需要权威部门的介入了，就是说每个人都能有自己的秘钥，但是只有权威部门（CA）盖章的公钥才是准确的，而这个我们就称为证书。

证书有什么？

1. 公钥
2. 证书所有者，
3. 发布机构和有效期

证书如何生成呢？会不会有人冒充生成证书呢？

生成证书需要发起一个请求，然后将这个请求发给一个权威机构去认证，这个权威机构我们称为CA（ Certificate Authority）。

证书请求可以通过这个命令生成。

openssl req -key cliu8siteprivate.key -new -out cliu8sitecertificate.req

请求CA机构对证书盖章时候，会同时根据请求内容生成一个签名，同时发送给CA机构，相当于CA机构给服务端背书，CA会针对这个签名进行加密（使用CA的密匙）

此时客户端如果想拿服务端的公钥，就需要通过证书去获取（服务端会将证书传给客户端），客户端可以通过CA的公钥去解密外卖证书的签名（该签名在服务端CA签名的时候会发给CA机构，CA机构会根据CA机构的私钥去对签名进行加密），客户端通过CA公钥解密成功，并且验证签名无误之后，就说明这个证书是正确的

客户端的CA公钥哪里来的？

默认安装在操作系统中，并且有一个证书管理器去管理

客户端的CA公钥可不可能也不可靠呢?

会出现，但是证书以证书链的形式存在，就是说，CA 的公钥也需要更牛的 CA 给它签名，然后形成 CA 的证书。要想知道某个 CA 的证书是否可靠，要看 CA 的上级证书的公钥，能不能解开这个 CA 的签名。样层层上去，直到全球皆知的几个著名大 CA，称为root CA，做最后的背书。通过这种层层授信背书的方式，从而保证了非对称加密模式的正常运转。

5.3.2.https的工作模式

非对称加密在性能上不如堆成加密，因此https协议实际是将两者结合，公钥私钥主要用于传输对称加密的秘钥，而真正的双方大数据量的通信都是通过对称加密进行的

参考链接：

https://www.itzhai.com/articles/comprehend-the-underlying-principles-of-network-programming.html

https://time.geekbang.org/column/intro/100007101

转载链接：https://www.itzhai.com/articles/necessary-knowledge-of-network-programming-graphic-socket-core-insider-and-five-io-models.html

1.为什么IO会阻塞

1.1.TCP中的发送缓冲区和接收缓冲区

TCP的发送缓冲区：TCP的接收队列的数据没有应用程序读取或者读取的速度比较慢，发送缓冲区已发送未确认的数据越来越多，最终导致输出操作阻塞

TCP的接收缓冲区：同样的，接收端接收数据后放入到接收缓冲区中，然后对接收的数据返回一个ack确认信息，如果接收端还没有发送ack信息出去，或者应用进程一直没来取接受缓冲区已接受已确认的数据，那么就不会清除接收缓冲区的数据。

1.2.UDP的阻塞情况

UDP的输入操作：如果UDP套接字没有一个完整的数据报可读，那么就会导致输入操作阻塞；

UDP的输出操作：UDP没有真正的发送缓冲区，内核只是复制应用进程数据并把它沿着协议向下传送，所以对于一个设置为阻塞的UDP套接字，输出函数不会因为与TCP同样的原因导致阻塞，但是可能因为其他原因而阻塞。

1.3.ACCEPT阻塞

如果针对一个阻塞的套接字调用accept函数，并且连接请求还未到达，那么进程会进入睡眠状态，阻塞代表的是当前进程需要等待该函数执行完毕才可以进行下一步的处理（因此Redis的IO模型中listen返回的监听套接字都是非阻塞模式）。对于一个非阻塞的套接字，这种情况，会立刻返回一个EWOULDBLOCK错误。

1.4.Connect阻塞

如果对一个阻塞的套接字调用connect函数，一直要等到收到发出的SYN的ACK为止才返回，所以每个connect至少会阻塞进程至少一个到服务器的RTT时间。对于非阻塞的套接字，这种情况会返回一个EINPROGRESS错误。

为了避免阻塞导致IO性能下降，所以衍生出了几种IO模型，下面我们来介绍下。

2.五种IO模型

下述的IO模型可以看做从已连接套接字中读取TCP数据这一IO过程，因为socketfd的数据都存储在内核中

一般而言，一个输入操作一般会经历如下过程：

1. 等待数据准备好
2. 从内核复制到进程：这里的数据复制，一般是应用进程调用了某个IO方法之后，陷入系统调用，在内核态完成的

下面我们通过UDP的recvfrom()函数来说明具体的IO模型。

2.1.阻塞I/O模型

阻塞主进程：会等待数据准备好，例如使用了阻塞的已连接套接字，因为会导致send（）阻塞读取tcp的数据

如上图，在应用进程调用 recvfrom()之后，陷入内核态，直到数据报到达并且复制到应用进程缓冲区之后才返回到用户态。

或者在系统调用期间发生错误，也会立刻返回。

这种I/O称为阻塞I/O。

2.2.非阻塞I/O模型

轮询：当我们将套接字设置为非阻塞模式的时候，内核会这样处理IO操作，原本IO操作需要阻塞主进程，当非阻塞时，是直接报错，还不是阻塞主进程。上面的例子中，调用recvfrom()之后，因为数据没有准备好，所以内核直接返回一个EWOULDBLOCK错误，直到数据准备好了，才复制数据到进程空间，并返回系统调用继续处理进程逻辑。

而应用进程会不断轮询调用recvfrom()函数，这种处理方式我们称为polling(轮训)，持续到轮训内核，查看数据是否准备好。这种方式的缺点是会消耗大量的CPU时间。

2.3.IO复用模型

IO复用：通过一个支持同时感知多个描述符的函数系统调用，阻塞在这个系统调用。等待某一个或某几个描述符准备就绪，再去读写。例如select，poll，epoll系统调用可以实现此类功能功能。这种模型不用阻塞在真正的I/O系统调用上。

与非阻塞IO相比，其实就是将轮询每一个fd抽象为了select函数调用来实现

在多线中使用阻塞I/O，即每个文件描述符一个线程，与I/O复用模型很类似，每个线程可以自由调用阻塞式I/O系统调用。

2.4.信号驱动式IO模型

所谓信号驱动式I/O(signal-driven I/O)，就是指在描述符准备就绪的时候，让内核发送一个SIGIO信号通知应用进程进行后续的数据读取等处理。工作原理如下图所示：

注册了SIGIO信号处理函数，开启了信号驱动式IO之后，就可以继续执行程序了，等到数据报准备好之后，内核会发送一个SIGIO信号给应用进程，然后应用进程在信号处理函数中调用recvfrom读取数据报。

这种模型在内核等待数据报达到期间进程不会被阻塞，可以继续执行

2.5.异步IO模型

可以发现，上面所有的I/O模型都会在某一个执行点阻塞，并不是真正的异步的。其实就是通知的时间不同

通过异步处理函数如aio_read告知内核启动某个动作，并且让内核在整个操作完成之后再通知应用进程，内核会在把数据复制到用户空间缓冲区之后再进行通知。整个IO过程应用进程都不会被阻塞

3.IO复用模型

3.1.select

3.2.poll

3.3.epoll

1.IoC容器是什么

举个例子：

例如有一天，一个农民，他需要一把铲子去种田，因此这个农民就需要自己去造一把铲子去种田，但是后面农民感觉自己造铲子太麻烦了，然后他就去找一个能够帮忙造铲子的工厂（IoC容器）帮忙造，农夫就只需要从工厂去取（getBean）然后使用就好了，这里我们知道了农夫从工厂通过getBean拿到铲子，那么铲子又是如何造的呢？

造铲子：

工厂内有个员工叫做RES（Resource）负责接收‘取铲子’的需求，需求包括铲子的所需创建零部件（xml参数）和图纸（Class），以及依赖的零部件（依赖的bean）

另外一个员工BDR（BeanDefinitionReader）负责分析需求，并且把需求整理为工厂流水线生产铲子的规范格式BeanDefinition

还有员工BF(BeanFactory)拿到BDR员工提供的BeanDefinition开始制造产品

三个员工同时负责外部交易，通过向客户提供getBean方法让客户来这里拿产品

ClassPathResource res = new ClassPathResource("spring.xml");DefaultListableBeanFactory factory = new DefaultListableBeanFactory();XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);reader.loadBeanDefinitions(res);

但是厂长觉得三个员工配合的流程过于复杂并且没有一个带头的门面大哥去指挥，因此厂长招了个项目经理对三个员工进行管理以及指挥，使得农民拿铲子的流程看起来更简单，并且农民可以直接找项目经理提需求，而不需要直接去找员工，除此之外，项目经理还在之前生产铲子功能之外，扩展了如下的功能：

• 从ApplicationEventPublisher那里学会了事件监听机制，可以让工厂里面的产品之间发送接收消息；
• 从MessageSource学会了外语交流能力；
• 从InitializingBean那里学会了售后服务，在卖出产品后，接收用户的需求调整；
• 从BeanPostProcessor那里学会了售前售后

2.Spring IoC设计原理

从宏观角度看：

其本质就是把程序的类和配置元数据组装起来，然后就可以通过ApplicationContext创建并初始化好之后，通过IoC容易就能直接获得装配好的实例

3.IoC的设计与实现：BeanFactory和ApplicationContext

3.1.BeanFactory容器设计

其中的BeanFactory定义了基本的IoC容器的规范

用XmlBeanFactory的实现为例子来简单说明下IoC容器的设计理念，下图是其一个简单的类图:

• BeanFactory实现是IoC容器的基本形式，各种ApplicationContext的实现是IoC容器的高级表现形式。
• DefaultListableBeanFactory作为一个默认的功能完整的IoC容器来使用
• Resource是Spring用来封装I/O操作的类

3.2.ApplicationContext

前面我们说了ApplicaitonContext，其类似于工厂的项目经理，一个生产的需求提过来，ApplicationContext能够很好并且很简单的完成。对于农民而言无需关注生产过程中过多的细节，并且其相较于BeanFactory也扩展了很多功能，可以这样说：

• ApplicationContext是一个高级形态的IoC容器
• 支持不同的信息源：继承接口Messagesource；
• 访问资源：继承接口ResourceLoader；
• 支持应用事件
• 在ApplicationContext中提供附加功能；

3.2.1.ApplicationContext的实现

ApplicationContext的实现类主要有两个：

1. FileSystemXmlApplicationContext
2. ClassPathXmlApplicationContext

继承关系如下：

其中ApplicationContext的主要功能在AbstractRefreshableApplicationContext中实现了，接下来我们通ClassPathXmlApplicationContext来讲解下如下几个问题：

1. IoC容器的创建过程
2. bean的创建及其赋值过程
3. bean的初始化过程

接下来，我们用如下代码段作为入口，去深入探析如上的问题：

public static void main(String[] args) {    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("config.xml");    SimpleBean simpleBean = context.getBean(SimpleBean.class);    simpleBean.invoke();}

其中SimpleBean只是一个很普通的bean，代码如下：

/** * @Auther: zhang_yx * @Date: 2021/3/24 15:23 */public class SimpleBean {    private String desc;    public void invoke(){        System.out.println("我的描述："+desc);    }    public String getDesc() {        return desc;    }    public void setDesc(String desc) {        this.desc = desc;    }}

config.xml配置文件如下：

<bean class="com.lingwuee.zhang.springlearn.IoC.SimpleBean">    <property name="desc" value="冲起来"></property></bean>

3.3.ApplicaitionContext：IoC容器的创建过程

3.3.1.构造方法

3.3.1.1.获得当前的配置文件位置+将ClassPathXmlApplicationContext作为ResourceLoader存入成员变量

执行上述代码，首先进入的是构造方法：

public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)      throws BeansException {   //执行父类的构造方法，会一直执行到AbstractApplicationContext的构造方法，代码如下   super(parent);   //设置配置文件位置，并存储到成员变量configLocations中，其中会经过一段文本处理的代码   setConfigLocations(configLocations);   //默认为true   if (refresh) {      //Spring bean解析就在此方法，非常重要      refresh();   }}

AbstractApplicationContext构造方法，其实只是将ClassPathXmlApplicationContext作为ResourceLoader传入了AbstractApplicationContext成员变量resourcePatternResolver中

/** ResourcePatternResolver used by this context */private ResourcePatternResolver resourcePatternResolver;public AbstractApplicationContext(ApplicationContext parent) {   this();   setParent(parent);}public AbstractApplicationContext() {    this.resourcePatternResolver = getResourcePatternResolver();}

AbstractApplicationContext的refresh()源码如下：

@Overridepublic void refresh() throws BeansException, IllegalStateException {   synchronized (this.startupShutdownMonitor) {      // Prepare this context for refreshing.      prepareRefresh();      // Tell the subclass to refresh the internal bean factory.      ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();      // Prepare the bean factory for use in this context.      prepareBeanFactory(beanFactory);      try {         // Allows post-processing of the bean factory in context subclasses.         postProcessBeanFactory(beanFactory);         // Invoke factory processors registered as beans in the context.         invokeBeanFactoryPostProcessors(beanFactory);         // Register bean processors that intercept bean creation.         registerBeanPostProcessors(beanFactory);         // Initialize message source for this context.         initMessageSource();         // Initialize event multicaster for this context.         initApplicationEventMulticaster();         // Initialize other special beans in specific context subclasses.         onRefresh();         // Check for listener beans and register them.         registerListeners();         // Instantiate all remaining (non-lazy-init) singletons.         finishBeanFactoryInitialization(beanFactory);         // Last step: publish corresponding event.         finishRefresh();      }      catch (BeansException ex) {         if (logger.isWarnEnabled()) {            logger.warn("Exception encountered during context initialization - " +                  "cancelling refresh attempt: " + ex);         }         // Destroy already created singletons to avoid dangling resources.         destroyBeans();         // Reset 'active' flag.         cancelRefresh(ex);         // Propagate exception to caller.         throw ex;      }      finally {         // Reset common introspection caches in Spring's core, since we         // might not ever need metadata for singleton beans anymore...         resetCommonCaches();      }   }}

3.3.2.prepareRefresh()

准备上下文环境，其中只关注重要的方法：

protected void prepareRefresh() {   //空实现   initPropertySources();//AbstractApplicationContext.getEnvironment(),获得当前的环境信息，其中包括JVM的参数，操作系统的环境变量，spring中配置的config参数   getEnvironment().validateRequiredProperties();   this.earlyApplicationEvents = new LinkedHashSet<ApplicationEvent>();}

3.3.2.1.生成Environment实例并存入成员变量

getEnvironment方法源自于ConfigurableApplicationContext.createEnvironment(),源码很简单，其中存储的内容是当前系统的环境变量（如果能获取到）、JVM参数、spring的property、profile信息，其中Environment的继承体系如下图：

Spring Profile特性是从3.1开始的，其主要是为了解决这样一种问题: 线上环境和测试环境使用不同的配置或是数据库或是其它。有了Profile便可以在 不同环境之间无缝切换。**Spring容器管理的所有bean都是和一个profile绑定在一起的。**使用了Profile的配置文件示例:

<beans profile="develop">   <context:property-placeholder location="classpath*:jdbc-develop.properties"/>  </beans>  <beans profile="production">   <context:property-placeholder location="classpath*:jdbc-production.properties"/>  </beans>  <beans profile="test">   <context:property-placeholder location="classpath*:jdbc-test.properties"/>  </beans>

在启动代码中可以用如下代码设置活跃(当前使用的)Profile:

context.getEnvironment().setActiveProfiles("dev");

其中创建的environment持有一个MutablePropertySources对象，其中就使用了一个CopyOnWriteArrayList存储环境变量和JVM参数。PropertySource接口代表了键值对的Property来源，继承体系如下图：

3.3.3.ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

源码如下：

AbstractApplicationContext.class

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {   //初始化beanFactory   refreshBeanFactory();   ConfigurableListableBeanFactory beanFactory = getBeanFactory();   if (logger.isDebugEnabled()) {      logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);   }   return beanFactory;}

3.3.3.1.创建DefaultListableBeanFactory

此处由于并没有传一个ConfigurableApplicationContext的子类进来，传了则会将该值赋值给成员变量：AbstractBeanFactory.parentBeanFactory

protected final void refreshBeanFactory() throws BeansException {   try { //创建了一个DefaultListableBeanFactory对象      DefaultListableBeanFactory beanFactory = createBeanFactory();       //定制参数      customizeBeanFactory(beanFactory);      loadBeanDefinitions(beanFactory);      synchronized (this.beanFactoryMonitor) {         this.beanFactory = beanFactory;      }   }   catch (IOException ex) {   }}

3.3.3.2.DefaultListableBeanFactory定制参数

AbstractRefreshableApplicationContext.customizeBeanFactory方法用于给子类提供一个自由配置的机会，默认实现:

protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {    if (this.allowBeanDefinitionOverriding != null) {        //默认false，不允许覆盖        beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);    }    if (this.allowCircularReferences != null) {        //默认false，不允许循环引用        beanFactory.setAllowCircularReferences(this.allowCircularReferences);    }}

3.3.3.3.核心流程-Bean加载入DefaultListableBeanFactory：AbstractXmlApplicationContext.loadBeanDefinitions(beanFactory);

AbstractXmlApplicationContext.loadBeanDefinitions(beanFactory)，这个就是核心bean的加载了，此处的执行步骤

@Overrideprotected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {    // 1.为给定的beanFactory创建一个XmlBeanDefinitionReader对象   XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);   // 2.设置必要参数   beanDefinitionReader.setEnvironment(this.getEnvironment());   beanDefinitionReader.setResourceLoader(this);   beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));   //创建BeanDefiniton并存储   loadBeanDefinitions(beanDefinitionReader);}

3.3.3.3.1.为DefaultListableBeanFactory创建XmlBeanDefinitionReader

其中BeanDefineReader继承关系如下图，其职责就是根据ResourceLoader读取到的xml解析的信息（图纸），生成bean的规范BeanDefiniton（工厂生产东西的规范格式）：

3.3.3.3.2.XmlBeanDefinitionReader.loadBeanDefinitions()创建BeanDefiniton并存储

1. getConfigLocations()：获得配置文件的具体位置
2. loadBeanDefinitions(configLocations)：生成BeanDefinition

protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {   Resource[] configResources = getConfigResources();   if (configResources != null) {      reader.loadBeanDefinitions(configResources);   }   String[] configLocations = getConfigLocations();   //重点生成的代码   if (configLocations != null) {      reader.loadBeanDefinitions(configLocations);   }}

其中通过ResourceLoader获得bean配置并且生成BeanDefinitions的核心代码如下：

AbstractBeanDefinitionReader.loadBeanDefinitions 206行：

//第二个参数为nullpublic int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {   ResourceLoader resourceLoader = getResourceLoader();   //ApplicationContext都实现了ResourceLoader相关的接口   if (resourceLoader instanceof ResourcePatternResolver) {      try {         Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);         int loadCount = loadBeanDefinitions(resources);         return loadCount;      }      catch (IOException ex) {         throw new BeanDefinitionStoreException(               "Could not resolve bean definition resource pattern [" + location + "]", ex);      }   }   else {      // Can only load single resources by absolute URL.      Resource resource = resourceLoader.getResource(location);      int loadCount = loadBeanDefinitions(resource);      return loadCount;   }}

其中有两个核心的调用：

//加载Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);//解析int loadCount = loadBeanDefinitions(resources);

3.3.3.3.2.1.AbstractApplicationContext.getResources(location)加载xml配置文件

代码如下：

/** 其值再实例化ApplicaitionContext的时候会赋值好，其类内部持有ResourceLoad也就是ApplicaitionContext的引用 */private ResourcePatternResolver resourcePatternResolver;//读取文件，并返回Resource对象public Resource[] getResources(String locationPattern) throws IOException {   return this.resourcePatternResolver.getResources(locationPattern);}

3.3.3.2.2.2.XmlBeanDefinitionReader.loadBeanDefinitions(resources)解析文件并生成BeanDefinitions

其中底层调用的方法是XmlBeanDefinitionReader.loadBeanDefinitions（EncodedResource encodedResource），代码如下，其中关键的源码只有两行：

public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {    InputStream inputStream = encodedResource.getResource().getInputStream();    InputSource inputSource = new InputSource(inputStream);    //源码如下    return doLoadBeanDefinitions(inputSource, encodedResource.getResource());}

Resource是一种代表资源的接口，其中EncodedResource扮演的是一个装饰器模式，为InputStreamSource添加了字符编码(虽然默认为null)。这样为我们自定义xml配置文件的编码方式提供了机会

XmlBeanDefinitionReader.doLoadBeanDefinitions：

protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource) {    Document doc = doLoadDocument(inputSource, resource);    return registerBeanDefinitions(doc, resource);}

其中doLoadDocument返回的就是解析之后的结果，spring也是采取了dom的方式解析，即一次全部load到内存当中

public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {   BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();    //解析Resource对象并生成BeanDefinition对象存入map交由ApplicationContext持有   documentReader.registerBeanDefinitions(doc, createReaderContext(resource));}

XmlBeanDefinitionReader.createBeanDefinitionDocumentReader：

这里为什么用了转型呢？因为这里使用到了策略模式，spring的使用方可以通过set的方式去修改这个BeanDefinitionDocumentReader策略实现，实现了IoC容器针对BeanDefinitionDocument也就是xml信息读取之后的操作的可扩展，调用方只需要初始化XmlBeanDefinitionReader时set入自己的BeanDefinitionDocument类就好了

//默认值是DefaultBeanDefinitionDocumentReader类private Class<?> documentReaderClass = DefaultBeanDefinitionDocumentReader.class;public void setDocumentReaderClass(Class<?> documentReaderClass) {    this.documentReaderClass = documentReaderClass;}protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {   return BeanDefinitionDocumentReader.class.cast(BeanUtils.instantiateClass(this.documentReaderClass));}

DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(Document doc, XmlReaderContext readerContext) ：

@Overridepublic void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {   this.readerContext = readerContext;   Element root = doc.getDocumentElement();   doRegisterBeanDefinitions(root);}

DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(Element root)：

protected void doRegisterBeanDefinitions(Element root) {  BeanDefinitionParserDelegate parent = this.delegate;    this.delegate = createDelegate(getReaderContext(), root, parent);    //默认的命名空间即    //http://www.springframework.org/schema/beans    if (this.delegate.isDefaultNamespace(root)) {        //检查profile属性        String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);        if (StringUtils.hasText(profileSpec)) {            //profile属性可以以,分割            String[] specifiedProfiles = StringUtils.tokenizeToStringArray(                    profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);            if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {                return;            }        }    }   preProcessXml(root);   parseBeanDefinitions(root, this.delegate);   postProcessXml(root);   this.delegate = parent;}

delegate的作用在于处理beans标签的嵌套，其实Spring配置文件是可以写成这样的：

<?xml version="1.0" encoding="UTF-8"?>    <beans>        <bean class="base.SimpleBean"></bean>    <beans>        <bean class="java.lang.Object"></bean>    </beans></beans>

preProcessXml方法是个空实现，供子类去覆盖，目的在于给子类一个把我们自定义的标签转为Spring标准标签的机会, 想的真周到。

DefaultBeanDefinitionDocumentReader.parseBeanDefinitions：

protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {    if (delegate.isDefaultNamespace(root)) {        NodeList nl = root.getChildNodes();        for (int i = 0; i < nl.getLength(); i++) {            Node node = nl.item(i);            if (node instanceof Element) {                Element ele = (Element) node;                if (delegate.isDefaultNamespace(ele)) {                    parseDefaultElement(ele, delegate);                } else {                    delegate.parseCustomElement(ele);                }            }        }    } else {        delegate.parseCustomElement(root);    }}

对于非默认命名空间的元素交由delegate处理。

默认命名空间：import、alias、bean、beans

private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {   if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {      importBeanDefinitionResource(ele);   }   else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {      processAliasRegistration(ele);   }   else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {      processBeanDefinition(ele, delegate);   }   else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {      // recurse      doRegisterBeanDefinitions(ele);   }}

1. import标签：

   写法示例:

   <import resource="CTIContext.xml" /><import resource="customerContext.xml" />

   importBeanDefinitionResource(ele)：着重看下下述源码，其实核心还是只想的BeanDefinitionReader.public int loadBeanDefinitions(String location, Set actualResources) throws BeanDefinitionStoreException 方法：

   private XmlReaderContext readerContext;//其中持有BeanDefinitionReader对象的实例protected void importBeanDefinitionResource(Element ele) {   String location = ele.getAttribute(RESOURCE_ATTRIBUTE);   int importCount = getReaderContext().getReader().loadBeanDefinitions(location, actualResources);}protected final XmlReaderContext getReaderContext() {return this.readerContext;}

2. alias

   加入有一个bean名为componentA-dataSource，但是另一个组件想以componentB-dataSource的名字使用，就可以这样定义:

   <alias name="componentA-dataSource" alias="componentB-dataSource"/>

   processAliasRegistration核心源码:

   protected void processAliasRegistration(Element ele) {    String name = ele.getAttribute(NAME_ATTRIBUTE);    String alias = ele.getAttribute(ALIAS_ATTRIBUTE);    getReaderContext().getRegistry().registerAlias(name, alias);    getReaderContext().fireAliasRegistered(name, alias, extractSource(ele));}

   从前面的源码可以发现，registry其实就是DefaultListableBeanFactory，它实现了BeanDefinitionRegistry接口。registerAlias方法的实现在SimpleAliasRegistry:

   @Overridepublic void registerAlias(String name, String alias) {    Assert.hasText(name, "'name' must not be empty");    Assert.hasText(alias, "'alias' must not be empty");    //名字和别名一样    if (alias.equals(name)) {        //ConcurrentHashMap        this.aliasMap.remove(alias);    } else {        String registeredName = this.aliasMap.get(alias);        if (registeredName != null) {            if (registeredName.equals(name)) {                // An existing alias - no need to re-register                return;            }            if (!allowAliasOverriding()) {                throw new IllegalStateException                    ("Cannot register alias '" + alias + "' for name '" +                    name + "': It is already registered for name '" + registeredName + "'.");            }        }        checkForAliasCircle(name, alias);        this.aliasMap.put(alias, name);    }}

   所以别名关系的保存使用Map完成，key为别名，value为本来的名字。

3. bean

   bean节点是Spring最最常见的节点了。

   DefaultBeanDefinitionDocumentReader.processBeanDefinition:

   protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {//生成BeanDefinition    BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);    if (bdHolder != null) {        bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);        try {            // Register the final decorated instance.            BeanDefinitionReaderUtils.registerBeanDefinition                (bdHolder, getReaderContext().getRegistry());        }        catch (BeanDefinitionStoreException ex) {            getReaderContext().error("Failed to register bean definition with name '" +                    bdHolder.getBeanName() + "'", ele, ex);        }        // Send registration event.        getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));    }}

   id & name处理

   delegate.parseBeanDefinitionElement(ele)：

   代码比较长，大概逻辑如下：

   1. 首先获取到id和name属性，name属性支持配置多个，以逗号分隔，如果没有指定id，那么将以第一个name属性值代替。id必须是唯一的，name属性其实是alias的角色，可以和其它的bean重复，如果name也没有配置，那么其实什么也没做。

   2. beanName生成：如果name和id属性都没有指定，那么Spring会自己生成一个, BeanDefinitionParserDelegate.parseBeanDefinitionElement:

      beanName = this.readerContext.generateBeanName(beanDefinition);String beanClassName = beanDefinition.getBeanClassName();aliases.add(beanClassName);

      可见，Spring同时会把类名作为其别名。最终调用的是BeanDefinitionReaderUtils.generateBeanName:

   3. bean解析：

      首先获取bean的class属性和parent属性：配置了parent属性的话，当前bean会继承父parent的属性，之后根据class和parent创建BeanDefinition对象。

      AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);public AbstractBeanDefinition parseBeanDefinitionElement(Element ele, String beanName, BeanDefinition containingBean) {this.parseState.push(new BeanEntry(beanName));String className = null;if (ele.hasAttribute(CLASS_ATTRIBUTE)) {className = ele.getAttribute(CLASS_ATTRIBUTE).trim();}    String parent = null;    if (ele.hasAttribute(PARENT_ATTRIBUTE)) {            parent = ele.getAttribute(PARENT_ATTRIBUTE);        }    //1.生成bean    AbstractBeanDefinition bd = createBeanDefinition(className, parent);    //2.解析bean标签的各个属性，setter存入BeanDefinition    parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);    //3.descrition属性的信息    bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));//4.meta等属性的信息    parseMetaElements(ele, bd);    parseLookupOverrideSubElements(ele, bd.getMethodOverrides());    parseReplacedMethodSubElements(ele, bd.getMethodOverrides());    //5.标签内的构造标签处理<constructor-arg>    parseConstructorArgElements(ele, bd);    //6.标签内的<property>处理        parsePropertyElements(ele, bd);        parseQualifierElements(ele, bd);        bd.setResource(this.readerContext.getResource());        bd.setSource(extractSource(ele));        return bd;}

      BeanDefinition的创建在BeanDefinitionReaderUtils.createBeanDefinition:

      其中返回的GenericBeanDefinition主要包括如下信息：当前bean标签class熟悉的Class信息、ClassName信息、parentName信息

      public static AbstractBeanDefinition createBeanDefinition(        String parentName, String className, ClassLoader classLoader) {    GenericBeanDefinition bd = new GenericBeanDefinition();    bd.setParentName(parentName);    if (className != null) {        if (classLoader != null) {            bd.setBeanClass(ClassUtils.forName(className, classLoader));        }        else {            bd.setBeanClassName(className);        }    }    return bd;}

      具体的attribute属性值信息调用如下发方法设置：

      其实就是读取其配置，调用相应的setter方法保存在BeanDefinition中:

      parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);

      之后解析bean的decription子元素:就仅仅是个描述。

      <bean id="b" name="one, two" class="base.SimpleBean">    <description>SimpleBean</description></bean>

      然后是meta子元素的解析：

      meta元素在xml配置文件里是这样的:

      <bean id="b" name="one, two" class="base.SimpleBean">    <meta key="name" value="skywalker"/></bean>

      注释上说，这样可以将任意的元数据附到对应的bean definition上。解析过程源码

      构造参数的解析：

      作用一目了然，使用示例:

      <bean class="base.SimpleBean">    <constructor-arg>        <value type="java.lang.String">Cat</value>    </constructor-arg></bean><bean class="com.lingwuee.zhang.springlearn.IoC.SimpleBean">        <constructor-arg index="0" type="java.lang.String" value="11"/></bean>

      type一般不需要指定，除了泛型集合那种。除此之外，constructor-arg还支持name, index, ref等属性，可以具体的指定参数的位置等。构造参数解析后保存在BeanDefinition内部一个ConstructorArgumentValues对象中。如果设置了index属性，那么以Map<Integer, ValueHolder>的形式保存，反之，以List的形式保存。

      property解析:

      非常常用的标签，用以为bean的属性赋值，支持value和ref两种形式，示例:

      <bean class="base.SimpleBean">    <property name="name" value="skywalker" /></bean>

      value和ref属性不能同时出现，如果是ref，那么将其值保存在不可变的RuntimeBeanReference对象中，其实现了BeanReference接口，此接口只有一个getBeanName方法。如果是value，那么将其值保存在TypedStringValue对象中。最终将对象保存在BeanDefinition内部一个MutablePropertyValues对象中(内部以ArrayList实现)。

      ​

   4. Bean注册：

      BeanDefinitionReaderUtils.registerBeanDefinition:

      public static void registerBeanDefinition(    BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry) {    // Register bean definition under primary name.    String beanName = definitionHolder.getBeanName();    registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());    // Register aliases for bean name, if any.    String[] aliases = definitionHolder.getAliases();    if (aliases != null) {        for (String alias : aliases) {            registry.registerAlias(beanName, alias);        }    }}

      registry其实就是DefaultListableBeanFactory对象，registerBeanDefinition方法主要就干了这么两件事:

      @Overridepublic void registerBeanDefinition(String beanName, BeanDefinition beanDefinition) {//beanName如果没有设置，那么默认为类的全限定名    this.beanDefinitionMap.put(beanName, beanDefinition);    this.beanDefinitionNames.add(beanName);}

      一个是Map，另一个是List，一目了然。registerAlias方法的实现在其父类SimpleAliasRegistry，就是把键值对放在了一个ConcurrentHashMap里。

   BeanDefiniton数据结构：

   

   BeanDefinition在BeanFactory中的主要数据结构如下图:

   

3.3.4.prepareBeanFactory(beanFactory)

该方法复制对BeanFactory进行一些特征方面的设置

源码如下：

protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {   // Tell the internal bean factory to use the context's class loader etc.   beanFactory.setBeanClassLoader(getClassLoader());   beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));   beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));   // Configure the bean factory with context callbacks.   beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));   beanFactory.ignoreDependencyInterface(EnvironmentAware.class);   beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);   beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);   beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);   beanFactory.ignoreDependencyInterface(MessageSourceAware.class);   beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);   // BeanFactory interface not registered as resolvable type in a plain factory.   // MessageSource registered (and found for autowiring) as a bean.   beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);   beanFactory.registerResolvableDependency(ResourceLoader.class, this);   beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);   beanFactory.registerResolvableDependency(ApplicationContext.class, this);   // Register early post-processor for detecting inner beans as ApplicationListeners.   beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));   // Detect a LoadTimeWeaver and prepare for weaving, if found.   if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {      beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));      // Set a temporary ClassLoader for type matching.      beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));   }   // Register default environment beans.   if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {      beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());   }   if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {      beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());   }   if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {      beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());   }}

3.3.5.postProcessBeanFactory(beanFactory)

空实现，运行子类在所有的bean尚未初始化之前注册BeanPostProcessor，空实现且没有子类覆盖

3.3.6.invokeBeanFactoryPostProcessors(beanFactory)

3.3.7.registerBeanPostProcessors(beanFactory)

本质就是从BeanDefitions中获得BeanFactoryPostProcessor，之后调用BeanFactory.addBeanPostProcessor方法保存在一个List中，注意添加时仍然有优先级的概念，优先级高的在前面。

3.3.8.initMessageSource()

该方法用于提供spring国际化，该方法就是在BeanFactory中查找MessageSource的bean并通过getBean方法实例化，并保存在ApplicaitonContext内部的messageSource成员变量中，用以处理ApplicationContext的getMessage调用，从继承体系上来看，ApplicationContext是MessageSource的子类，此处是委托模式的体现。如果没有配置此bean，那么初始化一个DelegatingMessageSource对象，此类是一个空实现，同样用以处理getMessage调用请求

委托模式就是指A类中关联了B类，业务通过调用A类的接口实现功能，但是A类的方法实际调用的是B类，其实就是门面模式

3.3.9.initApplicationEventMulticaster()

spring的驱动（监听模式）

initApplicationEventMulticaster则首先在BeanFactory中寻找ApplicationEventMulticaster的bean，如果找到，那么调用getBean方法将其初始化，如果找不到那么使用SimpleApplicationEventMulticaster。

监听者模式：

3.3.10.onRefresh()

模板方法，交由子类实现，允许子类在bead初始化之前进行一些定制操作

3.3.11.registerListeners()

注册监听时间以及发布时间，从BeanFactory获得ApplicationListener的bean并注册

3.3.12.finishBeanFactoryInitialization(beanFactory)

完成scope为singletonBean并且非lazy-init的bean的初始化（通过调用getBean，单例的bean会有一个单独的ConcurrentHashMap存储），spring的Bean默认为单例

3.3.13.finishRefresh()

完成容器的刷新，调用LifecycleProcessor的onrefresh方法，发布ContextRefreshedEvent事件

LifecycleProcessor：负责管理ApplicationContext的生命周期

1.JUC的包结构

我们查看下java.util.concurrent.locks包下面，发现主要包含如下类：

构建UML图如下：

JUC包下主要有三把锁：

1. ReentrantLock
2. StampedLock，其相较于ReentrantReadWriteLock，多了个乐观读，其实就是用于校验读取的数据是否被修改了
3. ReentrantReadWriteLock

我们可以看到上述三个锁除了StampedLock，顶层都是AbstractQueueSynchronizer类，因此我们来介绍下该类

2.AbstractQueueSynchronizer

AbstractQueuedSynchronizer，简写为AQS，抽象队列同步器，许多同步器都可以通过AQS很容易并且高效的构造出来，以下都是通过ASQ构造出来的：ReentrantLock，Semaphore，CountDownLatch，ReentrantReadWriteLock，SynchronousQueue，FutureTask

2.1.AQS原理

AQS的作用：通过队列来辅助实现线程同步。线程并发争夺state资源，争夺失败的则进入等待队列（同步队列）并进入阻塞状态，在state资源被释放之后，从队列头唤醒被阻塞的线程节点，进行state资源的竞争

AQS的抽象：AQS将最难写的频繁出队入队操作、线程的阻塞唤醒操作已模板的方式写好了，实现类只需要将模板的相关方法进行实现，即可实现不一样的锁或者同步器

AQS使用了模板方法，把同步队列都封装起来了，同时提供了以下五个未实现的方法，用于子类的重写：

2.2.AQS的数据结构

AQS中包含的变量

• state：所有线程通过CAS尝试给state设值，当state>0时表示线程被占用，同一个线程多次获取state，会叠加state的值，从而实现了可重入
• exclusiveOnwerThread：在独占模式下这个属性会用到，当线程尝试以独占模式成功给state设值之后，该变量会存储独占的线程。
• 等待队列（同步队列）：等待队列中存放了所有针对state失败的线程，是一个双向链表结构。state被某一个线程占用之后，其余线程会进入等待队列等待，等待state被释放（state=0），释放state的线程会唤醒等待队列中的线程继续尝试cas设值state
• head：指向等待队列的头节点，延迟初始化，除了初始化之外，只能通过setHead方法进行修改
• tail：指向等待队列的队尾，延迟初始化，只能通过enq方法修改tail，该方法主要是往队列后面添加等待节点

AQS队列节点Node类的数据结构：

• pre：指向队列的上一个节点
• waitStatus：节点的等待状态，初始化为0，表示正常同步等待
  • CANCELLED：1 节点因超时或者被中断而取消时设置为取消状态
  • SIGNAL：-1 指示当前节点被释放后，需要调用unpark通知后面节点，如果后面节点发生竞争导致获取锁失败，也会将当前节点设置为SIGNAL
  • CONDITION：-2 指示该线程正在进行条件等待，条件队列中会用到
  • PROPAGATE：-3 共享模式下释放节点时设置的状态，表示无限传播下去
• thread：当前节点操作的线程
• nextWaiter：该字段在Condition条件等待中会用到，指向条件队列的下一个节点。或者链接到SHARED常量，表示节点正在以共享模式等待
• next：指向队列的下一个节点

2.3.LockSupport.park(Object blocker)和LockSupport.unpark(Thread thread)

如果想要了解AQS的实现，您需要先知道以下这些内容，因为源码中会大量使用：

AQS中线程的阻塞和唤醒基本上都是使用这两个方法实现的，其底层都是依赖的Unsafe实现的

LockSupport是用来创建锁和其他同步类的基本线程阻塞的原语：

此类与每一个线程都关联一个许可（permit：0 表示无许可，1 表示有许可），如果有许可，将立即返回对park（）的调用，如果没有则阻塞当前调用线程，调用unpark（线程1）可使许可有效，此时被阻塞的线程得以执行，unpark可以先于park执行也没关系，此时unpark的入参线程调用park方法时，会直接执行

该类中常见的两个方法两个方法：

• park(Object blocker)：实现线程的阻塞。除非有许可，否则出于线程调度目的将阻塞线程；如果有许可，则将许可消耗，然后线程往下继续执行；
• unpark(Thread thread)：实现解除线程的阻塞。如果线程在park方法上被阻塞，则调用该方法将取消阻塞。否则，许可变为1，保证下一次调用park方法不会阻塞。

这两个方法底层是调用了Unsafe中的park和unpark的native方法。

2.3.AQS中的一般处理流程

为了弄清楚AQS中是如何进行队列同步的，我们先从一个简单的独占加锁方法说起

2.3.1.public final void acquire(int arg)

以独占模式获取锁，忽略中断。 通过至少调用一次tryAcquire ，成功返回。 否则线程会排队，可能会反复阻塞和解除阻塞，调用tryAcquire直到成功。 此方法可用于实现方法Lock.lock 。

我们先看一下这个方法的入口代码：

public final void acquire(int arg) {  if (!tryAcquire(arg) &&  // 尝试获取锁，这里是一个在AQS中未实现的方法，具体由子类实现      acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  // 获取不到锁，则 1.addWaiter添加到等待队列 2.acquireQueued不断循环等待重试    selfInterrupt();//如果没有获取到锁并且进入了等待队列，则end}

tryAcquire(arg)：

1. 线程1、线程2通过方法tryAcquire()尝试获取锁同时去获取锁
2. 获取成功的线程会返回true，一般都是通过CAS对state进行设置值尝试获取锁

不同的锁有不同的tryAcquire的实现，所以你可以看到ReentrantLock锁里面会有非公平锁和公平锁的实现方式

ReentrantLock公平锁的实现代码是在获取锁之前通过!hasQueuedPredecessors()，判断当前线程处于等待队列的节点前面没有别的节点了，此时才会去获取锁

addWaiter(Node.EXCLUSIVE)：

获取锁失败之后，则在等待队列之后追加一个节点，通过CAS进行追加，追加失败会循环重试，如果追加的时候发现head节点还不存在，可以先初始化一个head节点，然后追加上去

源码如下：

/** * 为当前线程和给定模式创建和排队节点 */private Node addWaiter(Node mode) {    //初始化一个新节点    Node node = new Node(Thread.currentThread(), mode);    // Try the fast path of enq; backup to full enq on failure    //拿到尾节点    Node pred = tail;    if (pred != null) {        //将新的节点指向尾节点        node.prev = pred;        // 尝试用新节点取代原来的尾节点        if (compareAndSetTail(pred, node)) {            pred.next = node;            return node;        }    }   // 如果当前尾指针为空，则调用enq方法去初始化tail及head    enq(node);    return node;}

acquireQueued(final Node node, int arg)：

1. 线程节点进入等待队列后，执行该方法，不断循环判断当前节点是否在head节点的后继节点，如果是则去尝试tryAcquire()获取锁，如果获取成功，则将当前节点作为head节点，并将next设置为null，head节点只是起到标识作用，每次处理的都是head的下一个节点
2. 如果当前节点（线程A）竞争锁失败或不是头结点的下一个节点，则会将前面的节点状态设置为SIGNAL（代表该节点执行完成后需要调用LockSupport的unpark（线程A）方法），如果前面的节点状态>0，表示这个节点被取消，移除队列，然后通过parkAndCheckInterrupt()调用LockSupport.park(this)挂起线程
3. 上述步骤1、2会for循环一直执行，类似于wait的范式，当线程从park处唤醒后，会再去执行上述步骤1、2

final boolean acquireQueued(final Node node, int arg) {  boolean failed = true;  try {    boolean interrupted = false;    for (;;) {      // 获取该节点的上一个节点，判断是否头节点，如果是则尝试获取锁      final Node p = node.predecessor();      if (p == head && tryAcquire(arg)) {        // 获取锁成功，把当前节点变为头节点        setHead(node);        p.next = null; // help GC        failed = false;        return interrupted;      }      // 判断是否需要阻塞线程，该方法中会把取消状态的节点移除掉，并且把当前节点的前一个节点设置为SIGNAL      if (shouldParkAfterFailedAcquire(p, node) &&          parkAndCheckInterrupt())        interrupted = true;    }  } finally {    if (failed)      cancelAcquire(node);  }}

大家看AQS的源码的时候，可以发现这里的线程阻塞与唤醒基本上是用一个循环+LockSupport.park+LockSupport.unpark实现的

2.3.2.public final boolean release(int arg)

源码如下：

public final boolean release(int arg) {  if (tryRelease(arg)) { // 尝试释放锁    Node h = head;    if (h != null && h.waitStatus != 0)  // 如果头节点waitStatus不为0，则唤醒后续线程节点继续处理      unparkSuccessor(h);    return true;  }  return false;}

tryRelease()具体实现由其子类实现，一般是让state值减一

1. 释放锁成功，并且头结点waitStatus != 0那么会调用unparkSuccessor()通知唤醒后续的线程节点进行处理

   注意：在遍历队列查找唤醒下一个节点的过程中，如果发现下一个节点状态是CANCELLED那么就会忽略这个节点，然后从队列尾部向前遍历，找到与头结点最近的没有被取消的节点进行唤醒操作

2. 线程A被唤醒之后，其又会从acquireQueued()方法被阻塞出继续执行，其流程和上述acquireQueued()方法一致

3.使用AQS实现的锁

例如ReentrantLock

• lock(): 调用该方法会使锁计数器加1，如果共享资源最初是空闲的，则将锁定并授予线程；
• unlock(): 调用该方法使锁计数器减1，当计数达到0的时候，将释放资源；
• tryLock(): 如果资源没有被任何其他线程占用，那么该方法返回true，并且锁计数器加1。如果资源不是空闲的，则该方法返回false。这个时候线程不会阻塞，而是直接退出返回结果；
• lockInterruptible(): 该方法使得资源空闲时允许该线程在获取资源时被其他线程中断。也就是说：如果当前线程正在等待锁，但其他线程请求该锁，则当前线程将被中断并立即返回，不会继续等待获取锁；
• getHoldCount(): 获取资源上持有的锁的计数器；
• isHeldByCurrentThread: 如果资源锁有当前线程持有，则此方法返回true。

参考链接：

https://www.itzhai.com/articles/aqs-and-lock-implementation-in-concurrent-packages.html#fn1

https://baijiahao.baidu.com/s?id=1666548481761194849&wfr=spider&for=pc

1.写入总体框架

转载链接:http://hbasefly.com/2018/03/27/timeseries-database-6/

数据写入的方式：

1. collector采集上传
2. opentsdb作为输入
3. http或udp协议批量写入数据

批量数据进入InfluxDB经过三个步骤处理，总体架构图如下：

1. 分组到Shard：批量数据首先会分组到不同的Shard（先是根据RP，再根据Shard Group再根据SeriesKey哈希到Sjard）
2. 倒排索引引擎构建倒排索引：InfluxDB中Shard由两个LSM引擎组成--倒排索引引擎和TSM引擎，时序数据会首先构建倒排索引
3. TSM引擎持久化数据：TMS处理数据流程基本和LSM一样，先将请求写入WAL日志文件，再写入Cache，一旦达到阈值就将Cache中的数据flush落盘形成TSM文件

2.批量时序数据Shard路由

批量数据写入InfluxDB之后做的第一件事情是分组**，将时序数据点按照所属shard划分为多组（称为Shard Map）**，每组时序数据点将会发送给对应的shard引擎并发处理

入库流程还是之前的shard策略（range+Hash），即按时间分片，比如7天一个分片的话，最近7天的数据会分到一个shard，一周前到两周前的数据会被分到上一个shard，以此类推；在时间分片的基础上还可以再执行Hash Sharding，按照SeriesKey执行Hash（保证同一个SeriesKey对应的所有数据都落到同一个shard），再将数据分散到指定的多个shard中。

当然，经过笔者深进一步了解，发现单机InfluxDB只有第一层sharding，即只有根据时间进行Range Sharding，并没有执行Hash Sharding。Hash Sharding只会在分布式InfluxDB中才会用到。

3.倒排索引引擎构建倒排索引

InfluxDB中倒排索引引擎使用LSM引擎构建，LSM引擎非常适合写多读少的场景，例如HBase、Kudu都是使用的LSM存储引擎，InfluxDB的戴欧索引引擎既然使用的是LSM，那么流程必然是：

1. 先写WAL以及Cache：数据写入WAL再写入Cache，就返回写入成功，WAL可以保证即使发生异常宕机也可以恢复Cache丢失的数据（MySQL也有类似的double writer机制）
2. Cache的flush：一旦满足特定条件系统会将Cache中的时序数据执行flush操作落盘形成文件，文件数量超过一定的阈值就合并成一个大文件

具体流程如下：

3.1.WAL追加写入

Inverted Index WAL的文件格式如下，由一个个LogEntry组成，用于记录数据的每一次的写入，如下图：

一个LogEntry由如下组成

• Flag：更新类型，写入或删除等
• Measurement：表示数据表
• Key/Value：表示写入的Tag Set和Checksum。Checksum用于根据WAL恢复数据时验证LogEntry的完整性

3.2.Cache的写入（ Inverted Index在内存中构建）

1. 拼接seriesKey：时序数据写入到系统之后先将measurement和所有的维度值拼成一个seriesKey
2. 确认seriesKey是否已经构建过索引：在文件中确认seriesKey是否存在，这就是Series Block中Bloom Filter的核心作用，首先使用Bloom Filter进行判断，如果不存在，肯定不存在。如果存在，不一定存在，需要进一步判断。再进一步使用B+树以及HashIndex进一步查找判断
3. 如果seriesKey在文件中不存在，则将其写入内存倒排索引。倒排索引内存结构主要包含两个Map：<measurement, List> 和 <tagKey, <tagValue, List>>。InfluxDB中SeriesKey就是一把钥匙，只有拿到这把钥匙才能找到这个SeriesKey对应的数据。而倒排索引就是根据一些线索去找这把钥匙

3.3.flush（Inverted Index Cache Flush流程）

触发时机：当Inverted Index WAL日志的大小超过阈值（默认5MB），就会执行flush操作将缓存中的两个Map写成文件

基本流程：

1. 缓存Map排序：<measurement, List>以及<tagKey, <tagValue, List>都需要经过排序处理，排序的意义在于有序数据可以结合Hash Index实现范围查询，另外Series Block中B+树的构建也需要SeriesKey排序。
2. 构建并持久化Series Block：在排序的基础上首先持久化<tagKey, tagValue, List>结构中所有的SeriesKey，也就是先构建Series Block。依次持久化SeriesKey到SeriesKeyChunk，当Chunk满了之后，根据Chunk中最小的SeriesKey构建B+树中的Index Entry节点。当然，Hash Index以及Bloom Filter是需要实时构建的。需要注意的是，Series Block在构建的同时需要记录下SeriesKey与该Key在文件中偏移量的对应关系，即<SeriesKey, SeriesKeyOffset>，这一点至关重要。
3. 内存中将SeriesKey映射为SeriesId：将<tagKey, <tagValue, List>结构中所有的SeriesKey由上一步中得到的<SeriesKey, SeriesKeyOffset >中的SeriesKeyOffset代替。形成新的结构：<tagKey, <tagValue, List>，即<tagKey, <tagValue, List>>，其中SeriesKeyId就是SeriesKeyOffset。
4. 构建并持久化Tag Block：在新结构<tagKey, <tagValue, List>>的基础上首先持久化tagValue，将同一个tagKey下的所有tagValue持久化在一起并生成对应Hash Index写入文件，接着持久化下一个tagKey的所有tagValue。所有tagValue都持久话完成之后再依次持久化所有的tagKey，形成Tag Block。
5. 构建并持久化Measurement Block：最后持久化measurement形成Measurement Block。

4.时序数据写入流程

数据写入引擎也是用的TSM类似于LSM的引擎，写入流程也大致如下：先写WAL、再写Cache、最后满足一定条件的阈值后，将Cache中的数据flush到文件

4.1.WAL追加写入

时间线数据数据会经过两重处理，首先格式化为WriteWALEntry对象，该对象字段元素如下图所示。然后经过snappy压缩后写入WAL并持久化到文件

4.2.写入Cache（时序数据写入内存结构）

1. 时序数据点格式化：将时序数据点point按照时间线性组织成一个Map，<SeriesKey+FieldKey, List>，即将相同的Key(SeriesKey+FieldKey)的时序数据集中放在一个List中并写入TSM File的block中

2. 时序数据点写入Cache：InfluxDB中Cache是一个crude hash ring（一致性hash），这个ring由256个partition组成，每个partition负责存储一部分时序数据key对应的值，就相当于数据写入Cache的时候又根据Key Hash了一次，根据Hash结果映射到不同的partition。

   这样做的原因：个人认为有点像Java中ConcurrentHashMap的思路，将一个大HashMap切分成多个小HashMap，每个HashMap内部在写的时候需要加锁。这样处理可以减小锁粒度，提高写性能。

4.3.Flush流程（Data Cache Flush流程）

触发时机:

1. Cache大小超过一定阈值，可以通过参数’cache-snapshot-memory-size’配置，默认是25M大小。
2. 超过一定时间没有数据写入WAL，默认时间间隔是10分钟，以通过参数’cache-snapshot-write-cold-duration’配置

基本流程：

1. 内存中构建Series Data Block：顺序遍历Map：<SeriesKey+FieldKey, List>中的时序数据，分别对时序数据的时间列和数值列进行相应的编码，按照Series Data Block的格式进行组织，当Block大小超过一定的阈值就构建成功，并记录这个Block

2. 将构建好的Series Data Block写入文件：使用输出流将内存中的数据输出到文件，并返回Block在文件中的偏移量offset以及总大小Siez

3. 构建文件级别B+树索引：在内存中为该Series Data Block构建一个索引节点Index Entry，使用数据Block在文件中的偏移量offset、总大小size以及MinTime，MaxTime构建一个Index Entry对象，写入到内存搞Series Index Block

   

这样每构建一个Series Data Block并写入文件后都会在内存中顺序构建（注意是顺序，代表这里的B+树是顺序写，这样的再平衡就会快很多，并且也可以利用到B+树查询的快速）一个Index Entry，写入内存Series Index Block对象，一旦一个Key对应的所有时序数据都持久化完成，一个Series Index Block就构建完成（因为一个Series Index Block只会存储一个SeriesKey的数据），构建完成之后填充Index Block Meta信息。接着新建一个新的Series Index Block开始构建下一个Key的对应的数据索引信息

5.InfluxDB数据删除（DropMeasurement，DropTagKey）

一般LSM存储引擎采取的删除操作通常都是Tag标记的方式，即删除操作和写入流程一致，只是数据上会多一个Tag标记 – deleted，表示该值已经被deleted。但是这种方案删除的代价是变低了，但是Tag方案在读取的时候需要对标记有deleted的数值进行特殊处理，这个代价还是很大的，但是InfluxDB采取的方案是通常不会删除一条记录，而是会删除某段时间或某个维度下的数据，甚至一张表

InfluxDB一共有两个LSM引擎，一个是倒排索引引擎（存储维度列到SeriesKey的映射关系，方便多维度查找），一个是TSM 引擎（用于存储时序数据），如果只删除一条记录，倒排索引引擎不需要操作，但是如果删除Measurement的话，两个引擎就都需要操作：

• TSM采取的是同步删除策略
• 倒排索引引擎采取标记删除策略

5.1.TSM 引擎的删除操作

同步删除策略流程如下：

1. TSM FIle Index相关处理：在内存中删除Index Entry，通常删除会带有时间筛选或key筛选，而且TSM File Index会在引擎启动之后加载到内存。因此删除操作会将满足条件的Index Entry从内存中删除

2. 生成tombstoner文件：tombstoner文件会记录当前TSM File中所有被删除的时序数据，时序数据用[key, min, max]三个字段表示，其中Key即SeriesKey+fileKey，［min, max］表示要删除的时间段

   

3. 删除Cache中满足条件的Series

4. 在WAL中生成一条删除series的记录并持久化到硬盘

5.2.倒排索引引擎的删除操作

标记Tag删除策略，标记Tag删除非常简单，和一次写入流程基本相同

1. 在WAL中生成一条flag为deleted的LogEntry并持久化到硬盘
2. 将要删除的维度信息写入Cache，需要标记deleted（设置type=deleted）
3. 当WAL大小超过阈值之后标记为deleted的维度信息会随Cache Flush到倒排索引文件
4. 和HBase一样，Inverted Index Engine中索引信息真正被删除发生在compact阶段