1. 项目概述最近在GitHub上看到一个挺有意思的开源项目标题叫“探索高效便捷的飞机票订购系统C/C实现的开源项目”。作为一个在后台系统开发领域摸爬滚打了十多年的老码农我第一眼就被这个标题吸引了。在当今这个Java、Go、Python大行其道的时代一个用C/C实现的、面向具体业务场景机票订购的开源系统本身就充满了挑战和独特的魅力。这玩意儿可不是简单的“Hello World”或者玩具项目它背后涉及到的技术栈和工程复杂度足以让任何一个中高级C开发者兴奋起来。这个项目本质上是一个模拟的机票订购系统后端核心。它要解决的问题非常明确如何用C/C这种偏底层的语言构建一个能够处理高并发查询、复杂业务逻辑如座位锁定、票价计算、订单生成以及数据持久化的服务端应用。这不仅仅是语法和算法的练习更是对系统设计能力、网络编程、内存管理、并发控制的一次综合考验。对于想深入理解高性能服务端开发、或者希望从应用层开发转向基础架构开发的工程师来说这是一个绝佳的练手和学习的样本。我花了些时间研究了这个项目的思路和可能的实现路径。接下来我会结合自己这些年做高并发系统的经验把这个项目的核心设计、关键技术点、实操细节以及可能遇到的“坑”系统地拆解一遍。无论你是想学习C/C在业务系统中的实战应用还是单纯对如何构建一个机票系统后端感兴趣相信这篇内容都能给你带来不少干货。2. 核心架构设计与技术选型2.1 为什么选择C/C看到“飞机票订购系统”和“C/C”放在一起很多人的第一反应可能是为什么不用Java Spring Boot或者Go这不是自找麻烦吗确实对于大多数Web业务系统高级语言有成熟的框架和生态开发效率更高。但这个项目的价值恰恰在于“探索”二字。性能与可控性是首要原因。机票查询尤其是热门航线、节假日期间的秒杀场景对响应延迟和吞吐量的要求是极高的。C/C没有虚拟机的开销内存分配和回收完全由开发者掌控在极端优化下其性能上限远高于托管语言。你可以精细地控制每一个字节、每一个系统调用这对于构建底层核心交易引擎是至关重要的。学习与挑战价值。用C/C实现一个完整的业务系统是对开发者基本功的全面检验。你需要手动管理内存、设计高效的数据结构、处理复杂的多线程同步、实现网络通信协议。这个过程能让你深刻理解计算机系统是如何工作的而不是仅仅停留在框架API的调用层面。从Awesome_c-cpp_Projects列表里可以看到像HP-Socket高性能网络通信框架、TinyWebServerC11编写的高性能Web服务器这类项目都是学习网络和高并发的优秀范本它们的很多思想可以直接借鉴到机票系统中。技术栈的纯粹性。这个项目强迫你从最底层思考问题如何解析HTTP请求如何设计数据库连接池如何实现一个线程安全的订单缓存这些在Java里可能被Spring和MyBatis封装好的东西在C里都需要你亲手搭建。这种“造轮子”的过程虽然痛苦但成长也是最快的。2.2 整体架构蓝图一个高效的机票订购系统其后台核心通常采用分层和模块化的设计。我们可以设想一个简化的架构接入层负责接收来自客户端Web、App的请求。这里可以采用Libevent、Boost.Asio或者国内搜狗开源的Workflow这类高性能异步网络库来构建HTTP/HTTPS服务器。它们的共同特点是基于事件驱动如epoll/kqueue能够用少量线程支撑大量并发连接非常适合I/O密集型的查询请求。业务逻辑层这是系统的核心包含航班查询、票价计算、座位库存管理、订单创建与支付等核心服务。这一层需要精心设计数据结构如使用robin-hood hashing这样的高效哈希表来缓存航班信息和算法如最短路径搜索用于联程票。数据访问层负责与数据库交互。考虑到机票数据读多写少、且对实时性要求高通常会采用缓存数据库的模式。缓存可以使用Redis的C客户端库如Hiredis来缓存热点航班信息和座位库存减轻数据库压力。数据库关系型数据如用户信息、订单详情可以选用MySQL通过MySQL Connector/C或ORM库如sqlite_orm的设计思想进行交互。对于简单的配置或测试甚至可以用SQLite通过SQLiteCpp封装来快速原型开发。基础组件层提供系统运行所需的通用能力。配置解析使用inih或cpptoml来解析配置文件。日志记录集成spdlog或glog实现分级、异步的日志输出便于问题排查。并发工具使用C11/14/17标准的thread,mutex,atomic或更高级的库如taskflow来管理复杂的并行任务。序列化系统内部模块间通信或与外部服务交互可能需要序列化。protobufC版本是高效二进制序列化的首选JSON交互则可以用nlohmann/json。注意在项目初期切忌追求大而全。建议采用“演进式架构”先实现最核心的“查询-下单”链路后续再逐步引入缓存、消息队列、分布式等复杂特性。2.3 关键技术点预研在动手之前有几个关键的技术点需要想清楚HTTP服务框架选型是自己基于libevent从头写还是用现成的Crow微框架或Drogon全功能框架对于学习项目我建议从Boost.Asio开始它足够底层能让你透彻理解异步编程模型生态也丰富。如果追求快速搭建TinyWebServer的代码结构非常清晰适合学习。数据库操作直接使用C API如mysql.h虽然高效但代码繁琐易错。可以借鉴SQLiteCpp或sqlite_orm的设计封装一个简单的、类型安全的数据库操作类支持连接池和预处理语句Prepared Statement这对防止SQL注入和提升性能至关重要。内存管理这是C项目的重中之重。对于高频创建销毁的小对象如请求/响应对象可以考虑使用对象池Object Pool。对于核心数据结构如航班信息表要仔细选择是使用std::vector、std::unordered_map还是更专业的第三方容器如parallel hashmap。并发模型是“一个连接一个线程”thread-per-connection还是“Reactor模式”单线程/多线程事件循环对于机票系统这种连接寿命短、请求处理快的场景Reactor模式配合线程池是更主流和高效的选择。这需要深入理解libevent或Boost.Asio的Proactor/Reactor实现。3. 核心模块实现与细节剖析3.1 网络通信与HTTP服务搭建我们选择Boost.Asio作为网络库的基石。它提供了跨平台的异步I/O操作是构建高性能网络服务的利器。首先我们需要定义一个简单的HTTP服务器类监听特定端口。这里的关键是使用io_context作为I/O调度中心并采用异步接受连接的方式。#include boost/asio.hpp #include iostream #include memory #include thread #include vector using boost::asio::ip::tcp; class HttpSession : public std::enable_shared_from_thisHttpSession { public: HttpSession(tcp::socket socket) : socket_(std::move(socket)) {} void start() { doRead(); } private: void doRead() { auto self(shared_from_this()); socket_.async_read_some(boost::asio::buffer(data_, max_length), [this, self](boost::system::error_code ec, std::size_t length) { if (!ec) { // 解析HTTP请求 std::string request(data_, length); std::cout Received: request std::endl; // 构造一个简单的HTTP响应 std::string response HTTP/1.1 200 OK\r\nContent-Length: 13\r\n\r\nHello, World!; doWrite(response); } }); } void doWrite(const std::string response) { auto self(shared_from_this()); boost::asio::async_write(socket_, boost::asio::buffer(response), [this, self](boost::system::error_code ec, std::size_t /*length*/) { if (!ec) { // 写入完成后可以关闭socket或等待下一个请求保持连接 boost::system::error_code ignored_ec; socket_.shutdown(tcp::socket::shutdown_both, ignored_ec); } }); } tcp::socket socket_; enum { max_length 1024 }; char data_[max_length]; }; class HttpServer { public: HttpServer(boost::asio::io_context io_context, short port) : acceptor_(io_context, tcp::endpoint(tcp::v4(), port)) { doAccept(); } private: void doAccept() { acceptor_.async_accept( [this](boost::system::error_code ec, tcp::socket socket) { if (!ec) { std::make_sharedHttpSession(std::move(socket))-start(); } doAccept(); // 继续接受新连接 }); } tcp::acceptor acceptor_; };这只是一个最简化的回声服务器。真正的机票系统需要完整的HTTP解析需要解析请求方法GET/POST、URL路径、查询参数、头部和正文。可以集成picohttpparser这样的轻量级解析器或者自己实现一个状态机。路由分发根据URL路径如/api/flight/search,/api/order/create将请求分发到不同的处理函数Handler。可以维护一个std::unordered_mapstd::string, HandlerFunc的路由表。JSON请求/响应处理使用nlohmann/json库来解析客户端传来的JSON查询条件并序列化航班列表、订单信息等数据为JSON返回。线程池为了避免在I/O线程中执行耗时的业务逻辑如数据库查询需要将解析好的请求任务投递到一个后台线程池中执行。可以使用C17的std::async配合自定义的任务队列或者直接用taskflow这类库。实操心得在调试网络服务时务必使用telnet或curl命令手动发送请求进行测试。同时集成spdlog日志库在关键步骤如收到请求、开始处理、发生错误输出日志这是后期排查线上问题的生命线。3.2 航班数据管理与查询引擎这是系统的核心。我们需要一个高效的数据结构来存储和检索航班信息。假设航班数据包含航班号、起降机场、起降时间、票价、剩余座位数等。数据结构设计内存中维护一个std::vectorFlight作为主存储按航班号或起飞时间排序便于范围查询。为了支持多条件快速查询如“上海到北京明天”需要建立倒排索引。可以使用std::unordered_mapstd::string, std::vectorsize_t键是“出发地-目的地-日期”的组合值是对应航班在主向量中的索引列表。剩余座位数是一个高频更新的字段需要使用std::atomicint来保证线程安全避免在并发订票时出现超卖。struct Flight { std::string flightNo; std::string depAirport; std::string arrAirport; std::chrono::system_clock::time_point depTime; std::chrono::system_clock::time_point arrTime; float price; std::atomicint seatsAvailable; // ... 其他字段 }; class FlightManager { public: bool addFlight(const Flight f); std::vectorFlight searchFlights(const std::string dep, const std::string arr, const std::string date); bool bookSeat(const std::string flightNo, int numSeats); // 原子操作减少座位数 private: std::vectorFlight flights_; std::shared_mutex flightsMutex_; // 读写锁保护flights_的增删改 // 索引 “SHA-PEK-20231027” - [0, 5, 10] (flight indices) std::unordered_mapstd::string, std::vectorsize_t flightIndex_; std::shared_mutex indexMutex_; // 保护索引 };查询流程客户端发送查询请求包含出发地、目的地、日期。HTTP层解析请求提取参数。业务层调用FlightManager::searchFlights。在函数内部首先根据参数生成索引键如SHA-PEK-20231027。加读锁std::shared_lock访问flightIndex_获取符合条件的航班索引列表。根据索引列表从flights_中取出航班数据注意检查座位数0。对结果进行排序如按时间、价格并返回。注意事项这里使用了C17的std::shared_mutex读写锁。因为flightIndex_和flights_是读远多于写的场景查询多新增/更新航班少使用读写锁可以大幅提升并发读的性能。但在更新航班数据如新增航班、调整时间时需要加写锁std::unique_lock此时会阻塞所有的读和写。3.3 订单处理与库存扣减订单处理是系统中最容易出错的环节核心在于保证“查询-扣减-创建订单”这一系列操作的原子性和一致性防止超卖。简易流程与问题用户查询到航班F有1个座位。用户A和用户B几乎同时点击购买该航班最后1个座位。两个请求分别进入系统都检查到seatsAvailable 1通过。两个请求都执行seatsAvailable--原子操作结果可能变成0和-1实际上原子操作保证--是原子的但检查与扣减是两步非原子。两个请求都创建订单成功导致超卖1张票。解决方案使用数据库事务 乐观锁/悲观锁内存中的原子变量只能保证单步操作的原子性无法保证“检查-扣减”这个业务逻辑的原子性。因此必须依赖数据库或一个中央化的、支持事务的存储来作为最终的一致性仲裁者。我们以MySQL为例航班库存表flight_inventory可以设计如下CREATE TABLE flight_inventory ( flight_no VARCHAR(10) PRIMARY KEY, total_seats INT NOT NULL, available_seats INT NOT NULL, version INT DEFAULT 0 -- 乐观锁版本号 );下单的原子操作伪代码bool BookFlightTransaction(const std::string flightNo, int userId) { // 开始数据库事务 dbConnection-execute(BEGIN); // 使用 SELECT ... FOR UPDATE 悲观锁锁定该行记录 auto result dbConnection-query(SELECT available_seats, version FROM flight_inventory WHERE flight_no ? FOR UPDATE, flightNo); if (result.empty() || result[0][available_seats] 0) { dbConnection-execute(ROLLBACK); return false; // 无票或航班不存在 } int currentSeats result[0][available_seats]; int currentVersion result[0][version]; // 扣减库存 dbConnection-execute(UPDATE flight_inventory SET available_seats ?, version ? WHERE flight_no ? AND version ?, currentSeats - 1, currentVersion 1, flightNo, currentVersion); // 检查更新是否成功乐观锁 if (dbConnection-affectedRows() 0) { // 更新失败说明版本号被其他事务修改了发生了冲突 dbConnection-execute(ROLLBACK); return false; // 可以重试 } // 创建订单记录 dbConnection-execute(INSERT INTO orders (user_id, flight_no, status, create_time) VALUES (?, ?, PENDING, NOW()), userId, flightNo); // 提交事务 dbConnection-execute(COMMIT); return true; }核心要点这里结合了悲观锁FOR UPDATE和乐观锁version字段。FOR UPDATE在事务内锁定了这行数据防止其他事务同时修改。version字段用于在更新时做最终的一致性校验。affectedRows() 0表示更新失败通常意味着在SELECT和UPDATE之间该行数据被其他事务修改了本次扣减失败需要回滚并告知用户“库存已变化”。在实际高并发场景前端通常会引导用户重试。内存缓存与数据库的同步为了提升查询性能Flight对象中的seatsAvailable是从数据库flight_inventory表缓存过来的。当库存通过事务扣减成功后必须同步更新内存缓存。这可以通过在数据库更新后发布一个“库存变更”的事件或者简单地设置一个较短的缓存过期时间如5秒来实现。更复杂的方案是使用数据库的binlog监听如Canal来同步变更。3.4 数据持久化与数据库交互我们不直接使用原始的MySQL C API而是进行一层简单的封装主要解决连接池和防止SQL注入问题。数据库连接池频繁创建和销毁数据库连接开销巨大。我们需要实现一个连接池初始化时创建一定数量的连接业务线程从池中借用用完后归还。class DBConnectionPool { public: static DBConnectionPool instance() { static DBConnectionPool pool; return pool; } std::shared_ptrMysqlConnection getConnection() { std::unique_lockstd::mutex lock(mutex_); while (connections_.empty()) { cond_.wait(lock); } auto conn connections_.front(); connections_.pop_front(); return conn; } void returnConnection(std::shared_ptrMysqlConnection conn) { std::unique_lockstd::mutex lock(mutex_); connections_.push_back(conn); cond_.notify_one(); } private: DBConnectionPool() { /* 初始化N个连接 */ } std::liststd::shared_ptrMysqlConnection connections_; std::mutex mutex_; std::condition_variable cond_; }; // 使用RAII管理连接借用 class ScopedDbConnection { public: ScopedDbConnection() : conn_(DBConnectionPool::instance().getConnection()) {} ~ScopedDbConnection() { DBConnectionPool::instance().returnConnection(conn_); } MysqlConnection* operator-() { return conn_.get(); } private: std::shared_ptrMysqlConnection conn_; };SQL执行封装封装一个executeQuery和executeUpdate函数内部使用MySQL的预处理语句Prepared Statement这能有效防止SQL注入并且对于重复执行的语句数据库有优化。class MysqlConnection { public: bool prepare(const std::string sql, MYSQL_STMT* stmt) { stmt mysql_stmt_init(mysql_); return mysql_stmt_prepare(stmt, sql.c_str(), sql.length()) 0; } // ... 绑定参数、执行等操作 };在实际业务代码中这样使用ScopedDbConnection db; MYSQL_STMT* stmt nullptr; if (db-prepare(SELECT * FROM flights WHERE dep_airport? AND arr_airport?, stmt)) { // 绑定参数std::string dep SHA; arr PEK; // 执行查询 // 获取结果集 // 清理stmt }4. 性能优化与高级特性探讨4.1 缓存策略深度优化之前提到了用Redis缓存热点数据。这里详细说一下策略缓存粒度粗粒度缓存整个查询结果JSON。例如键为flight:search:SHA:PEK:20231027值为该条件查询出的航班列表JSON。优点是命中后直接返回无需计算缺点是数据更新时失效范围大可能产生脏数据。细粒度缓存单个航班对象。键为flight:info:CA1234。业务查询时先根据索引键从另一个缓存如flight:index:SHA:PEK:20231027-[CA1234, MU5678]拿到航班号列表然后批量从缓存中获取航班详情。更新库存时只需使flight:info:CA1234失效或更新即可更精准。推荐使用细粒度缓存虽然逻辑稍复杂但一致性更好。缓存更新Cache Aside旁路缓存这是最常用的模式。读先读缓存命中则返回未命中则读数据库写入缓存。写更新数据库删除缓存。注意要先更新数据库再删缓存顺序不能错否则在极端并发下仍有脏数据风险。Write Through直写写操作同时更新缓存和数据库。这对缓存的一致性要求高实现复杂一般用于写多读少的场景机票系统不适用。缓存穿透、击穿、雪崩穿透查询一个不存在的数据如不存在的航班号缓存不命中每次都打到数据库。解决方案将空结果如null也缓存一小段时间如30秒或者使用布隆过滤器Bloom Filter在查询前快速判断数据是否存在。击穿某个热点key过期瞬间大量请求同时涌向数据库。解决方案使用互斥锁mutex第一个请求未命中时加锁去数据库加载其他请求等待。或者对热点数据设置永不过期通过后台任务异步更新。雪崩大量缓存key在同一时间过期导致所有请求涌向数据库。解决方案给缓存过期时间加上一个随机值如基础300秒 随机0-60秒分散过期时间。4.2 异步化与响应式编程为了进一步提升吞吐量可以考虑将一些I/O密集型或计算密集型的操作异步化。异步数据库查询Boost.Asio本身支持异步操作但MySQL的C API是阻塞的。一种做法是将数据库查询任务提交到专门的数据库线程池然后通过std::future或回调函数通知主线程。更现代的做法是使用libmysqlclient的非阻塞接口配合Asio但这需要较深的定制。异步HTTP客户端如果机票系统需要调用外部服务如支付网关、航司系统使用Boost.Asio或libcurl的异步接口可以避免工作线程被阻塞。响应式编程对于复杂的业务流程例如“查询航班 - 查询票价规则 - 计算税费 - 检查用户权益”这些步骤可能有依赖关系。可以使用RxCppReactive Extensions for C来以声明式的方式编排这些异步操作让代码更清晰。// 伪代码展示RxCpp思路 auto searchFlow rxcpp::observable::just(searchParams) .flat_map([](Params p) { return asyncSearchFlights(p); }) // 异步查询航班 .flat_map([](FlightList flights) { return asyncCalculateTax(flights); }) // 异步计算税费 .subscribe( [](FinalResult result) { /* 成功返回结果 */ }, [](std::exception_ptr ep) { /* 处理错误 */ } );4.3 可观测性与监控系统上线后监控是眼睛。我们需要知道系统的健康状况。日志使用spdlog配置异步日志、按级别和模块输出到不同文件。关键业务节点如收到订单请求、开始扣库存、扣库存成功/失败、创建订单必须打日志且要包含唯一请求ID方便串联整个请求链路。指标Metrics使用Prometheus的C客户端库暴露系统指标。计数器Counter总请求数、成功订单数、失败订单数。测量仪Gauge当前内存使用量、数据库连接池活跃连接数、当前在线用户数。直方图Histogram接口响应时间分布P50, P90, P99。分布式追踪Tracing如果系统规模扩大需要追踪一个请求跨多个服务的路径。可以集成OpenTelemetry C SDK为每个请求生成唯一的Trace ID并在日志和跨服务调用中传递。5. 开发环境搭建、调试与部署5.1 开发环境与工具链编译器推荐GCC (9.0)或Clang (10.0)以支持C17/20的现代特性。构建系统CMake是事实标准。它管理依赖、编译选项、跨平台构建非常方便。项目根目录的CMakeLists.txt是入口。依赖管理C没有官方包管理器可以用vcpkg或Conan。它们能帮你自动下载、编译像Boost、spdlog、nlohmann/json这些第三方库。在CMakeLists.txt中集成它们也很容易。IDE/编辑器Visual Studio CodeCMake ToolsC/C扩展是跨平台开发的绝佳组合。CLion是专业的C IDE对CMake支持极好。确保配置好.vscode/c_cpp_properties.json和launch.json实现代码跳转和调试。5.2 单元测试与集成测试没有测试的项目是不可靠的。使用测试框架来保证代码质量。单元测试框架Google Test (gtest)或Catch2。它们功能强大社区活跃。为FlightManager、订单服务等核心类编写单元测试。Mock测试对于依赖外部数据库或网络的服务使用Google Mock (gmock)来模拟Mock这些依赖让测试可以独立运行。集成测试编写一些端到端E2E的测试脚本使用curl或Python的requests库模拟用户行为调用真实的HTTP接口验证整个“查询-下单”流程。一个简单的gtest示例TEST(FlightManagerTest, SearchFlightsBasic) { FlightManager mgr; mgr.addFlight({CA1234, SHA, PEK, ...}); mgr.addFlight({MU5678, SHA, PEK, ...}); auto results mgr.searchFlights(SHA, PEK, 20231027); ASSERT_EQ(results.size(), 2); EXPECT_EQ(results[0].flightNo, CA1234); }5.3 部署与运维考量进程管理使用systemd或supervisor来管理服务进程实现开机自启、崩溃自动重启。配置管理将数据库地址、Redis地址、服务端口等配置信息外置到配置文件如config.toml或环境变量中不要硬编码在代码里。性能剖析使用gperftoolsCPU Profiler或Valgrind的callgrind工具来分析性能瓶颈。使用Valgrind的memcheck工具来检查内存泄漏。这是C/C项目必须经历的环节。容器化使用Docker将应用及其所有依赖打包成镜像。这保证了环境一致性便于部署和扩展。编写Dockerfile基于一个轻量级Linux镜像如Alpine安装运行时库拷贝编译好的可执行文件。6. 常见问题排查与实战经验在实际开发和运行中你肯定会遇到各种各样的问题。这里记录几个我踩过的“坑”和解决方法。6.1 内存问题排查问题1内存缓慢增长疑似内存泄漏现象服务运行一段时间后top命令看到RES内存持续上涨不释放。排查首先用Valgrind --leak-checkfull运行程序看是否有明确的“definitely lost”内存块。这是最直接的方法但Valgrind会拖慢程序速度不适合长时间压测。如果Valgrind没发现明显泄漏可能是“未释放缓存”或“容器未清理”。检查全局或长生命周期的std::vector,std::unordered_map是否只增不减例如是否把每个请求的上下文都塞进了一个全局Map却忘了清理使用tcmalloc或jemalloc替换默认的malloc它们提供更好的内存碎片管理和分析工具。通过环境变量HEAPPROFILE可以生成堆内存剖析文件用pprof工具可视化分析。我的经验曾经遇到一个Bug是在一个全局的std::map里缓存了用户会话键是用户ID但忘记设置过期时间或LRU淘汰机制导致Map无限增长。后来改为std::unordered_map 定期清理或使用robin-hood hashing这类有更好性能的库解决了。问题2程序崩溃coredump文件分析现象服务突然崩溃生成了core.xxx文件。排查编译时务必加上-g选项保留调试符号。使用gdb /path/to/your/program core.xxx加载coredump。在gdb中输入btbacktrace查看崩溃时的调用栈。这能直接定位到崩溃的代码行。常见原因空指针解引用、数组越界、使用已释放的内存use-after-free、多线程数据竞争。预防大量使用智能指针std::shared_ptr,std::unique_ptr管理资源所有权。对于数组访问使用at()方法而非operator[]因为at()会进行边界检查并抛出std::out_of_range异常。使用线程安全的数据结构或严格加锁。6.2 并发与同步问题问题库存扣减出现负数超卖现象如3.3节所述即使使用了原子变量在极高并发下仍可能出现超卖。根因“检查库存”和“扣减库存”不是原子操作。解决方案如3.3节详细所述必须依赖数据库事务和锁悲观锁SELECT ... FOR UPDATE结合乐观锁version字段来保证原子性。内存中的缓存值仅用于快速展示最终一致性由数据库保证。进阶思考对于秒杀场景甚至可以提前在内存中划分好“令牌”或“资格”使用更高效的无锁队列如MPMCQueue来发放将库存扣减的压力从数据库转移到内存中但这套逻辑非常复杂需要极强的一致性和容错设计。问题死锁现象多个线程互相等待对方持有的锁程序卡死。排查在GDB中thread apply all bt查看所有线程的栈分析每个线程在等待哪个锁。通常是因为锁的获取顺序不一致。预防建立严格的锁获取顺序规则。例如规定总是先锁indexMutex_再锁flightsMutex_。或者尽可能使用std::shared_mutex读写锁来提升读并发减少写锁持有时间。考虑使用TBB或taskflow中的并发容器它们内部实现了更细粒度的锁或无锁算法。6.3 网络与性能问题问题连接数过多accept失败或报too many open files现象压测时服务端出现大量连接错误日志显示EMFILE或ENFILE。原因系统或进程的文件描述符FD数量达到上限。每个TCP连接都是一个FD。解决使用ulimit -n查看和修改当前shell的文件描述符限制。对于服务进程需要在启动脚本或systemd service文件中设置LimitNOFILE。检查代码中是否有关闭连接后没有正确关闭socket的情况资源泄漏。确保所有socket都使用了RAII管理或在析构函数中关闭。优化服务器架构使用连接池或长连接复用减少频繁创建销毁连接的开销。问题QPS上不去CPU利用率不高现象压测时吞吐量达不到预期但top看CPU还有空闲。排查使用perf top或vtune进行性能剖析看热点在哪里。很可能卡在I/O上数据库查询、Redis访问。检查数据库查询是否没有用索引。使用EXPLAIN分析慢SQL。检查网络延迟。是否Redis或MySQL部署在远端网络往返时间RTT成为瓶颈考虑部署在同机房或使用更快的网络。检查是否在关键路径上进行了不必要的拷贝。例如在解析HTTP请求时是否将整个请求体字符串传来传去尽量使用string_viewC17来避免拷贝。优化对于数据库慢查询增加索引、优化SQL语句、考虑分库分表如果数据量极大。对于缓存访问使用pipeline或mget批量操作减少网络往返次数。这个用C/C实现飞机票订购系统的项目就像一次深入技术腹地的探险。它强迫你从内存、CPU、网络这些最基础的层面去思考一个业务系统的构建过程中遇到的每一个问题都是对基本功的锤炼。从最开始的HTTP服务器搭建到核心的库存扣减事务再到最后的性能调优和问题排查完整走下来你对“系统”二字的理解会完全不同。它可能没有直接用Spring Boot那么快但这种从零搭建、掌控一切的体验和收获是使用高级框架无法比拟的。如果你正想挑战自己或者为面试一个基础架构岗位做准备动手实现这样一个项目会是你简历上非常亮眼的一笔。