1. 项目概述：为什么我们需要一个高可靠的服务框架？

在后台服务开发领域，尤其是用C++构建长期运行、高并发的服务时，我们常常会陷入一个困境：业务逻辑代码和基础设施代码纠缠不清。今天加个日志，明天改个配置，后天发现任务调度有瓶颈。每次新启动一个服务项目，都要从零开始搭建日志、配置、监控、任务调度这些轮子，不仅效率低下，而且每个服务的实现质量参差不齐，埋下了无数稳定性隐患。

我经历过不止一次线上事故，根源就是某个服务的日志打爆了磁盘，或者任务调度死锁导致服务假死。痛定思痛，我决定系统性地构建一个高可靠的C++服务框架，将日志、配置、监控、任务调度这些基础设施组件化、标准化。这个框架的目标很明确：让开发者能专注于业务逻辑，同时获得生产级可靠性的保障。它不是一个玩具，而是从实际线上服务的血泪教训中提炼出来的，核心设计哲学就是“可靠第一，性能第二，但性能也不能差”。

这个框架的核心由两大支柱构成：一个健壮的日志系统和一个高效的任务调度器。日志系统负责记录服务的“黑匣子”数据，是问题排查的命脉；任务调度器则是服务的“心脏”，负责协调所有异步任务的执行。两者结合，构成了服务可观测性和稳定性的基石。无论你是正在开发一个微服务、一个数据处理引擎，还是一个实时计算平台，这套框架的设计思路和实现细节都能给你带来直接的参考价值。

2. 框架整体架构与设计哲学

2.1 核心架构拆解：模块化与松耦合

一个高可靠框架的首要原则是清晰的边界和松耦合的模块。我们不能把所有代码都塞进一个巨大的Service类里。我的设计将框架划分为四个核心层次，自底向上分别是：

1. 基础设施层：提供最基础的、与业务无关的通用能力。这包括我们首先要实现的日志系统、后续会扩展的配置管理、以及工具类（如字符串处理、时间戳等）。这一层的特点是稳定、轻量、无外部依赖（或依赖极少且稳定的第三方库）。
2. 核心引擎层：这是框架的“大脑”，包含了任务调度器的核心逻辑。它负责管理任务生命周期、线程池、队列、资源配额等。这一层依赖基础设施层，但完全不知道上层业务是什么。
3. 服务抽象层：在核心引擎之上，提供更贴近业务开发的抽象。例如，定义Service基类，提供启动、停止、健康检查等生命周期钩子；或者提供RPC Server、HTTP Server的封装模板。业务服务继承或组合这些类来快速构建。
4. 业务实现层：这就是开发者实际编写业务代码的地方。他们只需要关注“收到一个请求后做什么”，而“请求怎么来”、“怎么异步处理”、“日志怎么记”都由下层框架搞定。

这种分层带来了几个关键好处：

• 可测试性：你可以单独为日志系统或调度器写单元测试，模拟上层调用。
• 可替换性：如果未来有更优秀的日志库（如spdlog），你可以在基础设施层替换，而不会影响核心引擎和业务代码。
• 可理解性：新人接手项目，可以快速理清代码结构，知道该在哪里添加功能。

2.2 可靠性设计原则：从“可能出错”出发

C++服务运行在复杂的生产环境中，网络抖动、磁盘满、内存不足、第三方库崩溃都是家常便饭。高可靠框架的设计必须悲观，时刻假设“任何环节都可能出错”，并为此做好准备。

• 故障隔离：这是最重要的原则。一个任务的崩溃（如内存越界）绝不能导致整个调度器挂掉，更不能影响其他任务。我们通过进程隔离（每个任务在独立子进程中运行）或至少是线程隔离+异常捕获来实现。日志系统写入失败，也不能阻塞主线程，应有异步落盘或降级策略（如写入标准错误）。
• 优雅降级与自我保护：当系统资源（CPU、内存、文件描述符）紧张时，框架不能“硬扛”直到崩溃。任务调度器需要具备背压（Backpressure）感知能力，当系统压力（如Linux PSI指标）过高时，自动拒绝新任务或降低调度频率。日志系统在磁盘空间不足时，应自动切换为滚动删除旧日志或仅输出错误日志。
• 可观测性内置：可靠不等于不犯错，而是犯错后能快速发现和恢复。因此，日志、指标（Metrics）、分布式追踪这“三大支柱”必须作为一等公民内置在框架中。我们的日志系统要能结构化输出；调度器要能暴露任务队列长度、执行耗时、失败率等指标（例如通过Prometheus格式）。
• 确定性行为：框架的行为必须是可预测的。例如，服务停止时，框架必须保证：1）不再接收新任务；2）等待正在执行的任务完成（或超时强制结束）；3）刷新所有日志；4）释放所有资源。这个过程必须是清晰的、可配置的（如设置等待超时时间）。

3. 基石一：构建一个生产级C++日志系统

日志不是简单的printf或std::cout。一个生产级的日志系统需要兼顾性能、可靠性、功能性和易用性。

3.1 日志系统核心需求分析

在动手写代码前，我们先明确需求：

1. 多级别日志：DEBUG, INFO, WARN, ERROR, FATAL。能运行时动态调整级别。
2. 多输出目的地：同时支持文件、标准输出/错误、甚至网络（如Syslog）。文件要支持按大小/时间滚动。
3. 高性能与低延迟：日志写入不能成为性能瓶颈。特别是在高并发场景下，必须采用异步写入。
4. 线程安全：多个线程同时打日志不能导致乱码或崩溃。
5. 丰富的上下文信息：自动记录时间戳、线程ID、日志级别、源代码文件和行号。
6. 格式化灵活：支持类似printf的格式，也最好支持流式输出。
7. 崩溃安全：即使在程序崩溃（如SIGSEGV）时，也应尽量将最后的日志刷入磁盘。

3.2 实现方案选型：自研 vs 第三方库

市面上有优秀的C++日志库，如spdlog、glog。但对于框架而言，自研一个精简的核心版本有其独特价值：

• 零外部依赖：让框架更轻便，部署更容易。
• 深度定制：可以完美契合框架的异步模型、配置系统。
• 理解原理：自己实现一遍是理解异步IO、队列、线程同步的最佳实践。

当然，在业务项目中，直接使用spdlog是更高效的选择。这里我们为了阐述框架设计，选择自研一个具备核心特性的日志系统。

3.3 核心实现：异步日志器

我们采用“前端”与“后端”分离的经典异步日志模型。

3.3.1 前端接口设计前端提供易用的API给业务代码调用。我们采用宏定义来简化调用并自动捕获文件名和行号，但宏的内部调用一个线程安全的单例日志类。

// logger.h #pragma once #include <string> #include <memory> #include <thread> #include <vector> #include <queue> #include <mutex> #include <condition_variable> #include <atomic> #include <fstream> enum class LogLevel { DEBUG, INFO, WARN, ERROR, FATAL }; class AsyncLogger { public: static AsyncLogger& instance(); void log(LogLevel level, const char* file, int line, const std::string& message); void set_level(LogLevel level) { current_level_.store(level); } void flush(); ~AsyncLogger(); private: AsyncLogger(); void init(const std::string& basename = "service", size_t roll_size = 100 * 1024 * 1024 /* 100MB */); void backend_thread_func(); // 后端写线程函数 struct LogItem { std::chrono::system_clock::time_point timestamp; LogLevel level; std::thread::id tid; std::string file; int line; std::string message; }; std::unique_ptr<std::ofstream> file_stream_; std::string basename_; size_t roll_size_; std::atomic<LogLevel> current_level_{LogLevel::INFO}; // 前端缓冲区（当前线程）和后端缓冲区交换 using Buffer = std::vector<char>; using BufferPtr = std::unique_ptr<Buffer>; BufferPtr current_buffer_; // 当前正在填充的缓冲区 BufferPtr next_buffer_; // 预备缓冲区 std::vector<BufferPtr> buffers_to_write_; // 待写入文件的缓冲区队列 std::mutex mutex_; std::condition_variable cond_; std::atomic<bool> running_{false}; std::thread backend_thread_; static const size_t kBufferSize = 4 * 1024 * 1024; // 每个缓冲区4MB };

3.3.2 后端写线程实现后端线程是日志系统的核心。它等待条件变量，当前端缓冲区满或定时触发时，交换缓冲区，并将满的缓冲区写入文件。

// logger.cpp 关键部分 void AsyncLogger::backend_thread_func() { BufferPtr new_buffer1 = std::make_unique<Buffer>(); new_buffer1->reserve(kBufferSize); BufferPtr new_buffer2 = std::make_unique<Buffer>(); new_buffer2->reserve(kBufferSize); std::vector<BufferPtr> buffers_to_write; buffers_to_write.reserve(16); while (running_) { { std::unique_lock<std::mutex> lock(mutex_); // 等待超时（如3秒）或前端通知 if (buffers_to_write_.empty()) { cond_.wait_for(lock, std::chrono::seconds(3)); } // 即使被唤醒，也可能是因为超时，需要再次检查 buffers_to_write_.swap(buffers_to_write); // 将空闲的缓冲区还给前端 if (!current_buffer_) { current_buffer_ = std::move(new_buffer1); } if (!next_buffer_) { next_buffer_ = std::move(new_buffer2); } } // 写入文件 for (const auto& buffer : buffers_to_write) { if (file_stream_ && file_stream_->is_open()) { file_stream_->write(buffer->data(), buffer->size()); } // 也可以同时输出到stdout，便于调试 if (current_level_ <= LogLevel::INFO) { // 假设INFO及以上也输出到控制台 std::cout.write(buffer->data(), buffer->size()); } } // 清空已写入的缓冲区，复用 if (buffers_to_write.size() > 2) { buffers_to_write.resize(2); // 只保留两个缓冲区复用 } if (!new_buffer1) { new_buffer1 = std::move(buffers_to_write.back()); buffers_to_write.pop_back(); new_buffer1->clear(); } if (!new_buffer2) { new_buffer2 = std::move(buffers_to_write.back()); buffers_to_write.pop_back(); new_buffer2->clear(); } buffers_to_write.clear(); if (file_stream_) { file_stream_->flush(); // 定期刷盘 } } // 退出前，再强制刷一次盘 flush(); }

3.3.3 日志宏与格式化提供易于使用的宏，并实现高效的格式化。我们可以借鉴fmtlib的思想，但为了简单，这里使用std::ostringstream。

// 日志宏 #define LOG_DEBUG(...) \ do { \ if (AsyncLogger::instance().get_level() <= LogLevel::DEBUG) { \ std::ostringstream oss; \ oss << __VA_ARGS__; \ AsyncLogger::instance().log(LogLevel::DEBUG, __FILE__, __LINE__, oss.str()); \ } \ } while(0) // 类似定义 LOG_INFO, LOG_WARN, LOG_ERROR, LOG_FATAL // 在 AsyncLogger::log 方法中格式化 void AsyncLogger::log(LogLevel level, const char* file, int line, const std::string& message) { if (level < current_level_.load(std::memory_order_relaxed)) { return; } auto now = std::chrono::system_clock::now(); auto tid = std::this_thread::get_id(); // 格式化日志行到当前缓冲区 // 格式示例: [2023-10-27 14:30:00.123][INFO][thread_id][file:line] message char time_buf[64]; auto t = std::chrono::system_clock::to_time_t(now); std::tm tm_buf; localtime_r(&t, &tm_buf); // 使用线程安全的 localtime_r strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S", &tm_buf); auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()) % 1000; // 将格式化后的字符串追加到 current_buffer_ // 这里省略了具体的字符串拼接和缓冲区管理细节... // 如果 current_buffer_ 剩余空间不足，则将其移入 buffers_to_write_，并尝试使用 next_buffer_ 或新建缓冲区。 // 最后，如果缓冲区快满了，通知后端线程 if (current_buffer_->avail() < 256) { // 预留一点空间 std::lock_guard<std::mutex> lock(mutex_); buffers_to_write_.push_back(std::move(current_buffer_)); if (next_buffer_) { current_buffer_ = std::move(next_buffer_); } else { current_buffer_ = std::make_unique<Buffer>(); current_buffer_->reserve(kBufferSize); } cond_.notify_one(); } }

实操心得：时间戳的性能陷阱获取时间戳（std::chrono::system_clock::now()）是一个相对昂贵的系统调用。在高频日志场景下，如果每条日志都调用一次，开销不可忽视。一个优化技巧是：每个日志条目复用同一个时间戳。可以在log函数入口获取一次时间戳，用于格式化该条日志的所有部分。更极致的优化是，后端写线程在批量写入时，使用它自己获取的“写入时刻”作为时间戳，但这会损失一些时间精度，需要权衡。

3.4 日志滚动与文件管理

日志文件不能无限增长。我们需要按大小或时间滚动。

• 按大小滚动：在backend_thread_func中，每次写入前检查当前文件大小，超过roll_size_则关闭当前文件，以新的文件名（如basename_20231027_143000.log）重新打开。
• 按时间滚动：例如每天零点滚动。后端线程可以记录当前日志文件的创建日期，在每次写入时检查日期是否变化。

一个更健壮的策略是结合两者：按天创建日志文件，并且当单个日志文件超过一定大小时，在同一天内进行编号滚动（如service_20231027.1.log,service_20231027.2.log）。

4. 核心二：实现高性能、可观测的任务调度器

任务调度器是服务框架的发动机。它负责接收任务、管理队列、分配线程/进程执行，并处理超时和失败。

4.1 调度器模型选择：线程池 vs 进程池

• 线程池：轻量，共享内存，通信高效。但一个任务的崩溃（如段错误）可能波及整个进程，隔离性差。适用于任务可信、主要是CPU计算或内存操作的场景。
• 进程池：重量级，创建开销大，进程间通信（IPC）复杂。但隔离性极好，一个任务崩溃不影响调度器和其他任务。适用于运行不可信第三方代码、或需要严格资源隔离（通过cgroups）的场景。

为了追求高可靠性（故障隔离）和资源控制，我们的框架选择进程池模型。调度器主进程负责任务队列管理和子进程生命周期管理，每个任务在独立的子进程中执行。

4.2 调度器核心组件设计

调度器主要由以下几个部分组成：

1. 任务定义（JobSpec）：描述一个任务的所有元数据，如命令行、工作目录、环境变量、资源限制（CPU、内存）、超时时间、优先级等。
2. 任务队列：存储待调度的任务。需要支持优先级队列（如使用std::priority_queue）。
3. 资源管理器（ResourceManager）：跟踪系统资源（如可用CPU核心数、剩余内存）和已分配的资源，确保不会过度提交（Overcommit）。
4. 调度循环（Dispatcher）：一个独立的线程，不断从任务队列中取出符合条件的任务（有资源、优先级最高），并启动子进程执行它。
5. 回收器（Reaper）：另一个独立的线程，通过waitpid（使用WNOHANG非阻塞模式）轮询已结束的子进程，回收其退出状态，释放其占用的资源，并触发回调（如通知任务完成）。
6. 监控与指标（Metrics）：收集任务排队时间、执行时间、成功率、系统负载等指标，并通过日志或Prometheus端点暴露。

4.3 关键实现细节与避坑指南

4.3.1 进程启动与资源限制使用fork()+exec()族函数启动子进程。在fork()后、exec()前，在子进程中进行环境设置：

• 设置进程组（setpgid）：将子进程设置为新的进程组组长。这样，我们可以通过向进程组ID发送信号（kill(-pgid, SIGTERM)）来终止整个任务树（包括它可能创建的子进程），这是实现“优雅终止”的关键。
• 设置资源限制（setrlimit）：限制子进程能创建的核心文件大小（RLIMIT_CORE，可设为0禁止生成core）、文件描述符数量（RLIMIT_NOFILE）等。
• 设置cgroup（可选但推荐）：对于更严格的资源隔离（尤其是内存），可以将子进程加入一个cgroup。这能防止单个任务耗尽所有内存导致系统OOM。通过写入/sys/fs/cgroup/...下的cgroup.procs文件实现。
• 重定向标准输入/输出：将子进程的stdout/stderr重定向到管道或文件，方便父进程（调度器）捕获输出，并记录到日志中。

// 简化版的进程启动函数 pid_t launch_job(const JobSpec& spec) { int stdout_pipe[2], stderr_pipe[2]; pipe(stdout_pipe); pipe(stderr_pipe); pid_t pid = fork(); if (pid == 0) { // 子进程 close(stdout_pipe[0]); close(stderr_pipe[0]); dup2(stdout_pipe[1], STDOUT_FILENO); dup2(stderr_pipe[1], STDERR_FILENO); close(stdout_pipe[1]); close(stderr_pipe[1]); // 创建新的进程组 setpgid(0, 0); // 设置资源限制 struct rlimit core_limit = {0, 0}; setrlimit(RLIMIT_CORE, &core_limit); // 切换工作目录（如果指定） if (!spec.workdir.empty()) { chdir(spec.workdir.c_str()); } // 准备参数和环境变量 // ... execvp(spec.cmd[0], const_cast<char* const*>(spec.cmd.data())); // 如果execvp失败 perror("execvp failed"); _exit(EXIT_FAILURE); // 使用_exit避免刷新父进程的stdio缓冲区 } else if (pid > 0) { // 父进程 close(stdout_pipe[1]); close(stderr_pipe[1]); // 将管道读端fd加入epoll或select，异步读取任务输出 // 记录pid和进程组pgid（等于pid，因为子进程是组长） return pid; } else { // fork失败 LOG_ERROR("fork failed: {}", strerror(errno)); return -1; } }

避坑指南：僵尸进程与信号处理子进程退出后，如果父进程不调用waitpid回收，它会变成“僵尸进程”，占用内核进程表项。我们的Reaper线程就是干这个的。但这里有个关键点：必须处理SIGCHLD信号。默认情况下，SIGCHLD信号会被忽略，但如果我们用waitpid非阻塞轮询，可能有一定延迟。更优雅的做法是捕获SIGCHLD信号，并在信号处理函数中向一个管道写入数据，唤醒Reaper线程立即进行回收。注意，信号处理函数中只能调用异步信号安全的函数（如write），不能调用printf、malloc等。

4.3.2 优雅终止与超时控制任务可能卡死，所以必须支持超时控制。

1. 启动任务时，记录其超时截止时间。
2. Reaper线程在轮询时，检查运行中任务的超时时间。如果超时，首先向其进程组发送SIGTERM（允许任务进行清理）。
3. 设置一个“宽限期”（Grace Period），例如5秒。
4. 宽限期后，如果任务仍未退出，则发送SIGKILL强制杀死。
5. 无论任务如何结束，Reaper最终都会通过waitpid回收它，并更新任务状态。

// Reaper线程循环片段 void reaper_loop() { while (running_) { // 非阻塞回收已结束的进程 int status; pid_t pid = waitpid(-1, &status, WNOHANG); if (pid > 0) { // 处理进程退出，释放资源，更新任务状态为Succeeded/Failed handle_job_finished(pid, status); } else if (pid == 0) { // 没有子进程退出，检查超时 check_timeouts(); } else if (pid == -1 && errno != ECHILD) { LOG_ERROR("waitpid error: {}", strerror(errno)); } std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 避免空转 } } void check_timeouts() { auto now = std::chrono::steady_clock::now(); std::vector<pid_t> to_kill; { std::lock_guard<std::mutex> lock(jobs_mutex_); for (auto& [pid, job] : running_jobs_) { if (job.timeout_point && now > *job.timeout_point) { if (!job.terminate_sent) { LOG_WARN("Job {} timeout, sending SIGTERM", pid); kill(-pid, SIGTERM); // 发给整个进程组 job.terminate_sent = true; job.grace_deadline = now + std::chrono::seconds(5); } else if (job.grace_deadline && now > *job.grace_deadline) { LOG_WARN("Job {} grace period expired, sending SIGKILL", pid); kill(-pid, SIGKILL); to_kill.push_back(pid); } } } } // 处理需要强制杀死的任务... }

4.3.3 资源管理与背压ResourceManager需要原子地预留和释放资源。当Dispatcher从队列取任务时，需要先向ResourceManager申请资源（如2个CPU核心，1GB内存），申请成功才能启动进程，否则任务需要放回队列或阻塞等待。

更高级的功能是背压感知。通过读取Linux内核提供的PSI（Pressure Stall Information）指标（/proc/pressure/cpu,/proc/pressure/memory,/proc/pressure/io），可以了解系统资源（CPU、内存、IO）的短缺程度。当PSI值超过阈值时，ResourceManager可以主动拒绝新的资源申请，甚至让Dispatcher暂停调度，直到系统压力下降。这能有效防止系统在负载过高时雪崩。

class ResourceManager { public: struct ResourceLimit { int cpu_cores; size_t memory_mb; }; bool reserve(const ResourceLimit& limit) { std::lock_guard<std::mutex> lock(mutex_); if (used_cpu_ + limit.cpu_cores > total_cpu_ || used_memory_ + limit.memory_mb > total_memory_) { return false; } if (system_under_pressure()) { // 检查PSI return false; } used_cpu_ += limit.cpu_cores; used_memory_ += limit.memory_mb; return true; } void release(const ResourceLimit& limit) { std::lock_guard<std::mutex> lock(mutex_); used_cpu_ -= limit.cpu_cores; used_memory_ -= limit.memory_mb; } private: bool system_under_pressure() { // 读取 /proc/pressure/cpu 等文件，解析avg10值 // 如果超过阈值（如cpu.pressure.avg10 > 0.7），返回true return false; // 简化实现 } int total_cpu_; size_t total_memory_; int used_cpu_{0}; size_t used_memory_{0}; std::mutex mutex_; };

5. 框架集成与高级特性

5.1 将日志系统与调度器整合

调度器本身应该是框架日志系统的主要用户。所有调度事件（任务提交、开始、结束、超时）、资源状态变化、系统警告都应通过日志系统记录。这要求日志系统在框架初始化时就必须就绪。

一个常见的模式是，在main函数或框架初始化函数中，首先初始化日志系统（指定日志文件、级别），然后启动调度器。调度器内部持有日志系统单例的引用。

5.2 暴露监控指标

一个没有监控的系统就是在“裸奔”。调度器需要暴露关键指标，方便集成到Prometheus、Grafana等监控栈中。

• 计数器：tasks_submitted_total,tasks_completed_total,tasks_failed_total,tasks_timeout_total。
• 测量值：task_queue_length,running_tasks。
• 直方图/摘要：task_duration_seconds（记录执行时间的分布），queue_wait_time_seconds。

我们可以实现一个简单的Metrics类，内部使用std::atomic变量存储这些值，并提供一个HTTP端点（例如使用libmicrohttpd或集成一个简单的HTTP服务器），当被访问/metrics时，以Prometheus文本格式返回所有指标。

5.3 集成eBPF进行深度性能剖析（可选但强大）

对于性能要求极高的场景，我们可以集成eBPF来动态追踪调度器和任务的行为，而无需修改代码或重启服务。

• 调度延迟分析：使用eBPF的tracepoint或kprobe，在内核态记录任务从入队到被Dispatcher线程取出的时间差。
• Off-CPU分析：任务执行慢，不一定是在消耗CPU，可能是在等待IO、锁或内存。eBPF可以跟踪任务被调度出CPU的原因和时间，生成Off-CPU火焰图，直观显示阻塞点。
• 系统调用分析：追踪任务执行了哪些系统调用及其耗时，帮助发现异常IO或网络问题。

集成eBPF通常需要编写BPF程序（用C语言），并通过bpf系统调用加载到内核。对于C++框架，我们可以封装一个EbpfProfiler类，在任务启动时附加BPF程序，在任务结束时收集并生成分析报告（如火焰图SVG）。这属于高级特性，但它能将框架的可观测性提升到另一个维度。

6. 常见问题排查与性能调优实录

在实际使用中，你肯定会遇到各种问题。以下是我踩过的一些坑和解决方案。

问题1：日志文件丢失最后几条日志？

• 现象：服务崩溃后，最新的几条日志没有写入文件。
• 原因：日志还在前端缓冲区，没来得及交换到后端线程，进程就崩溃了。
• 解决：
  1. 确保LOG_FATAL这类最高级别日志是同步写入（或立即触发刷新）。
  2. 注册信号处理函数（如SIGSEGV,SIGABRT），在信号处理中调用日志器的flush()方法。注意信号处理函数中只能调用异步信号安全函数，一个技巧是在信号处理中设置一个原子标志，然后由另一个监控线程来执行实际的刷新。
  3. 考虑使用O_DIRECT或O_SYNC方式打开日志文件（牺牲性能换取可靠性）。

问题2：任务调度器在高压下出现任务丢失？

• 现象：短时间内提交大量任务，有些任务状态一直为Pending，后来消失了。
• 原因：任务队列可能是有界的（如用std::queue），当提交速度远大于处理速度时，队列满导致新任务被丢弃。或者，ResourceManager的资源计数在多线程竞争下出错（非原子操作导致）。
• 解决：
  1. 使用无界队列（如std::deque）但要警惕内存增长，或者使用有界队列并配合合适的拒绝策略（如直接失败、或让调用者阻塞）。
  2. ResourceManager的reserve和release操作必须用锁或原子操作保护，确保检查-执行（check-then-act）是原子的。
  3. 增加指标task_rejected_total来监控拒绝情况。

问题3：子进程变成“僵尸”无法回收？

• 现象：ps aux看到很多<defunct>进程。
• 原因：Reaper线程的waitpid逻辑有bug，或者信号处理不当导致SIGCHLD被忽略。
• 解决：
  1. 确保waitpid使用WNOHANG在循环中调用，直到返回0或-1（ECHILD）。
  2. 设置SIGCHLD的处理函数为SIG_IGN（某些系统下可以自动回收僵尸进程），或者设置为自定义函数并配合管道通知Reaper线程。
  3. 检查是否在别处不小心调用了wait或waitpid阻塞了信号。

问题4：系统负载不高，但新任务调度延迟很大？

• 现象：CPU和内存使用率都很低，但任务排队时间很长。
• 原因：可能是IO或内存压力导致的。PSI指标中的memory.pressure或io.pressure可能很高，触发了调度器的背压机制，限制了新任务的启动。
• 解决：
  1. 检查调度器日志，看是否有背压相关的警告。
  2. 使用cat /proc/pressure/*查看当前PSI值。
  3. 如果确认是背压导致，需要优化任务本身的IO模式，或者调整背压阈值。

性能调优点：

• 日志缓冲区大小：kBufferSize（如4MB）需要权衡。太大会增加延迟（日志攒够4MB才刷），太小会增加系统调用和锁竞争频率。根据日志量调整，通常1-4MB是个不错的选择。
• 调度器线程数：Dispatcher和Reaper通常各一个线程就够了。如果任务启动非常频繁（每秒上千次），可以考虑使用多Dispatcher线程，但需要更复杂的队列同步。
• waitpid轮询间隔：Reaper线程的sleep时间（如100ms）影响僵尸进程的回收延迟和超时检测的精度。对于需要快速响应的场景，可以缩短间隔，或使用SIGCHLD信号驱动。
• 资源管理粒度：以CPU核心数为单位管理可能太粗。可以考虑使用CPU份额（CPU shares）或CFS配额进行更精细的管理。内存管理也可以结合cgroup的memory.high进行软限制，避免直接OOM kill。

构建这样一个高可靠的服务框架绝非一日之功，它需要你对C++语言特性、Linux系统编程、并发模型、性能分析和系统稳定性有深入的理解。但一旦构建完成，它将为你和你的团队提供一个坚实、可信赖的开发基础，让后续的业务开发效率和质量都得到质的提升。这个框架的每个组件，从日志的异步刷盘到调度器的背压控制，都凝结了线上系统稳定性的最佳实践。