diff --git a/2023/AugESC/index.html b/2023/AugESC/index.html index 1ab7e71..04fd88f 100644 --- a/2023/AugESC/index.html +++ b/2023/AugESC/index.html @@ -154,18 +154,18 @@ diff --git a/2023/Control Globally, Understand Locally/index.html b/2023/Control Globally, Understand Locally/index.html index 984100a..2e5d08b 100644 --- a/2023/Control Globally, Understand Locally/index.html +++ b/2023/Control Globally, Understand Locally/index.html @@ -166,18 +166,18 @@ diff --git a/2023/DQ-HGAN/index.html b/2023/DQ-HGAN/index.html index 85b157a..606fcb3 100644 --- a/2023/DQ-HGAN/index.html +++ b/2023/DQ-HGAN/index.html @@ -160,18 +160,18 @@ diff --git a/2023/FADO/index.html b/2023/FADO/index.html index 46b9238..17c700f 100644 --- a/2023/FADO/index.html +++ b/2023/FADO/index.html @@ -155,18 +155,18 @@ diff --git a/2023/HEAL_ A Knowledge Graph for Distress Management Conversations/index.html b/2023/HEAL_ A Knowledge Graph for Distress Management Conversations/index.html index 7d1a7ba..b842aae 100644 --- a/2023/HEAL_ A Knowledge Graph for Distress Management Conversations/index.html +++ b/2023/HEAL_ A Knowledge Graph for Distress Management Conversations/index.html @@ -154,18 +154,18 @@ diff --git a/2023/Knowledge-enhanced Mixed-initiative Dialogue System for Emotional Support Conversations/index.html b/2023/Knowledge-enhanced Mixed-initiative Dialogue System for Emotional Support Conversations/index.html index 4a506e1..6191192 100644 --- a/2023/Knowledge-enhanced Mixed-initiative Dialogue System for Emotional Support Conversations/index.html +++ b/2023/Knowledge-enhanced Mixed-initiative Dialogue System for Emotional Support Conversations/index.html @@ -155,18 +155,18 @@ diff --git a/2023/MISC_ A MIxed Strategy-Aware Model Integrating COMET for Emotional Support Conversation/index.html b/2023/MISC_ A MIxed Strategy-Aware Model Integrating COMET for Emotional Support Conversation/index.html index f04b1eb..e7c3fed 100644 --- a/2023/MISC_ A MIxed Strategy-Aware Model Integrating COMET for Emotional Support Conversation/index.html +++ b/2023/MISC_ A MIxed Strategy-Aware Model Integrating COMET for Emotional Support Conversation/index.html @@ -155,18 +155,18 @@ diff --git a/2023/Recipes for building an open-domain chatbot/index.html b/2023/Recipes for building an open-domain chatbot/index.html index 463e239..b7e055d 100644 --- a/2023/Recipes for building an open-domain chatbot/index.html +++ b/2023/Recipes for building an open-domain chatbot/index.html @@ -153,18 +153,18 @@ diff --git a/2023/Towards Emotional Support Dialog Systems/index.html b/2023/Towards Emotional Support Dialog Systems/index.html index 8412096..b2bd2b3 100644 --- a/2023/Towards Emotional Support Dialog Systems/index.html +++ b/2023/Towards Emotional Support Dialog Systems/index.html @@ -153,18 +153,18 @@ diff --git a/Docker/576507-docker1.png b/2024/Docker/576507-docker1.png similarity index 100% rename from Docker/576507-docker1.png rename to 2024/Docker/576507-docker1.png diff --git a/Docker/index.html b/2024/Docker/index.html similarity index 94% rename from Docker/index.html rename to 2024/Docker/index.html index 8df627d..85242d4 100644 --- a/Docker/index.html +++ b/2024/Docker/index.html @@ -19,27 +19,27 @@ - + - + - + - + - + - + - + - + Docker | 闻 @@ -155,18 +155,18 @@ @@ -198,7 +198,7 @@
- +
+
LLM人工对齐算法
+ + -
-
-
- -
+ + + +

TODOLIST

+

RM + PPO

+

DPO

+

ReMax和GRPO

+

RLOO

-
- -
+
- -
-
+ + + - + + + + + - - - - - diff --git "a/tags/Java\346\225\260\346\215\256\347\273\223\346\236\204/index.html" b/LLM/index.html similarity index 70% rename from "tags/Java\346\225\260\346\215\256\347\273\223\346\236\204/index.html" rename to LLM/index.html index dc05ddd..bf1c411 100644 --- "a/tags/Java\346\225\260\346\215\256\347\273\223\346\236\204/index.html" +++ b/LLM/index.html @@ -19,25 +19,27 @@ - - - - + + + + - + + + - + - + -标签: Java数据结构 | 闻 +LLM | 闻 @@ -149,18 +151,18 @@ @@ -181,50 +183,97 @@ -
+
+ + +
-
-
-
-

Java数据结构 - 标签 + +
+ + + + + + + +
+

+ LLM

-

+
+
+ + + + + 发表于 -
- 2024 + + + + + +
+ +
+ + + + + +
+

大模型核心技术点在于训练资源、数据清洗和数据配比等，其难点或许不在于模型训练和模型结构搭建

+
+

前缀语言模型 Encoder-Decoder

+

ChatGLM

+

掩码语言模型 自编码模型 Encoder-Only

+

因果语言模型 自回归模型 Decoder-Only

+
- +
+ + + + -
-
- - -
diff --git a/JUC/index.html b/Linux-Tool/index.html similarity index 51% rename from JUC/index.html rename to Linux-Tool/index.html index 3566835..f61d1ae 100644 --- a/JUC/index.html +++ b/Linux-Tool/index.html @@ -19,32 +19,28 @@ - + - - + + - + - - - - - + + - + - - + - + -Java 并发基础 | 闻 +Linux-Tool | 闻 @@ -144,7 +140,7 @@
-
  1. 1. ThreadLocal
    1. 1.1. Q&A
  2. 2. JMM
    1. 2.1. 概念
    2. 2.2. happens-before 原则
    3. 2.3. 并发的三大特性
+
  1. 1. Vim
    1. 1.1. 基本模式切换
    2. 1.2. 光标移动
    3. 1.3. 编辑文本
    4. 1.4. 搜索和替换
    5. 1.5. 文件操作
  2. 2. Screen
    1. 2.1. 基本命令
    2. 2.2. 在 screen 会话中操作
    3. 2.3. 会话管理
@@ -157,18 +153,18 @@ @@ -200,7 +196,7 @@
- +

- Java 并发基础 + Linux-Tool

@@ -228,15 +224,9 @@

发表于 + - - - - - - - 更新于 - + @@ -244,99 +234,129 @@

分类于 - +

-
JMM、ThreadLocal
+
Linux高效工具的使用方法
-
-

ThreadLocal

-

每一个线程都有自己的专属本地变量，通过空间换时间的方式避免并发下线程安全问题

+

Vim

+

基本模式切换

    -
  • 完整的一次请求处理，于唯一一个线程中执行，可以通过 ThreadLocal -共享数据
    • -
  • ThreadLocal.set 方法是将值存储到 Thread 线程本身的 -ThreadLocalMap 里面
    • +
  • i：进入插入模式，从光标前插入文本。
    • +
  • a：进入插入模式，从光标后插入文本。
    • +
  • Esc：退出插入模式，回到正常模式。
    • +
  • v：进入可视模式，用于选择文本块。
    • +
  • V 或 +vv：进入可视行模式，选择整行文本。
    • +
  • Ctrl + v：进入可视块模式，选择矩形区域。
-

原理

-
public class ThreadLocal<T> {
    static class ThreadLocalMap {
        static class Entry extends WeakReference<ThreadLocal<?>> {
            Object value;
            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        // 存放数据
        private Entry[] table;
    }
}
-

整体结构图

- -img -

引用关系图

- -img -

Q&A

-

Entry的key为什么设计成弱引用？

-

ThreadLocal 变量生命周期结束后，ThreadLocal 对象就可以被回收；

-

ThreadLocal为什么会导致内存泄露，如何解决？

-

虽然 get、set 或 remove 方法会回收 key 为 null 的 value -值，但是如果没有调用这些方法，Entry 和ThreadLocalMap -将会长期存在下去，会导致内存泄露；

-

使用完 ThreadLocal 对象之后，调用 remove 方法；

-

ThreadLocal 是如何定位数据的？

-

int i = key.threadLocalHashCode & (len-1);

-

如果有冲突就通过线性探测再散列，直到找到空 bin；

-
-

其他Hash冲突解决方法：开放寻址法（再散列）、拉链法

-
-

ThreadLocal 是如何扩容的？

-

父子线程如何共享数据？

-

InheritableThreadLocal：初始化时会拷贝一份父线程中 ThreadLocal -值，到子线程 InheritableThreadLocal 中；

-

ThreadLocal 作为成员变量时，为什么定义成 static -更好？

-

将 ThreadLocal 定义为 static 可以确保所有线程都访问同一个 ThreadLocal -实例，但它们各自存储的数据是独立的；

-

确保它们的生命周期与线程的生命周期一致，而不是与类的实例的生命周期一致；

-

使用 InheritableThreadLocal -时，如果父线程中重新set值，在子线程中能够正确的获取修改后的新值吗？

-

不会影响到已经存在的子线程中 InheritableThreadLocal -的值，子线程将保持它在创建时从父线程中继承的原始值；

-

JMM

+

光标移动

    -

  • 抽象了 happens-before -原则来解决这个指令重排序问题，保证多线程环境下数据的一致性和可见性。

    • -

  • 抽象了线程和主内存之间的关系，提供一套内存模型以屏蔽系统差异

    • +
  • w：光标移动到下一个单词的开头。
    • +
  • b：光标移动到上一个单词的开头。
    • +
  • 0：移动到行首。
    • +
  • $：移动到行尾。
    • +
  • gg：移动到文件的第一行。
    • +
  • G：移动到文件的最后一行。
    • +
  • H：移动到屏幕的顶部。
    • +
  • M：移动到屏幕的中部。
    • +
  • L：移动到屏幕的底部。
-

概念

-

CPU 高速缓存：为解决 CPU 处理速度和内存不匹配的问题；

-

指令重排序【编译器优化重排 —> 指令并行重排 —> -内存系统重排】：指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致；

-
-

内存屏障可以禁止处理器指令发生重排序，从而保障指令执行的有序性。此外，还能保证指令执行的可见性。

-
-

happens-before 原则

-

前一个操作的结果对于后一个操作是可见的，无论这两个操作是否在同一个线程里

+

编辑文本

    -
  • 只要不改变程序的执行结果，编译器和处理器怎么进行重排序优化都行；
    • -
  • 会改变程序执行结果的重排序，JMM -要求编译器和处理器必须禁止这种重排序；
    • +
  • x：删除光标所在的字符。
    • +
  • dw：删除从光标到单词末尾的内容。
    • +
  • dd：删除当前行。
    • +
  • d$：删除从光标到行末的内容。
    • +
  • yy：复制当前行。
    • +
  • p：粘贴到光标之后。
    • +
  • u：撤销上一步操作。
    • +
  • Ctrl + r：重做撤销的操作。
    • +
  • r：替换光标下的字符。
    • +
  • ciw：删除光标所在的单词并进入插入模式。
    • +
  • c$：删除从光标到行尾的内容并进入插入模式。
-

并发的三大特性

-

原子性：一次操作或者多次操作，要么所有的操作全部都得到执行并且不会受到任何因素的干扰而中断，要么都不执行

+

搜索和替换

    -
  • synchronized、各种 Lock 以及各种原子类；
    • +
  • /pattern：向下搜索 +pattern。
    • +
  • ?pattern：向上搜索 +pattern。
    • +
  • n：跳到下一个搜索结果。
    • +
  • N：跳到上一个搜索结果。
    • +
  • :s/old/new/g：将当前行的所有 +old 替换为 new。
    • +
  • :%s/old/new/g：将整个文件中的所有 +old 替换为 new。
-

可见性：当一个线程对共享变量进行了修改，那么另外的线程都是立即可以看到修改后的最新值

+

文件操作

    -
  • synchronized、Volatile 以及各种 Lock 实现可见性；
    • +
  • :w：保存文件。
    • +
  • :q：退出 Vim。
    • +
  • :wq：保存并退出。
    • +
  • :q!：不保存强制退出。
    • +
  • :e filename：打开文件 +filename。
    • +
  • :r filename：在当前文件中插入 +filename 的内容。
-

有序性：代码的执行顺序未必就是编写代码时候的顺序

+

Screen

+

基本命令

    -

  • Volatile -关键字：保证变量的可见性和代码执行的有序性，但无法在多线程读写变量时保证操作原子性；

    • -

  • 内存屏障：Unsafe 类的 fullFence() -可以避免代码重排序；

    • +
  • screen：启动一个新的 +screen 会话。
    • +
  • screen -S session_name：启动一个命名为 +session_name 的 screen 会话。
    • +
  • screen -ls：列出当前所有的 +screen 会话。
    • +
  • screen -r：重新连接到一个 +screen 会话（如果只有一个会话）。
    • +
  • screen -r session_name：重新连接到一个名为 +session_name 的 screen 会话。
    • +
  • screen -d session_name：在其他地方的终端断开某个会话的连接。
    • +
  • screen -d -r session_name：强制从其他地方的终端断开并重新连接到 +session_name 会话。
    • +
  • screen -X quit：关闭所有 +screen 会话
    • +
+

在 screen 会话中操作

+

在 screen 会话中，所有命令都以 Ctrl + a +开头（表示“前缀键”），然后跟随其他按键来执行操作。

+
    +
  • Ctrl + a, X：关闭当前的分割窗口。
    • +
  • Ctrl + a, c：创建一个新的窗口。
    • +
  • Ctrl + a, n：切换到下一个窗口。
    • +
  • Ctrl + a, p：切换到上一个窗口。
    • +
  • Ctrl + a, "：列出当前所有窗口，允许选择切换。
    • +
  • Ctrl + a, 0-9：切换到指定编号的窗口（例如 +Ctrl + a, 1 切换到窗口 1）。
    • +
  • Ctrl + a, d：将当前 +screen 会话断开（detach），会话继续在后台运行。
    • +
  • Ctrl + a, A：重命名当前窗口。
    • +
  • Ctrl + a, K：关闭当前窗口。
    • +
  • Ctrl + a, S：水平分割当前窗口。
    • +
  • Ctrl + a, |：垂直分割当前窗口。
    • +
  • Ctrl + a, tab：在分割的窗口间切换焦点。
    • +
  • Ctrl + a, Q：关闭除了当前窗口外的所有分割窗口。
    • +
  • Ctrl + a, X：关闭当前的分割窗口。
    • +
+

会话管理

+
    +
  • Ctrl + a, :quit 或 +Ctrl + a, d：结束当前 screen +会话。
    • +
  • Ctrl + a, :kill：强制关闭当前窗口。
    • +
  • exit：退出当前 screen +会话。
@@ -347,21 +367,18 @@

并发的三大特性

diff --git a/Machine-Learning/index.html b/Machine-Learning/index.html index d1223b2..8396c7a 100644 --- a/Machine-Learning/index.html +++ b/Machine-Learning/index.html @@ -35,7 +35,7 @@ - + @@ -148,7 +148,7 @@
-
  1. 1. 偏差方差
    1. 1.1. 泛化误差
    2. 1.2. 方差
    3. 1.3. 偏差
    4. 1.4. 噪声
    5. 1.5. 偏差-方差窘境
  2. 2. 模型训练
    1. 2.1. 优化器
  3. 3. 训练方法
    1. 3.1. 监督学习
    2. 3.2. 无监督学习
    3. 3.3. 半监督学习
    4. 3.4. 强化学习
      1. 3.4.1. RLHF
  4. 4. Torch
+
  1. 1. 偏差方差
    1. 1.1. 泛化误差
    2. 1.2. 方差
    3. 1.3. 偏差
    4. 1.4. 噪声
    5. 1.5. 偏差-方差窘境
  2. 2. 模型训练
    1. 2.1. 优化器
  3. 3. 训练方法
    1. 3.1. 监督学习
    2. 3.2. 无监督学习
    3. 3.3. 半监督学习
    4. 3.4. 强化学习
      1. 3.4.1. RLHF
  4. 4. 损失函数
  5. 5. Torch
@@ -161,18 +161,18 @@ @@ -240,7 +240,7 @@

更新于 - + @@ -332,21 +332,25 @@

RLHF

OpenAI 提出的生成领域（Decoder_only）的新训练范式

Policy Gradient

- -image-20240716101748533 + +image-20240716101748533

RM+PPO

步骤一、预训练语言模型

- -image-20240715191912939 + +image-20240715191912939

步骤二、训练奖励模型 RM

- -image-20240715191936226 + +image-20240715191936226

步骤三、用强化学习 PPO 微调

- -image-20240715192056550 + +image-20240715192056550

DPO

KTO

ORPO

+

损失函数

+

MSELoss 回归任务

+

CrossEntropyLoss 单标签分类

+

BCEWithLogitsLoss 多标签分类

Torch

torch.nn.Parameter()将一个不可训练的 tensor 转换成可以训练的类型 parameter，并将这个 parameter 绑定到这个 module @@ -364,7 +368,7 @@

Torch

-
diff --git a/MySQL/243b1466779a9e107ae3ef0155604a17-17146246150216.webp b/MySQL/243b1466779a9e107ae3ef0155604a17-17146246150216.webp deleted file mode 100644 index c4329db..0000000 Binary files a/MySQL/243b1466779a9e107ae3ef0155604a17-17146246150216.webp and /dev/null differ diff --git a/MySQL/COMPACT.drawio.png b/MySQL/COMPACT.drawio.png deleted file mode 100644 index 4dba165..0000000 Binary files a/MySQL/COMPACT.drawio.png and /dev/null differ diff --git a/MySQL/binlogcache.drawio.png b/MySQL/binlogcache.drawio.png deleted file mode 100644 index 213ab1a..0000000 Binary files a/MySQL/binlogcache.drawio.png and /dev/null differ diff --git a/MySQL/bufferpoll_page.png b/MySQL/bufferpoll_page.png deleted file mode 100644 index 8e5153e..0000000 Binary files a/MySQL/bufferpoll_page.png and /dev/null differ diff --git a/MySQL/checkpoint.png b/MySQL/checkpoint.png deleted file mode 100644 index 5641339..0000000 Binary files a/MySQL/checkpoint.png and /dev/null differ diff --git a/MySQL/freelist.drawio.png b/MySQL/freelist.drawio.png deleted file mode 100644 index f89dbdd..0000000 Binary files a/MySQL/freelist.drawio.png and /dev/null differ diff --git a/MySQL/index.html b/MySQL/index.html deleted file mode 100644 index ae95600..0000000 --- a/MySQL/index.html +++ /dev/null @@ -1,1091 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MySQL | 闻 - - - - - - - - - - - - - -
- -
-
-
-
-
- - - -
-
- -
- - - -

闻

- - -

Yesterday is history, tomorrow is a mystery but today is a gift.

-
- -
-
- -
-
-
- - - - - - - -
-
- - - -
- -
- - - -
-
-
- -
-
- -
-
- -
- - - - - -
- -
- - - - - -
- - - -
- - - - - - - -
-

- MySQL -

- -
-
- - - - - 发表于 - - - - - - - - 更新于 - - - - - - - 分类于 - - - - - - -
- -
MySQL 基础，包括索引、事务、锁、日志、BufferPool等
-
-
- - - - -

基础

-

SQL 查询语句执行过程

-
    -
  • 连接器：客户端与 Server 层建立连接，管理连接、校验用户身份；
    • -
  • 查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行（MySQL -8.0 已删除该模块）
    • -
  • 解析 SQL：通过解析器对 SQL -查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；
    • -
  • 执行 SQL： -
      -
    • 预处理阶段：检查表或字段是否存在；将 select * 中的 * -符号扩展为表上的所有列；
      • -
    • 优化阶段：基于查询成本的考虑， -选择查询成本最小的执行计划；查询优化器；
      • -
    • 执行阶段：根据执行计划执行 SQL -查询语句，从存储引擎读取记录，返回给客户端；
      • -
    • -
-

MySQL 数据文件

-
    -
  • db.opt，用来存储当前数据库的默认字符集和字符校验规则。
    • -
  • table.frm ，存放表结构，在 MySQL -中建立一张表都会生成一个.frm -文件，该文件是用来保存每个表的元数据信息的，主要包含表结构定义。
    • -
  • table.ibd，存放表数据，表数据既可以存在共享表空间文件（文件名：ibdata1）里，也可以存放在独占表空间文件（文件名：表名字.ibd）。这个行为是由参数 -innodb_file_per_table 控制的，若设置了参数 innodb_file_per_table 为 -1，则会将存储的数据、索引等信息单独存储在一个独占表空间，从 -MySQL 5.6.6 版本开始，它的默认值就是 1 了，因此从这个版本之后， MySQL -中每一张表的数据都存放在一个独立的 .ibd 文件。
    • -
-

表空间文件的结构

- -img -

InnoDB 行格式

-

共有 Redundant、Compact、Dynamic、Compressed 四种，下图时 Compact -行格式的结构

- -

InnoDB 页格式

-

InnoDB 的数据是按「数据页」为单位来读写的，数据页的默认大小是 -16KB

- -243b1466779a9e107ae3ef0155604a17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
名称说明
文件头页的信息；两个指针指向上一个/下一个数据页
页头页的状态信息
最小和最大记录两个虚拟伪记录，分别表示页中的最小记录和最大记录
用户记录储存所有的行记录
空闲空间还没被用到的空间
页目录用户记录相对位置，页中所有记录的索引
文件尾校验页是否完整
-

数据页中的 -页目录存储各个槽，用户记录按照「主键」顺序组成单向链表，可以通过二分查找法的方式进行检索。

-

索引

-

索引字段特性分类

-
    -
  • 主键索引
    • -
  • 唯一索引
    • -
  • 前缀索引
    • -
  • 普通索引
    • -
-

索引个数分类

-
    -
  • 单例索引
    • -
  • 联合索引：最左匹配原则（MySQL 有查询优化器，所以字段在 where -子句的顺序并不重要）
    • -
-
-

最左匹配原则：按照最左优先的方式进行索引的匹配，范围查询的字段可以用到联合索引，在遇到范围查询（如 ->、<）的时候，就会停止匹配，也就是范围查询的字段可以用到联合索引，但是在范围查询字段的后面的字段无法用到联合索引。注意，对于 ->=、<=、BETWEEN、like 前缀匹配的范围查询，并不会停止匹配。

-
-

Innodb 采用 B+Tree -作为索引的优势

-
-

MySQL 底层实现的 B+ 树在原有的 B+ 树的基础上做了改动

-
    -
  • 叶子节点采用双向链表连接
    • -
  • 所有节点都是 16KB 数据页
    • -
  • 非叶子节点中有多少个子节点，就有多少个索引
    • -
-

nosql 的 MongoDB 采用 B -树实现，适用于大量的单个索引（而不是范围查询）查询的场景；

-
-
    -
  • 查询底层节点的磁盘 -I/O次数少。非叶子节点只存放索引，相比 B -树，每个非叶子节点能存储更多的索引，树形结构更加矮胖；
    • -
  • 插入和删除效率高。非叶子节点中的都是冗余索引，所有索引都在叶子节点中又存储了一次；
    • -
  • 树层低，磁盘 I/O 次数少。若每行数据 -1KB，三层最多可存放千万级数据量；
    • -
  • 范围查询，磁盘 I/O -次数少。叶子节点采用双向有序链表连接；其他树结构需要中序遍历，磁盘 -I/O 次数多；
    • -
-

B+Tree 索引结构

-
    -
  • 主键索引/聚簇索引：叶子节点存放实际数据、事务 id、用于事务和 MVCC -的回滚指针；
    • -
  • 二级索引：叶子节点存放主键值；
    • -
-

Explain 执行计划

-

数据扫描类型 type

-
    -
  • All：全表扫描；
    • -
  • index：全索引扫描；
    • -
  • index merge：索引合并。先将使用到的索引先进行求 -交集、并集之后在进行回表；
    • -
  • range：索引范围扫描。使用 < 、>、in、between -等关键词，只检索给定范围的行；
    • -
  • ref：非唯一索引等值匹配；
    • -
  • eq_ref：唯一索引 多表联查 等值匹配；
    • -
  • const：主键或唯一索引 常量 等值匹配；
    • -
-

额外信息 extra

-
    -
  • Using filesort ：当查询语句中包含 group by -操作，而且无法利用索引完成排序操作的时候， -这时不得不选择相应的排序算法进行；
    • -
  • Using temporary：使了用临时表保存中间结果，如排序 order by -和分组查询 group by；
    • -
  • Using where：存储引擎层返回行以后在 MySQL 服务层应用 where -过滤条件；
    • -
  • Using -index：所需数据可以直接在二级索引值和主键值中得到，采用覆盖索引，不回表；
    • -
  • Using index condition 索引下推 -：可以在联合索引遍历过程中，对联合索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数；
    • -
-

是否需要索引

-

需要索引的情况

-
    -
  • 唯一性字段
    • -
  • 范围查询 WHERE
    • -
  • 排序查询 GROUP BY 、 ORDER BY
    • -
  • 覆盖索引，全索引扫描优于全表扫描
    • -
-

不需要索引的情况

-
    -
  • 不需要范围查询、排序查询
    • -
  • 大量重复数据
    • -
  • 频繁修改
    • -
  • 数据量少
    • -
-

索引优化

-

前缀索引：减小索引字段大小，可以增加一个索引页中存储的索引值，有效提高索引的查询速度。

-

覆盖索引：联合索引和主键值中包括了查询数据，避免回表

-

主键索引自增：追加记录时不需要移动数据；避免页分裂造成内存碎片；

-

主键字段长度尽可能短：聚簇索引非叶子节点可以装下更多的索引；二级索引叶子节点可以装下更多的主键值，占用空间更小

-

索引 NOT NULL：简化索引统计、值比较过程；减少 1 -字节的行格式长度；

-

联合索引 -区分度大的在前：建立联合索引时，要把区分度大的字段排在前面，这样区分度大的字段越有可能被更多的 -SQL 使用到。

-
-

如果索引的区分度很小，假设字段的值分布均匀，那么无论搜索哪个值都可能得到一半的数据（惯用的百分比界线是"30%"）MySQL -查询优化器，会忽略索引，进行全表扫描

-
-

索引失效

-
    -
  • 左或者左右模糊匹配
    • -
  • 查询条件中对索引列做了 -
      -
    • 计算
      • -
    • 函数
      • -
    • 类型转换操作
      • -
    • -
  • 联合索引未遵循最左匹配原则
    • -
  • 条件语句中 OR 前后子句一个有索引一个没索引
    • -
-

Count 计算

-

遍历索引，优先遍历 key_len -最小的二级索引，只有当没有二级索引的时候，才会采用主键索引来进行统计。

-

事务

-

事务是由存储引擎实现的，InnoDB 支持事务

-

特性

-
    -
  • 持久性是通过 redo log （重做日志）保证的；
    • -
  • 原子性是通过 undo log（回滚日志） 保证的；
    • -
  • 隔离性是通过 MVCC（多版本并发控制） 或锁机制保证的；
    • -
  • 一致性则是通过持久性+原子性+隔离性保证的；
    • -
-

并行事务会引发的问题

-
    -
  • 脏读：一个事务读到了另一个未提交事务修改过的数据
    • -
  • 不可重复读：一个事务内多次读取同一个数据，如果出现前后两次读到的数据不一样
    • -
  • 幻读：一个事务内多次查询某个查询条件的记录数量不同
    • -
-

隔离级别

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
隔离级别（是否会出现xx问题）脏读不可重复读幻读
READ-UNCOMMITTED 读未提交√√√
READ-COMMITTED 读已提交×√√
REPEATABLE-READ 可重复读××√
SERIALIZABLE 可串行化×××
-
    -
  • 读未提交：允许读取尚未提交的数据变更。直接读取最新的数据
    • -
  • 读已提交：允许读取并发事务已经提交的数据。「每个 SQL -语句执行前」都会重新生成一个 Read View
    • -
  • 可重复读：对同一字段的多次读取结果都是一致的。「启动事务时」生成一个 -Read View，然后整个事务期间都在用这个 Read View
    • -
  • 可串行化：所有的事务依次逐个执行，完全服从 ACID -的隔离级别。采用加读写锁的方式来避免并行访问
    • -
-

虽然 InnoDB 默认采用可重复读隔离级别，但基本不会出现幻读，因为其采用 -next-key lock（记录锁+间隙锁）和 MVCC 来避免幻读的发生

-
    -
  • 快照读（select）：采用 MVCC -方式解决了幻读。事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，保证事务隔离性； -
      -
    • 在执行第一个查询语句后，会创建一个 Read View，后续的查询语句利用这个 -Read View，通过这个 Read View 就可以在 undo log -版本链找到事务开始时的数据，所以事务过程中每次查询的数据都是一样的
      • -
    • -
  • 当前读/共享锁（select for update）：通过 next-key -lock（记录锁+间隙锁）方式解决了幻读，读到的记录是最新的。如果有其他事务在 -Next-Key Lock -范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入； -
      -
    • update、insert、delete -都是当前读，这些语句执行前都会查询最新版本的数据，然后再做进一步的操作；
      • -
    • 如果 update -是已经被锁住的记录，就生成插入意向锁并进入阻塞状态；
      • -
    • 当前读给某记录加锁了，那么对该记录已修改但未提交的事物就无法提交这个修改了，直到锁被释放；
      • -
    • Next-Key Lock 对索引记录加上行锁（Record -Lock），对索引记录两边的间隙加上间隙锁（Gap -Lock），是针对事务隔离级别为可重复读或以上级别而设计的；
      • -
    • -
-

MVCC 多版本并发控制

-

InnoDB 事务是通过 Read View 和 -聚簇索引中的两个隐藏列 实现 MVCC 的

-

Read View 字段

- -

聚簇索引中的两个隐藏列

-
    -
  • trx_id，当一个事务对某条聚簇索引记录进行改动时，就会把该事务的事务 -id 记录在 trx_id 隐藏列里；
    • -
  • roll_pointer，每次对某条聚簇索引记录进行改动时，都会把旧版本的记录写入到 -undo -日志中，然后这个隐藏列是个指针，指向每一个旧版本记录，于是就可以通过它找到修改前的记录。
    • -
-

MVCC 如何实现可重复读？

-

事务 A 读某字段时，会先读取该字段的 trx_id，如果 Read View 中记录的该 -trx_id 是活跃事务，则沿着 roll_pointer（即 undo -log 版本链）寻找旧版本字段；如果 Read View 中记录的该 trx_id -是当前事务 或 -已提交事务，则返回该记录。【注意，Read View -字段不随活跃事务的提交而改变，它是该事务开启时的数据库事务状态快照】

-

可重复读下发生幻读

-
    -
  1. 事务 A 先对某块记录执行快照读
    2. -
  2. 事务 B 插入数据到该块记录中，并提交事务 B
    3. -
  3. 事务 A 再对该块记录执行当前读或更新记录
    4. -
  4. 会读取到事务 B 插入的数据，因为当前读会读取最新的记录
    5. -
-

如何避免？

-

若事务中会对数据采取 当前读，则在事务刚开始时就执行，通过 next-key -lock 避免其他事物再插入数据。

-

锁

-
-

MySQL 加锁时，先 生成锁结构，然后 -设置锁的状态，即初始化锁再竞争锁；如果锁状态是等待状态，并不是意味着事务成功获取到了锁，只有当锁状态为正常状态时，才代表事务成功获取到了锁；

-
-

锁的种类

-
    -
  • 全局锁
    • -
  • 表级锁 -
      -
    • 表锁
      • -
    • 意向表：用于快速判断表里是否有记录被加锁。意向共享锁和意向独占锁是表级锁，不会和行级的共享锁和独占锁发生冲突，而且意向锁之间也不会发生冲突，只会和共享表锁（lock -tables ... read）和独占表锁（lock tables ... write）发生冲突
      • -
    • 元数据表 MDL 锁：更表结构时需要申请 MDL 写锁
      • -
    • AUTO-INC 锁：配置文件 -innodb_autoinc_lock_mode = 2, binlog_format = row，既能提升并发性，又不会出现数据一致性问题
      • -
    • -
  • 行级锁 -
      -
    • Record Lock 记录锁，区分读锁和写锁，锁定存在的记录；
      • -
    • Gap Lock -间隙锁，不区分读锁和写锁；间隙锁用来锁一个范围，间隙锁之间是兼容的；
      • -
    • Next-Key Lock 临键锁，区分读锁和写锁；
      • -
    • 插入意向锁，特殊的间隙锁，用于不同事务的并发控制和冲突检测；插入意向锁和不同事物的间隙锁之间是冲突的，当某个事务的插入语句遇到间隙锁时，会产生插入意向锁；
      • -
    • -
  • 隐式锁 -
      -
    • 延迟加锁机制，特点是只有在可能发生冲突时才加锁
      • -
    • 使用场景：事务 B 插入记录的索引 == 事务 A 已插入且未提交的索引，事务 -A 插入的记录上的「隐式锁」会变「显示锁」且锁类型为 X -型的记录锁，所以事务 B 想获取 S 型next-key -锁时会遇到锁冲突，事务 B 进入阻塞状态。
      • -
    • -
-

行级锁实现

-
-

行级锁时 Innodb 实现高效事务的关键

-
-

加锁是加在索引上的【加行级锁时还要加表锁：X 类型的意向锁】

-
    -
  • 全表当前读，遍历聚簇索引加临键锁（update -未走索引的情况）
    • -
  • 全索引当前读，遍历当前索引加临键锁
    • -
-

二级索引加锁后，还要在查询到的记录的主键索引项加记录锁

-

Insert 语句，加行级锁

-
    -
  • 记录被间隙锁，阻塞 -
      -
    • 插入意向锁
      • -
    • -
  • 唯一键冲突，执行失败 -
      -
    • 如果主键索引重复，插入新记录的事务会给已存在的主键值重复的聚簇索引记录添加 -S 型记录锁。
      • -
    • 如果唯一二级索引重复，插入新记录的事务都会给已存在的二级索引列值重复的二级索引记录添加 -S 型 next-key 锁。
      • -
    • -
-

临键锁退化成记录锁或间隙锁的情况

-

唯一索引查询

-
    -
  • 等值查询 -
      -
    • （条件值）存在，该索引加记录锁
      • -
    • （条件值）不存在，后一索引加间隙锁
      • -
    • -
  • 范围查询 -
      -
    • 条件值在表中，非等值查询 -
        -
      • 小于，该索引加间隙锁
        • -
      • 大于，后一索引加临键锁
        • -
      • -
    • 条件值在表中且条件是等值查询 -
        -
      • 小于等于，该索引加临键锁
        • -
      • 大于等于，该索引加记录锁
        • -
      • -
    • -
-

非唯一索引查询

-
    -
  • 等值查询 -
      -
    • 存在，扫描到的索引记录加的是 next-key -锁，而对于第一个不符合条件的索引记录，该索引的 next-key -锁会退化成间隙锁；
      • -
    • 不存在，扫描到第一条不符合条件的索引记录，该索引的 next-key -锁会退化成间隙锁；
      • -
    • -
  • 范围查询 -
      -
    • 为确保条件值前后都锁住，加锁时不存在临建锁退化为间隙锁和记录锁的情况
      • -
    • -
-

死锁

-
    -
  • 两个事务分别加了间隙锁（前提）
    • -
  • 两个事务分别向对方的间隙锁插入数据，于是都产生插入意向锁
    • -
  • 由于插入意向锁和间隙锁冲突，双方都为了获取插入意向锁，会等待对方事务的间隙锁释放，陷入循环等待，造成死锁
    • -
-

插入意向锁是对不同事务才产生作用的，对于本身事务的间隙锁是兼容的。

-

解决方法

-
    -
  • 设置事务等待锁的超时时间 innodb_lock_wait_timeout
    • -
  • 开启主动死锁检测 innodb_deadlock_detect
    • -
-

日志

-
-

目前，很多数据库采用的是 steal（没提交的事务写的脏页也可以马上落盘）+ -no force（已提交的事务可以不马上落盘）模式。MySQL 也参考了这个模式，undo -log 变更持久性和数据一样，由 redo log 保证，对 undo log -还没落盘的修改也会写入 redo log。这样不管怎么样基于 undo log -做事务回滚或者做 MVCC都可以保证原子和一致性。

-
-
    -
  • undo log（回滚日志）：是 Innodb -存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 -MVCC；
    • -
  • redo log（重做日志）：是 Innodb -存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复；
    • -
  • bin log （归档日志）：是 Server -层生成的日志，主要用于数据备份和主从复制；
    • -
-

回滚日志与重做日志的区别

-
    -
  • redo log -记录了此次事务「完成后」的数据状态，记录的是更新之后的值；防止已提交事务的修改丢失；
    • -
  • undo log -记录了此次事务「开始前」的数据状态，记录的是更新之前的值；防止未提交事务的修改无法回滚；
    • -
-

重做日志和归档日志的区别

-
    -
  • bin log -是追加写，写满一个文件，就创建一个新的文件继续写，不会覆盖以前的日志，保存的是全量的日志。
    • -
  • redo log -是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷入磁盘的脏页日志。
    • -
-

回滚日志 Undo log

-
    -
  • 实现事务回滚，保障事务的原子性。事务处理过程中，如果出现了错误 -或者 用户执行了 ROLLBACK 语句，MySQL 可以利用 undo log -中的历史数据将数据恢复到事务开始之前的状态。
    • -
  • 实现 MVCC（多版本并发控制）关键因素之一。MVCC 是通过 Read View + -undo log 实现的。undo log -为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select -语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log -的版本链找到满足其可见性的记录。
    • -
-

持久化方法：开启事务后，InnoDB 层更新记录前，首先要记录相应的 undo -log，如果是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo -log，undo log 会写入 Buffer Pool 中的 Undo 页面，对 undo -页的修改也都会记录到 redo log。redo log -会每秒刷盘，提交事务时也会刷盘，数据页和 undo -页都是靠这个机制保证持久化的。

-

重做日志 Redo log

-
-

防止 Buffer Pool 中的脏页丢失

-
-
    -
  • 实现事务的持久性，让 MySQL 有 -crash-safe 的能力，能够保证 MySQL -在任何时间段突然崩溃，重启后之前已提交的记录都不会丢失；
    • -
  • 将脏页的写操作从「随机写」变成了「顺序写」，提升 -MySQL 写入磁盘的性能；
    • -
-

WAL（Write-Ahead Logging）：MySQL -的写操作并不是立刻写到磁盘上，而是先写 redo log -日志，然后在合适的时间再将脏页写到磁盘上。

-

redo log -是物理日志，记录了某个数据页做了什么修改，即所有未还没持久化的脏页修改。在事务提交时，只要先将 -redo log 持久化到磁盘即可，可以不需要等到将缓存在 Buffer Pool -里的脏页数据持久化到磁盘。当系统崩溃时，虽然脏页数据没有持久化，但是 -redo log 已经持久化，接着 MySQL 重启后，可以根据 redo log -的内容，将所有数据恢复到最新的状态。

-

redo log 持久化操作：每当产生一条 redo log -时，会先写入到 redo log buffer，为了在 MySQL -处理大事务时尽可能少写入磁盘，进而提升写 IO 性能。redo log -buffer 写入磁盘的时机：

-
    -
  • MySQL 正常关闭时；
    • -
  • 当 redo log buffer 中记录的写入量大于 redo log buffer -内存空间的一半时；
    • -
  • InnoDB 的后台线程每隔 1 秒，将 redo log buffer -持久化到磁盘。
    • -
  • 每次事务提交时都将缓存在 redo log buffer 里的 redo -log 直接持久化到磁盘； -
      -
    • 参数为 0 时，事务提交不会主动触发写入磁盘的操作；MySQL -进程崩溃会导致上一秒钟所有事务数据的丢失；
      • -
    • 参数为 1 时，每次事务提交都将缓存在 redo log buffer 里的 redo log -直接持久化到磁盘；
      • -
    • 参数为 2 时，每次事务提交都只是缓存在 redo log buffer 里的 redo log -写到 redo log 文件（写入到 redo log -文件并不意味着写入到了磁盘，而是存在操作系统里的文件系统中的 Page -Cache）；操作系统崩溃或者系统断电会导致上一秒钟所有事务数据的丢失；
      • -
    • -
-

重做日志文件组

-

redo log 是为了防止 Buffer Pool -中的脏页丢失而设计的，只记录未被刷入磁盘的数据的物理日志。随着系统运行，Buffer -Pool 的脏页刷新到了磁盘中，redo log -对应的记录也就没用了，这时候我们需要擦除这些旧记录，以腾出空间记录新的更新操作。重做日志文件组由有 -2 个 redo log -文件组成，以循环写的方式工作，从头开始写，写到末尾就又回到开头，相当于一个环形。

- -img -
    -
  • write pos ～ checkpoint -之间的部分（图中红色部分）：记录新的更新操作；
    • -
  • check point ～ write pos -之间的部分（图中蓝色部分）：待落盘的脏数据页记录；
    • -
-

将 Buffer Pool 中的脏页刷新到磁盘中，然后标记 redo log -哪些记录可以被擦除，接着对旧的 redo log -记录进行擦除，等擦除完旧记录腾出了空间，checkpoint -就会往后移动（图中顺时针）。一次 checkpoint -的过程就是脏页刷新到磁盘中变成干净页，然后标记 redo log -哪些记录可以被覆盖的过程。

-

归档日志 Bin log

-

记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。MySQL -在完成数据库表结构变更或表数据修改（增删改）时，Server -层会生成一条 -binlog，等之后事务提交的时候，会将该事物执行过程中产生的所有 binlog -统一写入 binlog 文件。

-
    -
  • binlog 日志只能用于数据备份和主从复制，没有 crash-safe 的能力；
    • -
  • binlog -是全量日志，保存了所有数据变更的情况，可以恢复整个数据库所有数据；
    • -
-

主从复制

- -MySQL 主从复制过程 -
    -
  • 写入 Binlog：数据修改 -> 主库写 binlog 日志 -> commit 事务 --> 持久化本地数据 -> 提交事务成功；
    • -
  • 同步 Binlog：从库会创建一个专门的 I/O 线程，连接主库的 log dump -线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log -的中继日志里，再返回给主库“复制成功”的响应。
    • -
  • 回放 Binlog：读 relay log 中继日志，回放 -binlog，并更新从库中的数据。
    • -
-

主从复制模型

-
    -
  • 同步复制：MySQL -主库提交事务的线程要等待所有从库的复制成功响应，才返回客户端结果；
    • -
  • 异步复制（默认模型）：MySQL 主库提交事务的线程并不会等待 binlog -同步到各从库，就返回客户端结果；
    • -
  • 半同步复制：只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端；
    • -
-

binlog 刷盘

- -binlog cach -
    -
  • 图中的 write，把日志写入到 binlog 文件（文件系统的 page -cache 里），但是并没有把数据持久化到磁盘；
    • -
  • 图中的 fsync，把数据持久化到磁盘的操作，这里就会涉及磁盘 -I/O，所以频繁的 fsync 会导致磁盘的 I/O 升高；
    • -
-

MySQL 提供一个 sync_binlog 参数来控制数据库的 binlog -刷到磁盘上的频率：

-
    -
  • sync_binlog = 0 的时候，表示每次提交事务都只 write，不 -fsync，后续交由操作系统决定何时将数据持久化到磁盘；
    • -
  • sync_binlog = 1 的时候，表示每次提交事务都会 write，然后马上执行 -fsync；
    • -
  • sync_binlog =N(N>1) 的时候，表示每次提交事务都 write，但累积 N -个事务后才 fsync。
    • -
-

两阶段提交

-

binlog 主从复制和 redo log -崩溃恢复需要保持一致，不然会出现主从数据不一致、备份数据与真实数据不一致等问题。MySQL -采用两阶段提交来避免两份日志之间的逻辑不一致，两阶段提交是一种分布式事务一致性协议。

-

两阶段提交：把单个事务的提交拆分成了 2 -个阶段，分别是准备阶段和提交阶段（不是 commit -语句），每个阶段都由协调者和参与者共同完成。

-

内部 XA 事务

- -两阶段提交 -

为了保证这两个日志的一致性，MySQL 使用了内部 XA 事务。内部 XA 事务由 -binlog 作为协调者，存储引擎是参与者，可以实现跨数据库事务。将 redo log -的写入拆成了两个状态：prepare 和 -commit，中间再穿插写入binlog。

-
    -
  • 如果 binlog 中没有当前内部 XA 事务的 XID，说明 redolog -完成刷盘，但是 binlog 还没有刷盘，则回滚事务。对应时刻 -A 崩溃恢复的情况；
    • -
  • 如果 binlog 中有当前内部 XA 事务的 XID，说明 redolog 和 binlog -都已经完成了刷盘，则提交事务。对应时刻 B -崩溃恢复的情况；
    • -
-

对于处于 prepare 阶段的 redo -log，即可以提交事务，也可以回滚事务，这取决于是否能在 binlog 中查找到与 -redo log 相同的 XID，以 binlog 写成功为事务提交成功的标识。

-

组提交

-

采用组提交策略，减少 redolog 和 binlog -两次刷盘导致的 I/O -次数高和锁竞争激烈的问题。

-
-

多事务场景下，两阶段提交会导致锁竞争激烈，因为为保证两个日志保存的数据库状态一致，需要加锁操作保证两阶段提交的原子性。

-
-

binlog 组提交机制：当有多个事务提交的时候，会将多个 -binlog 刷盘操作合并成一个，从而减少磁盘 I/O 的次数。prepare -阶段不变，只针对 commit 阶段，将 commit 阶段拆分为三个阶段：

-
    -
  • flush 阶段：多个事务按进入的顺序将 binlog 从 cache -写入文件（不刷盘）；5.7 之后在该阶段增加了 redo log 的组提交，即多个事务 -redo log 统一刷盘； -
      -
    • 类似于 XA 事务的 Prepare 阶段，如果在这一步完成后数据库崩溃，由于 -binlog 中没有该组事务的记录，所以 MySQL 会在重启后回滚该组事务；
      • -
    • -
  • sync 阶段：对 binlog 文件做 fsync 操作（多个事务的 -binlog 合并一次刷盘）； -
      -
    • 类似于 XA 事务的 Commit 阶段，如果在这一步完成后数据库崩溃，由于 -binlog 中已经有了事务记录，MySQL会在重启后通过 redo log -刷盘的数据继续进行事务的提交。
      • -
    • -
  • commit 阶段：各个事务按顺序做 InnoDB commit -操作；
    • -
-

每个阶段都有一个队列，锁就只针对每个队列进行保护，不再锁住提交事务的整个过程。减小了锁粒度，这样就使得多个阶段可以并发执行，从而提升效率。

-

总结模拟一次更新流程

-
    -
  • MySQL 执行器检查记录是否在 buffer pool 中 -
      -
    • 若不在，将数据页从磁盘读入到 buffer pool；
      • -
    • 若更新前与更新后数据不同，调用 存储引擎 执行更新操作；
      • -
    • -
  • 开启事务，记录 undo log，同时将 Undo 页的修改记录存在 redo log -中；
    • -
  • 存储引擎更新数据，并标记数据页为脏页，同时将数据页的修改记录存在 -redo log 中； -
      -
    • 为了减少磁盘I/O，脏页选择合适时间持久化到硬盘，持久化后删除对应的 -redo log；
      • -
    • -
  • 记录更新完毕，记录 binlog 至 binlog cache；
    • -
  • 事务提交，将 redolog binlog 持久化到硬盘（两阶段提交；组提交） -
      -
    • prepare 阶段
      • -
    • commit 阶段
      • -
    • -
-

脏页刷盘的时机

-
    -
  • Redo log 满了；
    • -
  • BufferPool满了；
    • -
  • MySQL空闲；
    • -
  • 后台线程定时 checkpoint；
    • -
  • 事务提交时（一般不选）；
    • -
-

内存

-

Buffer Pool 缓存的内容包括：索引页、数据页、Undo -页、插入缓存页、自适应哈希索引、锁信息等。innodb_buffer_pool_size -默认 128MB。

-

为了管理这些在 Buffer Pool 中的缓存页，InnoDB -为每一个缓存页都创建了一个控制块，控制块信息包括：缓存页的表空间、页号、缓存页地址、链表节点等等。用三种链表管理不同状态的缓存块：

-
    -
  • Free List （空闲页链表），管理空闲页；
    • -
  • Flush List （脏页链表），管理脏页；
    • -
  • LRU -List，管理脏页+干净页，将经常查询或可能将要查询的数据缓存在其中，而不常查询的数据就淘汰出去；
    • -
-

Free 链表：使用链表结构，快速找到空闲的缓存页；

-

每当需要从磁盘中加载一个页到 Buffer Pool 中时，就从 -Free链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的控制块从 -Free 链表中移除

- -img -

Flush 链表：使用链表结构，快速找到脏页；（结构类似于 -Free 链表）

-

脏页落盘时，后台线程遍历 Flush 链表

-

提高缓存命中率

-

Buffer Pool 有三种页和链表用来管理数据

- -img -
    -
  • Free Page（空闲页），表示此页未被使用，位于 Free 链表；
    • -
  • Clean Page（干净页），表示此页已被使用，但是页面未发生修改，位于LRU -链表。
    • -
  • Dirty -Page（脏页），表示此页「已被使用」且「已经被修改」，其数据和磁盘上的数据已经不一致。当脏页上的数据写入磁盘后，内存数据和磁盘数据一致，那么该页就变成了干净页。脏页同时存在于 -LRU 链表和 Flush 链表。
    • -
-

普通的LRU 算法会出现以下两个问题

-
    -
  • 预读失效：加载访问数据页时，提前加载进来的相邻数据页，即预读页，但后续并没有访问预读页；
    • -
  • Buffer Pool 污染：某一个 SQL 语句扫描了大量的数据时，将 Buffer Pool -里的所有页都替换出去，导致大量热数据被淘汰了，后续热数据被访问时会产生大量磁盘 -I/O； -
      -
    • 索引失效批量扫描的时候会出现污染
      • -
    • -
-

解决办法

-
    -
  • 将 LRU 划分了 2 个区域：old 区域 和 young -区域。划分这两个区域后，预读的页就只需要加入到 old -区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部。
    • -
  • 只有同时满足被访问与在 old 区域停留时间超过 -innodb_old_blocks_time 秒两个条件，才会被插入到 -young 区域头部
    • -
  • young 区域优化：为了防止 young 区域节点频繁移动到头部。young -区域前面 1/4 被访问不会移动到链表头部，只有后面的 3/4被访问了才会
    • -
-

优化

-

磁盘IO、索引、数据分页（查询大量数据）、锁竞争、内存使用下·

- -
- - - - - - -
-
- - - - - - -
-
- -
-
- -
- © - 2024 - - - - ZheWen Wang -
-
由 Hexo & NexT.Gemini 强力驱动 -
- -
-
- - -
- - 0% -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git "a/MySQL/readview\347\273\223\346\236\204.drawio.png" "b/MySQL/readview\347\273\223\346\236\204.drawio.png" deleted file mode 100644 index 8d10f68..0000000 Binary files "a/MySQL/readview\347\273\223\346\236\204.drawio.png" and /dev/null differ diff --git "a/MySQL/\344\270\244\351\230\266\346\256\265\346\217\220\344\272\244.drawio.png" "b/MySQL/\344\270\244\351\230\266\346\256\265\346\217\220\344\272\244.drawio.png" deleted file mode 100644 index cbfecac..0000000 Binary files "a/MySQL/\344\270\244\351\230\266\346\256\265\346\217\220\344\272\244.drawio.png" and /dev/null differ diff --git "a/MySQL/\344\270\273\344\273\216\345\244\215\345\210\266\350\277\207\347\250\213.drawio.png" "b/MySQL/\344\270\273\344\273\216\345\244\215\345\210\266\350\277\207\347\250\213.drawio.png" deleted file mode 100644 index d5e421e..0000000 Binary files "a/MySQL/\344\270\273\344\273\216\345\244\215\345\210\266\350\277\207\347\250\213.drawio.png" and /dev/null differ diff --git "a/MySQL/\350\241\250\347\251\272\351\227\264\347\273\223\346\236\204.drawio.png" "b/MySQL/\350\241\250\347\251\272\351\227\264\347\273\223\346\236\204.drawio.png" deleted file mode 100644 index f0c5ea6..0000000 Binary files "a/MySQL/\350\241\250\347\251\272\351\227\264\347\273\223\346\236\204.drawio.png" and /dev/null differ diff --git a/Network/index.html b/Network/index.html index 40bcd4a..5555d5f 100644 --- a/Network/index.html +++ b/Network/index.html @@ -158,18 +158,18 @@ @@ -272,11 +272,11 @@

  • 传输层，关注链路级别的传输

    • 应用数据转换到传输块的过程：

    - -img + +img

    访问网站的过程

    - -image-20240730153032143 + +image-20240730153032143
    1. 解析 URL
    2. DNS 查询服务器 IP @@ -378,11 +378,11 @@

      传输层 TCP

      TCP ：面向连接的、可靠的、基于字节流的

      三次握手

      - -TCP 三次握手 + +TCP 三次握手

      四次挥手【closed_wait；last_ack】

      - -客户端主动关闭连接 —— TCP 四次挥手 + +客户端主动关闭连接 —— TCP 四次挥手
      • 首先确认客户端不会再发送请求给服务端
      • 然后服务端在发送完数据后，再向客户端发送断开连接
        • @@ -430,8 +430,8 @@

        网络层 IP

    -
    diff --git a/OS/index.html b/OS/index.html index 1246028..da50706 100644 --- a/OS/index.html +++ b/OS/index.html @@ -156,18 +156,18 @@ @@ -264,8 +264,8 @@

    虚拟内存

    只会访问虚拟内存地址，在操作总线前，通过一个地址转换硬件将虚拟内存地址转换为物理内存地址

    进程隔离：将虚拟内存映射到物理内存，进程之间的地址空间相互隔离，互不干扰

    虚拟内存空间：

    - -image-20240518105657086 + +image-20240518105657086

    用户态虚拟内存空间是相互隔离相互独立的；内核虚拟内存空间是各个进程共享的；

    进程管理

    数据结构 PCB

    @@ -345,8 +345,8 @@

    I/O 多路复用

    -
    diff --git a/Redis/98987d9417b2bab43087f45fc959d32a.png b/Redis/98987d9417b2bab43087f45fc959d32a.png deleted file mode 100644 index a61048c..0000000 Binary files a/Redis/98987d9417b2bab43087f45fc959d32a.png and /dev/null differ diff --git a/Redis/a6286053c6884cf58bf397d01674fe80.png b/Redis/a6286053c6884cf58bf397d01674fe80.png deleted file mode 100644 index 190bdfc..0000000 Binary files a/Redis/a6286053c6884cf58bf397d01674fe80.png and /dev/null differ diff --git a/Redis/d1b889b9039f4f2f9853d44e3aa258fctplv-k3u1fbpfcp-zoom-in-crop-mark1512000.webp b/Redis/d1b889b9039f4f2f9853d44e3aa258fctplv-k3u1fbpfcp-zoom-in-crop-mark1512000.webp deleted file mode 100644 index ab0e3ea..0000000 Binary files a/Redis/d1b889b9039f4f2f9853d44e3aa258fctplv-k3u1fbpfcp-zoom-in-crop-mark1512000.webp and /dev/null differ diff --git a/Redis/ea4f7e86baf2435af3999e5cd38b6a26.png b/Redis/ea4f7e86baf2435af3999e5cd38b6a26.png deleted file mode 100644 index 421eb52..0000000 Binary files a/Redis/ea4f7e86baf2435af3999e5cd38b6a26.png and /dev/null differ diff --git a/Redis/fdd5f695bb3643258662886f9fba0aab.png b/Redis/fdd5f695bb3643258662886f9fba0aab.png deleted file mode 100644 index d1ff1f2..0000000 Binary files a/Redis/fdd5f695bb3643258662886f9fba0aab.png and /dev/null differ diff --git a/Redis/index.html b/Redis/index.html deleted file mode 100644 index 050b1d3..0000000 --- a/Redis/index.html +++ /dev/null @@ -1,583 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Redis | 闻 - - - - - - - - - - - - - -
    - -
    -
    -
    -
    -
    - - - -
    -
    - -
    - - - -

    闻

    - -     -

    Yesterday is history, tomorrow is a mystery but today is a gift.

    -
    - -
    -
    - -
    -
    -
    - - - - - - - -
    -
    - - - -
    - -
    - - - -
    -
    -
    - -
    -
    - -
    -
    - -
    - - - - - -
    - -
    - - - - - -
    - - - -
    - - - - - - - -
    -

    - Redis -

    - -
    -
    - - - - - 发表于 - - - - - - - - 更新于 - - - - - - - 分类于 - - - - - - -
    - -
    Redis 基础
    -
    -
    - - - - -

    Redis 的特性：单线程、原子性、基于内存、优化数据结构、I/O -多路复用的非关系型数据库；

    -

    6.0 版本前网络 I/O 和命令处理都是单线程，6.0 版本后网络 I/O -改用多个线程处理

    -
      -
    • 大部分操作都在内存中完成（制约 Redis 性能的瓶颈并不是 -CPU，而是内存和网络带宽）
      • -
    • 避免了多线程之间的竞争
      • -
    • I/O 多路复用机制
      • -
    -

    数据结构

    -

    5 -种基础数据类型：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合） -3 种特殊数据类型：HyperLogLog（基数统计）、Bitmap （位图）、Geospatial -(地理位置)

    -

    持久化

    -

    保证即使在服务器重启的情况下也不会丢失数据（或少量损失）

    -

    AOF 日志

    -

    将每条执行成功的写操作命令追加到日志文件中，持久化代码命令在主进程上执行

    -

    写回策略（防止AOF日志在持久化过程中丢失）：

    - -img -

    重写机制（防止AOF日志文件过大）：

    -
      -

    • 删去已经无意义的日志；

      • -

    • 重写操作由后台子进程完成，子进程共享父进程内存（为什么不用线程？父子进程以只读的方式共享数据，如果任意一方修改了该共享内存，父子进程会有独立的数据副本，即写时复制，注意这里只会复制主进程修改的物理内存数据，没修改物理内存还是与子进程共享的。而线程共享内存需要加锁）；

      • -

    • AOF -重写缓冲区用于保存重写子进程启动后，新产生的AOF日志，并在重写结束后追加到新的AOF文件中；

      • -
    -

    RDB 快照

    -

    某一时刻内存数据的快照（二进制数据），恢复时直接读入内存即可

    -

    执行 bgsave 时，想要修改数据，需采用写时复制（Copy-On-Write, -COW），以减少性能损耗

    -

    混合持久化

    -

    在AOF日志重写过程中，将新的含有 RDB 格式和 AOF 格式的 AOF -文件替换旧的的 AOF 文件，前半部分是 RDB 格式的全量数据，后半部分是 AOF -格式的增量数据，即重写缓冲区数据。

    -

    策略

    -

    过期删除策略

    -

    惰性删除+定期删除

    -

    内存淘汰策略

    -

    仅淘汰过期数据：random、ttl、lru、lfu

    -

    淘汰所有数据：lru、lfu

    -

    高可用

    -

    主从复制

    -

    模式一：全量复制【多用于初始化】

    - -
      -
    • bgsave 命令创建子进程来做生成 RDB 文件的工作，是异步工作的
      • -
    -

    为了避免过多的从服务器和主服务器进行数据同步（全量复制），可以把一部分从服务器升级成分发节点，利用从节点分担读取操作的压力

    -

    模式二：基于长连接的命令传播【多用于保持同步】

    -

    主从服务器在完成第一次同步后，双方之间就会维护一个 TCP -连接，保证第一次同步后的主从服务器的数据一致性。

    -

    模式三：连接恢复时可以采用增量复制：repl_backlog_buffer -环形缓冲区保存了最近传播的写命令，若其中存着从服务器请求的 -offset，就采用增量复制；否则采用全量复制。若想降低主从服务器断开后全量同步的概率，需要增大 -repl_backlog_buffer

    -

    QA

    -

    如何应对异步复制导致的主从数据不一致？

    -

    外部程序来监控主从节点间的复制进度

    -

    主从切换如何减少数据丢失？

    -
      -
    • 设置复制延迟限制 min-slaves-max-lag
      • -
    • 客户端降级措施，当 master 不可写，就把数据存到本地或 kafka -中等待主节点正常后再消费
      • -
    -

    集群脑裂导致数据丢失

    -

    主节点必须要有至少 min-slaves-to-write -个从节点连接，主从数据复制和同步的延迟不能超过 -min-slaves-max-lag -秒。否则原主节点就会被限制接收客户端写请求，客户端也就不能在原主节点中写入新数据，等到新的主节点上线一切恢复正常。

    -

    哨兵机制

    -
    -

    自动完成故障发现和故障转移，并通知给应用方，从而实现高可用性

    -
    -

    哨兵之间建立连接

    - -img -

    哨兵与从节点建立连接

    - -img -

    第一轮投票：判断主节点下线

    -

    主观下线：主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令

    -

    客观下线：一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，通过多个哨兵节点一起判断主节点是否下线。哨兵的赞同票数达到哨兵配置文件中的 -quorum 配置项设定的值则判断主节点客观下线

    -

    第二轮投票：选出哨兵 leader

    -
      -
    • 哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者，所谓的候选者就是想当 -Leader 的哨兵。
      • -
    • 候选者会向其他哨兵发送命令，表明希望成为 Leader -来执行主从切换，并让所有其他哨兵对它进行投票。Raft 算法选择哨兵 Leader： -
        -
      • 第一，拿到半数以上的赞成票；
        • -
      • 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
        • -
      • -
    -

    由哨兵 leader -进行主从故障转移

    -
      -
    • 第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点，选择的规则： -
        -
      • 过滤掉已经离线的从节点；
        • -
      • 过滤掉历史网络连接状态不好的从节点；
        • -
      • 将剩下的从节点，进行三轮考察：优先级、复制进度、ID -号。在每一轮考察过程中，如果找到了一个胜出的从节点，就将其作为新主节点。
        • -
      • -
    • 第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
      • -
    • 第三步：将新主节点的 IP -地址和信息，通过「发布者/订阅者机制」通知给客户端；
      • -
    • 第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；
      • -
    -

    集群

    - -
      -
    • 同一个分区内的 Redis -节点之间的数据完全一样，多个节点保证了数据有多份副本冗余保存，且可以提供高可用保障；
      • -
    • 不同分片之间的数据不相同；
      • -
    • 通过水平增加多个分片的方式，可以实现整体集群容量的扩展；
      • -
    -

    集群数据分布策略

    -

    Hash 槽

    -
      -
    • 切片 slot 槽，共有16384个槽位；
      • -
    • 数据 key 通过 “CRC16 算法 + 16384 取模”，得到对应存储的哈希槽；
      • -
    • 数据存储在该槽位对应的 Redis -分区中，每个分区都有独立的主从哨兵保证高可用；
      • -
    -

    一致性Hash

    -

    虚拟节点

    -

    缓存

    -

    缓存雪崩、击穿、穿透

    -

    缓存穿透：大量请求了缓存和数据库里都没有的数据，请求穿透缓存和数据库

    -
      -
    • 参数校验：参数不合法直接抛出异常
      • -
    • 缓存无效 key：适用于 key 变化不频繁
      • -
    • 布隆过滤器：校验 Key -是否合法（有误差，可能会把未存的值当作已有，即不合法的 key -当作合法的）
      • -
    • 接口限流：固定窗口算法、滑动窗口算法、漏桶算法、令牌桶算法
      • -
    -

    缓存击穿：瞬间大量请求未缓存的数据库数据，请求击穿缓存直接打到数据库上

    -
      -
    • 热点数据永不过期或过期时间长
      • -
    • 预热热点数据：定时任务预热（定时触发缓存预热的逻辑，将数据库中的热点数据查询出来并存入缓存中）、kafka -异步预热（将数据库中的热点数据的主键或者 ID -发送到消息队列中，然后由缓存服务消费消息队列中的数据，根据主键或者 ID -查询数据库并更新缓存）
      • -
    • 访问数据库互斥锁
      • -
    -

    缓存雪崩：缓存在同一时间大面积的失效，导致大量的请求都直接落到了数据库上

    -
      -
    • Redis 集群
      • -
    • 限流
      • -
    • 多级缓存：本地缓存+Redis
      • -
    • 热点数据失效时间长
      • -
    • 预热热点数据
      • -
    -

    如何保证数据库和缓存一致性

    -
    -

    采用 Cache Aside -旁路缓存策略：以数据库中的数据为准，缓存中的数据是按需加载的；缺点：数据写入频繁时，缓存中的数据会被频繁的清理，降低缓存命中率；

    -
    -

    更新数据库+删除缓存：延迟双删

    -

    更新数据库+更新缓存：分布式锁

    -

    更新数据库+不更新缓存：较短的缓存有效期

    -

    删除缓存的时候失败了怎么办？

    -

    采用异步删除：

    -
      -
    • 消息队列确保缓存删除成功
      • -
    • 订阅 MySQL 的 binlog，数据修改时删除缓存
      • -
    -

    缓存预热

    -

    提高访问速度，平滑流量峰值，减少后端压力，保证数据的时效性

    -

    Redis 缓存预热的方法：系统启动时加载；定时任务加载；

    -

    实战

    -

    分布式锁

    -
    -

    Redis + Lua -脚本，可以以原子性的方式执行一组命令，可用于保证锁释放操作的原子性（Lua -脚本在处理的过程中不会被任意其它请求打断），但无法用于事务执行失败的回滚。Redisson -采用的就是这种方法保证分布式锁的原子性。

    -
    -

    SET 命令的 NX 参数可以实现：key -不存在才插入，可以用于实现分布式锁

    -

    优点：性能高效、实现方便、分布式高可用

    -

    缺点：不好设置超时时间（解决方法：守护线程定期续约）、主从异步复制可能导致不可靠性（解决方法如下）

    -

    提高可靠性（Redlock 算法）：客户端和多个独立的 Redis -节点依次请求申请加锁，如果客户端能够和半数以上的节点成功地完成加锁操作，那么就认为，客户端成功地获得分布式锁，否则加锁失败，所有的 -redis 实例都会进行解锁；

    -
      -
    • 单机的 redis 是 cp 的，但是集群情况下 redis 是 ap 的，所以运行 -Redisson -的节点必须是主节点，不能有从节点，防止主节点加锁成功未同步从节点就宕机，而客户端却收到加锁成功，导致数据不一致。
      • -
    -
    @Resource
    private RedissonClient redisson;
    -

    延迟队列

    -

    有序集合 Zset；score 存储延迟执行的时间

    -

    大 Key 问题

    -

    会导致的问题

    -
      -
    • 由于 Redis 单线程处理，大 Key -的增删改查都很耗时，会导致工作线程阻塞、客户响应超时、网络传输阻塞；
      • -
    • 内存分布不均，集群场景下 slot 槽数据量不均；
      • -
    • 持久化阻塞主线程，会主线程的两个阶段耗时增加：创建子进程复制页表结构、修改共享数据写时复制；
      • -
    -

    解决办法

    -
      -
    • 拆分大 key；
      • -
    • 及时/定时清理大 key，unlink 异步删除代替 del 同步删除；
      • -
    -

    发布者/订阅者

    -
    -

    订阅命令：subscribe channel [channel ... ]

    -
    - -img -

    Link

    -

    事务回滚

    -

    Redis 不支持回滚，事务没有原子性（要么全部成功要么全部失败）

    -

    管道

    -

    批处理技术，可以一次处理多个 Redis -命令，减少多个命令执行时的网络等待

    - -
    - - - - - - -
    -
    - - - - - - -
    -
    - -
    -
    - -
    - © - 2024 - - - - ZheWen Wang -
    -
    由 Hexo & NexT.Gemini 强力驱动 -
    - -
    -
    - - -
    - - 0% -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/Redis/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAwrfmooXoirHljYHkuIk=,size_20,color_FFFFFF,t_70,g_se,x_16.png b/Redis/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAwrfmooXoirHljYHkuIk=,size_20,color_FFFFFF,t_70,g_se,x_16.png deleted file mode 100644 index 410b113..0000000 Binary files a/Redis/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAwrfmooXoirHljYHkuIk=,size_20,color_FFFFFF,t_70,g_se,x_16.png and /dev/null differ diff --git a/Rpc/A5B6F28E3286E3F920698A1D904CE4B0.png b/Rpc/A5B6F28E3286E3F920698A1D904CE4B0.png deleted file mode 100644 index 6687fdd..0000000 Binary files a/Rpc/A5B6F28E3286E3F920698A1D904CE4B0.png and /dev/null differ diff --git a/Rpc/index.html b/Rpc/index.html deleted file mode 100644 index 0f2acf9..0000000 --- a/Rpc/index.html +++ /dev/null @@ -1,550 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rpc 中间件 | 闻 - - - - - - - - - - - - - -
    - -
    -
    -
    -
    -
    - - - -
    -
    - -
    - - - -

    闻

    - -     -

    Yesterday is history, tomorrow is a mystery but today is a gift.

    -
    - -
    -
    - -
    -
    -
    - - - - - - - -
    -
    - - - -
    - -
    - - - -
    -
    -
    - -
    -
    - -
    -
    - -
    - - - - - -
    - -
    - - - - - -
    - - - -
    - - - - - - - -
    -

    - Rpc 中间件 -

    - -
    -
    - - - - - 发表于 - - - - - - - - 更新于 - - - - - - - 分类于 - - - - - - -
    - -
    Rpc 框架搭建过程遇到的问题、Dubbo 使用过程遇到的问题
    -
    -
    - - - - -
    -

    分布式系统的 CAP 理论

    -
      -
    • 一致性（Consistency）：所有节点访问同一份最新的数据副本
      • -
    • 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）
      • -
    • 分区容错性（Partition -Tolerance）：分布式系统出现网络分区的时候，仍然能够对外提供服务。
      • -
    -

    分布式保证服务高并发稳定性

    -
      -
    • 缓存：缓存是一种提高数据读取性能的技术，通过在内存中存储经常访问的数据，可以减少对数据库或者其他存储系统的访问，从而提高系统的响应速度。缓存可以应用在多个层次，例如浏览器缓存、CDN -缓存、反向代理缓存、应用缓存等。
      • -
    • 降级：降级是在系统压力过大或者部分服务不可用的情况下，暂时关闭一些非核心的服务，以保证核心服务的正常运行。降级可以在多个层次进行，例如页面降级、功能降级、服务降级等。
      • -
    • 限流：限流是一种控制系统处理请求的速率的技术，以防止系统过载。限流可以通过多种算法实现，例如固定窗口、滑动窗口、漏桶算法、令牌桶算法等。
      • -
    -

    Nacos 配置中心 注册中心

    -

    RPC 框架

    -
    -

    泛指调用远程的函数的方法，对编解码和网络层有特殊的优化，从而有更高的效率。

    -
    -

    RPC 框架主要由 Server、Client、Server Stub、Client Stub 组件组成

    -
      -
    • Client Stub -主要是将客户端的请求参数、请求服务地址、请求服务名称做一个封装，并发送给 -Server Stub
      • -
    • Server Stub 主要用于接收 Client Stub 发送的数据并解析，去调用 Server -端的本地方法
      • -
    -

    层次结构：代理曾、注册中心层（服务发现、注册、管理）、

    -

    RPC 协议定制化程度高，可以采用体积更小的 Protobuf -或其他序列化协议去保存结构体数据，同时也不需要像 HTTP -那样考虑各种浏览器行为，如 302 -重定向跳转。因此性能也会更好一些。其底层不仅可以通过 tcp udp -实现，也可以通过 http 实现。

    -

    RPC -协议会建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。

    -

    目前，对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC -协议进行通讯。

    -

    Dubbo 上线问题

    -

    记录、学习、汇总实习和技术博客中看到的 Dubbo 实战遇到的问题

    -

    服务端接口不指定通讯协议导致 -OOM

    -

    问题背景：

    -

    问题描述：

    -
      -

    • 开发人员使用方没有配置接口的 protocol -字段，而是写在接口实现类上

      • -

    • dubbo-3.0.4 框架：

      -
        -
      • 若没有指定 protocol 字段，会创建服务端提供的所有协议的 invoker
        • -
      • EasyREST 包createClientInvoker创建 REST 协议的 invoker -时需要 HttpMethod 参数
        • -
      • 由于注解写在实现类而不是接口上面，导致消费端无法共享相应的 REST -配置信息，即 HttpMethod 为 null，因此 RESTClient 创建失败
        • -
      • 在服务更新过程中，客户端每次都是全量更新注册中心的服务端信息，这个过程中如果 -invoker -一直注册失败，会不断将失败的Client存到List<ResteasyClient>中，如果有 -n 台机器需要依次更新，这时客户端的数组中会存 n*n -个失败的连接实例，从而导致 OOM
        • -
      • -
    -

    解决方法（针对框架，开发人员需要牢记 Dubbo 配置必须在接口上）：

    -
      -
    • ResteasyClient 对象由 RestProtocol 协议对象持有，针对没有创建成功 -invoker 的场景应把其对应的 ResteasyClient 销毁掉
      • -
    -

    销毁方法

    -
      -
    • 用Map<String, ResteasyClient>代替 -List<ResteasyClient>，同一个服务端只存一次
      • -
    • 用WeakHashMap<String, ResteasyClient>自动回收不用的 -ResteasyClient（参考pr）
      • -
    -

    参考

    -

    父子线程并发 RPC 调用死锁

    -

    问题描述：

    -
      -
    • 直接通过 Executors 构造 固定数量+无限长等待队列 -线程池，该线程池在共享的无界队列上操作的固定数量的线程。在任何时候，最多nThreads线程将处于活动处理任务状态。如果在所有线程都处于活动状态时提交额外的任务，它们将在队列中等待，直到有线程可用。
      • -
    -
    public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }
    -
      -
    • 并发调用 Rpc 接口获取返回值
      • -
    -
    Future<String> future = executor.submit(()->{
        return 数据查询任务;
    })
    -
      -
    • 数据查询任务中存在父子调用关系，数据查询任务同步调用 Redis -查询缓存和 Rpc 调用微服务获得数据。如果本地 Redis -缓存中能获得数据，就直接返回缓存值并取消 Rpc 调用 -future.cancel(true)。
      • -
    -

    解决办法

    -
      -
    • 父子任务分开并发执行，耗时的异步线程应做好线程池隔离
      • -
    • CompletableFuture.anyOf(task1,tsak2) -优先取先完成的那个任务的返回值
      • -
    -

    参考

    -

    尝试开发基础版 Rpc 中间件

    -

    服务发现流程：使用远程服务的时候首先需要配置一个 -dubbo.xml -文件或者在使用的类加上@Reference，二者都是用来对dubbo消费者引用服务进行一些配置，然后应用在启动的时候会将配置信息转化为一个ReferenceBean对象，并调用createProxy方法创建一个远程服务接口的代理对象。

    -

    代理对象的 invoke -创建：启动时主动订阅注册中心，会显示地调用一次notify接口，这个接口会尝试将远程服务注册的url转换成一个本地的invoker。

    -
      -
    • 转换过程中会根据具体的 protocol 创建对应的 -invoker，如 Rest 和 Dubbo 需要解析不同的参数。
      • -
    -

    服务注册地址发生改变时：会通知给消费者，dubbo -协议里面明确讲到服务发生改变会全量更新所有客户端的缓存

    -

    Netty 数据传输

    -
    -

    在网络通信中，序列化和编码通常是结合使用的。序列化将对象转换为字节流，编码将字节流转换为网络传输所需的格式（如按照协议规定的格式进行编码）。在接收端，解码将网络传输的数据解析为原始的格式（如解码成对象），以便进行进一步的处理和使用。

    -
    -

    Netty 是一个高性能事件驱动型非阻塞 IO 框架：

    -
      -
    • 提供了 ByteBuf 容器，更方便地处理数据。ByteBuf -在重写编解码器的 encoder/decoder 方法中作为参数传入。
      • -
    • channel
      • -
    -

    编码：先序列化，再压缩，最后写进 ByteBuf 对象中

    -

    解码：从 ByteBuf 对象中读，然后转成我们需要的对象

    -

    代理模式

    -

    静态代理

    -
    -

    静态代理中，我们对目标对象的每个方法的增强都是手动完成的（后面会具体演示代码），非常不灵活（比如接口一旦新增加方法，目标对象和代理对象都要进行修改）且麻烦(需要对每个目标类都单独写一个代理类)。 -实际应用场景非常非常少，日常开发几乎看不到使用静态代理的场景。

    -
    -

    从 JVM 层面来说， -静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class -文件。

    -

    静态代理的步骤

    -
      -
    • 定义一个接口及其实现类；
      • -
    • 创建一个代理类同样实现这个接口
      • -
    • 将目标对象注入进代理类，然后在代理类的对应方法调用目标类中的对应方法。这样的话，我们就可以通过代理类屏蔽对目标对象的访问，并且可以在目标方法执行前后做一些自己想做的事情。
      • -
    -

    JDK 动态代理

    -
      -
    • 定义一个接口及其实现类；
      • -
    • 自定义 InvocationHandler 并重写 invoke 方法，在 invoke -方法中我们会调用原生方法（被代理类的方法）并自定义一些处理逻辑；
      • -
    • 通过 -Proxy.newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h) -方法创建代理对象；
      • -
    -
    public interface InvocationHandler {
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable;
    }
    public class RpcClientProxy implements InvocationHandler {
        // 在代理类内，根据传入的类 clazz，获得代理对象
        public <T> T getProxy(Class<T> clazz) {
            return (T) Proxy.newProxyInstance(clazz.getClassLoader(), new Class<?>[]{clazz}, this);
        }
        // 当通过代理类调用的所有方法，实际上调用的是这个invoke（传入的只是服务接口，具体的实现在服务端实现类中）
        public Object invoke(Object proxy, Method method, Object[] args) {...}
    }
    -

    那么是如何调用服务端实现类的代码的呢？注入

    -
      -
    1. 在实例化 bean 之后，postProcessAfterInitialization 方法被调用。
      2. -
    2. 对于每个 bean 类的字段，检查是否标记了 @RpcReference 注解。
      3. -
    3. 如果发现标记了 @RpcReference -注解的字段，根据注解中的信息创建相应的 RpcServiceConfig 对象。
      4. -
    4. 通过 RpcClientProxy 创建了一个代理对象 -clientProxy，这个代理对象实现了 declaredField.getType() -所表示的接口，这个接口可能就是 HelloService 接口或其它接口，取决于 -helloService 字段的类型。
      5. -
    5. 这个代理对象 clientProxy 会在方法调用时委托给 RpcClientProxy 的 -invoke 方法，该方法负责处理远程调用的逻辑。
      6. -
    6. 通过反射设置 clientProxy 到 HelloController 类的 helloService -字段上，替换了原来的字段值。
      7. -
    -
    Object clientProxy = rpcClientProxy.getProxy(declaredField.getType());
    declaredField.setAccessible(true);
    try {
        declaredField.set(bean, clientProxy);
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    -

    传输协议

    -
    *   0     1     2     3     4        5     6     7     8         9        10     11     12   13   14 15 16
    *   +-----+-----+-----+-----+--------+----+----+----+------+-----------+-------+-------+-----+---+-----+----+
    *   |   magic   code        |version | full length         | messageType| codec|compress|    RequestId       |
    *   +-----------------------+--------+---------------------+-----------+-----------+-----------+------------+
    *   |                                         body                                                            |
    *   +-------------------------------------------------------------------------------------------------------+
    * 4B  magic code（魔法数）   1B version（版本）   4B full length（消息长度）    1B messageType（消息类型）
    * 1B compress（压缩类型） 1B codec（序列化类型）    4B  requestId（请求的Id）
    -

    注册中心

    -

    服务注册：在 zk 里面创建一个对应的持久节点

    -

    当我们的服务被注册进 zookeeper -的时候，我们将完整的服务名称 rpcServiceName （class -name+group+version）作为根节点 -，子节点是对应的服务地址（ip+端口号）。相关代码在 -ZkServiceProviderImpl.publishService() 中。

    -

    如果我们要获得某个服务对应的地址的话，就直接根据完整的服务名称来获取到其下的所有子节点，然后通过具体的负载均衡策略取出一个就可以了。相关代码在 -ZkServiceDiscoveryImpl.lookupService() 中。

    -

    Zookeeper 客户端

    -
    -

    Curator 是 Netflix -公司开源的一套zookeeper客户端框架，解决了很多Zookeeper客户端非常底层的细节开发工作，包括连接重连、反复注册Watcher和NodeExistsException异常等等。项目内采用 -CuratorUtils 类调用 Curator。

    -
    -

    重试策略：ExponentialBackoffRetry是指数退避重试策略

    -
    // zk的对外接口，后面我们要干什么只需要通过单例模式获得这个类，然后用这个类的方法
    public interface ServiceProvider {
        // 添加到本地 serviceMap 中（远程Rpc调用，获取本地的调用类）
        void addService(RpcServiceConfig rpcServiceConfig);
        Object getService(String rpcServiceName);
        // 注册服务到 zookeeper 中（服务发现与注册）
        void publishService(RpcServiceConfig rpcServiceConfig);
    }
    -

    负载均衡

    -

    随机选取策略 轮询策略 加权轮询策略 最少活跃连接策略 一致性 Hash -策略

    -

    序列化

    -
      -
    • 序列化：将数据结构或对象转化为二进制字节流
      • -
    • 反序列化：将在序列化过程中生成的二进制字节流转化为数据结构或对象
      • -
    -

    数据传输过程中，可能会出现粘包和半包问题，你是如何解决的？

    -

    自定义消息结构（其他的还有固定长度传输、特殊字符分割）：MagicNumber -魔数、ContentLength 请求长度

    - -
    - - - - - - -
    -
    - - - - - - -
    -
    - -
    -
    - -
    - © - 2024 - - - - ZheWen Wang -
    -
    由 Hexo & NexT.Gemini 强力驱动 -
    - -
    -
    - - -
    - - 0% -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/Spring/image-20240521182846989.png b/Spring/image-20240521182846989.png deleted file mode 100644 index 475976d..0000000 Binary files a/Spring/image-20240521182846989.png and /dev/null differ diff --git a/Spring/image-20240521182854337.png b/Spring/image-20240521182854337.png deleted file mode 100644 index f7830fc..0000000 Binary files a/Spring/image-20240521182854337.png and /dev/null differ diff --git a/Spring/index.html b/Spring/index.html deleted file mode 100644 index d008ab7..0000000 --- a/Spring/index.html +++ /dev/null @@ -1,467 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Spring | 闻 - - - - - - - - - - - - - -
    - -
    -
    -
    -
    -
    - - - -
    -
    - -
    - - - -

    闻

    - -     -

    Yesterday is history, tomorrow is a mystery but today is a gift.

    -
    - -
    -
    - -
    -
    -
    - - - - - - - -
    -
    - - - -
    - -
    - - - -
    -
    -
    - -
    -
    - -
    -
    - -
    - - - - - -
    - -
    - - - - - -
    - - - -
    - - - - - - - -
    -

    - Spring -

    - -
    -
    - - - - - 发表于 - - - - - - - - 更新于 - - - - - - - 分类于 - - - - - - -
    - -
    什么是 Spring 框架？
    -
    -
    - - - - -

    SpringCore 主要提供 IoC 依赖注入功能的支持 SpringMVC 快速构建 MVC -架构的 Web 程序 SpringBoot 简化 Spring 开发，减少配置文件，开箱即用

    -

    IOC 控制反转

    -
    -

    当一个对象创建时，它所依赖的对象由外部传递给它，而非自己去创建所依赖的对象（比如通过new操作）。因此，也可以说在对象如何获取它的依赖对象这件事情上，控制权反转了。这便不难理解控制反转和依赖注入这两个名字的由来了。

    -
    -

    将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC -容器完成对象的注入 Bean 工厂模式

    -
      -
    • 单例 Singleton、多例/原型 Prototype Bean
      • -
    -

    AOP 面向切面编程

    -

    将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。 -实现方式：基于动态代理，有接口用 jdk 原生的代理方法，没借口用 CGLib -

    -

    Bean 生命周期

    -
    -

    自动装配：@Component；@Service；@Controller；@Configure + @Bean

    -
    - -

    xxx.class --> 默认无参构造方法 --> 普通对象 --> -依赖注入（属性赋值） --> 初始化前 --> 初始化 --> 初始化后 ---> 代理对象 --> 得到Bean（源码） -实例化 Bean -对象：默认调用无参构造器；若使用有参构造器，参数必须是容器中有的Bean【按参数查找 -Bean 时，先按照 classname 后按照参数名】 初始化前中后：BeanPostProcessor -的 postProcessAfterInitialization() --> @PostConstruct 注解 --> -InitializingBean 的 afterPropertiesSet() 方法 --> BeanPostProcessor -的 postProcessAfterInitialization()（实现了 AOP 代理)

    -
      -
    • Aware 其实就是一个标识；只有满足 Aware -规范或者其子类规范的才能进行相关的赋值操作，这样做的话可以少写很多判断，并且可以在一个地方进行统一的判断赋值；
      • -
    • BeanPostProcessor -前置处理器的关键实现类：ApplicationContextAwareProcessor
      • -
    • BeanPostProcessor -后置处理器的关键实现类：AbstractAutoProxyCreator。这个方法负责帮我们创建代理，底层采用对象cglib -或动态代理【AOP其实就是 IOC -整体流程（Bean生命周期）里的一个扩展点】
      • -
    • InitializingBean 接口中的 afterPropertiesSet -方法：在这个方法里面去编写我们的业务逻辑，以及进行相关的属性赋值等等
      • -
    -

    底层实现

    -
      -
    • AbstractAutowireCapableBeanFactory 内的 initializeBean 调用了所有 -BeanPostProcessor 的实现类
      • -
    • ApplicationContext 类型容器的内部维护了一个 BeanFactory -类型的容器（AnnotationConfigApplicationContext 的父类 -GenericApplicationContext 维护了一个 Bean -工厂实现类：DefaultListableBeanFactory）
      • -
    • DefaultListableBeanFactory：Spring 默认的 BeanFactory 实现
      • -
    • DefaultSingletonBeanRegistry：DefaultListableBeanFactory -单例模式存储关系的地方 Map<String(BeanName),Object(instance)>
      • -
    • AbstractApplicationContext.refresh() 方法 -
        -
      • 配置了对 BeanFactoryPostProcessor 的实现 -postProcessBeanFactory(beanFactory) 和处理 -invokeBeanFactoryPostProcessors(beanFactory)。BeanFactoryPostProcessor -可以自定义 ApplicationContext 容器中的 BeanFactory -进行处理，在还没有对任何Bean进行实例化之前（ConfigurationClassPostProcessor -通过注解解析配置类；PropertySourcesPlaceholderConfigurer：xml配置文件中导入的 -properties 文件进行解析,并替换bean定义中的占位符）
        • -
      • 配置了对 BeanPostProcessor 的实现
        • -
      • -
    -
    -
      -
    1. (1-1)依赖注入：@Autowired；@Resource
      2. -
    2. 事务 @Transactional、@Configuration
      3. -
    3. (1-2)单例 Singleton、多例/原型 Prototype Bean
      4. -
    4. jvm类加载器classloader：bootstrap ext app 博客
      5. -
    -

    TODO Spring 启动流程 Springboot 和 Spring 最大的区别就是不需要 xml -配置 Springboot 自动配置

    -
      -
    • “约定优于配置”理念
      • -
    • @EnableAutoConfiguration
      • -
    • 自动将一些配置类的bean注册进ioc容器
      • -
    -

    logback是 slf4j 的官方实现，log4j 是另一个实现，logback 和 log4j -才是二选一，slf4j 是门面日志的 api。

    -

    TODO https://www.cnblogs.com/tuyang1129/p/12861617.html -https://www.cnblogs.com/tuyang1129/p/12866484.html

    -

    Spring 事务

    -

    Spring 的声明式事务信息是存在 ThreadLocal -中的，所以一个线程永远只能有一个事务，所以 Spring -的事务是无法实现事务一致性（同时提交、同时回滚）的

    -

    解决方法：可以通过编程式事务，或者通过分布式事务的思路：二阶段提交方式

    -

    如何解决循环依赖

    -

    三层缓存设计

    -
      -
    • 一级缓存，缓存正常的 bean 实例
      • -
    • 二级缓存，缓存还未进行依赖注入和初始化方法调用的 bean 实例
      • -
    • 三级缓存，缓存 bean 实例的 ObjectFactory，用于解决 BeanPostProcessor -代理类时正确地依赖注入
      • -
    -
    -

    循环依赖的情况下，不管使用三级缓存还是两级缓存，代理类逻辑都必须提前曝光

    -
    - -
    - - - - - - -
    -
    - - - - - - -
    -
    - -
    -
    - -
    - © - 2024 - - - - ZheWen Wang -
    -
    由 Hexo & NexT.Gemini 强力驱动 -
    - -
    -
    - - -
    - - 0% -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/SpringMVC/2018120522281643.gif b/SpringMVC/2018120522281643.gif deleted file mode 100644 index 8b47562..0000000 Binary files a/SpringMVC/2018120522281643.gif and /dev/null differ diff --git a/SpringMVC/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5q2i5q2l5YmN6KGM,size_20,color_FFFFFF,t_70,g_se,x_16.png b/SpringMVC/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5q2i5q2l5YmN6KGM,size_20,color_FFFFFF,t_70,g_se,x_16.png deleted file mode 100644 index 049b7f8..0000000 Binary files a/SpringMVC/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5q2i5q2l5YmN6KGM,size_20,color_FFFFFF,t_70,g_se,x_16.png and /dev/null differ diff --git a/Transformers/index.html b/Transformers/index.html index f16ea9a..d8a4a30 100644 --- a/Transformers/index.html +++ b/Transformers/index.html @@ -19,16 +19,16 @@ - + - + - + @@ -141,7 +141,7 @@
    -
    1. 1. Transformers及相关库
    2. 2. NLP
    +
    1. 1. Transformers及相关库
      1. 1.1. 分布式训练
    2. 2. NLP
    @@ -154,18 +154,18 @@ @@ -211,7 +211,7 @@

    @@ -233,47 +233,50 @@

    更新于 - +

    +
    Transformers & NLP 相关库及实现
    -

    NLP -任务：情感分析、文本生成、命名体识别、阅读理解、掩码填充、文本摘要、机器翻译、特征提取、对话机器人

    -

    万物之始 Transformer Attention is all you need

    - -image-20240714162218754 -
      -
    • 直接将句子中任意两个单词的联系通过一个计算步骤直接联系起来，远距离依赖特征之间的距离被极大缩短，有利于有效地利用这些特征；
      • -
    • Self Attention 对于增加计算的并行性有直接帮助作用；
      • -
    -

    Transformers及相关库

    -

    Transformers：核心库，模型加载、模型训练、流水线并行等

    -

    Tokenizer：分词器，对数据进行预处理，文本到token序列的互相转换。具体工作包括：分词、索引、填充截断、attention_mask、token_type

    -

    Datasets：数据集库，提供了数据集的加载、处理等方法

    -

    Evaluate：评估函数，提供各种评价指标的计算函数

    -

    Trainer：将模型训练流程打包，包括：创建优化器、创建DataLoader、tensor转移到CUDA上

    -

    PEFT：高效微调模型的库，提供了几种高效微调的方法，小参数量动大模型

    -

    Accelerate：分布式训练，提供了分布式训练解决方案，包括大模型的加载与推理解决方案

    -

    Optimum：优化加速库，支持多种后端，如Onnxruntime、OpenVino等

    -

    Gradio：可视化部署库，几行代码快速实现基于Web交互的算法演示系统

    -

    NLP

    -

    NLP -数据集大多是未标注的文档，因此采用自监督学习的方式训练模型，如预测下一个词 -LM、完形填空 MLM。

    -

    早些年，流行的是词嵌入 Word -Embedding，目标是采用向量的形式表示词元，采用一组向量表示一段话，可以用于计算词/句子相似度。

    -

    现阶段，Transformer -的出现促使三种类型的模型的出现：Encoder-only-only-Decoder。Encoder-only -适用于机器翻译、句子分类、命名体识别和问答；Decoder-only -适用于文本预测；Encoder-Decoder 适用于文本压缩。

    +

    NLP +任务：情感分析、文本生成、命名体识别、阅读理解、掩码填充、文本摘要、机器翻译、特征提取、对话机器人

    +

    万物之始 Transformer Attention is all you need

    + +image-20240714162218754 +
      +
    • 直接将句子中任意两个单词的联系通过一个计算步骤直接联系起来，远距离依赖特征之间的距离被极大缩短，有利于有效地利用这些特征；
      • +
    • Self Attention 对于增加计算的并行性有直接帮助作用；
      • +
    +

    Transformers及相关库

    +

    Transformers：核心库，模型加载、模型训练、流水线并行等

    +

    Tokenizer：分词器，对数据进行预处理，文本到token序列的互相转换。具体工作包括：分词、索引、填充截断、attention_mask、token_type

    +

    Datasets：数据集库，提供了数据集的加载、处理等方法

    +

    Evaluate：评估函数，提供各种评价指标的计算函数

    +

    Trainer：将模型训练流程打包，包括：创建优化器、创建DataLoader、tensor转移到CUDA上

    +

    PEFT：高效微调模型的库，提供了几种高效微调的方法，小参数量动大模型

    +

    Accelerate：分布式训练，提供了分布式训练解决方案，包括大模型的加载与推理解决方案

    +

    Optimum：优化加速库，支持多种后端，如Onnxruntime、OpenVino等

    +

    Gradio：可视化部署库，几行代码快速实现基于Web交互的算法演示系统

    +

    分布式训练

    +

    Accelerate 包，融合了 Deepspeed、DDP、FSDP；

    +

    NLP

    +

    NLP +数据集大多是未标注的文档，因此采用自监督学习的方式训练模型，如预测下一个词 +LM、完形填空 MLM。

    +

    早些年，流行的是词嵌入 Word +Embedding，目标是采用向量的形式表示词元，采用一组向量表示一段话，可以用于计算词/句子相似度。

    +

    现阶段，Transformer +的出现促使三种类型的模型的出现：Encoder-only-only-Decoder。Encoder-only +适用于机器翻译、句子分类、命名体识别和问答；Decoder-only +适用于文本预测；Encoder-Decoder 适用于文本压缩。

    @@ -292,8 +295,8 @@

    NLP

    -
    diff --git a/about/index.html b/about/index.html index 4c03e1a..0b3c810 100644 --- a/about/index.html +++ b/about/index.html @@ -150,18 +150,18 @@ diff --git a/archives/2023/08/index.html b/archives/2023/08/index.html index 6257174..9271fa5 100644 --- a/archives/2023/08/index.html +++ b/archives/2023/08/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    diff --git a/archives/2023/09/index.html b/archives/2023/09/index.html index 976e2d1..2195b38 100644 --- a/archives/2023/09/index.html +++ b/archives/2023/09/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    diff --git a/archives/2023/10/index.html b/archives/2023/10/index.html index 4bf74a7..2c6bf0f 100644 --- a/archives/2023/10/index.html +++ b/archives/2023/10/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    diff --git a/archives/2023/index.html b/archives/2023/index.html index 7912013..09740f6 100644 --- a/archives/2023/index.html +++ b/archives/2023/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    diff --git a/archives/2024/01/index.html b/archives/2024/01/index.html index 91a50c2..e4fbd4f 100644 --- a/archives/2024/01/index.html +++ b/archives/2024/01/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    diff --git a/archives/2024/03/index.html b/archives/2024/03/index.html index 6aa7a15..8457e2a 100644 --- a/archives/2024/03/index.html +++ b/archives/2024/03/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -239,26 +239,6 @@

    闻

    - -
    diff --git a/archives/2024/04/index.html b/archives/2024/04/index.html index 0624b05..6e88b69 100644 --- a/archives/2024/04/index.html +++ b/archives/2024/04/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -199,26 +199,6 @@

    闻

    2024
    - -
    @@ -239,26 +219,6 @@

    闻

    - -
    @@ -299,66 +259,6 @@

    闻

    - - - - - -
    @@ -399,26 +299,6 @@

    闻

    - -
    diff --git a/archives/2024/05/index.html b/archives/2024/05/index.html index f97bca9..d73f691 100644 --- a/archives/2024/05/index.html +++ b/archives/2024/05/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -259,26 +259,6 @@

    闻

    - -
    diff --git a/archives/2024/06/index.html b/archives/2024/06/index.html index 4c6c89c..0a76193 100644 --- a/archives/2024/06/index.html +++ b/archives/2024/06/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -230,7 +230,7 @@

    闻

    -
    diff --git a/archives/2024/07/index.html b/archives/2024/07/index.html index 05e4b9e..17125d4 100644 --- a/archives/2024/07/index.html +++ b/archives/2024/07/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -199,26 +199,6 @@

    闻

    2024
    - -
    diff --git a/archives/2024/02/index.html b/archives/2024/08/index.html similarity index 87% rename from archives/2024/02/index.html rename to archives/2024/08/index.html index 868e602..9324506 100644 --- a/archives/2024/02/index.html +++ b/archives/2024/08/index.html @@ -22,7 +22,7 @@ - + @@ -30,11 +30,11 @@ - + - + 归档 | 闻 @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -203,15 +203,15 @@

    闻

    -
    @@ -223,15 +223,15 @@

    闻

    -
    @@ -243,15 +243,35 @@

    闻

    - +
    + + +
    +
    + +
    +
    +
    + +
    + +
    +
    diff --git a/archives/2024/index.html b/archives/2024/index.html index 7eb55db..24f10da 100644 --- a/archives/2024/index.html +++ b/archives/2024/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -203,15 +203,75 @@

    闻

    - +
    + + +
    +
    + + + + + +
    +
    +
    + +
    + +
    +
    @@ -330,7 +390,7 @@

    闻

    -
    @@ -399,46 +459,6 @@

    闻

    - - - -
    @@ -459,26 +479,6 @@

    闻

    - -
    @@ -523,15 +523,15 @@

    闻

    -
    @@ -543,15 +543,15 @@

    闻

    -
    @@ -563,15 +563,15 @@

    闻

    -
    @@ -583,15 +583,15 @@

    闻

    -
    diff --git a/archives/2024/page/2/index.html b/archives/2024/page/2/index.html index daaf36e..313de5b 100644 --- a/archives/2024/page/2/index.html +++ b/archives/2024/page/2/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -199,166 +199,6 @@

    闻

    2024
    - - - - - - - - - - - - - - - -
    diff --git a/archives/index.html b/archives/index.html index 88675c4..0cd365d 100644 --- a/archives/index.html +++ b/archives/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -203,15 +203,75 @@

    闻

    - +
    + + +
    +
    + + + + + +
    +
    +
    + +
    + +
    +
    @@ -330,7 +390,7 @@

    闻

    -
    @@ -399,46 +459,6 @@

    闻

    - - - -
    @@ -459,26 +479,6 @@

    闻

    - -
    @@ -523,15 +523,15 @@

    闻

    -
    @@ -543,15 +543,15 @@

    闻

    -
    @@ -563,15 +563,15 @@

    闻

    -
    @@ -583,15 +583,15 @@

    闻

    -
    diff --git a/archives/page/2/index.html b/archives/page/2/index.html index 10583b7..5222bff 100644 --- a/archives/page/2/index.html +++ b/archives/page/2/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - 还行! 目前共计 39 篇日志。 继续努力。 + 还行! 目前共计 31 篇日志。 继续努力。
    @@ -199,166 +199,6 @@

    闻

    2024
    - - - - - - - - - - - - - - - -
    diff --git "a/categories/Java\345\237\272\347\241\200/index.html" "b/categories/Java\345\237\272\347\241\200/index.html" index a501ef4..493b5a1 100644 --- "a/categories/Java\345\237\272\347\241\200/index.html" +++ "b/categories/Java\345\237\272\347\241\200/index.html" @@ -149,18 +149,18 @@ @@ -220,126 +220,6 @@

    Java基础

    - - - - - - - - - - - -
    diff --git "a/categories/LLM\345\272\224\347\224\250\345\274\200\345\217\221/index.html" "b/categories/LLM\345\272\224\347\224\250\345\274\200\345\217\221/index.html" index 3b556a3..015e906 100644 --- "a/categories/LLM\345\272\224\347\224\250\345\274\200\345\217\221/index.html" +++ "b/categories/LLM\345\272\224\347\224\250\345\274\200\345\217\221/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/LLM\345\276\256\350\260\203/index.html" "b/categories/LLM\345\276\256\350\260\203/index.html" index fa7a49f..fad893a 100644 --- "a/categories/LLM\345\276\256\350\260\203/index.html" +++ "b/categories/LLM\345\276\256\350\260\203/index.html" @@ -149,18 +149,18 @@ diff --git a/categories/index.html b/categories/index.html index 9e42c33..906e2d3 100644 --- a/categories/index.html +++ b/categories/index.html @@ -150,18 +150,18 @@ @@ -202,10 +202,10 @@

    categories
    - 目前共计 12 个分类 + 目前共计 11 个分类
    - +
    diff --git a/tags/Spring/index.html b/categories/paper/index.html similarity index 92% rename from tags/Spring/index.html rename to categories/paper/index.html index 47e155e..733a113 100644 --- a/tags/Spring/index.html +++ b/categories/paper/index.html @@ -22,7 +22,7 @@ - + @@ -30,14 +30,14 @@ - + - + -标签: Spring | 闻 +分类: paper | 闻 @@ -149,18 +149,18 @@ @@ -181,7 +181,7 @@
    -
    +
    @@ -190,8 +190,8 @@
    -

    Spring - 标签 +

    paper + 分类

    @@ -204,15 +204,15 @@

    Spring
    -
    diff --git "a/categories/\345\205\253\350\202\241\346\226\207/index.html" "b/categories/\345\205\253\350\202\241\346\226\207/index.html" index 975aca2..0e49e9a 100644 --- "a/categories/\345\205\253\350\202\241\346\226\207/index.html" +++ "b/categories/\345\205\253\350\202\241\346\226\207/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/\345\267\245\344\275\234/index.html" "b/categories/\345\267\245\344\275\234/index.html" index 85b3535..1399c07 100644 --- "a/categories/\345\267\245\344\275\234/index.html" +++ "b/categories/\345\267\245\344\275\234/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/\345\267\245\344\275\234/\346\200\235\350\200\203/index.html" "b/categories/\345\267\245\344\275\234/\346\200\235\350\200\203/index.html" index 5627b7a..d9dd295 100644 --- "a/categories/\345\267\245\344\275\234/\346\200\235\350\200\203/index.html" +++ "b/categories/\345\267\245\344\275\234/\346\200\235\350\200\203/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/\345\274\200\345\217\221\345\267\245\345\205\267/index.html" "b/categories/\345\274\200\345\217\221\345\267\245\345\205\267/index.html" index d003ed9..2b8df20 100644 --- "a/categories/\345\274\200\345\217\221\345\267\245\345\205\267/index.html" +++ "b/categories/\345\274\200\345\217\221\345\267\245\345\205\267/index.html" @@ -149,18 +149,18 @@ @@ -200,6 +200,26 @@

    开发工具 2024

    + +
    @@ -211,7 +231,7 @@

    开发工具

    -
    diff --git "a/categories/\346\200\235\350\200\203/index.html" "b/categories/\346\200\235\350\200\203/index.html" index b8a4227..c802f3c 100644 --- "a/categories/\346\200\235\350\200\203/index.html" +++ "b/categories/\346\200\235\350\200\203/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/\346\225\260\346\215\256\345\272\223/index.html" "b/categories/\346\225\260\346\215\256\345\272\223/index.html" deleted file mode 100644 index 210c02d..0000000 --- "a/categories/\346\225\260\346\215\256\345\272\223/index.html" +++ /dev/null @@ -1,307 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -分类: 数据库 | 闻 - - - - - - - - - - - - - -
    - -
    -
    -
    -
    -
    - - - -
    -
    - -
    - - - -

    闻

    - -     -

    Yesterday is history, tomorrow is a mystery but today is a gift.

    -
    - -
    -
    - -
    -
    -
    - - - - - - - -
    -
    - - - -
    - -
    - - - -
    -
    -
    - -
    -
    - -
    -
    - -
    - - - - - -
    - -
    - - - - - -
    -
    -
    -

    数据库 - 分类 -

    -
    - - -
    - 2024 -
    - - - - - -
    -
    - - - - -
    -
    - -
    -
    - -
    - © - 2024 - - - - ZheWen Wang -
    -
    由 Hexo & NexT.Gemini 强力驱动 -
    - -
    -
    - - -
    - - 0% -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git "a/categories/\347\247\221\347\240\224/index.html" "b/categories/\347\247\221\347\240\224/index.html" index 270149e..ed285c0 100644 --- "a/categories/\347\247\221\347\240\224/index.html" +++ "b/categories/\347\247\221\347\240\224/index.html" @@ -149,18 +149,18 @@ diff --git "a/categories/\347\256\227\346\263\225/index.html" "b/categories/\347\256\227\346\263\225/index.html" index 5337f0e..b429489 100644 --- "a/categories/\347\256\227\346\263\225/index.html" +++ "b/categories/\347\256\227\346\263\225/index.html" @@ -149,18 +149,18 @@ diff --git a/index.html b/index.html index 5f8440c..4658d71 100644 --- a/index.html +++ b/index.html @@ -149,18 +149,18 @@

    闻

    @@ -191,7 +191,7 @@

    闻

    - +

    - +

    @@ -219,15 +219,18 @@

    发表于 + - + - + - 更新于 - + 分类于 + + + @@ -240,10 +243,10 @@

    -

    大模型微调具体实现方法，包括数据预处理、数据加载、微调模型构建、模型训练、加速训练方法、保存微调结果、加载 Adapter、推理测评、可交互 Cli等

    +

    Linux高效工具的使用方法

    - + 阅读全文 »
    @@ -274,7 +277,7 @@

    - +