人脑的容量有限，为了在有限的脑容量中高效的存储更多的知识，需要对知识进行归纳整理，变成自己的文章。但是并不是所有的知识都能够变成文章，出于篇幅、与其他知识点的关联等原因，很多知识当前还处于一种零散状态。

为了更有效的管理这些零散知识，现在将它们都存储在博客中的这个模块之中。当某些知识变成了一种常识或者许多知识积累了足够的信息量能够写一篇文章，则这些知识就会从这里删除。

计算机类一般性知识

摩尔定理的直观感受

2007 年的专用数值计算计算机（当时的顶级超算 / 专业工作站），按Linpack 浮点算力对比，大致相当于2025 年 1 台高端工作站或 1–4 张旗舰消费 GPU；当年的普通数值工作站，现在只相当于入门笔记本 / 轻薄本。统一按双精度浮点（科学/数值计算标准） 对标

2007年设备档次 典型配置 当年双精度峰值算力 现在2025年对等水平
全球顶级超算 IBM BlueGene/L 榜首超算 约 478 TFLOPS 4张 RTX 5090 显卡 算力总和
专业高端工作站 双路至强Xeon 8核 约 96 GFLOPS 现在普通酷睿/锐龙 轻薄本、入门游戏本CPU
高校普通计算主机 Core2 双核 E8400 约 24 GFLOPS 当代旗舰智能手机处理器水平

二进制编辑

对于Linux/Mac系统, 自带了xxd工具, 可以读写二进制文件, 例如

1
2
3
4
5
# 将二进制文件dump为可读的文本文件
xdd a.out > a.txt

# 直接修改文本文件后使用-r参数重新写回二进制文件
xdd -r a.txt a.out

注意: 对于Mac平台, 由于签名机制, 直接修改二进制文件可能触发Killed:9, 需要对文件重新签名, 可执行

1
codesign -f -s - myapp_new

QUIC协议与弱网条件

此前听说QUIC协议由于在应用层构建拥塞控制逻辑, 以及一些其他重要的特性, 对于弱网条件时, 相对于TCP连接有更好的传输效率. 于是我将博客的nginx配置进行了修改, 使其支持HTTP 3协议. 最后实际体验下来发现博客加载时间大幅增加, 原本1秒内可以加载完毕的页面平均需要5秒以上时间才能加载.

分析后判断原因如下

  1. nginx启动QUIC协议后, 默认拥塞控制算法为CUBIC而非BBR, 因此默认的表现低于开启了BBR算法的TCP协议
  2. 从服务器到用户的链路中经过多个网络, 每个运营商对于UDP协议的支持各不相同, 可能受到各自限流策略的影响
  3. 服务器端需要单独调整缓冲区大小, 缓冲区太小影响发包速度

基于以上分析, 如果启用QUIC协议, 理论上至多与启用BBR协议的TCP传输效率接近, 而不太可能有明显的提升. 由于整个网络对于UDP协议的支持不如TCP协议, 大概率只能比当前的TCP传输效果更差.

纸上得来终觉浅, 绝知此事要躬行

win10特殊配置

清除输入法缓存

在运行窗口中输入%AppData%\Microsoft\InputMethod\Chs可以打开微软的输入法的缓存页面. 该路径下的文件数量会影响输入法的启动速度, 如果存在超过1万文件, 则会在首次输入时产生明显的卡顿. 删除该目录下的所有文件即可解决卡顿问题.

这也是微软的历史BUG之一了, 并且由于涉及底层组件, 有生之年可能都不会修复

修复输入法使用英文标点无效

win10的输入法实际上存在新版和旧版两套, 对于新版输入法, 虽然配置了在中文输入中使用英文标点符号, 但该功能无法正常生效, 只能在每次输入时, 使用Ctrl + .进行切换.

打开设置 → 时间和语言 → 语言 & 区域 → 中文 (简体，中国) → 选项, 进入微软拼音 → 选项 → 常规, 勾选使用以前版本的微软拼音输入法后重启电脑, 即可启用旧版输入法并解决设置不生效的问题.

不知道是该吐槽微软的新功能根本没有测试, 还是应该吐槽微软的兼容性做的太好旧版还真能解决问题了

PostgreSQL

PostgreSQL是一种不同于MySQL的数据库. 由于数据库都使用SQL语言, 因此在基本功能上都大致相同, 但PostgreSQL具有如下的一些特殊能力

  1. 支持存储数组数据
  2. 支持存储JSON, 并针对JSON有特殊优化, 支持对其中的字段建立索引, 使用二进制存储JSON数据等
  3. 支持存储和快速查询几何信息(例如坐标)
  4. 全文索引
  5. 更完善的SQL标准支持(数据完整性与约束等)

如果业务需要上述功能, 那么可以考虑使用PostgreSQL. 否则如果仅需要简单的存储服务, 那么MySQL还是更成熟易用.

Siphash算法

SipHash是由BLAKE算法的设计者Jean-Philippe Aumasson等人于2012年设计的，它是一类针对短消息设计的伪随机函数族，可用于消息认证，用途一般与MAC算法相似。

SipHash算法通过让输出随机化，能够有效减缓哈希洪水攻击凭借这一点，它逐渐成为Ruby、Python、Rust等语言默认的Hash表实现的一部分。

规则学习

规则学习是机器学习的一个子领域，专注于从数据中学习出能够描述数据分布所隐含的客观规律或领域概念的规则。这些规则通常以“如果…那么…”的形式表示，能够用于对未见示例进行判别

经典类型的规则学习算法与一般性的深度学习相比, 似乎并无明显优势. 唯一的优势是更加具备可解释性. 但如果是多个因子的复杂组合, 那么其可读性也未必比深度学习 有多高.

SIMD如何加速JSON反序列化

SIMD（单指令多数据）通过并行处理多个字符来加速JSON反序列化，尤其是在扫描结构字符（如引号、冒号）和批量处理数据时效果显著。以下是一个简化示例：

假设需要解析JSON字符串："name":"John"，目标是快速定位键值对的分隔符冒号 :。

传统逐字符扫描

1
2
3
4
5
6
const char* str = "\"name\":\"John\"";
for (int i = 0; i < strlen(str); i++) {
    if (str[i] == ':') {  // 逐个字符比较
        return i;          // 找到冒号位置
    }
}

SIMD优化示例（伪代码）

使用SSE指令集（128位寄存器，一次处理16个字符）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <emmintrin.h>  // SSE2头文件

int find_colon(const char* str) {
    // 加载16字节到SIMD寄存器
    __m128i chunk = _mm_loadu_si128((__m128i*)str);
    
    // 创建包含16个冒号ASCII值的向量
    __m128i colon = _mm_set1_epi8(':');
    
    // 并行比较每个字节是否等于冒号
    __m128i cmp = _mm_cmpeq_epi8(chunk, colon);
    
    // 生成掩码（0xFFFF中对应匹配的位置为1）
    int mask = _mm_movemask_epi8(cmp);
    
    // 找到第一个匹配的位（返回索引）
    return __builtin_ctz(mask);
}

关键优化点

  1. 批量比较：一次比较16个字符，而非逐个检查。
  2. 快速掩码生成：通过位操作（如__builtin_ctz）快速定位匹配位置。
  3. 减少分支预测失败：避免循环中的条件判断。

实际应用场景

• 结构字符扫描：快速定位{}, [], ,, :等符号。
• 转义字符处理：批量搜索反斜杠\的位置。
• 数值解析：并行处理数字字符（如"value":1234中的1234）。

性能对比

• 传统方式：需循环N次（时间复杂度O(N)）。
• SIMD方式：仅需N/16次循环（理论加速16倍，实际受内存对齐等因素影响）。

通过将重复性字符操作向量化，SIMD显著减少了JSON解析中耗时的扫描步骤。

SIMD加速JSON解析的实践与思考

JSON解析常被认为难以利用SIMD加速, 因为其包含大量分支跳转（处理转义字符、类型推断、括号匹配等）。但现代解析器通过架构分层设计, 在特定环节实现了3-5倍的SIMD加速。我们通过几个关键优化点来解析这个矛盾。

阶段分离策略
高效解析器的核心是将任务拆分为两个阶段:

1
2
3
4
5
6
7
8
9
10
// 阶段1: SIMD预扫描 (向量化友好)
simd_buffer = load_64bytes(json);          // AVX-512加载
quote_mask = simd_check_quotes(simd_buffer); // 批量检测引号
struct_mask = quote_mask ^ (quote_mask >> 1); // 生成结构位图

// 阶段2: 语义解析 (分支密集型)
while(!struct_mask.empty()) {
   if(current_char == '"') handle_string();  // 不可避免的分支
   else if(isdigit(*p)) parse_number();      // 类型判断
}

第一阶段用SIMD批量处理结构化标记, 实测占整体耗时的35%-50%。第二阶段虽然存在分支, 但通过预先生成的位图减少了50%以上的冗余判断。

关键优化技术对比

优化手段 传统方案 (ns/op) SIMD优化后 (ns/op) 加速比
引号匹配 82 19 4.3x
数字解析 67 28 2.4x
转义字符处理 113 105 1.1x
整体解析 420 155 2.7x

测试数据: 100KB嵌套JSON, Ice Lake平台

突破分支限制的实践
在必须保留分支的场景下, 通过掩码运算重构逻辑:

1
2
3
4
5
6
7
// 传统分支写法
if (ch == '"') { in_string = !in_string; }

// SIMD友好改写
const __m512i quote = _mm512_set1_epi8('"');
__mmask64 mask = _mm512_cmpeq_epi8_mask(input, quote);
in_string ^= (mask >> bit_offset) & 0x1;  // 位运算代替分支

这种方法在解析10万级键值对时, 分支预测失败率从18%降至3.7%。

混合架构的价值
simdjson等领先解析器的设计启示:

  1. 分层处理: SIMD负责结构扫描, 标量代码处理业务逻辑
  2. 内存优化: 通过位图记录结构偏移, 避免二次扫描
  3. 并行试探: 对数值类型预转换, 失败时回退到稳健解析
1
2
3
解析流水线示例:
原始字节 → SIMD标记层 → 结构位图 → 类型推测 → 最终DOM树
           (3.8 cycles/byte)   (分支密集)   (内存敏感)

取舍的艺术
SIMD在JSON解析中的实践证明了工程优化的典型特征: 在局部热点上集中火力。当某个子任务满足以下特征时, 就值得尝试SIMD加速:

  1. 数据处理量占比 >20%
  2. 可转换为位/掩码操作
  3. 能通过预计算减少后续工作

这种针对性优化使得现代解析器在保持通用性的同时, 性能逼近手动编写的二进制协议解析器, 为数据密集型应用提供了重要助力。

SIMD性能对比

Linux平台, AMD EPYC 7763 64-Core Processor, 2核心

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@LiZeC123 ➜ /workspaces/C_and_CPP/AVX2/CALC (master) $ ./no_simd 
Array size: 16777216 floats
Normal version: 0.1412 seconds
SIMD version:    0.0811 seconds
Speedup: 1.74x
Result valid: Yes

@LiZeC123 ➜ /workspaces/C_and_CPP/AVX2/CALC (master) $ ./auto_vec
Array size: 16777216 floats
Normal version: 0.1038 seconds
SIMD version:    0.0796 seconds
Speedup: 1.30x
Result valid: Yes

@LiZeC123 ➜ /workspaces/C_and_CPP/AVX2/CALC (master) $ ./manual_simd
Array size: 16777216 floats
Normal version: 0.1448 seconds
SIMD version:    0.0776 seconds
Speedup: 1.87x
Result valid: Yes

Mac平台, M4 Pro, 14核心

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ ./no_simd 
Array size: 16777216 floats
Normal version: 0.0621 seconds
SIMD version:    0.0166 seconds
Speedup: 3.73x
Result valid: Yes

$ ./auto_vec
Array size: 16777216 floats
Normal version: 0.0309 seconds
SIMD version:    0.0198 seconds
Speedup: 1.55x
Result valid: Yes

$ ./manual_simd
Array size: 16777216 floats
Normal version: 0.0357 seconds
SIMD version:    0.0192 seconds
Speedup: 1.86x
Result valid: Yes

使用SIMD可以比较明显的获得加速效果, 甚至手动写的代码比编译器的自动向量化的效果更好.

Maglev：谷歌的“拍卖算法”如何让流量调度稳如磁悬浮？

当你的服务器集群每分钟要处理上亿请求，节点还在不断上下线时，传统负载均衡器可能瞬间崩溃——但谷歌用一张“智能座位表”和巧妙的拍卖机制实现了近乎无损的流量迁移。

场景痛点
设想你运营着庞大的数据中心，每天处理数十亿请求。突然，一个后端节点宕机，传统轮询或一致性哈希会导致海量连接断链重试；新节点加入时，流量分配不均又可能压垮旧节点。这种场景下，连接保持性（Connection Persistence）与动态均衡成为核心需求。而Google在2016年开源的 Maglev 负载均衡算法，正是为此而生。

核心原理：一张“拍卖”生成的智能映射表

Maglev 的核心是构建一个大小为 M（远大于节点数 N 的质数，如65537）的查找表。其精妙之处在于生成过程：

  1. 每台服务器提交“心愿单”
    每台服务器通过哈希生成专属的 M 个偏好位置，组成自己想要的“座位号”序列。例如：

    • 节点 A 的偏好：[3, 1, 4, 0, 2] （最想要位置3，然后是1、4…）
    • 节点 B 的偏好：[2, 0, 1, 4, 3]

  2. 全局拍卖：谁最想要这个位置？
    系统按位置顺序（0→M-1）进行“拍卖”：

    • 步骤1：查看位置 k=0，问所有节点：“你们当前最想要且未被占的位置是0吗？”
    • 步骤2：
      • 若仅一个节点举手（如C的首选是0），则位置0归它。
      • 若多人举手，选ID最小的节点（公平裁决）。
      • 若无人举手，强制指派ID最小的节点。
    • 步骤3：中标节点消耗此次“心愿”，其心愿单指针移向下一位。继续拍卖位置 k=1。

▶️ 最终效果：
所有位置被分配给最渴求它（或妥协接受）的节点，每节点获得约 M/N 个位置。例如下表中，5个位置被2个节点瓜分：

1
2
位置 k:  0   1   2   3   4  
初始分配: A   A   B   A   A   // A占80%流量，B占20%

动态调度的魔力：节点变更时发生了什么？

场景1：节点B宕机（剔除失效节点）

  • 动作：系统检测到B下线，用剩余节点 A 重建表。
  • 新表结果：
    1
    2
    位置 k:  0   1   2   3   4  
    新分配:  A   A   A   A   A   // 所有位置归A
  • 流量迁移：
    仅原指向 k=2（旧B）的连接（占总量 20% ）会被迁移至A，其余 80% 连接无感切换！

场景2：新增节点C（动态扩容）

  • 动作：添加节点C（假设偏好：[0, 2, 3, 1, 4]），A/B/C共同拍卖。
  • 新表结果：
    1
    2
    位置 k:  0   1   2   3   4  
    新分配:  C   A   B   C   A   // A占40%, B占20%, C占40%
  • 流量迁移：
    • 原指向 k=0 和 k=3 的连接（占 40% ）从A转向C。
    • 其余 60% 连接保持原路径（k=1→A, k=2→B, k=4→A）！

✅ 关键结论：无论扩缩容，影响比例 ≈ 1/当前节点数。千节点集群中，单节点变更仅扰动约0.1%流量！

为何选择Maglev？谷歌级调度三优势

  1. 超高连接保持性
    传统轮询在节点变更时全连接震荡，Maglev 保证超 90%+ 的连接稳定。

  2. O(1) 超低开销
    查表操作仅需一次内存访问，支持硬件加速百万级TPS调度。

  3. 逼近完美的均衡性
    偏好列表的随机性 + 大表尺寸M，使流量分配标准差近乎于0。

现实世界的应用

如今，Maglev 已从Google内网走向开源世界：

  • Kubernetes：作为 kube-proxy 的IPVS调度算法
  • 服务网格（如Istio）：处理东西向流量
  • CDN调度层：应对边缘节点频繁变更

“它就像交通管制中心——车辆（流量）按固定路线（查找表）行驶，即使新增道路（节点）或封闭路段（宕机），95%的车辆也无需改道。” —— 某大型云架构师笔记

结语
Maglev 用一张动态生成的“智能座位表”，在分布式系统的流量调度领域实现了优雅的平衡。下次当你访问谷歌服务却未感知后端变更时，或许正受益于这场精妙的“位置拍卖”。（延伸阅读：《https://research.google/pubs/pub44824/》）

查看DNS服务的IP地址

在Window平台执行如下指令查看DNS服务的IP地址

1
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize

例如

1
2
3
4
5
6
7
InterfaceAlias              InterfaceIndex AddressFamily ServerAddresses
--------------              -------------- ------------- ---------------
vEthernet (以太网 2)                    33 IPv4          {}
vEthernet (Default Switch)              38 IPv4          {}
以太网 2                                11 IPv4          {192.168.1.1}
蓝牙网络连接                            13 IPv4          {}
Loopback Pseudo-Interface 1              1 IPv4          {}

编译器如何帮助CPU更好的实现分支预测

总所周知, 分支预测的准确性对于CPU的执行性能有很大的影响, 而GCC提供了 likely(x) 和 unlikely(x) 宏来实现分支预测的提示. 那么GCC是怎么做到的呢?

GCC 的分支提示 (likely/unlikely) ​​不直接​​向硬件预测器发送命令或设置其内部状态。它无法控制预测器在运行时如何做决策。但通过改变代码布局，GCC 使得

  • 对于标记为 likely 的条件，其最可能路径（then）正好是硬件预测器​​默认倾向预测​​的路径（fall-through）。
  • 对于标记为 unlikely 的条件，其最可能路径（else）也正好是硬件预测器​​默认倾向预测​​的路径（fall-through）。

这样，硬件预测器的​​静态预测策略​​（通常是预测 fall-through 或向后跳转为 Taken，向前跳转为 Not-Taken）就能在第一次或模式不明确时，更大概率地猜中实际的分支走向。预测器会​​持续学习​​分支的历史行为（动态预测），但一个好的初始布局（由编译器根据提示生成）可以减少预测器学习过程中的错误预测次数。

有趣的项目推荐

Github使用

免费开发环境

每月可免费使用120核心小时的服务器资源. 停止运行后, 不计算核心小时资源, 仅计算存储资源.

默认启用2核心服务器, 可使用60小时, 平均每天可使用2小时. 30min无操作自动关闭, 几乎等于无限制使用.

Calibre优化

书籍样式修改

对于EPUB格式的数据, 实际上就是压缩格式的HTML代码, 因此可以使用HTML的技术进行修改, 例如调整文字行间距, 可使用属性

1
<p style="line-height:1.5;">

将行间距调整为1.5倍

机器学习

大模型提示词

  • 赛博人格分裂，(启动人格分裂讨论模式+问题)
  • 阴阳怪气模式，(问题+笑死)毒舌属性
  • 触发预判模式，假设性问题(如果，，，会不会，，，)
  • 预言家模式，预判未来(如果，，，会发生什么)
  • 灵魂拷问模式，(①启动杠精模式②先写方案，再模拟杠精从*个角度狂喷，最后给出V2版方案)，
  • 玄学编程(，，，带点蝉意)
  • 驯服转业话痨，(说人话！)
  • 人设粘贴术，
  • 启动老板思维(如果你是，，，你会怎么骂这个方案)
  • 过滤废话，(问题，+删掉所有正确的废话，只留能落地的建议)

高性能服务设计原则

无状态, 轻重分离, 消息队列, 缓存.

无锁化: 串行无锁 结构无锁
零拷贝: 内存映射 零拷贝
序列化: 性能 选型
池子化: 内存池 线程池 连接池 对象池
并发化: 请求并发 请求冗余
异步化: 调用异步化 流程异步化
缓存: 使用场景 回收策略 清理与修复
分片: 分片策略 二级索引 路由策略 动态平衡 分库分表 任务分片
存储: 读写分离 动静分离 冷热分离 重写轻读 数据异构
队列: 异步处理 流量削峰 系统解耦 数据同步 柔性事务
监控: 指标监测 指标告警
限流: 限流熔断 负载均衡

最后更新： 2026年09月08日 16:28

版权声明：本文为原创文章，转载请注明出处

原始链接： https://lizec.top/2010/01/01/%E4%B8%AA%E4%BA%BA%E7%9F%A5%E8%AF%86%E5%BA%93%E4%B9%8B%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%8A%80%E6%9C%AF/