2017年愛奇藝高可用高性能服務器編程架構實踐.pdf

1、愛奇藝高可用高性能服務器編程架構實踐2017.11背景 對于高可靠、高可用框架的要求 1、應用服務的不間斷性：1.1、服務程序可在線熱升級1.2、數據及配置可在線重新加載 2、應用服務可運維可監控：2.1、服務異常自動重啟2.2、服務異常自動報警2.3、服務配置項一致性2.4、服務進程統一管理 為什么需要高并發、高性能框架？1、互聯網尤其是移動互聯網的快速蓬勃發展對服務端應用的壓力與日俱增2、高性能、低延遲的業務需求對應用服務提出了更高的要求3、內網中 RPC 通信、連接池的大量存在要求服務端支持大并發、高性能Acl 服務器編程框架內容分類內容分類功能項功能項服務器模型服務器模型多進程服務模型

2、、多線程服務模型、多線程服務模型、非阻塞服務模型、觸發器服務模型、網絡協程服務模型安全運行機制安全運行機制嚴格的用戶權限限制，防止越權操作；IP 地址訪問控制，防止非法地址訪問配置驅動方式配置驅動方式獨立的服務配置文件，豐富的配置項：進程數、線程數、防問控制、監聽地址、進程預啟動等均由配置項決定服務監聽服務監聽支持綁定 TCP 套接口、UDP 套接口以及 UNIX 域套接口，支持同一進程同時綁定多個地址及端口服務管理服務管理支持應用服務在線熱升級，升級過程不會中斷服務；提供 WEB 管理接口及管理工具，方便遠程管理運維監控運維監控提供應用服務進程管理模塊，在線監控各個應用服務的存活狀態，對異常

3、崩潰的服務實時報警運行方式運行方式生產環境由 acl_master 服務管理進程控制管理；開發環境可以手工單獨運行開發調試開發調試用服務器生成向導直接生成服務器程序框架；用 valgrind 檢查服務程序的內存問題Acl 服務器框架模型memorydata structurelogstreamnetthreadTPollconfigureevents(select/poll/epoll/kqueue/iocp/wmsg)fiberProcessesThreadsAioFibersUdpTriggersTQueueaiohttpsmtpicmpmemcacheredisbeanstalkmysq

4、ljsonxmlmimecoderurlbase64uucodecharsetQP基礎層通信層協議層服務層基礎層通信層協議層服務層sslmasterDNSWEBDBCDNGAME應用層應用層MAILCHATOS APILinuxFreeBSDWindowsMacOSAndroidIOS適配層適配層postgressqlsqlite網絡協程調度-設計原理創建網絡協程創建網絡協程IO阻塞阻塞準備運行準備運行運行運行掛起協程掛起協程IO 調度協程調度協程由由IO協程監控協程監控IO喚醒協程喚醒協程IOIOIOIO編程要點：編程要點：1、每個網絡連接對應一個協程2、遇到網絡 IO 讀/寫 堵點就切走相

5、應協程3、將 IO 句柄由 epoll 協程進行監控4、IO 準備好時其對應協程重新加入調度隊列網絡協程應用場景 一、問答式應用服務基于 HTTP 協議的服務應用，諸如：網站基于 SMTP/POP3/IMAP 協議的服務應用 二、生產者 消費者類應用服務如消息隊列類應用 三、reactor 和 proactor 兩種模式的結合統一的事件引擎監控所有的網絡連接，有一個連接就緒時創建協程獨立處理此類應用如聊天服務、游戲服務等無狀態的應用服務 四、大并發類應用服務因為通過協程方式，將上層應用的堵塞式在底層轉為非阻塞模式，所以非常容易以較低資源支持大并發類應用如內網的多數應用服務為提高效率都支持連接池

6、模式，需要服務端支持非常大的并發 五、網絡限流在協程中可以直接 sleep，非常容易控制網絡流量愛奇藝高性能高可用服務的工程實踐 背景：1、如何支撐超 5 億月活用戶的視頻收看？-海量用戶、海量存儲、海量帶寬，每項都是巨大的挑戰 2、如何達到熱播劇的快速分發？-新發視頻快速“送達”用戶最近觀影點，即發即播 3、如何達到視頻流的快速開播？-不能讓用戶多等一秒 4、如何針對大文件進行有效回源？-這是 Squid/Apache Traffic/Nginx 目前都未解決的問題CDN 回源系統開發歷程 遇到的坑：1、Squid，Apache Traffic，Nginx 無法針對大文件進行有效合并回源 2

7、、多線程/多協程方式下的各種死鎖 3、緩存對象提前釋放導致的各種崩潰 4、內存“暴漲”導致的瞬間崩潰 5、用戶跳躍式點播視頻導致回源帶寬的大量浪費 。踩坑方案：1、合并相同請求塊數據，支持緩存部分數據 2、優化線程鎖及協程鎖設計，避免死鎖 3、有效隔離緩存對象的內存隊列 4、內部禁止大內存分配，同時采用 sendfile 等零拷貝技術，內存僅占幾百兆 5、調整數據視頻回源優先級，優先保證在線收看請求 6、支持流式數據傳輸，提升視頻開播速度 。愛奇藝 CDN 回源軟件架構協程協程協程協程協程協程協程協程任務管理器協程協程協程協程緩存管理器磁盤管理器客戶端連接客戶端連接下載協程池下載協程池連接協程

8、池連接協程池Acl 服務基礎框架服務基礎框架協程線程線程線程線程線程連接管理器消息管理器線程管理器線程管理器愛奇藝 CDN 回源方案解析特性特性說明說明高并發高并發采用網絡協程方式，支持高并發接入，同時簡化程序設計高性能高性能采用線程池+協程+連接池+內存池技術，提高業務處理性能高吞吐高吞吐采用磁盤內存映射及零拷貝技術，提升磁盤及網絡 IO 吞吐能力低回源低回源合并相同請求，支持部分回源及部分緩存，大大降低回源帶寬開播快開播快采用流式數據讀取方式，提升視頻開播速度可擴展可擴展模塊化分層設計，易于擴展新功能易維護易維護采用統一服務器編程框架，易管理，好維護愛奇藝 CDN 分發同步系統架構消息處理

9、節點消息處理節點消息處理節點redisredisredis服務管理節點服務管理節點消息分發節點方案特點：方案特點：1、消息處理模塊消息處理模塊、消息分發模塊消息分發模塊、服務管理模塊服務管理模塊均為多節點部署方式，消除故障單點；2、采用集群版 redis 存儲狀態數據，降低消息丟失，同時提高消息處理能力；3、服務管理模塊服務管理模塊檢控所有服務的運行狀態，可動態增加、刪除服務節點；4、消息接收模塊消息接收模塊通過服務管理模塊服務管理模塊自動獲得 消息分發模塊消息分發模塊接入點，可自動負載均衡及容錯。消息接收節點消息接收節點。消息發送節點。消息分發節點消息分發節點消息分發節點消息發送節點愛奇藝高

10、性能 DNS 愛奇藝為什么要開發自己 DNS？1、愛奇藝本身業務的需要，如 CDN 智能調度的需要 2、高性能 QPS 以滿足業務頻繁訪問需要，同時應對一定 DDos 攻擊 開發 DNS 面臨的挑戰：1、目標達到百萬級 QPS 2、QPS 與 View 數量無關 3、Zone 頻繁更新不影響正常服務 4、主從切換無感知愛奇藝高性能 DNS 架構UDP 進程工作線程工作線程工作線程數據加載線程DNS數據DNS UDP 請求TCP 進程工作協程數據加載線程DNS TCP 請求工作協程工作協程工作協程工作協程Master 管理進程一、UDP 服務進程：1、采用 RUSEPORT 方式，提升工作線程并

11、行收包能力2、采用 recvmmsg/sendmmsg 多讀多寫方式，提升每次 IO 包收發能力3、采用內存預分配策略，減少內存動態分配/釋放時的“鎖”沖突二、TCP 服務進程：每個 TCP 請求分配一個協程進行業務處理三、UDP 及 TCP 服務進程在更新數據時采用 RCU 方式四、UDP 及 TCP 服務進程均由 master 管理進程統一管理愛奇藝高性能 DNS 架構分析優勢優勢說明說明高性能高性能啟用 Linux 3.0 內核的 REUSEPORT 功能，提升多線程并行收發包的能力采用 Linux 3.0 內核的 recvmmsg/sendmmsg API，提升單次 IO 數據包收發能

12、力采用內存預分配策略，減少內存動態分配/釋放時的“鎖”沖突針對 TCP 服務模式，采用網絡協程框架，最大化 TCP 并發怎能能力高可用高可用采用RCU（Read Copy Update）方式更新視圖數據及配置項，無需停止服務，且不影響性能網卡 IP 地址變化自動感知（即可自動添加新 IP 或摘除老IP而不必停止服務）采用 Keepalived 保證服務高可用易管理易管理由 Acl master 服務管理模塊管理 DNS 進程，控制 DNS 進程的啟動、停止、重讀配置/數據、異常重啟及異常報警等愛奇藝生產環境數據真實展現 1、視頻卡頓比 2%2、CDN 視頻回源帶寬 200 萬次/秒 4、單機數據分發能力：視頻文件達千萬/日，靜態圖片文件達億/日歡迎加入愛奇藝大家庭 公司總部：北京-愛奇藝創新大廈 地址：北京海淀區海淀北一街2號愛奇藝創新大廈11層 郵編：100080 電話：+86 10 6267.7171 傳真：+86 10 6267 7000 聯系方式:http:/