- 博客(871)
- 资源 (31)
- 收藏
- 关注
RSS订阅
原创 c语言链表（插入，删除，更改，查找）
初始化链表int main( ) { int i; struct link // 定义链表的类型 { int data; // 数据区 struct link *next; // 地址区用来存放下一个元素的地址 }; struct link *p = (struct link *) malloc(sizeof(struct link)); // 创建一个头结点 就是指向链表的第一个元素 struct link *te
2021-05-12 23:31:04
5430
16
原创 server_name是怎么匹配的？1000行源码揭秘Nginx静态哈希表的5个精妙设计
12163841000712和区分两种规模的键值管理数组：小表初始容量4、冲突检测数组大小107，适用于少量server_name的场景；大表初始容量16384、冲突检测数组大小10007，适用于大规模虚拟主机配置。表示当前key可能是通配符格式（需要特殊处理），表示key的内容不能被修改（不做大小写转换）。哈希表的桶数量选择是一个经典问题：桶太少，每个桶里挤满了元素，查找退化为线性扫描；桶太多，大量空桶浪费内存。
2026-02-21 20:43:50
3
原创 Nginx源代码学习：六种算法、六个文件、两千行C——Nginx负载均衡的全部秘密
写过Nginx配置的人对这个upstream块不会陌生：一行，Nginx就知道该用IP哈希来分配请求。换成、、，分别切换到最少连接、一致性哈希、随机选择。再加一行就能缓存到后端的TCP连接，配上就让多个worker进程共享后端状态。这六种能力分别藏在六个文件里，总共不到2500行有效代码（去掉空行和注释）。它们各自独立、各自编译、各自注册，却共用同一套upstream框架接口——负责集群初始化，负责请求级初始化，负责选择后端。这三个函数指针构成了Nginx负载均衡的全部抽象，任何新算法只要实现这三个回调就
2026-02-20 14:39:53
4
原创 Nginx源码分析：一个HTTP请求的安检之旅——Nginx ACCESS_PHASE源码全景
Nginx选择"简单正确"而不是"优化但复杂"，这是典型的工程判断。原因很直觉——子请求是Nginx内部发起的，不应该再被主请求的访问控制规则拦截，否则auth_request就会死循环：主请求触发认证子请求，认证子请求又触发新的认证子请求，永远走不出来。这种"不做判断就弃权"的约定让模块之间零耦合——access模块不知道auth_basic存在，auth_basic不知道auth_request存在，它们各自只关心自己的配置和逻辑，组合方式完全由checker和satisfy决定。
2026-02-19 07:55:48
17
原创 红黑树+事件驱动+DNS协议：Nginx解析器5000行源码的架构设计课
Nginx在DNS报文头固定12字节，包含6个16位字段。注意Nginx没有用uint16_t来定义这些字段，而是把每个16位字段拆成两个u_char（高字节和低字节）。这个选择不是随意的——DNS协议使用网络字节序（大端），如果用uint16_t，在小端机器上需要调用ntohshtons做字节序转换；而用两个u_char手工拆分后，在任何平台上都能正确组装出16位值，完全消除了字节序依赖。这种"逐字节解析避免字节序问题"的技巧在网络编程中非常实用。
2026-02-19 07:47:45
14
原创 worker进程之间怎么共享数据？从限流计数器到Nginx Slab分配器的完整实现
地址计算宏sizeofslots数组紧跟在结构体之后。这个宏计算slots数组的起始地址。-><<uintptr_t->这个宏完成从页面管理结构到实际数据页面地址的转换。得到页面索引，左移位（乘以页面大小）得到字节偏移，加上得到实际地址。平台相关常量（64位系统）032（低4位）：提取BIG类型页面中存储的shift值。（高32位）：提取BIG类型页面中的位图部分。（32）：位图在slab字段中的起始位置。（最高位）：标记PAGE类型的首页。（全1）：EXACT类型页面已满的标志。
2026-02-17 23:37:21
10
原创 从Initial包到连接迁移：拆解Nginx QUIC模块的13个源文件，看一个生产级QUIC协议栈是怎么炼成的
这些代码覆盖了QUIC协议的方方面面：从Initial包的解析到连接迁移的处理，从TLS 1.3握手集成到CUBIC拥塞控制，从变长整数编解码到eBPF连接分发——几乎把RFC 9000、9001、9002、9438涉及的所有机制都实现了一遍。整篇文章按照一个QUIC连接的生命周期来组织——从收到第一个UDP包开始，到连接关闭为止，每一步涉及哪些源文件、哪些函数、做了什么RFC合规性检查，一个不落。每一行代码都有它存在的理由——要么是RFC合规性要求的，要么是安全性必须的，要么是性能优化驱动的。
2026-02-16 17:19:05
46
原创 用纯C写出面向对象：Nginx连接管理与地址解析源码中的9个设计模式
C语言没有class，没有virtual，没有template，没有继承，没有多态——至少语法层面上没有。但翻开Nginx的连接管理模块（）和网络地址模块（），你会发现一件有意思的事：这3500行纯C代码里，函数指针充当虚函数表、联合体充当多态容器、空闲链表充当对象池、位域充当状态机——几乎每一个面向对象的核心概念，都能在这里找到对应的纯C实现。而且不是那种"为了演示可以这么写"的教学代码，而是真正支撑着Nginx处理百万级并发连接的生产代码。这四个文件解决了两个Nginx最底层的工程问题。第一个是连接管理
2026-02-15 19:15:36
62
原创 Nginx源码阅读：深入Nginx代理模块群：从FastCGI到gRPC，五大协议代理的源码级拆解
Memcached模块实现了自己的响应体过滤器，因为Memcached响应末尾有个sizeof1过滤器用rest字段追踪还有多少尾部字节要丢弃。数据完整接收后设允许连接复用。Memcached（737行）只读的文本协议代理。没有参数传递、请求体转发、SSL、缓存——但它是理解upstream框架最好的入门教材。SCGI（2135行）最朴素的请求代理。netstring编码简单直接，却支持完整的参数传递和缓存。uWSGI（2754行）在SCGI基础上加了二进制帧头和SSL，复杂度适中。
2026-02-14 00:57:28
31
原创 Nginx源码学习：拆解ngx_process_events_and_timers：Nginx百万并发的事件驱动引擎是如何运转的
回头看这个事件驱动引擎的全貌。这70行代码是调度中枢，它在每一轮迭代中协调六个子系统——I/O多路复用器收集事件、延迟队列做优先级分发、定时器红黑树管超时检测、accept互斥锁防惊群、连接池做资源管理、事件管道搬运数据。每个子系统都极其精简：定时器模块不到130行，延迟队列不到60行，连接池初始化不到50行。但组合在一起，就是能扛百万并发的事件引擎。Nginx事件模块的哲学不是靠某一个环节的极致优化来撑，而是让每一个环节都做到"刚好够用且零冗余"。
2026-02-13 21:52:05
13
原创 Nginx源码学习：我学到的4个反直觉设计：为什么C语言老手不用你以为的“标准做法“
void *data;// 指向实际数据每个节点包含一个data指针指向实际数据。这叫"非侵入式"设计——链表实现和数据结构完全解耦。Nginx的两个指针，16字节，没有任何数据字段。它要求使用者把节点嵌入到自己的结构体内部，然后通过offsetofoffsetofint value;// 嵌入的链表节点// 从链表节点反向获取宿主结构体这个技巧在Linux内核中无处不在——宏做的就是同样的事情。已知成员地址和成员在结构体中的偏移量，减一下就得到了结构体首地址。
2026-02-12 16:41:00
18
原创 Nginx源码学习：多进程不共享内存？Nginx说不——从200行底层封装到百万级连接的共享内存全链路拆解
用Nginx做过限流的人应该都写过类似这样的配置：一行配置，Nginx就能对每个IP做精确限流，哪怕你开了8个worker进程。但你有没有想过一个问题：Nginx的master进程fork出多个worker之后，每个worker拥有独立的虚拟地址空间。fork刚完成的那一刻，父子进程的页表其实指向同一组物理页面；但一旦某个worker对某页执行写操作，内核的写时拷贝（Copy-on-Write）机制就会为该worker创建一份独立的物理页面副本。之后worker A看到的变量x和worker B看到的变量
2026-02-11 20:38:41
42
原创 Nginx源码学习：共享内存里的两棵红黑树——Nginx限流模块数据结构源码全景
Nginx红黑树的接受三个参数：树指针、哨兵指针和insert函数指针。Nginx提供了默认的，它只比较node->key（类型为，即ngx_uint_t——64位系统上是8字节无符号整数）。但限流模块的key是变长字符串（IP地址、URI等），不能用一个整数完整表示——虽然这里存的是CRC32哈希值（32位），但哈希碰撞不可避免，必须有第二级比较。两个模块的方案一致：用key的CRC32哈希值作为node->key存入红黑树，但CRC32有碰撞的可能——两个不同的key可能算出相同的哈希值。
2026-02-10 13:31:22
40
原创 Nginx源码分析：current_weight、fail_timeout、cache_valid——三个字段撑起Nginx整个反向代理
三个子系统在这个流程中各司其职：负载均衡决定了回源的目标，故障转移保证了个别后端不可用时的服务连续性，缓存系统则在源头上减少了回源的次数。不走流水账式的代码逐行翻译，而是聚焦每个子系统最精华的数据结构和算法——加权轮询怎么做到"平滑"、故障转移的状态机长什么样、缓存系统怎么用红黑树+LRU+共享内存撑起高并发场景。当peer因为故障被降低了有效权重后，每次参与选择时都会+1慢慢恢复，实现了一种渐进式的回归机制——不是一下子恢复满血，而是一次加一点，让故障恢复后的peer逐步承担更多流量。
2026-02-09 18:09:50
65
原创 Nginx源码学习：Nginx的“内部电话系统“，Master如何用5条命令指挥Worker
整篇文章走完了Nginx channel机制的全部源码。的4个字段、socketpair的6步初始化、sendmsgrecvmsg的SCM_RIGHTS控制消息、5条命令的完整生命周期、的无限循环读取、Worker初始化时的精确fd清理——一个不漏。回到最初的问题：Master怎么告诉Worker该干嘛？答案是250行C代码：一个socketpair建起全双工管道、一个4字段结构体封装消息格式、4个API函数完成收发和事件注册、5条命令覆盖进程生命周期的所有管理场景。
2026-02-08 13:05:17
30
原创 malloc每秒百万次调用扛不住？看Nginx如何用500行代码打造零碎片内存池
116102416ngx_alignsizeofngx_pool_t2sizeof：小块分配的最大尺寸上限，等于一个内存页大小减1。在x86上，为4096，所以这个值是4095字节。任何超过4095字节的分配请求都会走大块内存路径。：默认的池大小，16KB。在Nginx的HTTP模块中，请求级别的内存池大小可以通过指令配置。：池的对齐边界，16字节。通过按此对齐方式分配内存。：池的最小大小，等于ngx_pool_t加上两个的大小，再对齐到16字节。
2026-02-07 16:46:08
57
原创 Nginx源码学习：逐行拆解Nginx UDP事件处理框架：1200行代码背后的高性能设计
说了这么多，我们来回顾一下Nginx UDP事件处理框架的核心设计。在无连接协议上构建连接抽象。UDP本身无连接，但业务层需要会话状态。Nginx用结构和红黑树索引，在无连接的UDP上硬生生造出了"虚拟连接"——同一客户端的所有包都路由到同一个连接对象。精妙的内存管理。静态缓冲区省去每次分配内存的开销，内存池cleanup自动删除红黑树节点，键值直接指向连接地址不拷贝。每个细节都在抠性能。平台适配做得干净。条件编译封装差异，联合体适配不同结构，上层代码只需检查一个宏。新增平台支持改一处就行。
2026-02-05 14:06:13
18
原创 Nginx epoll封装的10个神级优化：1052行代码，扛住百万并发
接口应该足够抽象，不暴露底层细节。ngx_epoll_module.c这1052行代码，展示了如何把简单的epoll API封装成一个健壮、高效、可维护的事件模块。关键技术点：instance机制：用位运算解决stale event问题EPOLLRDHUP检测：运行时探测内核特性eventfd通知：跨线程/跨进程的轻量级通信AIO集成：把异步文件I/O统一到事件循环POST模式：支持事件优先级和accept_mutex接口稳定，实现灵活运行时检测优于编译时假设完备的错误处理。
2026-02-04 15:46:30
25
原创 逐行拆解Nginx事件管道：1147行代码背后的高性能设计，从ngx_event_pipe源码看如何实现零拷贝代理
分析完1147行代码，让我们总结的设计哲学和性能优化技巧。不是靠更多的线程，而是靠更聪明的设计。该分配内存时分配，该复用时复用该等待时等待，该放弃时放弃该用磁盘时用磁盘，该用内存时用内存这种对资源的精准控制，值得每一个追求高性能的开发者学习。
2026-02-03 15:07:01
26
原创 Nginx源代码学习：为什么Nginx能处理百万并发？从112行源码看延迟事件队列的精妙设计
极简的双向链表结构。只有两个指针：prev指向前一个节点，next指向后一个节点。这里没有数据字段。数据在哪？在包含这个的外层结构体中。这就是侵入式设计的精髓。现在进入正题。先看头文件，它定义了操作延迟事件队列的宏和函数声明。三个全局队列的定义。它们在回顾一下这112行代码教会了我们什么。核心设计：三个全局队列（accept事件、普通事件、下一轮事件）、两个宏（入队和出队）、两个函数（处理队列、合并队列）。就这么简单。关键价值解耦事件收集与处理，锁持有时间最小化。
2026-02-02 14:59:39
23
原创 看懂Nginx源码才发现：我和高手的差距不在算法，而在Reactor模式
回到开头的问题：我和高手的差距在哪里？不在算法。Nginx没用什么高深的算法，红黑树是最复杂的了，而且是复用的通用实现。不在数据结构。链表、数组、红黑树，都是基础数据结构。而在设计模式。知道在什么场景用什么模式，如何组合使用多个模式解决复杂问题——这才是高手和普通程序员的区别。理解核心思想：事件驱动 + 非阻塞I/O掌握关键组件：事件循环、事件分发、回调机制学习工程实践：连接池、定时器、多进程架构领悟设计哲学：预分配、接口抽象、简单稳定如果你想写出高性能的服务器代码，不要只盯着算法和数据结构。
2026-02-01 16:22:47
28
原创 Nginx处理10万并发时，CPU在干什么？源码级解析异步非阻塞
很多人会问：为什么Nginx用多进程而不是多线程？第一，稳定。进程之间内存隔离，一个Worker崩了不影响其他Worker，Master会自动拉起新的。多线程的话，一个线程崩溃可能把整个进程带走。第二，简单。多进程不用考虑线程安全，不用加锁，代码简单，Bug少。Nginx追求的是"稳定"，多进程正好符合这个目标。第三，性能。在Linux上，进程切换的开销和线程切换差不多——Linux的线程本质上就是轻量级进程。
2026-01-31 17:02:06
21
原创 跟着源码走一遍：从sk_buff到ngx_event_t，用500行核心代码讲透Linux网络收发与Nginx事件
* 事件结构体：对应一个可监控的I/O事件 */void *data;/* 通常指向ngx_connection_t *//* 是否是写事件 *//* 是否是accept事件 *//* 事件是否活跃（已加入epoll） *//* 事件是否就绪 *//* 是否收到EOF *//* 是否有错误 *//* 是否超时 *//* 是否设置了定时器 *//* 待处理的EOF *//* 是否在posted队列中 *//* 事件处理函数指针 *//* 红黑树节点，用于定时器 */
2026-01-29 15:42:43
24
原创 Nginx架构学习：为什么Nginx不怕“一拥而上“？深入源码揭秘平滑加权轮询的精妙设计
写到这里，深入剖析了Nginx负载均衡的核心实现。做个总结。
2026-01-28 15:51:51
22
原创 我用200行代码手写了一个协程库，才真正理解了线程切换
上下文切换的本质，就是保存和恢复CPU的执行状态。把当前的寄存器值保存到某个数据结构从另一个数据结构加载寄存器值跳转到保存的指令地址继续执行保存在哪——用户态保存在用户堆/栈，内核态保存在内核task_struct；谁来保存——用户态是自己的代码，内核态是内核代码；保存多少——用户态只保存必要的，内核态保存全部的；切换时机——用户态是主动让出，内核态可以被抢占。理解了这个本质，再去看任何协程库、纤程库的实现，都能很快抓住要点。
2026-01-27 18:11:46
21
原创 Linux网络栈太慢？DPDK如何做到100倍性能提升
让我们回顾一下这篇文章的核心内容。中断开销数据拷贝（内核态↔用户态）协议栈处理开销上下文切换锁竞争问题DPDK的解决方案中断开销轮询模式驱动（PMD）数据拷贝内核旁路 + 零拷贝 + 用户态驱动协议栈处理绕过内核协议栈，用户态自定义处理上下文切换用户态轮询，避免系统调用锁竞争无锁数据结构（rte_ring）+ Per-lcore缓存TLB MissHugePages大页内存Cache MissNUMA感知 + CPU亲和性 + 缓存行对齐。
2026-01-26 16:28:48
27
原创 手撕 Linux 内核定时器：从 timer_list 到分层时间轮的完整链路
在 Linux 内核中，每个定时器用表示。// 链表节点，用于挂载到时间轮的槽位// 到期时间（单位：jiffies）// 回调函数u32 flags;// 标志位看起来很简洁对吧？entry：这是一个哈希链表节点。时间轮的每个槽位（slot）是一个链表头（hlist_head），多个定时器通过 entry 串成链表。为什么用而不是普通的list_head？因为hlist_head只有一个指针（first），而list_head需要两个指针（prev和next。
2026-01-25 02:51:26
30
原创 手撕B+树源码：从原理到C++实现，这篇文章够你吃透
B+树的节点分为两种：内部节点（Internal Node）和叶子节点（Leaf Node）。
2026-01-24 15:06:39
26
原创 深入KCP源码：一个2000行C实现，凭什么比TCP快40%？逐行拆解ARQ算法精髓
优化点TCP的做法KCP的做法效果RTO计算超时后RTO翻倍快速模式下只×1.5减少超时重传延迟最小RTO通常200ms+可配置到10ms更快检测丢包重传策略Go-Back-N选择性重传减少无效重传确认机制只用UNAUNA+ACK混合更精确的丢包判断延迟确认40-200ms可禁用更快触发重传拥塞控制丢包后窗口减半可选关闭稳定吞吐量这些优化的代价是什么？带宽占用增加10%-20%：因为更激进的重传策略和更小的包间隔对网络不友好。
2026-01-23 16:14:39
37
原创 为什么大厂都用消息队列？一文讲透分布式MQ原理与C++实战
/ 消息结构// 注意：成员初始化顺序必须与声明顺序一致，这是 C++ 的规定// 消息键（用于分区路由）// 消息内容// 所属主题// 消息偏移量// 时间戳// 所属分区, topic()// 发送结果SEND_OK,到这里，我们已经从"为什么用消息队列"聊到了"怎么实现一个消息队列"，覆盖了概念、架构、可靠性、性能优化和选型等方方面面。最后，我总结一下全文的核心要点，并附上一些常见的面试问题供你参考。为什么用消息队列？解耦：服务间通过消息通信，互不感知。
2026-01-22 15:01:48
27
原创 字节面试官：问你C++观察者模式，你答了7点他说不够深
如果让你重新回答，你会这样子说了：C++实现观察者模式比其他语言多了不少坑，核心难点在于没有GC的情况下如何安全地管理观察者的生命周期和处理各种边界情况。接口设计：虚函数 vs std::function，根据灵活性需求选择注册机制：返回RAII封装的Subscription，自动管理订阅生命周期3. 生命周期：用weak_ptr或RAII避免悬垂指针4. 迭代器失效：通知时增删观察者要用副本或延迟删除5. 线程安全：不要持锁调用回调，避免死锁。
2026-01-21 23:23:08
489
原创 我用C++17实现了一个分布式锁，顺便踩完了SETNX的所有坑
写到这里，这篇文章的主要内容就结束了。分布式锁的核心概念：为什么需要分布式锁，它必须满足的4大特性Redis分布式锁：从SETNX到Redlock，踩过的那些坑（原子性、锁过期、误删、主从切换）etcd分布式锁：Lease机制、强一致性、Fencing TokenC++完整实现：Redis和etcd两种方案的生产可用代码Martin Kleppmann的批评：Redlock的安全性问题，Fencing Token的解决方案方案选择指南：不同场景该选什么方案生产实践经验。
2026-01-21 14:49:47
32
原创 Linux系统编程：内核协议栈，我把网络IO移到用户态后，延迟从毫秒级降到微秒级
用户态协议栈不是新概念。但在云原生和高性能计算的推动下，它正在变得越来越重要。内核协议栈的5大性能杀手：系统调用、数据拷贝、中断处理、锁竞争、上下文切换Kernel Bypass的核心思想：绕过内核，让应用直接访问网卡DPDK的关键技术：PMD轮询、大页内存、CPU绑核、NUMA感知、无锁队列F-Stack的实现原理：移植FreeBSD协议栈到用户态，通过DPDK与网卡交互适用场景：高频交易、电信网关、负载均衡、CDN等高性能网络场景。
2026-01-20 15:24:56
43
原创 C++中虚函数调用慢5倍？深入理解vtable和性能开销
内存访问：读vptr、读vtable，可能触发cache miss间接分支：预测失败有惩罚，类型频繁切换时尤其明显内联失效：丧失进一步优化机会，对短函数影响最大缓存效应：频繁切换类型影响缓存命中率但"慢"是相对的：对于短函数可能慢18%，对于长函数几乎没差别；一次调用多几十纳秒，调用百万次才能感受到。虚函数是C++多态的基础，别因为"听说有性能开销"就不敢用。先写出正确、清晰的代码，等profiler告诉你虚函数调用是瓶颈，再考虑优化也不迟——过早优化是万恶之源。
2026-01-19 23:39:01
703
原创 很多C++程序员不知道：Reactor模式为什么能让HTTP服务器支撑10万并发
别让CPU干等I/O，让它去做更有价值的事。传统的阻塞式编程，CPU大部分时间在等待。等网络数据、等磁盘读写、等用户输入。这些等待是白等，CPU明明可以去处理其他任务，却只能傻傻地停在那里。Reactor模式的革命性在于：它把"等待"从CPU的负担变成了内核的工作。CPU不再等待，它注册一个回调说"数据来了叫我"，然后就去干别的了。内核监控着成千上万个连接，哪个有数据就通知CPU处理哪个。CPU始终在忙碌，但忙的是有价值的事。
2026-01-19 20:52:03
40
原创 这3个volatile使用错误，正在毁掉你的多线程程序
不保证原子性- 多步操作可能被打断不保证内存序- 指令可能被重排不提供同步- 没有happens-before保证volatile是给编译器看的，不是给CPU看的。它只能防止编译器优化，不能防止CPU重排，也不能保证原子性。多线程编程，该用atomic就用atomic，该用mutex就用mutex。别指望volatile能解决线程安全问题。它真正的用途，是硬件寄存器和信号处理。仅此而已。
2026-01-17 23:40:35
570
原创 Linux内核是怎么发现内存泄漏的？深入kmemleak源码，揭秘检测原理
回顾一下这篇文章的核心内容。内核内存管理：页→伙伴系统→slab/slub→kmalloc，层层抽象，解决不同粒度的分配需求。理解这个架构是理解内存检测工具的基础。kmemleak原理：Hook分配/释放函数，用红黑树存储所有分配的内存块，周期性扫描整个内存空间查找"孤儿"内存。核心思想来自垃圾回收器，但只报告不回收。SLUB调试：红区检测越界，毒化检测use-after-free，调用栈追踪帮助定位问题。开销比KASAN小，适合测试环境。KASAN原理。
2026-01-17 14:45:36
33
原创 从零使用现代C++实现协程：理解有栈与无栈的本质区别
有栈和无栈各有适用场景，选择哪种要根据你的具体需求来决定。选择有栈协程（libco、goroutine）当你满足这些条件：你有大量现有的同步代码，你需要在任意位置暂停包括深层嵌套，你的协程数量在合理范围内（几千到几万），你追求简单不想学习复杂的异步编程模型。选择无栈协程（C++20 coroutine、Rust async/await）当你满足这些条件：你在写新项目可以从头设计异步架构，你需要支持海量并发（几十万到几百万），你对性能和内存有严格要求，你能接受调用链的改造（所有函数都要async）。
2026-01-16 15:48:09
29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人