前十天我们完整通关了：计算机网络、操作系统原理、Linux系统、MySQL、Redis 等核心理论。理论背得滚瓜烂熟，一行底层代码写不出来。C/C++ 基本功 + Linux系统调用 + 内存理解 + 文件IO + 进程调度 + 数据结构手写能力。今天一次性完成两个高含金量底层项目1.高性能Linux日志库（C语言）：文件IO、缓冲区、时间戳、日志分级、自动滚存2.Linux简易Shell解释器（

上一天我们手写了多进程TCP并发服务器，成功实现多客户端同时通信。多进程模型无法支撑高并发。每来一个客户端就要创建一个进程，Linux系统进程资源极其昂贵，单个服务器最多支撑几百个并发，一旦连接量上千上万，系统会直接卡死、资源耗尽、无法响应。想要实现百万并发、高吞吐、低延迟的工业级服务器（Nginx/Redis底层核心），必须彻底吃透Linux 四大IO模型 + Epoll多路复用机制。IO模型是

在C语言中，我们使用的数组是静态数组，大小固定、栈内存开辟、无法动态扩展，一旦空间不足只能重新手动开辟更大内存、手动拷贝、手动释放，代码冗余且极易出错。为了解决静态数组的死板缺陷，C++ STL 推出了vector 动态数组容器。vector 是STL中最常用、最基础、性能最高的序列式容器，也是所有容器的入门基石。它完全封装了动态数组的内存管理，自动扩容、自动释放、支持随机访问，完美替代原生数组，

上一天我们彻底吃透了 vector 动态数组容器，我们知道 vector 基于连续堆内存实现，随机访问速度极致高效，但存在致命短板：头部、中间插入删除元素需要批量移动后续元素，海量数据场景下性能急剧暴跌，且扩容、删除极易引发迭代器失效问题。为了弥补顺序容器在非尾部增删场景的性能缺陷，C++ STL 提供了list 双向链表容器。list 彻底抛弃了连续内存布局，采用链式存储结构，完美解决了 vec

我们彻底吃透了内存池高性能调度体系，解决了原生 new 分配慢、内存碎片多的性能痛点，掌握了工业级内存优化方案，补齐了C++内存高性能开发的核心短板。而日常C++工程开发中，STL容器是使用频率最高的核心组件，几乎所有业务数据存储、数据流转、算法处理都依赖vector、list、map、unordered_map等容器。绝大多数开发者只会简单调用push_back、find、erase接口，却完全

我们完成了 Linux 服务端底层全套基建：系统编程、进程线程、IPC通信、文件IO、Socket套接字、TCP全链路机制、UDP高性能协议、粘包拆包解决方案，具备了网络通信的所有基础能力。但掌握 Socket + TCP/UDP 只能写出单连接、串行阻塞的低配网络程序，完全无法支撑互联网服务的高并发场景。Nginx、Redis、网关、微服务网关能支撑十万、百万并发连接，不靠协议优化，靠的是Lin

我们彻底吃透了Linux IO多路复用全套体系，掌握了select/poll/epoll底层差异、LT/ET触发机制、百万并发核心原理，具备了高并发IO调度的底层能力。今天我们正式进入Linux核心网络编程——TCP协议与套接字实战，如果说多路复用是高并发的“调度大脑”，那TCP协议就是所有网络数据传输的“通信血管”。Nginx、Redis、微服务、后端接口、分布式通信，底层全部基于TCP协议实现

我们彻底吃透了Reactor三大高并发架构，掌握了单线程、多线程、多进程反应堆模型，读懂了Nginx、Redis底层架构核心，具备了高并发服务的架构设计能力。代码架构没问题，线上并发一高直接崩掉。明明写好了epoll+Reactor高并发框架，压测上千连接就出现无法建连、端口耗尽、TIME_WAIT爆满、文件描述符溢出、CPU软中断飙升等各种问题。核心原因不是代码问题，是Linux系统默认参数是为

我们打通了MySQL五层整体架构，明确了Server层只管解析调度，InnoDB才是真正存数据、管索引、控事务的核心。从今天开始，我们正式下沉到InnoDB最底层物理存储结构。索引快、B+树结构。但完全不知道：数据到底存在磁盘哪里？一行数据长什么样？聚簇索引和普通索引本质区别是什么？为什么主键查询最快？为什么回表会慢？为什么索引字段不宜过大？为什么自增主键最优？所有慢查询、索引失效、回表过多、页分

RC、RR两大主流隔离级别，依靠MVCC实现读写并发。如果没有MVCC，数据库读写操作会互相阻塞，读阻塞写、写阻塞读，高并发场景完全无法支撑业务流量。MVCC实现了无锁读、读写不冲突。但完全不懂底层核心：多版本到底多的是什么版本？版本链如何存储、如何回溯？ReadView快照如何判断数据可见性？为什么RC不可重复读、RR可重复读？根源在哪？为什么RC每次查询都刷新快照，RR事务只生成一次快照？