從SRS項目看現代C++最佳實踐：高性能實時流媒體服務器的設計智慧詳情 - c++,音視頻,多媒體,流媒體,rtmp 老司機博客

從SRS項目看現代C++最佳實踐：高性能實時流媒體服務器的設計智慧

68747470733a2f2f6f737372732e6e65742f77696b692f696d616765732f5352532d53696e676c654e6f64652d342e302d73642e706e673f763d313134.png

前言

SRS (Simple Realtime Server) 是一個高性能的實時視頻服務器，支持RTMP、WebRTC、HLS、HTTP-FLV、SRT等多種協議。作為一個擁有200萬行代碼、在生產環境廣泛應用的開源項目，SRS展現了許多值得學習的現代C++設計思路和最佳實踐。本文將深入解析SRS項目的C++代碼架構，探索其在高性能、高併發場景下的設計智慧。

項目背景：為什麼SRS值得研究？

技術規模與影響力

代碼規模: 超過200萬行C++代碼，6000+源文件
協議支持: RTMP/WebRTC/HLS/HTTP-FLV/SRT/MPEG-DASH/GB28181
平台兼容: Linux/macOS/Windows，支持X86_64/ARMv7/AARCH64/M1/RISCV等架構
編解碼: H.264/H.265/AV1/VP9/AAC/Opus/G.711
生產應用: 被眾多公司用於構建直播和實時通信平台

技術挑戰

流媒體服務器面臨的核心技術挑戰包括：

低延遲要求: 毫秒級別的延遲控制
高併發處理: 同時處理數萬路流
內存管理: 大量音視頻數據的高效處理
協議複雜性: 多種協議的狀態機管理
穩定性要求: 7x24小時穩定運行

這些挑戰促使SRS採用了許多精巧的C++設計模式和實踐。

現代C++特性的保守與務實使用

C++11標準的選擇

SRS項目選擇C++11作為基礎標準，這在看似保守的選擇背後體現了工程項目的務實考量：

// trunk/auto/utest.sh:24
SRS_CPP_VERSION="-std=c++11"

為什麼選擇C++11而非更新標準？

兼容性考慮: 確保在各種老舊系統上的編譯兼容性
穩定性優先: C++11已經足夠成熟，避免新標準的潛在bug
性能敏感: 避免新特性帶來的性能開銷
團隊協作: 降低團隊成員的學習成本

智能指針的自定義實現

SRS沒有直接使用std::unique_ptr，而是實現了自己的智能指針系統，這展現了高性能項目的典型做法：

// trunk/src/core/srs_core_autofree.hpp:32-89
template <class T>
class SrsUniquePtr
{
private:
    T *ptr_;
    void (*deleter_)(T *);

public:
    SrsUniquePtr(T *ptr = NULL, void (*deleter)(T *) = NULL)
    {
        ptr_ = ptr;
        deleter_ = deleter;
    }

    virtual ~SrsUniquePtr()
    {
        if (!deleter_) {
            delete ptr_;
        } else {
            deleter_(ptr_);
        }
    }

    // C++11 move semantics support
#if __cplusplus >= 201103L
    SrsUniquePtr(SrsUniquePtr<T> &&other);
    SrsUniquePtr<T> &operator=(SrsUniquePtr<T> &&other);
#endif
};

自定義智能指針的優勢：

自定義刪除器: 支持malloc/free、特殊釋放函數
性能優化: 避免標準庫的額外開銷
調試友好: 可添加自定義調試信息
向後兼容: 支持C++11之前的編譯器

模板的精確使用

SRS在模板使用上非常剋制，主要用於工具類和類型安全：

// trunk/src/kernel/srs_kernel_mp4.hpp:3027-3047
template <typename T>
std::stringstream &srs_dumps_array(std::vector<T> &arr, std::stringstream &ss,
                                   SrsMp4DumpContext dc,
                                   void (*pfn)(T &, std::stringstream &, SrsMp4DumpContext),
                                   void (*delimiter)(std::stringstream &, SrsMp4DumpContext))
{
    for (int i = 0; i < (int)arr.size(); i++) {
        if (i > 0 && delimiter) {
            delimiter(ss, dc);
        }
        if (pfn) {
            pfn(arr[i], ss, dc);
        }
    }
    return ss;
}

模板使用原則：

僅在必要時使用模板，避免過度抽象
優先考慮代碼可讀性和編譯速度
模板主要用於類型安全和代碼複用

內存管理的藝術

RAII模式的徹底貫徹

SRS通過RAII模式確保資源的安全釋放：

// trunk/src/core/srs_core.hpp:57-65
#define srs_freep(p) \
    delete p;        \
    p = NULL;        \
    (void)0

#define srs_freepa(pa) \
    delete[] pa;       \
    pa = NULL;         \
    (void)0

資源管理器模式

// trunk/src/kernel/srs_kernel_resource.hpp:215-249
template <typename T>
class SrsSharedResource : public ISrsResource
{
private:
    SrsSharedPtr<T> ptr_;
public:
    SrsSharedResource(T *ptr = NULL) : ptr_(ptr) {}
    virtual ~SrsSharedResource() {}

    T *operator->() { return ptr_.operator->(); }
    T *get() { return ptr_.get(); }
};

內存管理最佳實踐：

統一的資源管理: 所有資源都通過RAII管理
自定義智能指針: 滿足特定需求的智能指針實現
明確的所有權語義: 通過類型系統表達資源所有權

錯誤處理的工程化實踐

分層錯誤系統

SRS實現了一個強大的分層錯誤處理系統：

// trunk/src/kernel/srs_kernel_error.hpp:437-481
class SrsCplxError
{
private:
    int code_;
    SrsCplxError *wrapped_;
    std::string msg_;
    std::string func_;
    std::string file_;
    int line_;
    SrsContextId cid_;
    int rerrno_;

public:
    // 錯誤鏈構建
    SrsCplxError *wrap(const std::string &msg);
    SrsCplxError *transform(int code);

    // 錯誤信息提取
    std::string description() const;
    int error_code() const { return code_; }
};

錯誤分類體系

SRS按功能模塊對錯誤進行分類：

// 系統錯誤 (1000-1099)
#define ERROR_SOCKET_CREATE 1000
#define ERROR_SOCKET_BIND   1002
#define ERROR_SOCKET_LISTEN 1003

// RTMP協議錯誤 (2000-2999)
#define ERROR_RTMP_HANDSHAKE 2000
#define ERROR_RTMP_PACKET_SIZE 2001

// 應用錯誤 (3000-3999)
#define ERROR_HLS_DECODE_ERROR 3000
#define ERROR_DVR_CANNOT_OPEN 3001

錯誤處理最佳實踐：

分層錯誤鏈: 錯誤可以被包裝和傳遞，保持調用棧信息
上下文信息: 每個錯誤包含完整的調試信息
分類管理: 按模塊和嚴重級別分類錯誤代碼
性能考慮: 錯誤對象的創建和銷燬要高效

併發編程的創新方案

State Threads協程庫

SRS沒有使用標準的pthread或C++11線程，而是選擇了State Threads庫：

// trunk/src/protocol/srs_protocol_st.hpp:22-26
typedef void *srs_netfd_t;
typedef void *srs_thread_t;
typedef void *srs_cond_t;
typedef void *srs_mutex_t;

協程化的網絡IO

// 協程式的網絡讀寫
srs_error_t SrsStSocket::read(void *buf, size_t size, ssize_t *nread)
{
    *nread = st_read(stfd_, buf, size, ST_UTIME_NO_TIMEOUT);
    if (*nread <= 0) {
        return srs_error_new(ERROR_SOCKET_READ, "st_read failed");
    }
    return srs_success;
}

線程安全的鎖機制

// trunk/src/protocol/srs_protocol_st.hpp:152-174
#define SrsLocker(instance) \
    impl__SrsLocker _SRS_free_instance(instance)

class impl__SrsLocker
{
private:
    srs_mutex_t *lock_;
public:
    impl__SrsLocker(srs_mutex_t *l) {
        lock_ = l;
        srs_mutex_lock(*lock_);
    }
    virtual ~impl__SrsLocker() {
        srs_mutex_unlock(*lock_);
    }
};

併發編程最佳實踐：

協程優於線程: 在IO密集型場景下，協程提供更好的性能
RAII鎖管理: 通過RAII確保鎖的正確釋放
事件驅動架構: 基於事件循環的高效併發模型

類型安全與接口設計

前向聲明的大量使用

// trunk/src/app/srs_app_server.hpp:27-73
class SrsAsyncCallWorker;
class SrsUdpMuxListener;
class SrsRtcConnection;
class ISrsAsyncCallTask;
class SrsSignalManager;
// ... 更多前向聲明

前向聲明的價值：

編譯速度: 減少頭文件依賴，提升編譯速度
解耦合: 降低模塊間的耦合度
循環依賴: 解決頭文件的循環依賴問題

接口抽象的使用

SRS大量使用抽象接口來實現多態和解耦：

class ISrsSignalHandler
{
public:
    virtual ~ISrsSignalHandler() {}
    virtual srs_error_t on_signal(int signo) = 0;
};

class ISrsResourceManager
{
public:
    virtual ~ISrsResourceManager() {}
    virtual void subscribe(ISrsResource* c) = 0;
    virtual void unsubscribe(ISrsResource* c) = 0;
};

條件編譯與平台適配

測試友好的設計

// trunk/src/core/srs_core.hpp:16-25
#ifdef SRS_FORCE_PUBLIC4UTEST
#define SRS_DECLARE_PRIVATE public
#define SRS_DECLARE_PROTECTED public
#else
#define SRS_DECLARE_PRIVATE private
#define SRS_DECLARE_PROTECTED protected
#endif

這個設計讓所有私有成員在測試模式下變為public，極大地便利了單元測試。

平台兼容性檢查

// trunk/src/core/srs_core.hpp:67-70
#if !defined(__amd64__) && !defined(__x86_64__) && !defined(__i386__) && \
    !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && \
    !defined(__mips64) && !defined(__loongarch64) && !defined(__riscv)
#error "Only support i386/amd64/x86_64/arm/aarch64/mips/mips64/loongarch64/riscv cpu"
#endif

性能優化的細節考量

內存池和對象複用

SRS在關鍵路徑上大量使用對象池和內存池技術：

// 包對象的複用管理
class SrsPacketManager
{
private:
    std::vector<SrsRtpPacket*> free_packets_;

public:
    SrsRtpPacket* acquire_packet() {
        if (!free_packets_.empty()) {
            SrsRtpPacket* pkt = free_packets_.back();
            free_packets_.pop_back();
            return pkt;
        }
        return new SrsRtpPacket();
    }

    void release_packet(SrsRtpPacket* pkt) {
        pkt->reset();
        free_packets_.push_back(pkt);
    }
};

零拷貝技術

在媒體數據處理中，SRS儘可能避免不必要的內存拷貝：

class SrsBuffer
{
private:
    char* data_;
    int size_;
    int pos_;

public:
    // 返回當前位置的指針，避免拷貝
    char* current() { return data_ + pos_; }

    // 直接在緩衝區上操作
    void skip(int size) { pos_ += size; }
};

現代C++特性的取捨思考

為什麼不用更新的C++標準？

兼容性至上: 流媒體服務器需要在各種環境中部署
性能第一: 避免新特性可能帶來的性能開銷
穩定性考慮: 生產環境優先選擇成熟穩定的技術
團隊效率: 降低學習成本，提高開發效率

哪些現代特性值得采用？

建議採用的特性：

auto關鍵字：提高代碼可讀性
Lambda表達式：簡化回調和算法
智能指針：改善內存管理
右值引用：優化性能關鍵路徑
constexpr：編譯時計算

需要謹慎的特性：

複雜模板：可能影響編譯速度和調試
異常：在高性能場景下開銷較大
標準庫算法：不一定比手寫代碼更高效
新的併發庫：可能不如專門的高性能庫

總結：工程實踐的智慧

SRS項目展現了現代C++在大型工程項目中的最佳實踐：

設計原則

性能優先: 所有設計決策都以性能為首要考量
穩定可靠: 優先選擇成熟穩定的技術方案
可維護性: 代碼結構清晰，便於長期維護
可測試性: 設計時考慮測試的便利性

技術選擇

保守的標準選擇: C++11提供了足夠的現代特性
自定義核心組件: 針對性能需求定製關鍵組件
接口驅動設計: 通過抽象接口實現模塊解耦
RAII貫徹始終: 確保資源管理的安全性

工程化思維

分層架構: 清晰的模塊分層和職責劃分
錯誤處理: 完善的錯誤分類和處理機制
平台兼容: 考慮多平台部署的兼容性
性能調優: 在關鍵路徑上進行精細優化

SRS項目證明了現代C++不一定要追求最新的語言特性，而是要根據項目特點選擇合適的技術棧。在高性能、高可靠性要求的系統中，工程化的設計思維比語言特性的新穎性更為重要。

對於其他C++項目，SRS的經驗告訴我們：

根據需求選擇技術：不是越新越好，而是越合適越好
性能與可維護性平衡：在性能要求和代碼可維護性之間找到平衡
工程化思維：把代碼當作工程來設計，考慮長期維護和團隊協作
漸進式演進：在穩定的基礎上漸進式地引入新技術

這些實踐經驗對於開發高質量的C++項目具有重要的指導意義。

本文基於SRS 6.0版本代碼分析，SRS是一個持續演進的開源項目，代碼地址：https://github.com/ossrs/srs

博客 / 詳情