序言
業界周知，播出系統是全臺最復雜、安全性要求最高的系統，而數據庫的安全穩定運行則是播出系統的核心要素之一。在設計建設播出系統時，我們始終致力使數據庫安全穩定運行。但在現實場景中，由于數據庫故障導致的播出事故仍然常發，影響程度輕重不一，嚴重時將導致大面積長時間停播，恢復時間較長。本文就播出系統數據庫的幾個經典架構展開討論，供讀者參考。
一．共享盤陣雙機熱備數據庫
圖1 共享盤陣雙機熱備數據庫
雙機熱備數據庫架構見圖1，核心是采用DAS(Direct Attached Storage)存儲和雙機熱備軟件，任一時刻只有一臺主機處于服務狀態，另一臺主機處于等待服務狀態。處于服務狀態的主機占用對外的IP地址，對共享盤陣有讀寫權限，對應的數據庫進程處于活動狀態。而等待服務的主機釋放出對外的IP地址，沒有訪問共享盤陣的權限(甚至根本看不見盤符)，數據庫進程處于停止狀態。在這個架構中，盤陣有兩個SAS接口，分別接到主、備機上，主機寫進去的數據可被備機讀出，反之亦然，實現了數據的共享，數據的一致性非常好。
雙機熱備軟件是一套資源管理系統，負責對外IP地址的轉移、數據庫進程的管理、盤符保護。特別是在主、備機倒換期間，對各資源按規定順序停止、啟動，違反這些規定都將使數據出錯。從主機倒換到備機的過程是：1.停止主機數據庫進程、撤銷主機對外IP地址、關閉主機的盤陣訪問權限；2.開啟備機盤陣訪問權限、加載備機對外IP地址、啟動備機數據庫進程。從備機到主機的倒換與此類似，倒換的時間大約在1分鐘左右，倒換后客戶機的工作狀態需要認真確認。
這個架構的優點是數據“一致性”好，靠的是盤陣雙SAS連接主機實現共享讀寫。缺點是，盤陣必須選用高端的RAID，而且是故障“單點”。
在實際部署中，雙機熱備軟件需要作復雜的配置，在日常運行維護中，需要定期檢查和倒換測試。雙機通過RS232或CAT5心跳線相互檢測對方是否存活，對環境要求非常苛刻。在實際使用中，出現過雙機互檢失敗而爭搶資源致宕機的情況，因盤陣故障導致數據丟失的情況也發生過。
由于這種架構設備昂貴，且盤陣是故障“單點”，目前這類案例逐漸減少。
這種類型的架構適合多種平臺(Window、Linux、Solaris)、數據庫軟件(SQL Server、Oracle)、雙機熱備軟件(Costandby、EMC autostart、NEC Express cluster )。
二．動態鏡像雙機熱備數據庫
圖2 動態鏡像雙機熱備數據庫
為了規避共享盤陣的單點，動態鏡像雙機熱備數據庫架構得到廣泛使用，在播出系統中占比較大。
這種動態鏡像雙機熱備架構不再需要昂貴的DAS存儲盤陣，直接用服務器內置存儲就可以部署系統。數據的“一致性”是靠雙機熱備軟件實時鏡像數據來保證的。
這里的實時鏡像，不是文件級鏡像，文件級鏡像不能保證數據的一致性。在這個架構中，數據鏡像是磁盤指令級的鏡像，是單步鏡像，一步完成了再進行下一步。
該架構消除了單點故障，綜合性能較好。在實際使用中，發現的問題是，數據鏡像其實是很困難的，曾發生過倒換前后數據不一致的情況。
這種類型的架構也適合多種平臺(Window、Linux、Solaris)、數據庫軟件(SQL Server、Oracle)、雙機熱備軟件(Costandby、EMC autostart、NEC Express cluster )。
三．實時應用集群數據庫系統
圖3 實時應用集群數據庫雙機熱備
數據庫，有一臺主機處于待機狀態，未對外提供服務，存在浪費現象，并且倒換時會中斷1分鐘左右，對于訪問數量較大的業務(如金融、票務等)不太適合，這種環境下可采用實時應用集群。
實時應用集群數據庫RAC(real application clusters)多見于Oracle數據庫，是一種集數據多重復制、負載均衡、多層次故障轉移的系統架構。在該架構中，前臺有多個主機，每個主機有兩個網卡，每個網卡有一個IP地址。在后臺，用SAN網絡部署塊級(BLOCK)存儲，實現數據多重復制和故障轉移。另外，還有心跳線專屬網絡，這是系統正常工作的首要條件。
需要特別補充說明的是，在該架構中，Oracle數據庫系統自動部署Servicename服務，該服務類似于DNS，實現負載均衡。客戶端連接數據庫時，首先連接Servicename服務，得到相應的IP地址和數據庫SID，當有多個客戶端連接時，每個客戶端得到IP地址和SID都不同，分別對應不同的主機，實現了負載均衡。當某個主機一個網卡的網線斷開后，這個網卡的IP地址便轉移到另一網卡；當兩個網卡的網線都斷開后，兩個IP地址都轉移到另外的主機。在發生網卡斷線、主機失效等情況時，servicename服務系統會相應調整分配策略，以實現可靠的故障轉移和負載均衡。
實時應用集群數據庫，從多個層次保障了數據的安全性和服務的連續性，能夠滿足金融、股票等訪問量很大的業務需求。但該架構的缺點是系統復雜，對系統環境要求極高，稍不滿足就可能發生故障，維護成本高。在現實應用中，出現過網絡的瞬間丟包導致切換，也出現過因網絡的輕微故障導致保護性關機的情況。
四．容錯服務器搭建數據庫
前面介紹的三種數據庫架構，關系到三個層次：硬件及OS、集群軟件、數據庫軟件，結構復雜。在安裝部署時，有復雜的連接線，如SAS電纜、SAN存儲系統、心跳線，這些連接線要求很高，稍有缺陷便會成為隱患。然后每臺主機安裝操作系統和集群軟件，最復雜的是集群軟件的資源配置，幾乎涉及所有硬件的參數，沒有足夠的經驗是沒有把握的，在日常應用中，還要定期進行倒換實驗。盡管做了如此多而復雜的工作，這三種架構的數據庫故障并未顯著降低，離安全播出的“零事故”要求相差甚遠。
這三種架構的數據庫，我臺均采用過，但都不省心。在建設全頻道高清播出系統時，我們再次為數據庫的選型而糾結。“眾里尋他千百度……”,一個偶然的機會，我們了解到容錯服務器(fault tolerance server)，該服務器在高速ETC、國家氣象、國家電網、鋼鐵生產等行業廣泛應用。這些行業的安全性要求與播出等同，容錯服務器能否為我所用，我們作了必要的分析調研。
圖4 容錯服務器結構展示
從圖4左邊可以看到，容錯服務器是一個可以插入兩個服務器模塊的機箱，形成一個完整的容錯服務器。從圖4右邊可以看到，兩個模塊并非獨立存在，而是通過Lockstep關聯起來。正是這個關聯，解決了前面說的三種架構中數據同步、心跳檢測、故障切換的問題。
在安裝部署上，一個容錯服務器就是一個框體，自然不再需要集群軟件，操作系統、數據庫軟件只需安裝一次(在購買操作系統和數據庫軟件時,也只支付單臺服務器費用)，便自動同步到兩個模塊。運行管理上，也就是一臺服務器，但從內部看，具備完整的硬件容錯、數據鏡像、失效切換、安全離線等機制。
容錯服務器的設計理念，是將主要的硬件（CPU、內存、主板、I/O設備、硬盤驅動器和風扇）全部冗余化，實現在同一框體內的兩臺完整的服務器之間形成完全冗余結構，以提供服務器的連續可用能力。容錯服務器上線后，無間斷運行、無中斷維護，系統運行狀態下可直接拉出故障模塊進行維修，修復后可直接插入模塊，恢復到原始冗余狀態。容錯服務器的冗余機制見圖5。
圖5 容錯服務器的冗余機制
總結
在播出一線，效率和安全是王道，系統建設應該朝著傻瓜化努力，降低系統的技術門檻，減輕運行維護人員的負擔，把精力投入到提升業務水平、產生更多的效益上去。在采用容錯服務器后，數據庫變得非常簡單，只需做好日常巡查和數據備份，經過兩年多的使用證明，容錯服務器的確安全省心。