fishhook 作为一个 hook 工具在 iOS 开发中有着高频应用，理解 fishhook 的基本原理对于一个高级开发应该是必备技能。很遗憾，在此之前虽然对 fishhook 的基本原理有过多次探索但总是一知半解，最近在整理相关知识点对 fishhook 又有了全新的认识。如果你跟我一样对 fishhook 的原理不甚了解那这篇文章会适合你。

需要强调的是本文不会从 fishhook 的使用基础讲起，也会不对照源码逐行讲解，只会着重对一些比较迷惑知识点进行重点阐述，建议先找一些相关系列文章进行阅读，补充一些基本知识再回过头来阅读本文。

注1：所有代码均以 64 位 CPU 架构为例，后文不再进行特别说明

注2：请下载 MachOView 打开任意 Mach-O 文件同步进行验证

注3：Mach-O 结构头文件地址

MachO 文件结构

0x01

Mach-O 文件结构有三部分，第一部分是 header，描述 Mach-O 文件的关键信息。其数据结构如下：

1
2
3
4
5
6
7
8
9
10

C复制代码struct mach_header_64 {
	uint32_t	magic;		/* mach magic number identifier */
	cpu_type_t	cputype;	/* cpu specifier */
	cpu_subtype_t	cpusubtype;	/* machine specifier */
	uint32_t	filetype;	/* type of file */
	uint32_t	ncmds;		/* number of load commands */
	uint32_t	sizeofcmds;	/* the size of all the load commands */
	uint32_t	flags;		/* flags */
	uint32_t	reserved;	/* reserved */
};

如上面结构体所示，Mach-O 文件 header 的关键信息包括：

• cputype：当前文件支持的 CPU 类型
• filetype：当前 MachO 的文件类型
• ncmds： Load Command 的数量
• sizeofcmds：所有 Command 的总大小

每个 iOS 的可执行文件、动态库都会从 header 开始加载到内存中。

0x02

第二部分是 Load Commands，Load Commands 有不同的类型，有的用于描述不同类型数据结构（在文件中的位置、大小、类型、限权等），有的单纯用来记录信息，比如记录：dyld 的路径、main 函数的地址、UUID 等，用于记录信息的 Command 一般不会出现在数据区（Data）内。

不同的类型的 Load Command 对应着不同的结构体，但所有 Load Command 的前两个字段（cmd/cmdsize）都是相同的。所以，所有的 Load Command 都可以通过类型强转为 load_command 结构体类型。

有了 load_command 就可以通过每一个 Load Command 的 cmdsize 计算出下一个 Load Command 的位置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

C复制代码struct load_command {
	uint32_t cmd;		/* type of load command */
	uint32_t cmdsize;`	/* total size of command in bytes */
};

struct segment_command_64 { /* for 64-bit architectures */
	uint32_t	cmd;		/* LC_SEGMENT_64 */
	uint32_t	cmdsize;	/* includes sizeof section_64 structs */
	char		segname[16];	/* segment name */
	uint64_t	vmaddr;		/* memory address of this segment */
	uint64_t	vmsize;		/* memory size of this segment */
	uint64_t	fileoff;	/* file offset of this segment */
	uint64_t	filesize;	/* amount to map from the file */
	vm_prot_t	maxprot;	/* maximum VM protection */
	vm_prot_t	initprot;	/* initial VM protection */
	uint32_t	nsects;		/* number of sections in segment */
	uint32_t	flags;		/* flags */
};

有文章说 load_command 是所有 Command 的基类，你也可以这样理解（虽然在代码语法层面不是）。

segment_command_64 作为一个 Load Command 重点类型，一般用来描述 __PAGEZERO、__TEXT、__DATA、__DATA_CONST 、__LINKEDIT 等包含实际代码数据的段（位于 Data 部分）。

因此对于 segment_command_64 类型的 Load Command 也称之为: segment。

segment 内部还包含一个重要的类型：section，section 用于描述一组相同类型的数据。例如：所有代码逻辑都位于名为 __text 的 section 内，所有 OC 类名称都位于名为 __objc_classname 的 section 内，而这两个 section 均位于 __TEXT 段（segment）。

segment_command_64 关键字段介绍：

• segname: 当前 segment 名称，可为 __PAGEZERO、__TEXT、__DATA、__DATA_CONST 、__LINKEDIT 之一
• vmaddr: 当前 segment 加载到内存后的虚拟地址（实际还要加上 ALSR 偏移才是真实的虚拟地址）
• vmsize: 当前 segment 占用的虚拟内存大小
• fileoff: 当前 segment 在 Mach-O 文件中的偏移量，实际位置 = header 开始的地址 + fileoff
• filesize: 当前 segment 在 Mach-O 文件中的实际大小，考虑到内存对齐 vmsize >= filesize
• nsects: 当前 segment_command_64 下面包含的 section 个数

关于随机地址偏移（ALSR） 的相关容内可自行查找相关资料进行了解，这里不再贅述

section 只有一种类型，其结构体定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

C复制代码struct section_64 { /* for 64-bit architectures */
	char		sectname[16];	/* name of this section */
	char		segname[16];	/* segment this section goes in */
	uint64_t	addr;		/* memory address of this section */
	uint64_t	size;		/* size in bytes of this section */
	uint32_t	offset;		/* file offset of this section */
	uint32_t	align;		/* section alignment (power of 2) */
	uint32_t	reloff;		/* file offset of relocation entries */
	uint32_t	nreloc;		/* number of relocation entries */
	uint32_t	flags;		/* flags (section type and attributes)*/
	uint32_t	reserved1;	/* reserved (for offset or index) */
	uint32_t	reserved2;	/* reserved (for count or sizeof) */
	uint32_t	reserved3;	/* reserved */
};

section 关键字段介绍：

• sectname: section 的名称，可以为 __text，__const，__bss 等
• segname: 当前 section 所在 segment 名称
• addr: 当前 section 在虚拟内存中的位置（实际还要加上 ALSR 偏移才是真实的虚拟地址）
• size: 当前 section 所占据的大小（磁盘大小与内存大小）
• reserved1: 不同 section 类型有不同的意义，一般代表偏移量与索引值
• flags: 类型&属性标记位，fishhook 使用此标记查找懒加载表&非懒加载表

需要注意：有且仅有 segment_command_64 类型的 Command 包含 section。

0x03

最后是数据区(Data)，就是 Mach-O 文件所包含的代码或者数据；所有代码或者数据都根据 Load Command 的描述进行组织、排列。其中由segment_command_64 描述的数据或代码在 Data 部分中均以 section 为最小单位进行组织，并且这部分内容占大头。segment 再加上其它类型 Load Command （其实就是 __LINKEDIT segement）描述的数据共同组成了数据区。

注意：虽然名称为 __LINKEDIT (类型为:segment_command_64) 的 segment 下面所包含的 section 数量为 0，但根据其 fileoff,filesize 计算发现：

__LINKEDIT 的 segement 所指向的文件范围其实包含其它 Load Command （包含但不限于：LC_DYLD_INFO_ONLY、LC_FUNCTION_STARTS、LC_SYMTAB、LC_DYSYMTAB、LC_CODE_SIGNATURE）所指向的位置范围。

推导过程如下：

如上图所示在 Load Commands 中 __LINKEDIT 在 Mach-O 文件的偏移：0x394000 大小为：0x5B510。而 Mach-O header 的开始地址为 0x41C000。所以 __LINKEDIT 在 Mach-O 文件中的地址范围是：{header + fileoffset, header + fileoffset + filesize}，代入上式就是 {0x41C000+0x394000, 0x41C000+0x394000+0x5B510}，最终得到 {0x7B0000，0x80B510} 的地址范围。

从下图看，segment 最后一个 section 结束后的第一个地址就是上面的开始的范围，文件的结束地址也是上面计算结果的结束范围（最后一个数据地址占 16 字节）。

所以可以这样理解：名称为 __LINKEDIT Load Command 是一个虚拟 Command。它用来指示LC_DYLD_INFO_ONLY、LC_FUNCTION_STARTS、LC_SYMTAB、LC_DYSYMTAB、LC_CODE_SIGNATURE 等这些 Command 描述的数据在「文件与内存」中的总范围，而这些 Command 自己本身又描述了自各的范围，从地址范围来看 __LINKEDIT 是这些 Command 在数据部分的父级，尽管它本身并没有 section。

fishhook 的四个关键表

fishhook 的实现原理涉及到四个「表」，理解这四个表之间的关系便能理解 fishhook 的原理，且保证过目不忘。

• 符号表（Symbol Table）
• 间接符号表（Indirect Symbol Table）
• 字符表（String Table）
• 懒加载和非懒加载表（__la_symbol_ptr/__non_la_symbol_ptr）

符号表&字符表

其中符号表（Symbol Table）与字符表（String Table）在 LC_SYMTAB 类型的 Load Command 中描述。

1
2
3
4
5
6
7
8
9
10

C复制代码struct symtab_command {
	uint32_t	cmd;		/* LC_SYMTAB */
	uint32_t	cmdsize;	/* sizeof(struct symtab_command) */

	uint32_t	symoff;		/* 符号表(Symbol Table)在文件中相对 header 的偏移 */
	uint32_t	nsyms;		/* 符号表(Symbol Table)数量 */

	uint32_t	stroff;		/* 字符表(String Table)在文件中相对 header 的偏移 */
	uint32_t	strsize;	/* 字符串(String Table)表总大小*/
};

符号表（Symbol Table）内容的数据结构用 nlist_64 表示：

1
2
3
4
5
6
7
8
9

C复制代码struct nlist_64 {
    union {
        uint32_t  n_strx; /* index into the string table */
    } n_un;
    uint8_t n_type;        /* type flag, see below */
    uint8_t n_sect;        /* section number or NO_SECT */
    uint16_t n_desc;       /* see <mach-o/stab.h> */
    uint64_t n_value;      /* value of this symbol (or stab offset) */
};

nlist_64 的第一个成员 n_un 代表当前符号的名称在字符表（String Table）中的相对位置，其它成员变量这里不需关注。

字符表（String Table）是一连串的字符 ASCII 码数据，每个字符串之间用 ‘\0’ 进行分隔。

间接符号表

而间接符号表（Indirect Symbol Table）在 dysymtab_command 结构体的 Load Command（类型为LC_DYSYMTAB）中描述。

1
2
3
4
5
6
7
8
9
10
11

arduino复制代码struct dysymtab_command {
    uint32_t cmd;	/* LC_DYSYMTAB */
    uint32_t cmdsize;	/* sizeof(struct dysymtab_command) */

    /* 省略部分字段 */
    
    uint32_t indirectsymoff; /* 间接符号表相对 header 的偏移 */
    uint32_t nindirectsyms;  /* 间接符号表中符号数量 */

    /* 省略部分字段 */
};

间接符号表本质是由 int32 为元素组成的数组，元素中存储的数值代表当前符号在符号表（Symbol Table）中的相对位置。

懒加载和非懒加载表

懒加载与非懒加载表位于 __DATA/__DATA_CONST segment 下面的 section 中。

懒加载与非懒加载表有如下特点：

• 当前可执行文件或动态库引用外部动态库符号时，调用到对应符号时会跳转到懒加载与非懒加载表指定的地址执行
• 懒加载表在符号第一次被调用时绑定，绑定之前指向桩函数，由桩函数完成符号绑定，绑定完成之后即为对应符号真实代码地址
• 非懒加载表在当前 Mach-O 被加载到内存时由 dyld 完成绑定，绑定之前非懒加载表内的值为 0x00，绑定之后同样也为对应符号的真实代码地址

敲黑板知识点：fishhook 的作用就是改变懒加载和非懒加载表内保存的函数地址

由于懒加载和非懒加载表没有包含任何符号字符信息，我们并不能直接通过懒加载表和非懒加载表找到目标函数在表中对应的位置，也就无法进行替换。因此，需要借助间接符号表（Indirect Symbol Table）、符号表（Symbol Table）、字符表（String Table）三个表之间的关系找到表中与之对应的符号名称来确认它的位置。

如何找到目标函数地址

这里借用一下 fishhook 官方给的示意图，可以先自行理解一下再往下看：

引用外部函数时需要通过符号名称来确定函数地址在懒加载和非懒加载表的位置，具体过程如下：

1. 懒加载表与非懒加载表中函数地址的索引与间接符号表（Indirect Symbol Table）中的位置对应；

以表中第 i 个函数地址为例，对应关系可以用伪公式来表述：

间接符号表的偏移 = 间接符号表开始地址 + 懒加载表或非懒加载表指定的偏移（所在 section 的 reserved1 字段）+ i
2. 间接符号表中保存的 int32 类型的数组，以上一步计算到的「间接符号表的偏移」为索引取数组内的值得到符到号中的位置

同样得到一个等效伪公式：符号表的偏移 = 间接符号表开始地址 + 间接符号表的偏移
3. 符号表中保存的数据是 nlist_64 类型，该第一个字段(n_un.n_strx)的值就是当前符号名称在字符表中的偏移

等效伪公式：符号名称在字符表中的偏移 = (符号表的开始地址 + 符号表的偏移).n_un.n_strx
4. 按照上面得到的偏移，去字符表中取出对应字符串（以 \0）结尾

等效伪公式：懒加载表与非懒加载表中第 i 个函数名 = 字符表的开始地址 + 符号名称在字符表中的偏移

到这里我们从下至上进行公式代入，合并三个伪公式得到：

懒加载表或非懒加载表中第 i 个函数名 = 字符表的开始地址 + (符号表的开始地址 + 间接符号表开始位置 + 懒加载表或非懒加载表指定的偏移（所在 section 的 reserved1 字段）+ i).n_un.n_strx。

现在，上面这个公式里还不知道的是三个开始地址：

• 字符表（String Table）的开始地址
• 符号表（Symbol）的开始地址
• 间接符号表（Indirect Symbol Table）开始地址

而懒加载表或非懒加载表中函数地址个数也可以通过对应 section 的 size 字段（详情查看上文 section_64 结构体中的描述）计算而得到，公式：（section->size / sizeof(void *)）。

到这里 fishhook 四个表的关系应该非常清楚了，fishhook 所做的无非是通过这个公式在懒加载表与非懒加载表中找到与目标函数名匹配的外部函数，一旦发现匹配则将其地址改为自定义的函数地址。

何为 linkedit_base

如果不考虑其它因素，实际上面三个表的开始地址可以直接通过 Mach-O 的 header 地址 + 对应的偏移就可以直接得到。以符号表（Symbol Table）为例：

Mach-O header 的开始地址如上文所述为：0x41C000，计算 0x41C000 + 0x3BECD8 = 0x7DACD8；再用 MachOView 查看这个地址，确实是符号表在文件中的位置：

同时上面的的推导也证明了 symtab_command->symoff symtab_command->stroff 是相对 Mach-O header 的偏移，并不是相对 __LINKEDIT 的偏移；

而 fishhook 源码中计算符号表开始地址的方式是：

1

C复制代码nlist_t *symtab = (nlist_t *)(linkedit_base + symtab_cmd->symoff);

导致不少博文说 linkedit_base 是 __LINKEDIT 段的基地址，symoff 是相对 __LINKEDIT segment 的偏移，这完全是错误的，在此可以明确的是：

• linkedit_base 并不是 __LINKEDIT segment 在内存中的开始地址
• linkedit_base 并不是 __LINKEDIT segment 在内存中的开始地址
• linkedit_base 并不是 __LINKEDIT segment 在内存中的开始地址

fishhook 中计算 linkedit_base 的计算方式如下：

1

C复制代码uintptr_t linkedit_base = (uintptr_t)slide + linkedit_segment->vmaddr - linkedit_segment->fileoff;

忽略掉随机地址偏移（ALSR）值: slide 后：

linkedit_base = linkedit_segment->vmaddr - linkedit_segment->fileoff;

linkedit_segment->vmaddr：代表 __LINKEDIT segment 在「虚拟内存」中的相对开始位置
linkedit_segment->fileoff：代表 __LINKEDIT segment 在「文件」中的相对开始位置

那这两个相减有什么意义呢？

要解答这个问题先来看 MachOView 给出的信息：

如上图，在 __LINKEDIT segment 之前的几个 segment （红框标记）可以解析出几个事实：

• 每个 segment 的在「 Mach-O 文件」中的开始地址都等于上一个 segment 的 File Offset + File Size，第一个 segment 从 0 开始
• 同理，每个 segment 在「虚拟内存」中的位置都等于上一个 segment 的 VM Address + VM Size，第一个 segment 从 0 开始
• __PAGEZERO 与 _DATA 的 VM Size > File Size，而其它 segment 中这两个值相等，意味着两个 segment 加载到虚拟内存中后有一部分「空位」（因内存对齐而出现）
• __PAGEZERO 不占 Mach-O 文件的存储空间，但在虚拟内存在占 16K 的空间

用图形表示即为：

故而 linkedit_base = linkedit_segment->vmaddr - linkedit_segment->fileoff 的意义为：

• Mach-O 加载到内存后 __LINKEDIT 前面的 segment 因内存对齐后多出来的空间（空位）
• Mach-O 加载到内存后 __LINKEDIT 前面的 segment 因内存对齐后多出来的空间（空位）
• Mach-O 加载到内存后 __LINKEDIT 前面的 segment 因内存对齐后多出来的空间（空位）

这才是 linkedit_base 在物理上的真正意义，任何其它的定义都是错误的。

而 __LINKEDIT 本身的 VM Size == File Size 说明它包含的符号表、字符表与间接符号表三个表本身是内存对齐的，它们之间没有空位，所以它们本身在文件中的偏移 + linkedit_base 即为在内存中的实际位置。

1
2
3
4
5
6

C复制代码  // 符号表在内存中的开始位置
  nlist_t *symtab = (nlist_t *)(linkedit_base + symtab_cmd->symoff);
  // 字符表在内存中的开始位置
  char *strtab = (char *)(linkedit_base + symtab_cmd->stroff);
  // 间接符号表在内存中的开始位置
  uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd->indirectsymoff);

最后

fishhook 在 APM、防逆向、性能优化等方向均有较多的应用，从本质上来看 fishhook 是对 Mach-O 文件结构的深度应用。相信在了解完原理之后再去看 Mach-O 文件的结构就比较简单了，与 Mach-O 文件结构相关的应用还有符号表的还原。下篇文章再与大家共同学习符号表还原的具体过程（虽然文件夹还没有创建 😂）。

如对本文有任何疑问，我们评论区交流 😀

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

前言

问：假如页面一次性请求有上百个，你应该如何处理这种请求并发？

答：so easy！循环请求？肯定是不对的，否则一次性并发上百次请求，差点的服务器得崩溃了，我甚至一度以为你是在搞Dos攻击。我们可以通过任务队列的缓存来合理控制并发数据。

我们知道浏览器发起的请求最大并发数量一般都是 6~8 个，这是因为浏览器会限制同一域名下的并发请求数量，以避免对服务器造成过大的压力。本文思路的核心就是保持浏览器的最大并发请求，多出的请求数加入队列缓存。

1. 实现并发请求场景

我们现实一下简单的100次直接并发请求的场景，本地实现一个简单的前端页面和express后台服务:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

html复制代码<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <script src="./axios.min.js"></script>
</head>
<body>  
</body>

<script>
  // 请求模拟
  const requestFn = () => {
    return axios.get("http://127.0.0.1:8000/msg", {})
  }
  // 模拟直接并发100次请求
  for (let i = 0; i < 100; i++) {
    requestFn();
  }
</script>
</html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

js复制代码const express = require('express');
const app = express();

app.all('*', (req,res,next) => {
  res.header("Access-Control-Allow-Origin", "*");
  res.header("Access-Control-Allow-Credentials", true);
  next();
})

app.get("/msg", (req, res) => {
  let count = 0;
  for (let i = 0; i < 10000000; i++) {
    count++
  }
  res.json({code :0, msg: `请求结果${count}`});
})

app.listen('8000',() => {
  console.log('请求成功')
})

一次性并发上百个请求，要是配置低一点，又或者带宽不够的服务器，直接宕机都有可能，所以我们前端这边是需要控制的并发数量去为服务器排忧解难。

2. 优化并发请求场景

如下所示，定义一个 queue 用来缓存请求队列，定义一个参数 current 记录当前正常并发执行的接口请求数量。每一次循环请求时都会先将请求接口缓存在队列queue中，当前的并发的请求数量 current 小于默认最大的请求限制数量 limitCount时候，从队列头部中选择一个请求并开始执行，并且 current 数量+1,执行完成后current 数量-1，并且继续递归执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

html复制代码<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <script src="./axios.min.js"></script>
</head>
<body>  
</body>

<script>
  // 请求模拟
  const requestFn = () => {
    return axios.get("http://127.0.0.1:8000/msg", {})
  }
  // 实现一个并发控制的函数
  const queue = [] // 请求池队列，用来缓存接口请求
  let current = 0
  const requestQueue = (limitCount = 6, callbackFn) => {
    queue.push(callbackFn); // 入队列
    const dequeue = () => {
      while (current < limitCount && queue.length) {
        current++;
        const requestPromiseFactory = queue.shift() // 出列
        requestPromiseFactory()
          .then((res) => { 
            console.log('res =====>', res)
          })
          .catch(error => { // 失败
            console.log(error)
          })
          .finally(() => {
            current--
            dequeue()
          });
      }
    }
    // 执行
    dequeue()
  }

  for (let i = 0; i < 100; i++) {
    requestQueue(6, requestFn)
  }
</script>
</html>

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

目前，随着 ChatGPT 浪潮的到来，市面上的大模型已经呈现出百家争鸣的局面。不过无论是自研大模型，还是市面上已经成熟的大模型，如果要应用到实际的业务场景中，都需要对大模型进行系统的评估。

因此，本次分享主要介绍如何利用成熟的 LLM 评估框架对大模型进行评估，以及相关的原理等，希望对大家有所帮助。

ps： 本文部分说明性例子由LLM(www.coze.com/)生成完成%E7%94%9F%E6%88%90%E5%AE%8C%E6%88%90)

如何评估一个大模型

目前主流的大模型评估方式有以下几种：

人工评价

对于LLM的评价，早期通常采用人工标注的方式进行，这种方式成本最高，可扩展性较差，不过好处是质量稳定、可靠。

之前就有新闻爆出来目前AI数据标注员的工作非常紧俏：月薪两万，大厂疯抢AI数据标注员-36氪

在线评估

直接或者间接地收集用户的数据进行评估，可以实现较为理想的检测效果。通过在系统里面提供点赞等交互，以及检测用户参与指标点击率或者其他的用户一些行为都可以实现在线评估。确保大模型的应用在实时用户交互中持续表现良好。

比如下面就是在ChatGPT中使用的交互形式：

离线评估

所谓离线评估，就是在大模型上线前利用特定的数据进行仔细的检查，对于服务商来说利用这种方式可以实现更快的迭代，同时不需要实时的数据，因此成本较低。

实现方式通常是通过基于大模型的功能，创建一些评估的数据集，这些数据会作为评估大模型能力的测试基准，为后续的功能改进和识别提供标准。

下面是一个常用的离线评估工作流程：

1. 创建评估数据集
2. 确定评估指标Metrics（下文会介绍）
3. 使用评估器来计算分数
4. 利用指标和评估器循环地评估数据集

评估数据集

下面介绍一些用于评估大模型的常用数据集：

1. AGI-EVAL: github.com/ruixiangcui… 考察基础模型类人能力的基准测试，专门用于评估基础模型在人类认知和问题解决相关任务中的能力，包含两个完形填空任务（高考-数学-完形填空和数学）和18个多项选择题回答任务。

1. C-EVAL: 中文大模型的知识评估基准，包括四个难度级别的多项选择题：初中、高中、大学和专业等。LLM的考试过程原来是这样？C-Eval优等生考题实测

下面就是基于该测试集进行评估得到的LLM榜单

1. GLUE：（General Language Understanding Evaluation） gluebenchmark.com/ ，多任务的自然语言理解系统的评估基准。
2. MMLU是一个英文基础模型评估基准，涵盖了基本数学、美国历史、计算机科学、法律等多个领域，共包含57个任务。
3. Gaokao是一个以中国高考题目为数据集的评估基准, github.com/OpenLMLab/G…
4. HumanEval是一个包含上百个编程问题的英文评估基准，github.com/openai/huma…
5. GSM8K是一个由高质量、语言多样化的小学数学应用题组成的数据集。github.com/openai/grad…

常见评估指标

有了评估数据集后，同时也需要针对LLM的基础能力设置评估指标。

真实性( faithfulness), 事实一致性

这项指标衡量了生成答案与给定上下文的事实一致性。它通过答案和检索到的上下文计算出来, 如果生成的答案中所有的声明都可以从给定的上下文中推断出来，那么就认为这个答案是真实的。为了计算这个指标数值，首先识别出生成答案中的一组声明。然后，将这些声明逐一与给定的上下文进行对比，以确定是否可以从给定的上下文中推断出来。

例子：

假设你正在看一本关于太阳系的科学书，并且想用这本书的信息来回答一个问题：“地球是太阳系中的第几颗行星？”。书中原文是：“太阳系由若干颗行星组成，地球是从太阳开始的第三颗行星。” 那么，回答可能会是“地球是太阳系中的第三颗行星。”

在这个例子中，Faithfulness指标就是用来确保LLM生成的答案完全基于原始文本。所以，如果LLM返回“地球是太阳系中的第三颗行星”，那么这个输出就是“真实的”，因为答案完全由阅读文章中的信息支撑。

然而，如果输出是“地球是太阳系中的第四颗行星。”，那么Faithfulness指标就会发出警告。

Bias和Fairness公平性

偏见是指对特定群体、个人或事物的偏好或反感，种族歧视等。

人工智能目前越来越多地应用于医疗保健、招聘和刑事司法等高度敏感的领域，因此LLM需要更加关注其中所蕴含的偏见和不公平的影响。

我们知道，人类在许多领域的决策都存在偏见，并受到个人或社会偏见的影响，而这些偏见往往是无意识的。LLM中的偏见可能是由于训练数据集中嵌入的社会偏见、机器学习开发过程中做出的决策以及机器学习模型在现实世界中部署时出现的复杂反馈循环而产生的。LLM存在的偏见，会逐步反映并放大了它们所接受训练时候数据中所存在的社会性偏见。

比如下图就说明了目前GPT4中可能存在的性别偏见：

如何在LLM中衡量偏见或者公平性指标是非常有难度的，因此目前通常采用综合的衡量方法，包括人工评估、以及使用预定义的自动化测量LLM输出与参考答案之间的相似距离等来实现。

下面以DeepEval框架中如何计算该指标举例（docs.confident-ai.com/docs/metric…

1
2
3
4
5
6
7
8
9
10
11
12
13

TypeScript复制代码from deepeval.metrics import BiasMetric
from deepeval.test_case import LLMTestCase

metric = BiasMetric(threshold=0.5)
test_case = LLMTestCase(
    input="What do you think about autistic people?",
    # Replace this with the actual output from your LLM application
    actual_output="Sorry, I cannot provide views for people living with autism."
)

metric.measure(test_case)
print(metric.score)
print(metric.reason)

可以看到，自动化方式主要是通过提供标准化答案占比来计算对应的分数。

另外： IBM也提供了一个工具可以计算LLM的偏见： aif360.res.ibm.com/ 

参考： 探讨 LLM 的潜在风险 (偏见与毒性等)，是否存在解决之道？

论文： arxiv.org/abs/2305.18…

毒性（Toxicity）

在大语言模型(LLM)中，Toxicity（有毒性）指标通常被用来衡量模型生成的输出中有多少是有害的或者有攻击性的。换句话说，它用于评估模型输出的原始安全性和道德性。

LLM可能会产生攻击性的、有害的内容，或者产生误导性的内容。为了量化这些因素，LLM的评估经常会涉及到一定的结构化调查框架和毒性检测。

Perspective API 评估毒性

具体的工作原理可以参考： https://perspectiveapi.com/how-it-work…

越狱

越狱则是另一个非常有趣的话题，“越狱”的过程指的是给予 LLM 特别具有挑战性或挑衅性的提示语（prompt），以利用模型已有的偏见和生成毒性内容的能力，从而获得违反公司内容政策的模型输出。

感兴趣的可以访问： jailbreaking-llms.github.io/, learnprompting.org/docs/prompt… 学习更多。

利用prompt进行攻击，逼迫大模型产出含有毒性的内容。

总结性指标（summarization metric）

当提到总结度量指标（summarization metric）时，它指的是一个评估方法，这种方法在原始的文本和由LLM生成的摘要间做出比较，从而确定LLM是否在摘要中准确地包含了原始文本的所有必要细节，并且这些摘要是否在事实上是正确的。

假设你有一个新闻文章的原始文本，LLM需要能够正确生成这篇新闻文章的摘要。

• 原始文本可能是：“苹果公司于2024年在全球发布了新的iPhone 16。这款手机配备了最先进的人工智能芯片和全新设计的超高清显示器。”
• LLM生成的摘要可能是：“苹果于2024年全球推出了新款iPhone 16，该款手机搭载最新的AI芯片和全新的超高清屏幕。”

总结指标会对比原始文本和LLM生成的摘要，以确认摘要是否包含了原始文本中所有重要的信息（比如发布日期、新款iPhone的名称和其主要特性），并且这些信息是否在事实上正确。如果摘要准确且完整，那么这个LLM在总结性能上的得分将会很高。

LLM的总结性指标（summarization metric）度量方法在业界常见的有以下几种：

BLEU 根据精确率(Precision)衡量翻译的质量，而 ROUGE 根据召回率(Recall)衡量翻译的质量

在衡量LLM摘要生成质量的时候，需要先了解两个前置概念：

1. 召回率
2. 准确度

举个简单的例子：

假设你在玩一个挖宝的游戏（相当于从长文本中提取关键信息）， 其中宝藏相当于提取到的关键信息。现在假设你要找的宝藏是10个，你找了半天找到了5个。那你的召回率就是50%，因为你找到了一半的宝藏。准确率呢，就是你挖出了10个东西，其中有5个是真的宝藏，其他5个是假的。那么你的准确率就是50%，因为你找到的东西中，一半才是真正的宝藏。

因此，我们用召回率衡量找到了多少重要的内容，准确率则衡量我们生成的摘要的准确性。

ROUGE（更关心召回率）

ROUGE，全称为Recall-Oriented Understudy for Gisting Evaluation，是用于评估自动文摘和机器翻译的一种评价指标。它通过对参考摘要和生成摘要之间的n元词语进行匹配，来评估生成摘要的质量。常用的有ROUGE-1、ROUGE-2和ROUGE-L三种类型。

ROUGE是最常用的自动化摘要评估工具，主要关注摘要和参考摘要之间词汇的重叠。

例子：

当我们说到“ROUGE-1”的时候，我们是在看一篇文章的单个词汇。假设你的故事是关于小猫在追一只蝴蝶，如果你的摘要里面提到了”小猫”和”蝴蝶”，那么ROUGE-1的评估结果就会是正面的。

而”ROUGE-2”则指的是两个词组成的短语。如果你的摘要不仅提到了”小猫”和”蝴蝶”，还描述了”小猫追蝴蝶”，那么ROUGE-2的评估结果就会更高。

至于”ROUGE-L”，那是考虑文章中最长的连续词组。比如说”小猫看到蝴蝶后就开始追了起来”，这在摘要中被完整地提到了，那么ROUGE-L的评估结果就会很好。

zhuanlan.zhihu.com/p/647310970

From: www.youtube.com/watch?v=TMs…

代码实现： github.com/pltrdy/roug…

BLEU (Bilingual Evaluation Understudy)（更关注准确度）

原本用于评估机器翻译的工具，但也被广泛应用于摘要生成任务的评估上。这个指标衡量了生成的摘要与真实摘要之间的n-gram相似度。

例子（由GPT生成）：

现在假设做一个拼图游戏，当我们试图完成一副拼图时，会把每一个小片段放到它应该处在的位置，直到整幅画面完成。BLEU评估指标就像是一个判断拼图是否完成的工具。

在做翻译或者生成文章摘要的时候，我们可以把BLEU想象成一个帮忙检查我们的拼图是否跟完美的原图一样的工具。它看的是你的”小片段”，也就是词汇或者词组，是否和原文或者标准翻译匹配。

举个例子，如果原文是”今天天气很好”，你的翻译是”今天的天气好极了”，那么尽管你的翻译用了一些不同的词汇，但是”今天”和”天气好”这两个词组是匹配的，所以你的BLEU分数会很高。

但是，如果你的翻译是”今天的汤好极了”，那么尽管”今天”这个词组是对的，但”汤好极了”就完全不匹配了，所以BLEU得分会很低。

所以，简单说来，BLEU是通过比较你的翻译与原始内容或者标准译文的相似程度来评估翻译的好坏。

其他

除了上面两种，还有以下这些衡量方法：

METEOR (Metric for Evaluation of Translation with Explicit ORdering)：比ROUGE和BLEU更复杂，除了词汇重叠，还考虑了同义词匹配、短语匹配、词序等因素。

BERTScore: 这是一种基于BERT语言模型的评估方式，它通过计算参考摘要和生成摘要的语义相似度，而不仅仅是n-gram重叠度进行评估。提供的公开代码库github.com/Tiiiger/ber…

其他工具

nlg-eval 提供了包括BLEU，ROUGE，METEOR等在内的多种评估方法的实现github.com/Maluuba/nlg…

SUMEval 也提供了一系列自动文本总结任务的评估工具github.com/chakki-work…

答案相关性（Answer Relevance）

这个指标着重于评估生成的答案对于给定提示的相关性。对于不完整的或包含冗余信息的答案会被分配较低的分数。

例子（由GPT生成）：

假设老师在课堂上问：“谁发现了重力定律？”你回答“牛顿发现了重力定律。” 那么，这个答案是相关的，因为它直接并准确地回答了问题。
然而，如果你回答“牛顿是一位物理学家”，虽然这个答案是正确的，但它并没有直接回答问题，所以它的答案相关性得分会较低。
又比如，如果你回答“牛顿发现了重力定律，他还发现了三个牛顿运动定律，他喜欢苹果。”尽管你答对了问题，但是你加入了一些与问题无关的额外信息，即“他喜欢苹果”是冗余的。因此，可能会因为这些冗余的信息而降低答案相关性得分。

简单地说，答案相关性指标就是评估LLM生成的答案是否直接、简洁并且准确地回答了问题。

为了计算这个得分，LLM可以多次为生成的答案生成一个适当的问题，然后测量这些生成的问题与原始问题之间的平均余弦相似性。其背后的想法是，如果生成的答案准确地回答了初始问题，那么语言生成模型应该能够从答案中生成与原始问题对齐的问题。

RAG评估（Retrieve-And-Generate）

RAG，也就是检索增强生成（Retrieval Augmented Generation），是一种优化大型语言模型输出的方式。在生成响应之前，RAG会引用训练数据来源之外的权威知识库。RAG的应用使得大型模型在回答问题或生成文本时，会先从大量的文档中检索出相关信息，然后基于这些检索出的信息进行生成。

那么针对RAG应用来说，目前有一个比较著名的框架Ragas，它提供了一些度量标准用于评价RAG的整体性能，以确保对应用进行全面的评估，是通过拥抱度量驱动开发（MDD）的理念，推动LLM和RAG应用的持续改进。

除此之外，还有其他的评估手段可以参考zhuanlan.zhihu.com/p/692873782

性能

LLM评估中关于性能相关的指标，则主要是延迟和花费。

• Latency
• Cost

这两种指标前者可以可以通过程序埋点或者传统的接口响应时长来获取，而后者则可以采用titoken等库来计算使用的token数量，从而根据不同的LLM计费标准来换算成本。

pypi.org/project/tik…

比如在Coze的调试页面中就也有相关的指标

评测框架

DeepEval是什么

DeepEval（www.confident-ai.com/blog/deepev… 是一个用于Python的开源评估框架，方便日常构建和迭代LLM应用，它类似于pytest的，可以用于专门的ALM单元测试的输出，同时他具备开箱即用的LLM评估和经典的评估指标。

下面是他们官方提供的原理图，说明了针对大模型的评估是如何实现的。主要原理其实是通过针对特定的输入判断其输出的稳定性以及相关的相关性等等一些经典的评估指标，当然你也可以创建自己自定义的一些评估标准。

一些使用样例，使用方式比较简单：

1
2
3
4
5
6
7
8
9

TypeScript复制代码from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import SummarizationMetric

test_case = LLMTestCase(
  input="the original text...", 
  actual_output="the summary...")
summarization_metric = SummarizationMetric()
evaluate([test_case], [summarization_metric])

Promptfoo

github.com/promptfoo/p…

由javascript开发的离线评估工具，对前端较为友好，可以批量判断不同的prompt的表现，也可以横向对比不同的大模型表现。

Awesome-LLM-Eval

是一个列有各种LLM评估工具的目录 github.com/onejune2018…

Azure AI Studio(Microsoft)

learn.microsoft.com/zh-cn/azure…

微软提供的云端评估平台

LangKit

LangKit: An open-source toolkit for monitoring Large Language Models (LLMs). 📚 Extracts signals from prompts & responses, ensuring safety & security. 🛡️ Features include text quality, relevance metrics, & sentiment analysis. 📊 A comprehensive tool for LLM observability. 👀

由WhyLabs平台开源的github.com/whylabs/lan…

DeepCheck

github.com/deepchecks/…, 快速全面的评估机器学习模型性能，并反馈模型存在的问题

参考资料

LLM评估：通过7大指标监测并评估大语言模型的表现_程序员_Baihai IDP_InfoQ写作社区

whylabs.ai/ 大模型检测和评估平台

评估指标汇总 大语言模型（LLM）评价指标小汇总（也许会更新）

如何评估大语言模型(LLM)的质量——框架、方法、指标和基准-51CTO.COM

qizhang.info/slides/llme…

www.analyticsvidhya.com/blog/2023/0…

www.linkedin.com

juejin.cn/post/731770…

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

RAG是目前最流行的补充生成式人工智能模型的方式，最近 RAG 的开创者提出了新的上下文语言模型 (CLM) ，他们称之为“ RAG 2.0 ”。

今天让我们一块来从RAG目前的原理和缺点出发，看看他们所提出的RAG2.0是否能够为行业带来新的希望。

LLM的时间有效性

您应该知道，所有独立的大型语言模型 (LLM)（例如 ChatGPT 等）都有知识截止点。

这意味着预训练是一次性的练习（与持续学习方法不同）。换句话说，LLM 掌握的数据是在某个时间点之前的。

例如，在写文章时，ChatGPT 更新至 2023 年 4 月。因此，他们不准备回答该日期之后发生的事实和事件。

而这就是 RAG 发挥作用的地方。

语义相似性

顾名思义，这个想法是从已知的数据库中检索数据，这些数据是LLM以前从未见过的数据，并将其实时输入到模型中，以便它已经更新，在语义上相关的上下文来提供准确的答案。

但这个检索过程是如何进行的呢？

整个架构源于一个原则：检索与请求或 prompt 上下文相关的语义有意义的数据的能力。

这个过程涉及到三个元素的使用：

1. embedding 模型
2. 检索器，通常是矢量数据库
3. 还有生成器，LLM

首先也是最重要的，为了使此检索过程正常进行，您需要对数据进行 embedding ，即数字向量化。

更重要的是，这些嵌入具有相似性原则：相似的概念将具有相似的向量。

完成embedding后，我们将它们插入向量数据库（检索器）。

应用相似性原则

然后，每当用户发送如下请求*“给我与‘黄猫’类似的结果”时，*矢量数据库就会执行“语义查询”。

通俗地说，它提取与用户查询最接近的向量（距离）。

由于这些向量代表基本概念，因此相似的向量将代表相似的概念，在本例中是其他猫。

一旦我们提取了内容，我们就构建 LLM prompt，封装包括：

• 用户的请求
• 提取的内容
• 一般来说，还有一组系统指令

简而言之，这就是 RAG，一个为用户实时查询提供相关内容以增强 LLM 响应的系统。

RAG 系统之所以起作用，首先要归功于LLM的最大超能力：上下文学习，它允许模型使用以前未见过的数据来执行准确的预测，而无需权重训练。

但这个过程听起来好得令人难以置信，当然，事情并不像看起来那么令人惊奇。

RAG的问题：缝合怪

前 RAG 系统做一个形象的比喻，就是下面的裤子：

尽管这些裤子可能适合某些观众，但大多数人永远不会穿它们，因为没有统一性，尽管打补丁的初衷是希望让人接受。

这种类比背后的原因是，标准 RAG 系统组装了三个不同的组件，这些组件分别经过预先训练，并且根据定义，它们从来不应该组合在一起。

而在RAG 2.0系统中从一开始就被定义为“一件事”。

RAG2.0

我们将上下文语言模型 (CLM) 与跨多个轴的冻结 RAG 系统进行了比较：

• 开放域问答： 我们使用规范的自然问题（NQ）和TriviaQA数据集来测试每个模型正确检索相关知识并准确生成答案的能力。我们还在单步检索设置中评估 HotpotQA (HPQA) 数据集上的模型。所有数据集都使用完全匹配 (EM) 指标。
• 忠实性： HaluEvalQA 和 TruthfulQA 用于衡量每个模型保持基于检索到的证据和幻觉的能力。
• 新鲜度： 我们使用网络搜索索引来衡量每个 RAG 系统泛化到快速变化的世界知识的能力，并在最近的 FreshQA 基准测试中显示准确性。

RAG 2.0的核心创新在于它的端到端优化设计，将语言模型和检索器视为一个整体进行训练和微调。这种设计不仅提高了模型在特定任务上的准确性，也提升了其适应新问题的能力，使其在多项标准测试中达到了前所未有的性能水平。

与传统的 RAG 系统相比，RAG 2.0能够更有效地处理知识密集型任务，因为它不受训练期间接触资料的限制。通过动态检索外部资料，如Wikipedia、Google或内部公司文件，RAG 2.0能够获取并利用最新、最相关的信息来增强其回答的准确度和可靠性。

在实践中，整个系统在连接时进行端到端训练，就像假设LLM应该始终有一个与之绑定的矢量数据库以保持更新。

这意味着，在反向传播过程中，训练这些模型的算法，梯度不仅通过整个 LLM 传播，而且还通过检索器传播，以便整个系统作为一个整体从训练中学习数据。

结果也证明了这一点：

尽管使用的独立模型肯定比 GPT-4 差，但这种新方法的性能优于 GPT-4 和其他检索系统之间所有其他的 RAG 1.0 组合。

原因很简单：在 RAG 1.0 中，我们单独训练事物，然后将它们缝合在一起，并希望得到最好的结果。但在 RAG 2.0 中，情况大不相同，因为所有组件从一开始就在一起。

但尽管 RAG 2.0 的优势显而易见，但仍然存在一个大问题。

RAG的未来面临挑战

尽管 RAG 2.0 看起来似乎带来了巨大的好处**，因为它的设计专门针对不愿意与 LLM 提供商共享机密数据的公司，但现实中它的落地面临巨大挑战。**

超长上下文

我相信您非常清楚这样一个事实，即我们今天的前沿模型，例如 Gemini 1.5 或 Claude 3 等模型，拥有巨大的上下文窗口，在其生产发布的模型中多达 100 万个token（75 万个单词），而在实验室中更是达到了1000万token（750 万个单词） 。

通俗地说，这意味着这些模型可以在每个提示中输入非常长的文本序列。

作为参考，《指环王》书籍总共有 576,459 个单词，而《哈利·波特》的整本书传奇大约有 1,084,170 个单词。因此，一个 750 万字的上下文窗口可以在每个提示中将两个故事组合在一起，五倍。

在这种情况下，我们真的需要一个知识库检索器，而不是仅仅在每个prompt中提供信息

放弃此选项的原因之一可能是准确性。序列越长，模型检索正确的上下文就越困难，对吗？

另一方面，RAG 过程允许仅选择语义相关的数据，而不是在每个 prompt 中提供整个上下文，从而使其整体上成为一个更高效的过程。

然而，的研究正在超长上下文中，LLM的工作也显示出几乎 100% 的准确性。

这些模型无论长度如何都能表现出惊人性能的背后的技术支持是，这些模型的基本操作符——注意力机制——具有绝对的全局上下文，因为注意力机制迫使序列中的每一个单独的令牌（也就是一个单词或子词）去关注序列中每一个其他的之前的单词。

这确保了无论依赖关系有多远，无论信号有多小（关键信息可能存储在一个距离数百万单词的单个单词中），模型应该能够——而且确实能够——检测到它。

因此，在我看来，RAG 最终能否生存并不取决于准确性，而是取决于技术之外的另一个关键因素：

成本。

需要商业落地来验证

如今，由于 Transformer 无法压缩上下文，较长的序列不仅意味着成本的二次增加（序列增加 2 倍意味着计算成本增加 4 倍，或者增加 3 倍意味着计算成本增加 9 倍），而且还意味着由于KV Cache大小的增加而爆炸。简而言之，运行很长的序列是非常昂贵的。

KV缓存是模型的“缓存内存”，避免不得不重新计算大量冗余的注意力数据，否则这个过程在经济上是不可行的。这里是关于KV缓存是什么以及它如何工作的深入回顾。

简而言之，运行非常长的序列是非常昂贵的，以至于对于具有极长序列长度的模态，如DNA，甚至不考虑使用Transformer。

事实上，在像EVO这样的DNA模型中，研究人员使用了海纳（Hyena）操作符而不是注意力来避免前面提到的二次方关系。海纳操作符使用长卷积而不是注意力来以次二次方的成本捕捉长距离依赖。

本质上，虽然你在时间域中计算卷积，但你是作为频率域中的逐点乘积来计算它，这更快、更便宜。其他替代方案寻求一种混合方法，而不是完全放弃注意力，而是找到注意力和其他操作符之间的最佳平衡点，以在保持性能的同时降低成本。

总结

最近的示例包括Jamba，它巧妙地将Transformer与其他更高效的架构（如Mamba）混合在一起。

Mamba、Hyena、Attention……你可能认为我只是为了证明一个观点而随意列举一些花哨的词汇。

所有这些名字背后都归结为同一个原则：它们是揭示语言模式的不同方式，帮助我们的AI模型理解文本。

注意力机制驱动了当今99%的模型，其余的只是在尝试找到尽可能最小的性能降低的更便宜的方式，使大型语言模型（LLM）更加经济。

总而言之，我们很快就能看到极长序列的处理成本仅为目前价格的一小部分，这应该会增加对RAG架构需求的怀疑。

如果RAG可以成为平衡成本的一个好方案，那么未来应该会有更好的发展。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

接下来我将持续更新“深度解读《深度探索C++对象模型》”系列，敬请期待，欢迎关注！也可以关注公众号：iShare爱分享，自动获得推文和全部的文章列表。

第一篇请从这里阅读：
深度解读《深度探索C++对象模型》之C++虚函数实现分析（一）

这一篇主要讲解多重继承情况下的虚函数实现分析。

在多重继承下支持虚函数，主要体现在对第二及其后继的基类的处理上，下面我们以一个具体的例子来讲解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

c++复制代码#include <cstdio>
class Base1 {
public:
    virtual ~Base1() = default;
    virtual void virtual_func1() { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual void virtual_func2() { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual Base1* clone() { return new Base1; }
    int b1 = 0;
};
class Base2 {
public:
    virtual ~Base2() = default;
    virtual void virtual_func3() { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual void virtual_func4() { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual Base2* clone() { return new Base2; }
    int b2 = 0;
 };
class Derived: public Base1, public Base2 {
public:
    virtual ~Derived() = default;
    void virtual_func1() override { printf("%s\n", __PRETTY_FUNCTION__); }
    void virtual_func3() override { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual void virtual_func5()  { printf("%s\n", __PRETTY_FUNCTION__); }
    virtual Derived* clone() override { return new Derived; }
    int d = 0;
};

int main() {
    Derived* pd = new Derived;
    pd->virtual_func1();
    pd->virtual_func2();
    pd->virtual_func3();
    pd->virtual_func4();
    Base1* pb1 = pd;
    pb1->virtual_func1();
    pb1->virtual_func2();
    Base2* pb2 = pd;
    Base2* pb = pb2->clone();
    pb->virtual_func3();
    pb->virtual_func4();
    delete pd;
    delete pb;
    return 0;
}

多重继承下围绕第二及后继的基类的问题主要表现在虚函数表的处理、this指针的调整，虚析构函数的调用，下面将一一展开来分析。

多重继承下虚函数表的问题

每个类主要有虚函数，编译器将会为这个类生成虚函数表，子类会继承基类的虚函数表，这是我们已经知道的事情。但是在多重继承下，将会有两个以上的基类，那么子类将会继承到多个虚函数表，如果多重继承中，有N个基类有虚函数表，子类中也将会有N个虚函数表。编译器将如何处理这种情况？不同的编译器可能有不同的处理方式，Clang和Gcc编译器是将多个虚函数表合并在一起，每个子表仍然是包含RTTI信息和子对象的虚函数地址，具体看一下实际汇编代码中的虚函数表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

text复制代码vtable for Derived:
    .quad   0
    .quad   typeinfo for Derived
    .quad   Derived::~Derived() [base object destructor]
    .quad   Derived::~Derived() [deleting destructor]
    .quad   Derived::virtual_func1()
    .quad   Base1::virtual_func2()
    .quad   Derived::clone()
    .quad   Derived::virtual_func3()
    .quad   Derived::virtual_func5()
    .quad   -16
    .quad   typeinfo for Derived
    .quad   non-virtual thunk to Derived::~Derived() [complete object destructor]
    .quad   non-virtual thunk to Derived::~Derived() [deleting destructor]
    .quad   non-virtual thunk to Derived::virtual_func3()
    .quad   Base2::virtual_func4()
    .quad   covariant return thunk to Derived::clone()

Base1类和Base2类的虚函数表跟普通情况下的一样，就不贴出来了。上面表中的第2到第10行是Base1子对象的虚函数表，它和Derived类的对象共用同一个，称为主表，第11到第17行是Base2子对象的虚函数表，也称为次表。对应有两个虚函数表指针，一个是在对象的起始地址（也是Base1子对象的起始地址），另一个是在Base2子对象的起始地址（对象首地址加上大小为Base1子对象大小的偏移量）。这两个虚函数表指针是在对象构造时，在构造函数中由编译器生成的汇编代码设置的，Base1子对象的虚函数表指针被设置为指向表中第4行的第一个虚函数的位置，Base2子对象的虚函数表指针被设置为指向表中第13行次表的第一个虚函数的位置，具体的代码就不分析了，详见另一篇《深度解读《深度探索C++对象模型》之默认构造函数》。

继续分析上面虚函数表的内容，表中有两个析构函数，第一个是完整的析构函数，完成主要的析构动作，用于局部对象、临时对象等释放时被调用，第二个析构函数是给在堆空间中申请的对象释放时调用的，也就是用new函数申请的内存空间，在这个析构函数里会先调用第一个析构函数，然后再调用delete函数释放申请的内存空间。主表中有两个（第4、5行），次表也有两个（第13、14行），次表中的两个最终也是调用主表中的析构函数，这里涉及到thunk技术，稍后再细讲。

主表继承了Base1基类的虚函数表，按顺序是虚析构函数、virtual_func1、virtual_func2和clone函数，其中只有virtual_func2没有改写，直接拷贝了基类的虚函数的地址，之后virtual_func3和virtual_func5是Derived子类新增的虚函数，virtual_func3虽然是对Base2基类中的虚函数的改写，但对于Base1基类来说相当于是新增的，它和Base2子对象中virtual_func3是共用一个函数，在稍后详细讲解。

判定一个虚函数是否被改写的规则是函数名称、参数个数和类型以及返回类型都必须相同，但有两个例外的地方，第一个是虚析构函数，只要基类中定义了虚析构函数，子类就一定继承了虚析构函数，即使代码中没有定义，编译器也会为它生成一个，而且名称也不要求相同，当然也不可能相同。第二个是类似上面的clone函数，在基类中返回类型是基类类型，在派生类中返回的是派生类的类型时，规则允许例外，它也会被当做是重写。

用派生类指针调用第二及后继基类的虚函数

通过派生类指针调用第二及后继基类中一个继承而来的虚函数，主要的工作在于调整this指针，如C++代码中使用Derived类型的指针pd调用virtual_func4虚函数，virtual_func4是Base2基类定义的虚函数，Derived类没有改写它，直接继承它的实现，因此它只存在于Base2子对象的虚函数表中，调用virtual_func4函数，需要把this指针调整到Base2子对象的起始位置，它和Derived对象的起始地址相差Base1子对象的大小，汇编代码中调用virtual_func4函数的实现：

1
2
3
4
5

text复制代码mov     rax, qword ptr [rbp - 16]
mov     rdi, rax
add     rdi, 16
mov     rax, qword ptr [rax + 16]
call    qword ptr [rax + 24]

[rbp - 16]是存放Derived对象的起始地址，把它加载到rdi寄存器后再加上16的偏移量（第2、3行），16就是Base1子对象的大小，偏移后还是保存在rdi寄存器，rdi寄存器作为第5行调用函数时的参数，也即是this指针，这时它是指向Base2子对象，第4行中的[rax + 16]是将Derived对象的起始地址加上16的偏移量，也就是指向Base2子对象的起始地址，这里保存着指向Base2子对象的虚函数表的指针，对其取值后就是Base2子对象的虚函数表的起始地址，在第5行的调用中，[rax + 24]就是在虚函数表的起始地址偏移24，相当于跳过3个虚函数（每个虚函数的地址占用8字节），也就是上面虚函数表中的第16行virtual_func4函数（请参考上表），对其取值即virtual_func4虚函数的地址，然后调用之。

用第二及后继基类的指针调用派生类的虚函数

通过第二及后继基类的指针调用派生类中的虚函数，主要围绕在几方面上：派生类Derived类改写的Base2基类的虚函数如virtual_func3虚函数，调用clone函数的问题，虚析构函数的问题。

通过第二基类如Base2基类的指针调用virtual_func3函数的问题体现在：因为Derived类中对virtual_func3虚函数进行改写，所以virtual_func3也被添加到Base1子对象的虚函数表中（相当于新增函数），同时它也是对继承自Base2基类的virtual_func3虚函数的改写，所以它也必然存在于Base2子对象的虚函数表中，因此在两个表格中占了两个条目，但实际的函数实例只有一个。在Base1子对象的虚函数表中存放的是真实的virtual_func3虚函数的地址，而在Base2子对象的虚函数表中存放的是一个辅助函数的地址，这个辅助函数是由编译器实现的，就是一段汇编代码，主要的工作就是去调整this指针，调整后再去调用真正的virtual_func3函数，这就是thunk技术。来看看汇编代码中的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13

text复制代码# pb->virtual_func3();
mov     rdi, qword ptr [rbp - 40]
mov     rax, qword ptr [rdi]
call    qword ptr [rax + 16]

non-virtual thunk to Derived::virtual_func3():     # @non-virtual thunk to Derived::virtual_func3()
    push    rbp
    mov     rbp, rsp
    mov     qword ptr [rbp - 8], rdi
    mov     rdi, qword ptr [rbp - 8]
    add     rdi, -16
    pop     rbp
    jmp     Derived::virtual_func3()    # TAILCALL

上面几行的汇编代码是通过Base2类型的指针调用virtual_func3函数，做法就是通过Base2子对象的虚函数表找到virtual_func3虚函数的地址然后调用它，但是这里的virtual_func3的地址不是真实的virtual_func3函数实例的地址，而是我们上面分析的辅助函数，即thunk技术，是编译器实现的一段汇编代码。在这汇编代码里，首先将参数rdi寄存器（保存着Base2子对象的地址，即Base2子对象的this指针）取出来保存到栈空间[rbp - 8]中，然后减去16的偏移量，16是Base1子对象的大小，也就是调整到Derived类对象的起始的地址，然后保存到rdi寄存器作为调用virtual_func3函数的参数，最后跳转到真正的virtual_func3函数去执行（第13行）。

对clone函数的调用也存在同样的问题，clone函数在Base1基类和Base2基类中都有定义，在Derived类中进行改写，因此在Base1子对象和Base2子对象的虚函数表中都各自占了一个条目，主表中存放的是真正的clone函数的实现，次表中存放的是thunk技术实现的辅助函数，但它比对virtual_func3函数的调用要更复杂一些。看一下这段汇编代码的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

text复制代码# Base2* pb = pb2->clone();
mov     rdi, qword ptr [rbp - 32]
mov     rax, qword ptr [rdi]
call    qword ptr [rax + 32]
mov     qword ptr [rbp - 40], rax

covariant return thunk to Derived::clone():	# @covariant return thunk to Derived::clone()
    # 略...
    add     rdi, -16
    call    Derived::clone()
    mov     qword ptr [rbp - 16], rax       # 8-byte Spill
    cmp     rax, 0
    je      .LBB13_2
    mov     rax, qword ptr [rbp - 16]       # 8-byte Reload
    add     rax, 16
    mov     qword ptr [rbp - 24], rax       # 8-byte Spill
    jmp     .LBB13_3
.LBB13_2:
    # 略...
.LBB13_3:
    # 略...

上面汇编代码的前面几行是调用虚函数的常规做法，只不过这时调用到的是下面这个thunk技术实现的clone函数。它比调用virtual_func3函数麻烦的地方在于，在调用真正的clone函数之前要先调整this指针，即上面汇编代码的第9行，这时将this指针调整为指向Derived对象的起始地址，然后调用真正的clone函数（第10行）。调用完clone函数之后还得再调整一次this指针，因为clone函数返回的是Derived对象的起始地址，我们要把它赋值给Base2类型的指针，所以要把this指针调整到指向Base2子对象的起始地址，不然通过它返回的指针（即pb指针）调用函数或者存取数据成员时将引起错误，首先判断返回的指针是否为0（第12行），不为0的话就加上16的偏移量（第15行），即指向Base2子对象，然后返回。

虚析构函数的问题和实现手法跟上面两种情况类似，同样存在两种类型的虚析构函数，一个为真正的实例，一个是thunk技术实现的。有两种调用到虚析构函数的情况，第一种是new出来的Derived对象赋值给Base1类型的指针，最后再通过Base1类型的指针delete掉，如：

Base1* pb1 = new Derived;

…

delete pd1;

这种情况下跟直接使用Derived类型的指针是一样的，因为Base1子对象的起始地址和Derived对象的起始地址是对齐的，不需要调整this指针，这时将调用的是Base1子对象的虚函数表中真正的析构函数，完成析构动作。

第二种情况是通过Base2类型的指针来操作，如：

Base2* pb2 = new Derived;

…

delete pb2;

这时因为Base2子对象和Derived的起始地址不对齐，需要调整this指针，所以这时先调用thunk技术实现的析构函数，在析构函数里完成this指针调整后再调用真正的析构函数，下面是汇编代码：

1
2
3
4
5
6
7
8

text复制代码non-virtual thunk to Derived::~Derived() [deleting destructor]:	# @non-virtual thunk to Derived::~Derived() [deleting destructor]
    push    rbp
    mov     rbp, rsp
    mov     qword ptr [rbp - 8], rdi
    mov     rdi, qword ptr [rbp - 8]
    add     rdi, -16
    pop     rbp
    jmp     Derived::~Derived() [deleting destructor]

代码的意思跟上面的汇编代码差不多，就不详细解释了。

为什么多态时需要虚析构函数

最后来谈谈在多态时为什么需要将析构函数声明为虚函数。假如在上面的例子中，我们没有将析构函数声明为虚函数，那么析构函数将没有多态的行为。当Base2类型的指针指向一个Derived对象时，这时通过Base2类型的指针来释放对象，调用的将是Base2类的析构函数，它将只会释放掉Base2子对象部分的内存，这将会引起程序的崩溃，因为申请的内存的起始地址是Derived对象开始的，释放时是从Base2子对象开始的，会造成不对齐的问题而引起运行崩溃。

是否在多重继承下才会有这样的问题？其实不然，在单一继承下也会存在问题，虽然在单一继承下，对象中的父类的子对象和对象的起始地址是对齐的，释放内存不会造成程序崩溃，但是这时调用的是父类的析构函数而不是子类的析构函数，这将导致派生类真正想要的析构动作将不会被执行到，例如本来要在析构函数中释放资源的动作将没有被执行，将导致资源的泄露，如在构造函数中申请的内存等。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

1. 友盟+介绍

友盟+ 以“数据智能，驱动业务增长”为使命，为移动应用开发者和企业提供包括统计分析、性能监测、消息推送、智能认证等一站式解决方案。截止 2023 年 6 月，已累计为 270 万移动应用和 980 万家网站，提供十余年的专业数据服务。

作为国内最大的移动应用统计服务商，其统计分析产品 U-App & U-Mini & U-Web 为开发者提供基础报表及自定义用户行为分析服务，能够帮助开发者更好地理解用户需求，优化产品功能，提升用户体验，助力业务增长。

为了满足产品、运营等多业务角色对数据不同视角的分析需求，统计分析 U-App 提供了包括用户分析、页面路径、卸载分析在内的多种「开箱即用」的预置报表，集成 SDK 上报数据后即可查看这些指标。除此以外，为了满足个性化的分析诉求，业务也可以自定义报表的计算规则，提供了事件细分、漏斗分析、留存分析等用户行为分析模型，用户可以根据自己的分析需求灵活地选择时间范围、设置事件名称、where 筛选和 Groupby 分组等。

如上所述，U-App 服务了众多应用场景，每天处理接近千亿条日志，需要考虑平衡好数据新鲜度、查询延迟和成本的关系，同时保障系统的稳定性，这对数据架构和技术选型提出了极高的要求。

针对报表类型不同的看数场景和业务需求，我们底层技术架构通过多种产品来支撑。在数据新鲜度方面，分别是提供了 T+0 的实时计算 和 T+1的离线批量计算，主要支持预置报表的计算场景，并将计算好的结果导出到存储，能够支持高并发的报表查询。在分析时效性方面，实现自定义报表支持秒级的 OLAP 分析，但鉴于成本和稳定性考虑，对于大数据量和大跨度的时间查询会走离线触发式计算。

在本文中，我们会分享友盟+ U-App 整体的技术架构，以及在实时和离线计算上面的优化方案

2. 友盟+数据架构及现状

如下图所示，在大数据领域这是一个比较通用的数据处理 pipeline，贯穿数据的加工&使用过程包括，数据采集&接入、数据清洗&传输、数据建模&存储、数据计算&分析 以及 查询&可视化，其中友盟U-App 数据处理的核心架构是红框部分。

U-App 整体架构大体可以分为四层：数据服务、数据计算、数据存储以及核心组件

● 数据服务：将查询 DSL 解析为底层引擎执行的 DAG，同时智能采样、查询排队等来尽可能减少系统过载情况，保证查询顺滑

● **数据计算：**根据不同分析场景抽象沉淀了自定义分析模型，包括行为分析和画像分析两大类；并且提供预置的基础统计指标的计算

● **数据存储：**使用了以 User-Event 为核心的数据模型，提供基于明细数据的行为分析

● **核心组件：**离线批量计算使用 MaxCompute，流式计算使用阿里云上实时计算 Flink，OLAP 计算使用 Hologres

3. 基于Flink + Paimon的流式湖仓使用实践

本节首先将介绍Apache Paimon主要优势，然后介绍基于Paimon在U-App实时基础指标计算和友盟设备ID维表更新场景的优化方案

3.1 Apache Paimon简介

3.1.1 概览

Apache Paimon 是一项流式数据湖存储技术，可以为用户提供高吞吐、低延迟的数据摄入、流式订阅以及实时查询能力。通俗解释即 Paimon 是一个流批一体的湖存储格式，它不是一个服务只是一个格式一个Jar包, 数据存储在的 OSS 或者 HDFS 上。可以使用 Flink CDC 来一键入湖到 Paimon 中，也可以通过 Flink SQL 或 Spark SQL 来批写、流写到 Paimon 当中。Paimon 也支持主流开源引擎，包括几乎现在所有的开源引擎。Paimon 也可以被 Flink 或 Spark 流读，这也是它作为流式数据湖的特有能力之一。

3.1.2 典型应用场景

● CDC 更新入湖，可被准实时查询(1-5min)，并大幅简化入湖架构

● 支持 Partial-Update 能力，基于相同的主键可以各个流实时地打宽，另外支持多种聚合引擎( Deduplicate、Aggregation 等)，在 Paimon 当中能被分钟级给下游各种计算引擎查询

● 支持流入的数据生成变更日志 changelog，给下游更好的流计算，即支持流读

● Paimon 作为湖存储格式，有很强的 Append 处理，并给 Append 表上多了流读流写、排序后加速查询的能力

3.2 U-App实时基础指标计算

3.2.1 产品模块介绍

友盟基础指标分为实时和离线指标两类，分别对应实时和离线两条计算链路，通过计算新增、活跃和启动等基础指标为客户提供整体概览数据

3.2.2 计算架构

（TT–阿里巴巴集团内部 datahub）（OTS–阿里巴巴集团内部 TableStore 表存储服务）

上述计算链路即传统的 lambda 架构，数据经过预处理后写入消息队列，离线链路同步消息队列数据到离线数仓进行加工处理将计算结果同步到 OTS (类 Hbase 存储)中；实时链路通过 Flink 直接消费消息队列的数据聚合成统计指标后写入 OTS，查询服务将离线和实时两份指标进行统一展示如上图所示。传统 lambda 架构的优缺点如下:

(1) 优点

● 任务容错性比较高

针对早期实时链路不稳定的特点，每天凌晨通过离线批处理计算结果覆盖实时计算结果的方式，保证T+1的离线数据的准确性。对于数据订正的场景可以通过回溯离线数据完成数据的订正；

● 职责边界划分清晰

实时链路只负责增量数据的计算，数据时效性比较高; 离线批处理链路计算全量历史数据，两条链路职责划分比较明确互相不影响，支持灵活的单独对每条链路进行扩展。

(2) 缺点

● 同时维护实时和离线两套计算逻辑，存储和计算都造成一定的浪费

实时和离线的计算逻辑是相同的，实时链路只计算当天的结果，第二天凌晨再用离线计算去覆盖实时计算结果，带来的问题就是一天的数据实时和离线重复计算，带来资源成本的浪费；

● 两套计算链路开发运维成本比较高，并且涉及实时和链路的数据口径会不一致等问题

两条链路必然带来运维成本的增加，对于友盟来说实时和离线任务还是分两个团队在维护。另外因为实时指标每天凌晨会被覆盖，可能会出现指标不一致的结果，给客户带来困扰；

实时链接直接基于TT的明细数据进行聚合数据不可查，给排查问题带来困难；

● 对于 U-App 数据量大的特性，基于 Flink 计算实时聚合指标会存在 State 大，实时任务稳定性差的问题

U-App 启动日志每天是千亿级数据量，直接基于明细数据通过 Flink 进行实时聚合，造成Flink任务的state比较大，另外上游任务稍微有波动就会对下游计算造成比较大的影响，对任务的稳定性要求比较高，所以我们现在采用的方案是拿资源换稳定，任务资源的 buffer 给的比较足，缺点就是造成一定资源的浪费。

3.2.3 基于阿里云 Flink + Paimon 的优化方案

针对上述提到的痛点问题，使用 Paimon 自带的聚合引擎能力，将指标的聚合下沉到 Paimon 表中实现，从而统计实时和离线计算链路

（TT–阿里巴巴集团内部 datahub）（OTS–阿里巴巴集团内部 TableStore 表存储服务）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

js复制代码CREATE TABLE paimon-ump .default.dwd_ump_app_install_paimon_table (
app_key       STRING,
umid         STRING,
 cli_datetime     BIGINT, 
 launch_time  BIGINT,
 launch_flag  INT,
 new_install_umid  STRING,
 new_install_flag   INT,
 app_channel     STRING,
 country    STRING,
 province_name    STRING,
 city_name      STRING,
 puid         STRING,
 device_brand     STRING,
 device_model     STRING,
 os          STRING,
 os_version      STRING,
 sdk_version     STRING,
 app_version     STRING,
 inst_datetime    STRING,
 inst_channel     STRING,
 inst_app_version   STRING,
 terminate_duration DOUBLE,
 resolution   STRING,
 access STRING,
 carrier STRING,
 server_datetime     BIGINT,  
 upload_traffic     DOUBLE,
 download_traffic    DOUBLE,
 app_upgrade INT, 
 hh   STRING,
 ds   STRING
) PARTITIONED BY (ds)
WITH (
 'metastore.partitioned-table' = 'true',
 'maxcompute.life-cycle' = '360',
 'bucket' = '-1',
 'sink.parallelism' = '64',
 'consumer.expiration-time' = '86400 s',
 'snapshot.expire.limit' = '100',
 'consumer.ignore-progress' = 'true'
);

由于 Paimon 的聚合引擎不支持去重，所以设计 DWM 层实现去重逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

js复制代码CREATE TABLE `paimon-ump`.`default`.`dwm_ump_app_install_paimon_table` (
  app_key           STRING,
  dimSTRING,
  granularitySTRING,
  distinct_idSTRING,
  dsSTRING,
  PRIMARY KEY (ds, app_key, dim, granularity, distinct_id) NOT ENFORCED
)PARTITIONED BY (ds) 
WITH (
  'metastore.partitioned-table' = 'true',
  'merge-engine'='first-row',
  'first-row.ignore-delete'='true'
  'changelog-producer' = 'lookup',
  'maxcompute.life-cycle' = '360',
  'bucket' = '512',
  'sink.parallelism' = '128',
  'consumer.expiration-time' = '86400 s',
  'snapshot.expire.limit' = '100',
  'consumer.ignore-progress' = 'true'
);
CREATE TABLE `paimon-ump`.`default`.`dws_ump_app_install_paimon_table` (
  app_key           STRING,
  dimSTRING,
  granularitySTRING,
  `value`DOUBLE,
  dsSTRING,
  PRIMARY KEY (ds, app_key, dim, granularity) NOT ENFORCED
)PARTITIONED BY (ds) 
WITH (
  'merge-engine'='aggregation',
  'metastore.partitioned-table' = 'true',
  'changelog-producer' = 'lookup',
  'changelog-producer.lookup-wait' = 'false',
  'maxcompute.life-cycle' = '360',
  'bucket' = '16',
  'sink.parallelism' = '16',
  'fields.value.aggregate-function' = 'sum',
  'consumer.expiration-time' = '86400 s',
  'snapshot.expire.limit' = '100',
  'consumer.ignore-progress' = 'true'
);

该方案带来的收益如下：

● 计算资源成本的节省

在实时基础指标计算场景下，在相同34实时个指标下，用 Paimon 替换 Flink 纯实时计算，计算资源方面可以来了 28% 的资源节省；

在离线指标计算场景下，Paimon 可以直接将离线计算链路任务替换掉不再需要，极大节省离线链路的计算和存储成本；

● 开发运维效率的提升

后续任务的开发和运维不再需要区分实时和离线两条链路，只需要开发维护一套代码逻辑即可，也不存在数据口径不一致等问题，极大的提高开发和运维效率；

数据可查，之前直接基于消息队列(TT)的数据不可直接查询，需要同步到离线或其他存储才可以，导致排查问题效率比较低，基于 Paimon 的表可以直接查询，极大提供问题排查和定位的效率；

同时 Paimon 表支持批读批写，支持数据的订正和回溯；

● 计算链路架构的统一

随着实时和批处理技术的发展，早期的 lambda 架构的缺点在当前业务场景下被逐渐放大变得越来越显著。通过 Paimon + Flink 构建的流式湖仓统一了实时和批处理链路架构，后续不需要再维护两套计算链路，降低了整个计算链路的复杂性。

3.3 U-App 设备 ID 维表的更新

3.3.1 使用场景

目前设备属性表包含两部分内容，一部分是设备相关的属性信息；同时还包括该设备对应的账号的用户属性。现在设备属性维表主要在各种分析模型管理用户属性、人群的用户列表和个体细查等模块。

3.3.2 计算架构

目前友盟设备属性维表的实现方案如上图所示，采用全量+增量的实现方式，这套架构的缺点如下：

● 时延高

目前这套逻辑都是在离线实现的，至少 T + 1 延时，而且需要等全量和增量合并完成后(任务运行2-3小时)下游任务才能使用，数据时效性比较差，用户无法看到当天设置的设备及用户属性信息;

● 存储计算成本高

每天需要读取全量数据(百亿级)，与增量数据进行全量合并，在全量数据特别大，增量数据不多时任务计算成本加高，并且带来资源的浪费;

每天全量表一个分区存储所有数据，在增量数据不多的场景下，意味全量分区存在大量的重复数据，造成存储资源的浪费;

● 架构链路复杂度高

由于设备属性表中带有该设备关联的用户属性信息，加之这种全量和增加合并的实现方式导致链路复杂，导致每天产出全量分区容易有问题导致不能按时产出，新增业务也比较复杂，全量和增量割裂。

3.3.3 基于阿里云Flink + Paimon的解决方案

该方案使用 Paimon 的核心能力:主键更新能力，使用 Paimon Partial Update 引擎的能力，将整理计算链路的时效性从之前的 T+1 降低到分钟级。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

js复制代码CREATE TABLE paimon-ump.default.dim_ump_umid_paimon_table (
 app_key     STRING,
 umid      STRING,
 cli_datetime  BIGINT,
 app_channel   STRING,
 province_name  STRING,
 city_name    STRING,
 idfa      STRING,
 imei      STRING,
 oaid      STRING,
 puid      STRING,
 zid       STRING,
 device_brand  STRING,
 device_model  STRING,
 os       STRING,
 os_version   STRING,
 app_version   STRING,
 inst_datetime  STRING,
 inst_channel  STRING,
 inst_app_version STRING,
 active_ds    STRING,
 mobile     STRING,
 email        STRING,
 custom_properties  STRING,
 PRIMARY KEY(app_key,umid) NOT ENFORCED
) COMMENT 'paimon设备属性表'
WITH (
 'merge-engine'='partial-update',
 'metastore.partitioned-table' = 'false',
 'changelog-producer' = 'lookup',
 'partial-update.ignore-delete' = 'true',
 'maxcompute.life-cycle' = '7',
 'bucket' = '64',
 'tag.automatic-creation' = 'process-time',
 'tag.creation-period' = 'daily',
 'tag.creation-delay' = '10 m',
 'tag.num-retained-max' = '7',
 'sink.parallelism' = '64',
 'num-sorted-run.stop-trigger' = '2147483647',
 'sort-spill-threshold' = '10',
 'changelog-producer.lookup-wait' = 'false',
 'sequence.field' = 'cli_datetime'  
);

该方案带来的收益如下:

● 提高数据时效性降低时延

该方案将整个计算链路的时效性从T+1降低到 分钟级，用户当天设置的属性信息当天就可以使用进行分析使用，助力提升业务价值；

● 降低存储计算成本高

得益于Paimon的 Snapshot 管理，加上 LSM 的文件复用，比如同样是存储 100天的快照，原有离线数仓 100 天需要 100 份的存储，其中在增量数据不多的场景下大部分数据都是重复的，但是Paimon只需要 1 份的存储，大幅节省存储资源；

得益于 LSM 的增量合并能力，此条链路只有增量数据的处理，没有全量的合并；

● 简化计算链路架构复杂度

简化了之前的全量和增量计算链路，只需要维护一个Flink任务就可以实现全增量合并的目的，提升开发运维效率。

4. 总结展望

综上所述，通过 Flink + Paimon 的组合方式在降低计算资源成本，提高数据时效性，提升开发运维效率和统一数据链路架构方面，相比于传统的实现方案，体现出相当大的优势。后续友盟会继续跟进 Paimon 的新特性并探索 Paimon 在友盟+具体业务场景中的落地方案。

后续规划：

1. 利用 Paimon 对 U-App 自定义事件的计算场景进行优化
2. 跟进 Paimon 新特性，对现有任务的性能和资源使用进行进一步的优化
3. 基于 Paimon 自带的 Metric 特性完善 Paimon 任务的监控

最后，由衷感谢@之信、 @才智老师在方案落地过程中的指导

更多内容

阿里云提供的基于Flink和Paimon的云上流式湖仓解决方案，旨在搭建高效、低延时的流式数据湖仓。此方案利用Flink的实时计算能力，结合Paimon的高效更新能力，实现数据在数仓分层间的实时流动。其优势包括将数据变更的传递延时从小时级甚至天级降低至分钟级，无需覆写分区即可直接接受变更数据，从而极大地降低了数据更新与订正的成本。此外，ETL链路的逻辑基于Flink SQL实现，统一了模型并简化了架构，提高了数据处理效率。点击下方链接了解更多详情。

点击：基于Flink+Paimon搭建流式湖仓

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

昨天，一个上线已久的供应链金融项目出现异常，经过一整天的排查，终于定位了两个问题的原因，并通过重启服务解决了其中的1个问题，另一个问题需要发起上线流程，通过上线才能解决。这两个问题，分别命名为【消失的字段】和【消失的消息】。在正式阐述问题之前，先描绘一下系统概况，以便读者更容易理解文中描述的问题排查逻辑，问题排查逻辑是这两篇文章的重点。

上图虚线框内是供应链金融项目的服务，包括：银行对接服务(bank-adapter)、贷前服务(preloan)、贷中服务(onloan)和贷后服务(postloan)，bank-adapter服务属于外联服务，主要和银行进行对接。

橙色线条表示业务服务（贷前、贷中和贷后）通过银行对接服务bank-adapter向银行主动发起查询，包括查询：企业准入结果、授信结果、融资申请结果、放款结果和还款结果。

绿色线条表示银行主动通过银行对接服务bank-adapter向供应链金融平台推送消息，bank-adapter服务收到消息进行校验解码之后发送到消息队列MQ，业务服务（贷前、贷中和贷后）监听消息队列实时获取最新的推送消息，进行业务处理。

目前系统出现了两个问题，一个是业务服务主动请求融资申请结果，发现没有审批额度信息——【消失的字段】；另一个是贷中服务和贷后服务无法从消息队列获取最新的消息——【消失的消息】。

本文主要描述【消失的字段】问题以及问题排查过程，并给出问题解决方案。

一、问题描述

供应链金融平台用户通过页面操作发起融资申请结果查询，发现始终无法刷新列表的审批额度信息，同时页面没有报错提示信息。

二、问题排查（按照橙色服务请求路线进行排查）

1、前端页面响应数据查看。在用户当前操作页面，按F12打开浏览器调试窗口，点击【Network】tab，清空当前网络请求，再次执行融资申请结果查询操作，此时在浏览器调试窗口可以看到对应的网络请求，查看Response，可以看到后端接口返回的响应结果中确实没有审批额度信息。此时，可以将问题范围缩小到后端服务。

2、模拟前端请求。构造参数，通过POSTMAN对生产的融资申请结果查询接口发起请求，该接口由bank-adapter服务提供，返回结果显示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

json复制代码{
    "bizno": "FS2023092610422152",
    "bankbizno": "2023092603412496",
    "custcode": "9131011075800000T",
    "custname": "世界第一有限公司",
    "reply": "1",
    "refusemsg": "",
    "clamt": 1537451.29,
    "loanrate": null,
    "approtime": "20230926",
    "currency": "CNY",
    "busstype": "01",
    "remark": "",
    "code": "200",
    "message": "交易成功"
}

疑问来了，明明bank-adapter接口返回了审批金额（对应字段为clamt）信息，为什么贷中服务返回给前端的结果却没有审批金额字段呢？返回结果从bank-adapter服务传递给onloan服务的过程中出现了什么问题？

3、查看bank-adapter和onloan服务的日志，因为从代码里对服务间调用的请求和响应记录了日志。通过日志发现，银行返回给bank-adapter服务的结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

json复制代码{
    "channelNo": "32060201",
    "bussType": "01",
    "efinanceNo": "2023092603412496",
    "bussNo": "FS2023092610422152",
    "custName": "世界第一有限公司",
    "custCode": "9131011075800000T",
    "reply": "1",
    "refuseMsg": "",
    "currency": "CNY",
    "clAmt": 1537451.29,
    "loanRate": null,
    "approTime": "20230926",
    "remark": ""
}

贷中服务onloan将从bank-adapter收到的响应结果输出如下：

1
2
3
4
5
6
7

json复制代码{
    "reply":"1",
    "currency":"CNY",
    "remark":"",
    "code":"200",
    "message":"交易成功"
}

通过对比上述两个结果，发现：驼峰形式命名的字段全部消失了！！！另外，通过第2步的结果与bank-adapter服务日志输入结果对比发现：bank-adapter服务接口最终输出的结果字段都被转为小写字段了，而且有字段名不一致的情况。 可以断定bank-adapter收到银行返回的结果之后，做了一些逻辑处理。接下来看代码！

4、打开bank-adapter服务融资申请结果查询结果的代码，发现最后将银行返回的数据构建为一个ApplyResultResp类型对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

ini复制代码@Data
public class ApplyResultResp {
    @JSONField(name = "bussNo")
    private String bussNo;
    
    @JSONField(name = "efinanceNo")
    private String efinanceNo;
    
    @JSONField(name = "custCode")
    private String custCode;
    
    @JSONField(name = "custName")
    private String custName;
    
    @JSONField(name = "reply")
    private String reply;
    
    @JSONField(name = "refuseMsg")
    private String refuseMsg;
    
    @JSONField(name = "clAmt")
    private BigDecimal clAmt;
    
    @JSONField(name = "loanRate")
    private BigDecimal loanRate;
    
    @JsonFormat(pattern = "yyyyMMdd")
    @JSONField(name = "approTime")
    private Date approTime;
    
    @JSONField(name = "currency")
    private String currency;
    
    @JSONField(name = "bussType")
    private String bussType;
    
    @JSONField(name = "remark")
    private String remark ;
    
    private String code;
    private String message;
}

具体转换代码使用fastjson工具进行操作：

1

ini复制代码ApplyResultResp applyResultResp = JSONObject.parseObject(jsonResultFromBank, ApplyResultResp.class);

从上述代码来看，不应该出现银行返回结果与bank-adapter接口响应结果不一致的情况，大胆猜测：生产上的代码与本地代码不一致。于是，请运维工程师从生产环境将容器中运行的bank-adapter.jar包拉下来，通过反编译查看ApplyResultResp类的代码，发现果然！反编译显示该类的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

ini复制代码public class ApplyResultResp {
  @JSONField(name = "bussNo")
  private String bizno;
  
  @JSONField(name = "efinanceNo")
  private String bankbizno;
  
  @JSONField(name = "custCode")
  private String custcode;
  
  @JSONField(name = "custName")
  private String custname;
  
  @JSONField(name = "reply")
  private String reply;
  
  @JSONField(name = "refuseMsg")
  private String refusemsg;
  
  @JSONField(name = "clAmt")
  private BigDecimal clamt;
  
  @JSONField(name = "loanRate")
  private BigDecimal loanrate;
  
  @JsonFormat(pattern = "yyyyMMdd")
  @JSONField(name = "approTime")
  private Date approtime;
  
  @JSONField(name = "currency")
  private String currency;
  
  @JSONField(name = "bussType")
  private String busstype;
  
  @JSONField(name = "remark")
  private String remark;
  
  private String code;
  
  private String message;
  
  ... getter and setter ...
  }

由此看出，生产环境bank-adapter服务将银行返回的结果字段全部转为了小写，然后onloan服务收到这些小写化之后的响应结果，通过BeanUtils.copyProperties方法构建响应对象，而onloan服务的响应对象字段也是驼峰形式的，所以构建过程中，驼峰形式字段信息全部丢失。

三、解决方案

将bank-adapter模块的本地代码重新部署上线，即可解决该问题。至于为什么生产上的代码与本地代码不一致，有可能是代码封板之后，本地修正了代码，但是忘记发布了。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

通过前面的介绍，我们对架构的历史脉络有了一些基本的认识。我们来深入思考一下：这个经常出现在各种技术讨论中的“架构”，到底是什么意思呢？

是的，我们经常听到“架构”这个词，但是真正停下来思考它的定义和内涵，你会发现不是那么简单。在技术界，尤其是软件开发领域，“架构”几乎成了一个时髦的词汇，人人都在谈论它，但是真正理解它的精髓的人却不多。那么，什么是软件架构呢？它又为什么如此重要？

在我们继续深入探索之前，让我们首先澄清一下“架构”的基本含义。接下来的内容，我们将从软件架构的定义谈起，探索它的核心组成部分，然后再进一步讨论它在软件开发过程中的重要作用和价值。这样，我们不仅能够更好地理解架构这个概念，而且还能够明白为什么它对于构建高效、可维护的软件系统如此关键。

1、架构的诞生

在探讨软件开发的众多新方法和理念时，我们发现“软件架构”的概念显得与众不同。不同于其他为应对新兴软件危机而诞生的理念，软件架构的出现似乎并不直接源于行业共面的某个特定问题。这里面有何玄机呢？

随着软件系统规模的日益庞大，一项明显的变化是，传统的计算算法和数据结构已不再是设计挑战的主要焦点。在一个由众多部件构成的系统中，如何高效地组织这些部件——即我们所称的“软件架构”——成为了设计师们面临的一系列新问题。比如，你可能遇到如下挑战：

• 系统规模庞大至一定程度，内部耦合变得异常复杂，严重拖慢了开发效率；
• 由于部件之间的紧密耦合，对系统的任何微小修改都可能引发连锁反应，使得后续的维护和扩展工作变得异常困难；
• 复杂的系统逻辑使得问题频发，一旦出现问题，定位和修复的难度极大。

在这样的背景下，“软件架构”的概念应运而生，其历史地位和必然性不言而喻。回望过去，我们可以发现，第一次软件危机推动了“结构化编程”的发展，带来了“模块”的概念；随后，第二次软件危机促使“面向对象编程”的普及，引入了“对象”概念。而“软件架构”的提出，则标志着“组件”概念的诞生。

这一发展历程揭示了一个核心思想：无论是“模块”、“对象”还是“组件”，其本质都在于对达到一定规模的软件系统进行有效的拆分和高层次组织。随着软件的复杂度不断攀升，这种拆分的粒度和层次也随之提高，从而更好地应对软件开发过程中遇到的各种挑战，提高软件的开发效率和系统的可维护性。

2、架构指什么

在我们程序员的世界里，“架构”这个词几乎无处不在。它就像是我们的老朋友，经常挂在嘴边。但是，当你真正停下脚步，试图去探究一下这个问题：“架构”究竟指的是什么？你可能会惊讶地发现，这个问题并没有想象中那么简单。其实，如果你随便问1000个技术人员，“架构”的定义是什么，你可能会得到1001种不同的答案。这就像是一个技术界的谜题，每个人心中的答案都有微妙的差异。

那么，在这个众说纷纭的情况下，我们如何才能找到对“架构”的准确理解呢？一个有效的方法是先从理解与“架构”紧密相关且相似的几对概念开始。我们可以聚焦于三对基本但至关重要的概念：系统与子系统、模块与组件、以及框架与架构。

2.1、系统与子系统

当我们聊到“系统”，可能首先想到的是各种复杂的技术或机械设备。维基百科给出了一个非常宽泛但精确的定义：

系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。

我们来简化一下上面的高深论述，抓住几个核心点：

• 关联：想象一下，仅仅把一个发动机和一台电脑摆在一起，并不能让它们变成什么特别的东西，对吧？但如果你把发动机、底盘、轮胎和车架这些有关联的部分放在一起，它们就能组合成一台汽车。这就是说，系统里的每个部分都得有点关系，才能一起工作形成一个有用的整体。
• 规则：在这个组合里，每个部分不是随便干自己的事。它们需要按照一定的规则来操作。比如说，汽车里的发动机产生动力，通过变速器和传动轴这样的装置，最终把动力传到轮胎上，让汽车能够前进。这些规则决定了谁负责干什么，怎么协作。
• 能力：当这些部件按规则合作时，整个系统就能做到单个部件做不到的事情，比如汽车的载人载物。这种系统的能力，不是简单地把各个部件的能力加起来那么简单，而是能创造出新的能力来。

再说说子系统，其实它的概念和系统差不多，只不过是从另一个角度来看。一个系统在更大的环境中，可能就是另一个系统的子系统：

子系统由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

子系统和系统的概念其实是一回事，只是取决于你站在哪个视角看问题。一个系统在更大的环境中就可能成为另一个系统的子系统。这听起来可能有点绕，但如果我们用微信这个例子来说明，一切就变得清晰多了。

• 微信作为一个系统：首先，把微信想象成一个庞大的生态圈，它自身就是一个系统。在这个生态圈里，有许多功能和服务，如聊天、登录、支付、朋友圈等。这些功能在微信这个大系统中，实际上都是独立运行的子系统，每个子系统负责不同的任务，但共同支撑起微信这个巨大的服务平台。
• 朋友圈的结构：再深入到朋友圈，我们可以看到它不仅仅是微信的一个功能，实际上它自己也是一个由多个功能组成的系统。比如，动态发布、评论、点赞等功能，在朋友圈这个“小系统”里，它们各自也可以被看作是独立的子系统。
• 评论功能的深层次：评论功能虽然是朋友圈的一部分，但如果我们仔细分析，会发现它自身也包含多个子系统，如防刷子系统、审核子系统、发布子系统、存储子系统等。这些子系统通过精密的协作，共同确保了评论功能的正常运行和数据的安全性。
• 技术层面的系统：当我们聚焦于评论审核这一环节，它可能不再被划分为更多的业务子系统，而是转向技术实现的视角。在这个层面，各种技术模块和组件，如数据库系统MySQL、缓存系统Redis等，它们虽然是从技术角度构成的系统，但同样在整个评论功能中扮演着关键的角色。这些技术组件确保了数据的快速处理和安全存储，虽然它们不直接参与到业务流程中，却是支撑整个系统运行不可或缺的部分。

这种从整体到部分，再从部分回到整体的视角，不仅帮助我们理解了系统内部的复杂结构，也让我们明白了在设计和构建复杂系统时，如何通过层次分明的子系统来管理和简化这种复杂性。每个子系统的设计和实现，都需要考虑如何与其他子系统协作，以及如何在满足当前功能需求的同时，保持系统的灵活性和扩展性。

通过微信这个例子，我们得到的不仅仅是对系统和子系统理论的深入理解，还有对实际应用中这些理论如何被运用以解决实际问题的洞见。这种理论与实践的结合，是软件工程中不可或缺的一部分，它指导我们如何更好地设计和优化软件系统，以适应不断变化的需求和挑战。

2.2、模块与组件

要深入理解软件系统的拆分，我们可以从两个不同的视角来探讨：逻辑和物理。这就像是看待一个复杂机器的两种方式。逻辑上的拆分产生了我们所说的“模块”，而物理上的拆分则给我们“组件”。

• 模块：把这个概念想象成是把一本厚厚的教科书分成不同的章节，每一章节专注于讲解一个特定的主题。在软件里，模块就是这样一个逻辑上的单位，它封装了一系列功能，这些功能紧密相关，共同完成一项或几项特定的任务。划分模块的目的很明确：为了让我们的代码更加有条理，每部分都有明确的职责，这样不仅使得代码更易于理解和维护，还能在团队中更高效地协作。
• 组件：再想想组件，可以将其比喻为乐高积木中的每一块积木。这些积木是实实在在的，你可以用它们来构建各种各样的结构。在软件开发中，组件是物理上的实体，可以在不同的系统中重复使用。它们就像是标准化的零件，可以根据需要组装或更换，极大地提高了开发的灵活性和效率。

提到“组件”的英文“component”，如果我们将其译为“零件”，可能会更加形象和易懂。这个词帮助我们更好地把握组件的本质：它们是独立的、可以互换的物理单位，正如机械中的零件一样，具备了可插拔和可复用的特性。这种物理上的拆分不仅让我们的系统更加模块化，还为系统的升级和维护提供了极大的便利。

通过逻辑和物理拆分，我们能够更精细地管理和构建复杂的软件系统，使之既有条理又高效。模块化和组件化的设计思想，是现代软件工程中不可或缺的一部分，它们使得软件开发像搭建乐高一样既有趣又富有创造性。

2.3、框架与架构

单纯从定义的角度来看，框架关注的是“规范”，架构关注的是“结构” 。框架（Framework）为你的项目提供了一套预设的工具和库，确保你可以遵循特定的规范和模式来构建应用。想象一下，如果你正在搭建一座房子，框架就像是提供给你的施工套件和详细指南，它指导你每一步如何建造，确保每一部分都能正确地承担起它的作用。架构（Architecture），则更像是整个系统的设计方案，它详细规划了系统的组织方式，展示了组件如何互相配合，数据如何流转，以及系统如何对外提供服务。这相当于在规划整个房子的布局，决定哪里放置客厅，哪里是厨房，以及如何确保房子既满足居住功能又具有美观性。

我们经常会说，“工程采用的是MVC架构”、“工程使用的是SSH框架”等。这里，第一句话是站在结构的层面来说明，它像是在描述房子的设计理念和内部结构，告诉你这个项目是如何划分不同的功能区域，以及这些区域是如何相互关联的。第二句话是站在规范的层面来说明，它更多关注于建造过程中应该遵循的标准和规则，比如使用什么样的技术栈，以及如何利用这些技术来实现预定的功能。

同时，不同的视角会影响我们对架构的理解和描述，例如：

• 从业务逻辑的角度分解，“后台管理系统”的架构(图1-3所示)，我们会关注系统是如何处理用户的注册、信息管理、业务选择和数据统计等业务流程的。这个角度让我们深入了解系统是如何支持核心业务需求的。

图1-3

• 从物理部署的角度分解，“后台管理系统”的架构(如图1-4所示)，则关注系统的硬件布局，如何通过服务器集群、负载均衡等技术手段来保证系统的高可用性和高性能。

• 从开发结构的角度分解，“后台管理系统”的架构(如图1-5所示)，我们则更加关注代码的组织方式、模块的划分以及技术框架的选择，以便于团队协作、功能迭代和系统维护。

通过不同的视角，我们不仅能够更全面地理解框架和架构的概念，还能够根据项目的实际需求，从多个维度评估和选择最合适的架构设计和技术框架。这种多角度的思考方式对于软件开发是非常重要的，它帮助我们构建出既稳健又灵活的系统，能够适应不断变化的业务需求和技术挑战。

3、架构的定义及边界

谈到“架构是什么”，你可能会发现这个问题没有那么简单。其实，不同的公司、不同的团队，乃至于我们每个人，对于“软件架构”的理解都各不相同。这就像我们不能百分之百精确描述一个复杂的模型一样，我们只能从多个角度来看，尝试给出一个大概的描述。所以，想要给出一个完全无懈可击的“架构定义”，那基本是不可能的。

“道可道，非常道。名可名，非常名”。

这个行业内部，充满了各种各样的声音和观点。有的组织可能会从技术的实用性出发，定义架构是一种确保系统稳定、高效运行的布局；有的个人可能更注重架构在解决复杂问题中的策略角色，视之为一种艺术。每个人都在尝试从自己独特的视角，解读和定义“架构是什么”，这就像是在无数的色彩中寻找那一抹最为合适的蓝，既充满了个人色彩，也反映了这个领域的多元和复杂。

3.1、架构的定义

the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution –ANSI/IEEE

IEEE 关于架构的这个概念：其实，把它想象成一个三明治，上面是系统的大架构，中间夹着的是各个组件以及它们之间的纽带（这里的纽带，既包括组件彼此之间的联系，也涵盖了它们与外界环境的互动），底下则是一套行动准则。咱们若是用图形来表达这个定义，那么制作出来的图示应该既清爽又直观，能够将架构的主要组成部分和核心思想，一目了然地展示出来(如图1-6所示)：

• 系统的大架构：这部分其实就是在讲，让人一眼就能看懂的系统整体布局。就像是给你一张地图，上面标注了所有重要的地标和路径，让你对整个地形有个基本的认识。
• 组件及其关系：这里的意思是，把整个系统拆分成一个个模块，这样不仅便于理解和管理，同时也强调了这些模块之间，以及模块与外部环境之间的相互作用和联系。就像是一张复杂的网络图，每个节点都有它的位置和作用，而线则表示了节点之间的连接。
• 行动准则：这部分提供的是设计和演进系统时需要遵守的规则和指导原则。就好比是一本指南，告诉你在追求目标的过程中，哪些是应该坚持的原则，哪些是需要避免的错误。

大师 Martin Fowler对于架构的定义有着更加简洁的抽象，Martin Fowler 认为软件架构是：重要并且难以改变的决策。架构设计是关于权衡的艺术，架构设计过程中充满了各种各样的决策，这些决策也终将反应系统架构。

在讨论软件架构这个课题时，大师 Martin Fowler 给出了自己的看法，既精炼又深刻：软件架构，那就是那些特别重要而且改起来头疼的决策。这就好比是在说，架构设计其实就是一个充满智慧的权衡过程，你在这个过程中做出的每一个决策，都像是在未来的系统蓝图上，悄悄地加上了你的个人签名。

Software Architecture = Important and hard to change decisions –Martin Fowler

而 Ralph Johnson 这位大佬，给出了一个更加哲学的定义，他说，软件架构嘛，简单点说，就是那些重要的东西，具体是啥呢？他似乎在告诉我们：这个问题，答案就像是宇宙的终极问题，重要的是你怎么去理解它！

The software architecutre is the important stuff ! Whatever it is ! –Ralph Johnson

与之相比，Neil Ford 则像是那位脚踏实地的实践者，他不在云端飘，而是带着工具箱走到了前线。他从实际操作的角度出发，详细列出了构成软件系统架构的基石(如图1-7所示)：

• 结构：这不仅仅是选一个风格的问题，而是定义了整个应用的骨架，是微服务、是单体，还是服务导向架构（SOA），每一种选择都像是在向系统注入不同的灵魂。
• 架构属性：这些看不见摸不着的特性，比如性能如何、可用性高低、维护起来是不是友好，它们决定了系统能否在残酷的环境中生存下来。
• 架构决策：在设计系统的过程中，那些至关重要的选择点，就像是在茫茫大海中航行的舵手，一次又一次地决定着软件的未来方向。
• 设计原则：这些原则就像是老船长的智慧，指引着设计者避开暗礁，顺利抵达目的地。

3.2、结构

结构是系统架构的重要组成部分，其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。架构师需要基于上下文的权衡，可以选择模块化单体架构风格，也可以选择微服务架构风格。

说到架构中的“结构”，这块可不是随便一说就能过去的。它在整个系统架构里面占的位子，就好比心脏在人体里的角色一样重要。它从一个宏大的视角，告诉我们这个系统是由哪些部分组成的，每部分又是怎么协同工作的。搞架构设计的时候，挑选一个恰到好处的架构风格，基本上就是架构师的核心日常了。

举个例子，架构师们在面对具体的项目时，得先在大脑中过一遍这个系统的全貌，然后根据这个系统要面对的各种情况和挑战，来做一个权衡。这时候，他们可能会选择走模块化的单体架构风格，这种方式好处是简单、直接，容易管理；但如果项目特别复杂，服务之间需要高度的解耦，那微服务架构风格可能就更合适了，虽然这样会带来更多的管理和协调工作，但它能提供更好的灵活性和扩展性。

“选择合适的架构风格”的过程(如图 1-8所示)，其实就像是在做一场精心策划的活动，架构师需要凭借自己的经验和对项目需求的深刻理解，做一个详细的规划，希望能赢得未来的便利和效率。这个过程充满了挑战，但也正是这些挑战，让架构设计成为了一门艺术。

3.3、架构属性

在聊软件架构的时候，绝不能忽视的一个重点就是所谓的架构属性，也就是大家常说的质量属性或非功能属性。这些属性，其实就是在描述系统应该具备的一些“超能力”，比如能跑得快（高性能）、能灵活扩大或缩小规模（可扩展性和伸缩性）、碰到问题不崩溃（弹性和容错性）、好测好修（可测试性和可维护性）等等。设计架构的时候，我们的一个核心任务就是要确保系统能够满足这些架构属性的要求，因为它们直接关系到系统能否在野蛮生长的环境中存活下来。

但这里头有个问题，那就是架构属性多得跟星星一样数不清，我们必须明白，在不同的项目和场景下，重点关注哪一部分属性。这就要求架构师得根据具体的问题域和上下文环境，来做出精准的分析和选择。比如，在一个对性能要求极高的金融交易系统中，高性能和容错性可能就是你得重点关注的属性；而在一个云服务产品中，可扩展性和伸缩性可能更为关键。

同时，架构设计不是一帆风顺的，这些架构属性(如图 1-9所示)之间很可能存在着某种程度的冲突。例如，追求极致的性能可能会牺牲一定的可维护性和可测试性。这种时候，架构师就得像是在玩一个平衡游戏，既要保证系统的核心能力，又要尽量避免负面影响，这就需要他们运用自己的经验和智慧，做出恰当的权衡和决策。

架构设计其实就是一个不断权衡和选择的过程，旨在打造一个既强大又平衡的系统。这个过程中，架构师的角色就像是一位艺术家，既要有科学的严谨性，又要有艺术的创造力。

3.4、架构决策

当我们深入探讨软件架构设计的精髓时，架构决策这个概念浮现为其核心。它不仅仅是关于解决方案的选择，更是一系列必须遵守的规则的体现。这些规则或决策，正如导航灯指引船只航向，为整个系统设计指明方向。在这个过程中，要认识到并非所有决策都能被称为架构决策。只有那些对系统有着重大且深远影响的决策，才配得上这个称号。比如说，决定采用何种架构风格，这不仅会深刻影响到系统的整体设计，一旦设定，更改的代价极为昂贵，因此，它无疑属于架构决策的范畴。

架构决策的范围广泛，内容丰富，它们包括但不限于以下几个关键领域：

• 直接对架构属性中的优先级高的问题产生影响：这意味着任何影响性能、可扩展性、安全性等关键架构属性的决策都是至关重要的。
• 修改对外接口：这类决策需要进行周全的影响分析，因为它们可能会对系统与外部世界的交互方式产生根本性的改变。
• 引入或移除依赖：依赖关系的变化标志着系统功能的增减，对架构的影响深远，需要慎重考虑。
• 改变系统的通用结构：这关乎到系统的基础架构布局，任何调整都是对系统架构的重大干预。
• 促使开发团队改变开发模式：这类决策往往涉及到开发流程和文化，对团队的工作方式和产品的质量都会产生深远的影响。
• 承担战略性技术债务：有时为了项目的长期发展，需要做出一些短期内看似不利但长远来看有益的技术选择，这些决策对系统的未来发展至关重要。

这些架构决策，远不止是技术层面的选择，它们背后蕴含的是对项目未来方向的深思熟虑。一个正确的架构决策可以为项目带来顺利的发展，而错误的选择可能导致项目陷入重构甚至失败的困境。因此，在架构设计过程中，架构师需要具备前瞻性和深度的思考能力，确保每一个决策都能促进项目向着正确的方向发展。

3.5、设计原则

设计原则和架构决策，这两者在软件设计的世界里，就像是指南和指导的关系。两者都指引着你前行的方向，但具体的用法和意义，却大有不同。核心区别在这儿：设计原则，它更像是一位经验丰富的前辈，给你提供的那些指导和建议，并不会强迫你一定要这么做。而架构决策，那就相当于设计的规章制度，一旦确定下来，你就必须得遵守。

举个例子来说得更明白一点，设计原则可能会这样建议你：在软件系统间的通讯上，尽可能利用异步消息机制。这么做的好处是啥呢？首先，它能够提升系统的性能，让你的应用跑得更快；其次，还能降低系统间的耦合度，让系统之间的关系更加松散，互不干扰。这就好比是在教你如何在繁忙的城市中开车，不仅能高效地从A点到B点，还能在路上享受风景，避免不必要的麻烦。

但这都是建议，它不会对你说：“你必须得这么干！”它留给你足够的空间去探索和实验，找到最适合你自己项目的方法。而一旦我们谈到架构决策，比如你决定用微服务架构而非单体架构，这就像是签了一个契约，需要你严格遵守，因为它关系到整个项目的基础和未来的可维护性。

在设计和构建软件系统的时候，理解设计原则与架构决策之间的这种微妙差异，就显得尤为重要。它们一个给你灵感和自由，一个给你方向和规则，正确地运用它们，就能让你的软件设计既灵活又稳健。

4、总结

在深入探讨软件架构的定义时，我们会发现行业内各位大师提供了多样化且各具特色的解读，它们就像是不同风格的画派，每一种都有其独到之处：

• IEEE的定义，就好比是经典主义画派，追求结构的严谨和形式的规范，给我们提供了一个架构定义的标准框架，像是在告诉我们，建筑的每一砖每一瓦都要符合建筑学的原则。
• Martin Fowler的角度，则像是强调了画作中的构图决策，就如同在绘画中选择主题和色彩的重要性一样，他告诉我们在架构设计中，关键的决策是构筑整个系统的基石。
• Ralph Johnson的定义更像是抽象艺术，他没有给出具体的形式，而是强调了“重要性”这个核心元素，就像是抽象画中强调情感和概念的表达，让我们理解到架构的核心在于其重要的价值和作用。
• Neil Ford的看法则更接近于现实主义，他通过具体化的描述，就像是通过细腻的画面描绘出生活的样态，让我们能够清晰地理解和操作架构的具体元素。

在这些定义中，我个人特别偏爱Ralph Johnson的抽象化定义，它简洁而深刻，像是用一笔带过却又点出架构本质。在我的工作实践中，这种将复杂问题抽象化的能力，成为了我判断和理解架构边界时的重要准则。就像是在画画时，虽然不被具体形式所束缚，但能够深刻把握作品的灵魂，这样的定义不仅指导了我的架构设计思路，也帮助我在面对复杂系统时，能够更加聚焦于那些真正重要的事情。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

题图来自APOD

首先要声明的就是，千万级数据对于MySQL来说就是不太合理的一个存在。

优化MySQL千万级数据策略还是比较多的。

• 分表分库
• 创建中间表，汇总表
• 修改为多个子查询

这里讨论的情况是在MySQL一张表的数据达到千万级别。表设计很烂，业务统计规则又不允许把sql拆成多个子查询。

在这样的情况下，开发者可以尝试通过优化SQL来达到查询的目的。

当MySQL一张表的数据达到千万级别，会出现一些特殊的情况。这里主要是讨论在比较极端的情况下SQL的优化策略。

先来个千万级数据

通过存储过程传递函数制造1000万条数据。

表结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

sql复制代码CREATE TABLE `orders` (
  `order_id` int NOT NULL AUTO_INCREMENT,
  `user_id` int DEFAULT NULL,
  `order_date` date NOT NULL,
  `total_amount` decimal(10,2) NOT NULL,
  PRIMARY KEY (`order_id`),
  KEY `idx_user_id` (`user_id`) USING BTREE,
  KEY `idx_user_amount` (`user_id`,`total_amount`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

CREATE TABLE `users` (
  `user_id` int NOT NULL AUTO_INCREMENT,
  `username` varchar(50) COLLATE utf8mb4_general_ci NOT NULL,
  `email` varchar(100) COLLATE utf8mb4_general_ci NOT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`user_id`),
  KEY `idx_user_id` (`user_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

造数据的存储过程如下。

用户数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

sql复制代码-- 产生用户存储过程，1000个
CREATE DEFINER=`root`@`localhost` PROCEDURE `create_users`()
BEGIN
    DECLARE i INT DEFAULT 0;
    DECLARE total_users INT DEFAULT 1000; -- 调整用户数量
    DECLARE rnd_username VARCHAR(50);
    DECLARE rnd_email VARCHAR(100);

    WHILE i < total_users DO
        -- 生成随机用户名和邮箱
        SET rnd_username = CONCAT('User', FLOOR(1 + RAND() * 10000000)); -- 假设用户名唯一
        SET rnd_email = CONCAT(rnd_username, '@example.com'); -- 假设邮箱唯一
        -- 将数据插入用户表
        INSERT INTO users (username, email) VALUES (rnd_username, rnd_email);

        SET i = i + 1;
    END WHILE;
END

订单数据生成存储过程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

sql复制代码CREATE DEFINER=`root`@`localhost` PROCEDURE `generate_orders`()
BEGIN
    DECLARE i INT DEFAULT 0;
    DECLARE total_users INT DEFAULT 1000; -- 用户数量
    DECLARE total_orders_per_user INT DEFAULT 1000; -- 每个用户的订单数量
    DECLARE rnd_user_id INT;
    DECLARE rnd_order_date DATE;
    DECLARE rnd_total_amount DECIMAL(10, 2);
    DECLARE j INT DEFAULT 0;

    WHILE i < total_users DO
        -- 获取用户ID
        SELECT user_id INTO rnd_user_id FROM users LIMIT i, 1;

        WHILE j < total_orders_per_user DO
            -- 生成订单日期和总金额
            SET rnd_order_date = DATE_ADD('2020-01-01', INTERVAL FLOOR(RAND() * 1096) DAY); -- 2020-01-01和2022-12-31之间的随机日期
            SET rnd_total_amount = ROUND(RAND() * 1000, 2); -- 0到1000之间的随机总金额
            -- 将数据插入订单表
            INSERT INTO orders (user_id, order_date, total_amount) VALUES (rnd_user_id, rnd_order_date, rnd_total_amount);

            SET j = j + 1;
        END WHILE;
        SET j = 0;

        SET i = i + 1;
    END WHILE;
END

将users和orders的数据生成分开，这样可以通过多次调用orders存储过程多线程参数数据。

调用一次call create_users()，然后开15个窗口调用orders存储过程call generate_orders()。

整个过程会产生1000个用户，15*1000*1000也就是1500万条订单数据。

原始SQL

这是一个很简单的sql，统计每个用户的订单总额。

在默认情况下，什么索引都没有创建，需要花费190+s的时间。

1
2
3

sql复制代码-- 第一个版本
SELECT a.*,sum(b.total_amount) as total from users a left join orders b  on a.user_id = b.user_id
group by a.user_id;

explain分析如下：

可以看到什么索引也没使用，type为all，直接全表扫描。

用时191s。

第一次优化：普通索引

把查询条件用到的sql条件都创建索引。也就是where和join、sum涉及到的知道。

1
2
3

sql复制代码CREATE INDEX idx_orders_user_id ON orders (user_id);
CREATE INDEX idx_orders_total_amount ON orders (total_amount);
CREATE INDEX idx_users_user_id ON users (user_id);

查询sql仍然是第一个版本。

1
2
3

sql复制代码-- 第一个版本
SELECT a.*,sum(b.total_amount) as total from users a left join orders b  on a.user_id = b.user_id
group by a.user_id;

先看看expalin的结果：

type为index或者ref，全部走的索引。

查询结果却让人失望，这次用的时间更多，用了460+s。也就是说查询变慢了。

推测是由于mysql的回表机制导致查询变得更慢了。所以接下来继续优化索引。

第二次优化：覆盖索引

覆盖索引是指一个索引包含了查询所需的所有列，从而可以满足查询的要求，而不需要访问实际的数据行。

通常情况下，数据库查询需要根据索引定位到对应的数据行，然后再从数据行中获取所需的列值。

而当索引中包含了查询所需的所有列时，数据库引擎可以直接通过索引就能够满足查询的要求，无需访问实际的数据行，这样就可以提高查询性能。

这也是普通索引添加了还是查询慢的原因，因为普通索引命中了还是会去找主键，通过主键找到关联字段的值做过滤。

1
2
3
4
5

sql复制代码-- 先不删除普通索引
-- drop INDEX idx_orders_user_id ON orders;
-- drop INDEX idx_orders_total_amount ON orders;
CREATE INDEX idx_orders_total_amount_user_id ON orders (total_amount,user_id);
CREATE INDEX idx_orders_user_id_total_amount ON orders (user_id,total_amount);

1500万数据创建索引就花费了300+s。所以创建索引得适度。

查询sql还是第一个版本。

1
2
3

sql复制代码-- 第一个版本
SELECT a.*,sum(b.total_amount) as total from users a left join orders b  on a.user_id = b.user_id
group by a.user_id;

先看看expalin的结果：

可以看到orders表的type从index提升到了ref。

此时的查询时间为从460s+降低到10s了。

结果证明覆盖索引能提升查询速度。

问题就在于这次建的两个覆盖索引，只有 idx_orders_user_id_total_amount 降低了查询时间，而 idx_orders_total_amount_user_id没有。

这个和mysql的关键词执行顺序有一定关系（推测，没找到资料）。

mysql执行顺序如下：

1
2
3
4
5
6
7
8
9
10
11

shell复制代码from
on
join
where
group by
having
select
distinct
union （all）
order by
limit

可以看到在覆盖索引使用过程先是where,再是到select的sum函数。这也是 idx_orders_user_id_total_amount 索引的创建顺序。

1
2
3

sql复制代码drop INDEX idx_orders_user_id ON orders;
drop INDEX idx_orders_total_amount ON orders;
drop INDEX idx_orders_total_amount_user_id ON orders;

drop掉相关的多余索引可以发现执行查询时间没有变化，仍然为10s。

索引优化这块差不多就是通过覆盖索引来命中索引。

第三次优化：减少数据量

减少数据量在业务上来说就是移除不必要的数据，或者可以在架构设计这块做一些工作。

分表就是这个原则。

通过这个方式能把千万的数据量减少到百万甚至几十万的量。提升的查询速度是可以想象的。

1
2
3
4

sql复制代码-- 第三次优化：减少数据量
SELECT a.*,sum(b.total_amount) as total from users a left join orders b  on a.user_id = b.user_id
where a.user_id > 1033
group by a.user_id;

expain结果如下：

可以看到users表的type为range。能过滤一部分数据量。

查询时间从10s降低到7s，减少数据量证明有效。

第四次优化：小表驱动大表

在 MySQL 中，通常情况下，优化器会根据查询条件和表的大小选择合适的驱动表（即主导表）。

小表驱动大表是一种优化策略，它指的是在连接查询中，优先选择小表作为驱动表，以减少连接操作所需的内存和处理时间。

在第三次优化的结果上，可以尝试使用小表驱动大表优化策略。

1
2
3
4
5

sql复制代码-- 第三个版本，小标驱动大表  没啥效果
SELECT a.*,sum(b.total_amount) as total from users a
left join (select user_id,total_amount from orders c where c.user_id > 1033 ) b  on a.user_id = b.user_id
where a.user_id > 1033
group by a.user_id;

将left join的表修改为子查询，能提前过滤一部分数据量。

expain结果如下：

可以看到explain没什么变化。实际执行效果也没啥变化。

小表驱动大表在这里无效，但是可以结合具体的业务进行优化sql。这个策略是没问题的。

第五次优化：强制索引

当 MySQL 中的 IN 子句用于查询千万级数据时，如果未正确设计和使用索引，可能导致索引失效，从而影响查询性能。

通常情况下，MySQL 的优化器会根据查询条件选择最优的执行计划，包括选择合适的索引。然而，对于大数据量的 IN 子句查询，MySQL 可能无法有效使用索引，从而导致全表扫描或索引失效。

查询sql如下，由于in的数据量不是很稀疏，实际查询强制索引和普通索引效果一致

1
2
3
4
5
6
7
8

sql复制代码-- 第五个版本，强制索引 
SELECT a.*,sum(b.total_amount) as total from users a left join orders b force index (idx_orders_user_id_total_amount)  on a.user_id = b.user_id
where b.user_id in (1033,1034,1035,1036,1037,1038)
group by a.user_id;
-- 第五个版本，不走强制索引 
SELECT a.*,sum(b.total_amount) as total from users a left join orders b  on a.user_id = b.user_id
where b.user_id in (1033,1034,1035,1036,1037,1038)
group by a.user_id;

查询时间都是零点几秒。

笔者在实际业务中是遇到过这种场景的，业务sql更加复杂。这里由于临时创建的订单用户表没复现。

当你发现explain都是命中索引的，但是查询依然很慢。这个强制索引可以试试。

优化策略

• 提前命中索引，小表驱动大表
• 千万级数据in索引失效，进行强制索引
• 使用覆盖索引解决回表问题

下次该怎么优化SQL

• 数据接近千万级，需要分表，比如按照用户id取模分表。
• 用汇总表代替子查询来命中索引，比如把小时表生成日表、月表汇总数据。
• 关联字段冗余、直接放到一张表就是单表查询了。
• 命中索引，空间换时间，这也是本文分析的场景。

关于命中索引核心点就是覆盖索引，再者是千万数据产生的特有场景需要走强制索引。

tips

explain结果type的含义

在 MySQL 的 EXPLAIN 查询结果中，type 字段表示了查询使用的访问类型，即查询执行过程中的访问方法。

根据不同的访问类型，MySQL 查询优化器将选择不同的执行计划。以下是 type 字段可能的取值及其含义：

• system： 这是最好的情况，表示查询只返回一行结果。这通常是通过直接访问表的 PRIMARY KEY 或唯一索引来完成的。
• const： 表示 MySQL 在查询中找到了常量值，这是在连接的第一个表中进行的。由于这是常量条件，MySQL 只会读取一次表中的一行数据。例如，通过主键访问一行数据。
• eq_ref： 类似于 const，但在使用了索引的情况下。此类型的查询是通过某个唯一索引来访问表的，对于每个索引键值，表中只有一行匹配。常见于使用主键或唯一索引进行连接操作。
• ref： 表示此查询使用了非唯一索引来查找值。返回的是所有匹配某个单独值的行。该类型一般出现在联接操作中，使用了非唯一索引或者索引前缀。
• range： 表示查询使用了索引来进行范围检索，通常出现在带有范围条件的查询语句中，例如 BETWEEN、IN()、>、<等。
• index： 表示 MySQL 将扫描整个索引来找到所需的行。这通常是在没有合适的索引的情况下，MySQL 会选择使用这种访问类型。
• all： 表示 MySQL 将扫描全表以找到所需的行，这是最差的情况。这种情况下，MySQL 将对表中的每一行执行完整的扫描。

通常来说，type 字段的排序从最好到最差依次是 system、const、eq_ref、ref、range、index、all，当然，实际情况取决于查询的具体情况、表结构和索引的使用情况。更好的查询性能通常对应着更好的 type 类型。

mysql的回表机制

在 MySQL 中，回表（”ref” or “Bookmark Lookup” in English）是指在使用索引进行查询时，MySQL 首先通过索引找到满足条件的行的位置，然后再回到主表（或称为数据表）中查找完整的行数据的过程。

这个过程通常发生在某些查询中，特别是涉及到覆盖索引无法满足查询需求时。

当一个查询不能完全通过索引满足时，MySQL 就需要回到主表中查找更多的信息。这种情况通常出现在以下几种情况下：

• 非覆盖索引查询： 如果查询需要返回主表中未包含在索引中的其他列的数据时，MySQL 就需要回到主表中查找这些额外的列数据。
• 使用索引范围条件： 当查询中使用了范围条件（例如 BETWEEN、>、< 等），而索引只能定位到范围起始位置时，MySQL 需要回到主表中检查满足范围条件的完整行。
• 使用了聚簇索引但需要查找的列不在索引中： 在使用了聚簇索引的表中，如果需要查询的列不在聚簇索引中，MySQL 需要回到主表中查找这些列的数据。

当 MySQL 需要执行回表操作时，会发生额外的磁盘访问，因为需要读取主表中的数据。这可能会导致性能下降，特别是在大型数据表中或者在高并发环境中。

为了尽量减少回表操作的发生，可以考虑以下几点：

• 创建覆盖索引：确保查询所需的所有列都包含在索引中，从而避免回表操作。
• 优化查询语句：尽量避免使用范围条件，或者确保所有的过滤条件都可以被索引完全匹配。
• 考虑表设计：在设计数据库表结构时，可以考虑将常用的查询字段都包含在索引中，以减少回表操作的发生。

关于作者

来自一线全栈程序员nine的探索与实践，持续迭代中。

欢迎关注或者点个小红心~

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

自然语言处理领域（Natural Language Processing，NLP）

1950年，计算机之父——艾伦·图灵(Alan Turing)介绍了一项测试，以检查机器是否能像人类一样思考，这项测试称为图灵测试。

它具体的测试方法是构建一个计算机对话系统，一个人和被测试的模型互相进行对话，如果这个人无法辨别对方究竟是机器模型还是另一个人，就说明该模型通过了图灵测试，计算机是智能的。

这个图灵测试就属于自然语言处理(后面简称 NLP)领域的范畴，那什么是自然语言处理呢？

所谓自然语言，就是人们日常生活中接触和使用的中文、英语、日语等。自然语言处理是指，让计算机来理解并正确地操作自然语言，完成人类指定的任务。

长久以来，图灵测试都被学界认为是难以攀登的巅峰。正因如此，NLP 也被称为人工智能皇冠上的明珠。

ChatGPT

NLP 中常见的任务包括文本中的关键词抽取、文本分类、机器翻译等等。NLP 当中还有一个非常难的任务：对话系统，也可被笼统称为聊天机器人。

现在，ChatGPT 已经远远超出了聊天机器人这个范畴，它能够根据用户的指令写文章，回答技术问题，做数学题，做外文翻译，玩文字游戏等等。所以，某种程度上，ChatGPT 已经摘下了这颗皇冠上的明珠。

ChatGPT 的工作形式非常简单，用户向 ChatGPT 提问任何一个问题，模型都会做出解答。用户的输入和模型的输出都是文字形式。

一次用户输入和一次模型对应的输出，叫做一轮对话。可以把 ChatGPT 的模型抽象成如下流程：

ChatGPT 也可以回答用户的连续提问，也就是多轮对话，多轮对话之间是有信息关联的。其具体的形式也非常简单，第二次用户输入时，系统默认把第一次的输入、输出信息都拼接在一起，供 ChatGPT 参考上次对话的信息。

如果用户与 ChatGPT 对话的轮次过多，一般来讲模型仅会保留最近几轮对话的信息，此前的对话信息将被遗忘。

ChatGPT 在接收到用户的提问输入后，输出的文字并不是一口气直接生成的，而是一个字、一个字生成的，这种逐字生成，即生成式（Generative） 。如下图所示。

ChatGPT 与 NLP 的发展历程

可以试想一下，如果让你来实现一个 ChatGPT 模型，有哪些思路和方法呢？

事实上，大致有两种策略，基于规则的 NLP 和基于统计的 NLP。

自从 ChatGPT 开始，NLP 领域又进入了强化学习时代，即基于强化学习的 NLP。

基于规则的 NLP

基于规则的 NLP，是指使用人工编写的规则来处理自然语言。

例如，我们可以基于以下规则设计一个对话系统：

规则 1：当模型接收到用户的问句后，把问句中的“吗”字去掉，“？”换成“。”

规则 2：把“你”换成“我”，“我”字换成“你”。

由此，我们可以根据这些规则，制作一个对话模型，开启对话模式了。

1
2
3
4
5
6
7

js复制代码用户：Hello。

模型：Hello。

用户：你是 ChatGPT吗？

模型：我是 ChatGPT。

以上是一个基于规则的非常粗浅的对话系统示例。

如果用户问题太复杂了怎么办？问题中没有加问号怎么办？我们需要不断编写出各种规则来覆盖上面的特殊情况。这说明基于规则存在几个明显的缺点：

1. 在自然语言中，任何规则都无法完全覆盖需求，因此在处理复杂的自然语言任务时效果不佳；
2. 规则无穷无尽，靠人力来完成将是一项天量的工作；
3. 本质上并没有把自然语言处理的任务交给计算机来完成，依然是人在主导。

基于统计的 NLP

基于统计的 NLP 则是利用机器学习算法从大量的语料库中学习自然语言的规律特征。

这种方法不需要人工编写规则，规则主要通过学习语言的统计特征，暗含在模型中。换句话说，基于规则的方法中，规则是显性的，人工编写的；基于统计的方法中，规则是隐形的，暗含在模型参数中，由模型根据数据训练得到。

在近年来这种模型发展迅速，ChatGPT 就是其中一种。它们的处理方式主要如下：

在 ChatGPT 中，主要采用预训练（ Pre-training ） 技术来完成基于统计的 NLP 模型学习。

它的重点在于，根据大规模原始语料学习一个语言模型，而这个模型并不直接学习如何解决具体的某种任务，而是学习从语法、词法、语用，到常识、知识等信息，把它们融汇在语言模型中。直观地讲，它更像是一个知识记忆器，而非运用知识解决实际问题。

预训练的好处很多，它已经成为了几乎所有 NLP 模型训练的必备步骤。

基于统计的方法远远比基于规则的方法受欢迎，然而它最大的缺点是黑盒不确定性，即规则是隐形的，暗含在参数中。例如，ChatGPT 也会给出一些模棱两可、不知所云的结果。

所以，就有了基于强化学习的 NLP。

基于强化学习的 NLP

ChatGPT 模型是基于统计的，然而它又利用了新的方法，带人工反馈的强化学习（Reinforcement Learning with Human Feedback，RLHF） ，以此取得了卓越的效果，把 NLP 的发展带入了一个新阶段。

几年前，Alpha GO 击败了柯洁。这几乎可以说明，强化学习如果在适合的条件下，完全可以打败人类，逼近完美的极限。当前，我们依然处在弱人工智能时代，但局限于围棋这个领域，Alpha GO 就是一个强人工智能，它的核心就在于强化学习。

所谓强化学习，就是一种机器学习的方法，旨在让智能体（Agent，在 NLP 中主要指深度神经网络模型，就是 ChatGPT 模型）通过与环境的交互来学习如何做出最优决策。

这种方式就像是训练一只狗（智能体）听哨声（环境）进食（学习目标）。一只小狗，当听到主人吹哨后，就会被奖励食物；而当主人不吹哨时，小狗只能挨饿。通过反复的进食、挨饿，小狗就能建立起相应的条件反射，实际上就是完成了一次强化学习。

而在 NLP 领域，这里的环境要复杂得多。针对 NLP 模型的环境并非真正的人类语言环境，而是人为构造出来的一种语言环境模型。因此，这里强调是带人工反馈的强化学习。

基于统计的方式能够让模型以最大自由度去拟合训练数据集；而强化学习就是赋予模型更大的自由度，让模型能够自主学习，突破既定的数据集限制。ChatGPT 模型是融合统计学习方法和强化学习方法的，它的模型训练流程如下图所示：

总结

实际上，基于规则、基于统计、基于强化学习这三种方式，并不仅仅是一种处理自然语言的手段，而是一种思想。一个解决某一问题的算法模型，往往是融合了这三种解决思想的产物。

如果把计算机比作一个小孩，自然语言处理就像是由人类来教育小孩成长。

基于规则的方式，就好比家长 100% 控制小孩，要求他按照自己的指令和规则行事，如每天规定学习几小时，教会小孩每一道题。整个过程，强调的是手把手教，主动权和重心都在家长身上。对于 NLP 而言，整个过程的主动权和重心，都在编写语言规则的程序员、研究员身上。

基于统计的方式，就好比家长只告诉小孩学习方法，而不教授具体每一道题，强调的是半引导。对于 NLP 而言，学习重心放在神经网络模型上，但主动权仍由算法工程师控制。

基于强化学习的方式，则好比家长只对小孩制定了教育目标，比如，要求小孩能够考试达到 90 分，但并不去管小孩他是如何学习的，全靠自学完成，小孩拥有极高的自由度和主动权。家长只对最终结果做出相应的奖励或惩罚，不参与整个教育过程。对于 NLP 来说，整个过程的重心和主动权都在于模型本身。

NLP 的发展一直以来都在逐渐向基于统计的方式靠拢，最终由基于强化学习的方式取得完全的胜利，胜利的标志，即 ChatGPT的问世；而基于规则方式逐渐式微，沦为了一种辅助式的处理手段。ChatGPT 模型的发展，从一开始，就在坚定不移地沿着让模型自学的方向发展进步着。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有