一、开发环境搭建：工欲善其事，必先利其器
做低延迟系统，环境搭建不是随便装个Linux就完事的。我见过太多人，代码写得挺漂亮，结果一上生产环境，延迟直接翻倍。为什么？环境没配好。
这一章，咱们就把地基打牢。我会把我在生产环境中踩过的坑、积累的经验，都摊开来讲。
1.1 Linux系统选择：不是所有发行版都适合做撮合
我个人习惯用 Ubuntu Server LTS 或 CentOS Stream。为什么？
- Ubuntu 22.04 LTS：内核新，对NUMA、CPU隔离支持好。我有个项目，从CentOS 7切到Ubuntu 22.04，延迟抖动直接降了30%。
- CentOS Stream 9：如果你公司有Red Hat背景，这个更稳。但要注意，它默认的防火墙规则可能会干扰你的UDP组播。
避坑指南：我曾经在生产环境用Debian，结果发现它的内核默认没开CONFIG_PREEMPT_RT。做低延迟，一定要确认内核支持实时抢占。用
uname -a 看一眼，如果有 "PREEMPT" 字样，基本就对了。
1.2 编译器与工具链：GCC还是Clang？
这是个老生常谈的问题。我的答案是：两个都要会，但生产环境用GCC。
| 特性 | GCC 12+ | Clang 16+ |
|---|---|---|
| 编译速度 | 中等 | 快（约快30%） |
| 生成代码质量 | 优秀（尤其-O2 -march=native） | 优秀（但某些内联优化不如GCC激进） |
| 调试体验 | GDB配合良好 | LLDB更现代，但生态略弱 |
| 低延迟场景 | 推荐（我实测过，GCC的循环展开更彻底） | 可用（但注意某些原子操作优化有坑） |
安装很简单：
# Ubuntu
sudo apt install build-essential cmake g++-12 clang-16 lldb-16
# CentOS
sudo dnf install gcc-toolset-12-gcc-c++ cmake clang lldb
我的习惯：开发机用Clang，编译快，迭代爽。CI/CD流水线用GCC，生成最终二进制。这样两边都练到了。
1.3 CMake：别手写Makefile了
嗯，这里要注意。很多做C++的老哥喜欢手写Makefile，觉得CMake多此一举。但做撮合引擎，项目结构复杂，依赖多，手写Makefile迟早会出问题。
我建议用 CMake 3.25+，配合 Ninja 构建系统。Ninja比Make快一个数量级。
一个典型的低延迟项目CMakeLists.txt长这样：
cmake_minimum_required(VERSION 3.25)
project(MatchingEngine VERSION 1.0.0 LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2 -march=native -mtune=native -flto -fno-exceptions -fno-rtti")
# 低延迟专用优化
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-stack-protector -fomit-frame-pointer")
endif()
add_executable(matching_engine
src/main.cpp
src/order_book.cpp
src/message_parser.cpp
)
target_link_libraries(matching_engine PRIVATE pthread numa)
关键点：
-fno-exceptions 和 -fno-rtti 这两个flag，能减少二进制体积和运行时开销。但代价是代码里不能用try-catch和dynamic_cast。做撮合引擎，这些本来就不该用。
1.4 性能测试工具：perf + FlameGraph
写代码只是第一步。你得知道你的代码到底跑在哪。是CPU瓶颈？还是内存访问？还是锁竞争？
我常用的组合是 perf + FlameGraph。perf是Linux内核自带的采样工具，FlameGraph是 Brendan Gregg 大神写的可视化脚本。
安装：
# perf
sudo apt install linux-tools-common linux-tools-$(uname -r)
# FlameGraph
git clone https://github.com/brendangregg/FlameGraph.git
cd FlameGraph使用流程：
- 运行你的撮合引擎，比如
./matching_engine - 用perf采样：
sudo perf record -F 99 -g -p $(pgrep matching_engine) -- sleep 30 - 生成火焰图：
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg - 用浏览器打开flame.svg，一眼就能看出热点在哪。
小技巧：采样频率 -F 99 是经典值。太高了（比如999）会导致perf本身占用过多CPU，影响测量结果。太低则采样不足。99Hz是个平衡点。
1.5 代码版本管理：Git + 分支策略
这个其实不用多说，但我想强调一点：低延迟项目对代码变更极其敏感。一个看似无害的提交，可能让延迟从5微秒跳到50微秒。
我推荐的分支策略：
- main：只放经过严格性能测试的代码。每次合并前，必须跑一遍延迟基准测试。
- dev：日常开发分支。允许性能退化，但要有记录。
- feature/xxx：每个新功能独立分支。合并到dev前，至少做一次perf采样对比。
Git配置建议：
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
git config --global core.editor "vim"
git config --global merge.conflictstyle diff3
git config --global alias.lg "log --graph --oneline --all"
避坑指南：我曾经在合并分支时，不小心把调试用的日志打印带进了生产代码。结果延迟从8微秒飙到了120微秒。从那以后，我强制要求所有合并请求必须附带perf对比图。
1.6 本章知识体系
下面这张图，把咱们这一章的核心内容串起来了。你可以把它当作一个检查清单：
说白了，环境搭建这件事，你花一天时间认真配好，后面能省你一周的排查时间。别嫌麻烦。
公众号:蓝海资料掘金营，微信deep3321