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

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

计算机类一般性知识

摩尔定理的直观感受

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

macOS签名校验与SIP机制

macOS拥有内核级强制分页实时代码签名校验机制，这也是修改二进制文件后程序常被Killed:9的核心原因。该机制并非在程序启动时对全文件进行校验，而是在程序运行过程中，按需将内存页加载到内存时，实时校验该页哈希与二进制签名中记录的哈希是否一致，一旦发现不一致，内核会直接发送SIGKILL信号终止进程。

这一签名校验机制在Go与C程序上的表现差异显著。Go程序从1.14+版本开始，编译时会通过自带的链接器自动为二进制文件打上ad-hoc签名，且其字符串常量会存放在代码签名的强校验段中，因此修改Go程序的二进制内容后，极易触发校验失败，导致程序运行中被终止；而在Mac上使用clang/gcc编译的C程序，默认不会添加任何代码签名，即便修改其二进制内容，也不会触发内核的签名校验，可直接正常运行。

此外，macOS的SIP（系统完整性保护）作为内核级安全锁，进一步强化了系统安全。它的核心作用是限制即使是root用户，也无法修改/System、/usr等系统目录、注入系统进程，同时还会限制未签名内核驱动的加载。SIP与代码签名机制相互配合形成双重防护，且二者是独立的安全机制，即便关闭SIP，代码签名的校验机制依然会正常生效。

Unix Domain Socket

这是一种网络机制, 相当于一个只能在本机使用的Socket, 提供Sokcet的所有接口, 但内部并不需要经过网卡, 因此可以作为一个高效的进程间通信机制.

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

SOCKET_PATH = "/tmp/my_app.sock"

# 删除旧 sock
if os.path.exists(SOCKET_PATH):
    os.unlink(SOCKET_PATH)

# 创建 socket
server = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
server.bind(SOCKET_PATH)
server.listen(2)

使用Unix Domain Socket需要创建一个文件, 这非常具有Unix风味. 此文件只能使用一次, 一旦进程结束就不可以再次复用, 因此每次启动前需要删除已经存在的文件.

Unix Domain Socket的典型应用场景是访问本地的服务时, 替换掉传统的scoket. 由于数据仅在内核中拷贝, 因此比TCP本地回环还要快. Redis和Mysql等项目在本地连接时就会采用这种机制.

此外, 对于一个命令行程序, 如果想要输出多个流, 也可以使用此机制输出数据, 在其他的进程中读取数据并输出到各自的标准输出.

QUIC协议与弱网条件

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

分析后判断原因如下

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

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

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

台式机与Mac串流方案

家里有一个台式机和一台Mac笔记本, 但是只有一个显示器. 并不想在台式机和Mac之间来回插拔显示器的HDMI线, 因此考虑日常显示器接Mac, 在需要时通过Mac连接到台式机, 而台式机以无显示器的模式启动. 日常工作使用Mac完成, 比较省电, 也能够启动台式机执行必须使用Windows系统的事情.

首先需要安装parsec.app, 在台式机和Mac上均安装此软件后注册一个账号并登录. 默认情况下同一账号下的设备自动可以相互连接. Windows平台需要配置无密码登录, 具体配置路径可查询任意AI.

有文章指出需要安装额外的虚拟显示器驱动才能保证串流正常. 实测parsec会顺便解决此问题, 无需额外安装驱动. (额外安装驱动甚至可能触发其他BUG)

参考资料

效果评价

parsec实际上已经做的比较好了, 但是在我的局域网里面, 网速还是不够快, 画面相较于直接插显示器, 还是模糊不少. 另外由于通信原因产生了10ms左右的延迟, 这个延迟虽然不是很大, 但是可以感知到, 导致体验不佳.

最终的解决方案是购买一条DP线, 台式机使用DP线连接显示器, Mac使用HDMI线连接显示器. 当只有一台设备使用时, 显示器会自动切换信号源, 因此使用上也还算方便.

注意: DP线和HDMI线不一样, DP线接口有卡扣, 需要用力插入确保卡扣卡住才算插入到位.

为了使用一套输入设备在两台机器上使用, 需要购买一套多模的鼠标和键盘. 之前parsec会自动映射mac和window的键位(例如修改Ctrl和Cmd的位置), 但是如果使用同一套键盘, 那就没这能力了. 虽然可以修改windows的键位强行匹配Mac的逻辑, 但我感觉没必要, 用多了就习惯了. 交换一下Ctrl和Win键就可以了, 否则按错的概率还是太大了, 强行习惯得不偿失.

此外, 如果鼠标和键盘均使用无线接收器, 那么需要将两个接收器分开. 否则可能存在信号干扰, 导致鼠标出现明显的卡顿. 建议将键盘的无线接收器插入机箱后端的接口, 将鼠标的无线接收器插入机箱前端的接口.

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还是更成熟易用.

Mac系统配置

Ubuntu环境

对于Mac平台, 可以通过multipass创建一个Ubuntu虚拟机, 然后在虚拟机内安装和测试一些软件. 这一操作类似于Docker的容器, 如果玩坏了可以快速重新创建镜像. 虽然绝大部分项目也可以在Mac上编译和运行, 但Ubuntu具有更好的通用性. 而且在虚拟机内操作无需考虑依赖冲突问题, 可确保mac本身更稳定.

注意: 实际上, 由于multipass不支持创建镜像, 因此不建议在虚拟机内执行太多初始化指令. 可考虑把大部分操作在宿主机完成, 然后将项目挂载到虚拟机之中. 例如直接在宿主机执行Git操作, 从而在虚拟机内不需要再配置ssh.

基于docker或者podman的方案属于虚拟机套虚拟机, 配置过于复杂, 不推荐使用该方案.

依赖安装

  1. 能手动安装的全部手动安装. 下载安装包只需要浏览器能正常访问即可, 依赖最小.
  2. 能直接代理搞定的就直接代理搞定, 配置代理通常无需复杂配置, 要么成功要么失败, 能够快速获得结果. 而基于镜像的模式可能由于某些请求不走镜像导致失败.
  3. 对于依赖不是很复杂的项目, 可以尝试源码编译. 通常情况下如果文档提供了编译指引, 那么编译成功的概率还比较大.
  4. 不到最后, 不要尝试使用brew. brew可能由于某些模块强制依赖github或者某些无法访问的网站, 导致进行到最后一步执行失败. 解决这类问题非常困难, 有这折腾的时间, 从源码编译都搞完了,

tldr

这个工具可以用brew安装(在配置了镜像的情况下). 更新tldr数据库有点慢, 也可能会失败. 多重试几次可以成功更新.

Python SSL配置

在Mac安装官网的Python后, 默认不会使用系统的SSL配置, 导致使用网络库访问HTTPS网站时, 可能出现证书校验不通过的问题, 可以在.zshrc中配置如下环境变量

1
2
3
# Python SSL Config
export SSL_CERT_FILE=/etc/ssl/cert.pem
export REQUESTS_CA_BUNDLE=/etc/ssl/cert.pem

调整分辨率

使用Mac外接2K显示器后发现原生的2K分辨率字体太小, 看书写代码都很费劲. 但是如果调整分辨率, 只要不是整数倍分辨率, 都会导致字体模糊. 针对这一问题, 可以安装BetterDisplay.

Mac默认的分辨率调整算法是先渲染到2K, 然后插值到指定的分辨率. 当物理像素和渲染像素无法对齐时只能进行插值. 对于文字这种边缘锐利的场景会产生明显的模糊效果. BetterDisplay则会让Mac原生渲染制定的分辨率, 因此通过该软件调整分辨率后文字显示会变大, 但不会模糊.

对于这个问题Windows还是领先的, 默认的缩放功能在绝大部分常见都不会有任何问题. 反而是Mac直接一刀切, 必须要第三方软件才能解决

此外, BetterDisplay还有很多有用的功能, 例如可以和显示器通信, 直接调节显示器亮度的物理值.

翻转鼠标滚轮

Mac默认的鼠标滚轮逻辑与Windows相反. 如果使用内置的反转功能, 又会导致触摸板的逻辑反过来. 可以安装Scroll Reverser单独翻转鼠标滚轮.

也有一些鼠标原生支持识别操作系统, 并在Mac上自动反转, 不过这些鼠标都比普通鼠标贵很多. 这样比较下来, 使用软件解决就很香了.

图片编辑

在Mac平台并没有类似Paint.net这样好用的工具, 但存在GIMP这样对标Photoshop的软件. 操作逻辑与Paint.net略有一些差别

  1. 保存为图片并不是选保存, 而是选导出. 导出时可以选择图片格式.
  2. 调整图片大小不是调整画布, 而是缩放图片

反正这名字也合理吧, 习惯就好. 只能说.net提供的能力太强了, 所以Paint.net也很强

视频播放

Mac自带的视频播放器支持的格式比较少, 许多已经算常见的视频格式还是不支持播放. 可以下载IINA作为默认的视频播放器, 这个软件比较有苹果的风格.

对于各类视频格式的文件, 可以右键选择默认打开方式, 选择IINA并应用所有相似的格式.

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年05月03日 19:33

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

原始链接： 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/