文末有福利~
隨著大數據的日益普及，很多人對大數據越來越感興趣，有些程序開發者也躍躍欲試，但是苦於不會搭建集群環境，而常常被攔在大數據的門檻之外。
通過這次疫情，我相信各位也看見了，大數據真的很重要。從患者數字地圖，到疑似患者追蹤，再到可視化，都體現著大數據的作用，我也相信，在未來的5-10年裡，大數據會有非常非常多的應用與發展。
大數據裡最難的就是怎麼保持數據查詢的穩定性，那麼集群就很重要了。
先來給大家講講集群吧。
傳統的系統架構就是經典的三層結構，就一個項目跑在一個tomcat中，但是隨著用戶數量的增加，一個服務器一個tomcat肯定是不靠譜的，如果鄉村教師馬雲在杭州一個小地方，搞了一臺服務器，一個tomcat，跑天貓的代碼，然後讓我們去訪問，那我們估計是不可能看到網站首頁的，一直處於宕機狀態。哈哈！
這時候可以使用集群的架構，就是說現在馬雲狠著買了5臺服務器，每臺服務器都跑天貓的代碼，然後又搞了一個Nginx做負載均衡，這時候我們的請求由五臺服務器完成的，第一次請求是第一臺服務器響應，第二次請求是由第二臺服務器響應，這樣可以應對的併發量就是之前的5倍，馬雲很開心，美滋滋。
總結：多臺服務器跑的都是一套完整的代碼，這就叫集群。
那大數據的穩定集群方案怎麼搭建呢？
別急，我今天就給大家講講國內頂尖的大數據和商業智能（BI）領跑者：帆軟公司，來看看他們的集群方案是怎麼架構的。
先來介紹一下帆軟吧。IDC認證國內BI市場佔有率第一，注意是IDC認證，可不是什麼垃圾機構的證書。其次，超11000家大中型企業選擇，為38000個信息化項目提供BI支持，數字背後的實力不容小噓。
不說別的，就B端這種商業智能的公司，年銷售額達到5個億就已經很牛了，國內除了它就沒別的。不信？那就透明透明財務咯。
再來看看集群方案選擇。
帆軟集群架構簡單概述就是負載均衡+狀態服務器+文件服務器/節點間同步+外置數據庫，架構很明瞭，不過架構中各個應用組件，我們需要針對不同場景進行選擇和搭配。
本文將介紹如何選擇集群方案，以及各種方案的優劣勢，為IT人員規劃設計集群方案時提供一些有效的指引。
1. 選擇操作系統
帆軟集群方案對於windows系統和Linux系統均能支持，列舉一下兩類操作系統下可以選擇的方案（標紅為推薦或較常用方案）：
考慮到穩定性和性能情況，推薦選用Linux系統作為服務器的操作系統。下面簡單介紹Linux系統作為服務器操作系統對比windows系統的兩大特性：
1.1 穩定性
- Linux系統穩定性極佳，大部分硬件和配置更新無需重啟；
- Linux系統相對Windows系統，宕機機率更低，常常一年都不用關機；
1.2 性能優勢
- Linux系統處理多線程比Windows要好的多，是真正的多用戶多線程，而windows是單用戶偽多線程；
- Linux系統不像Windows系統必備圖形化操作界面，因此佔用資源會少一些，性能也更好；
- 內存管理和調度方式優秀，有效利用一切硬件資源；
但是影響我們最終哪種系統的因素，還有一個最關鍵的點——運維能力，如果公司不具備Linux系統的運維能力，那隻能選擇Windows系統了。
2. 選擇負載均衡
負載均衡分為軟件負載均衡和硬件負載均衡，兩種負載均衡核心作用是一樣的，負載均衡作為集群的入口，起到請求分發和節點健康檢查的作用。
2.1 硬件負載均衡
硬件負載均衡很穩定，性能也相對較好，但是成本也高，最常用的負載均衡就是F5。若公司有硬件負載均衡且具備較好的配置和運維能力，確認硬件負載均衡具備主動健康檢查功能後，即可選擇使用硬件負載均衡。
簡單介紹一下硬件負載均衡的優缺點：
- 優點：能夠直接通過智能交換機實現,處理，而且與系統無關，負載性能強更適用於一大堆設備、大訪問量、簡單應用；
- 缺點：成本高，除設備價格高昂，而且配置冗餘．很難想象後面服務器做一個集群，但最關鍵的負載均衡設備卻是單點配置；無法有效掌握服務器及應用狀態；
使用文檔：負載均衡配置指導
2.2 軟件負載均衡
簡單介紹一下軟件負載均衡的優缺點：
- 優點：基於系統與應用的負載均衡，能夠更好地根據系統與應用的狀況來分配負載。這對於複雜應用是很重要的，性價比高，實際上如果只有幾臺服務器，用F5之類的硬件產品顯然有些浪費，而用軟件就要划算的多，因為服務器同時還可以跑應用做集群（雖然不太推薦），或者僅提供一般配置的服務器來給負載均衡應用。
- 缺點：負載能力會受服務器本身性能的影響。
帆軟官方驗證過的軟件負載均衡有兩種：Treafik和Nginx，兩種均為開源軟件，更新頻率和維護力度穩定，下面說一下兩個負載均衡的適用場景。
2.2.1 Nginx
Nginx作為負載均衡在Linux系統上具備很好的併發性能，並且佔用極小的內存。許多大公司都在用，穩定性和性能是經過充分驗證的。但是在Windows系統上並不支撐較高併發，所以在Windows系統上選用Nginx作為負載均衡，需要考慮併發情況，若併發需求低於200，部署集群僅以熱備為目的，則可選用Nginx作為負載均衡，若併發需求超過200，則不建議使用Nginx，須換用其他負載均衡。
如果希望Nginx層面也具備高可用性，避免單點故障，那麼可以再做一個Keepalived+Nginx方案，確保一個Nginx服務宕機或異常後，有備用的Nginx服務可以接手。
使用文檔：Linux 系統安裝配置 Nginx、Windows系統安裝配置Nginx、Keepalived+Nginx部署方案
2.2.2 Treafik
Traefik是Go語言編寫的單一可執行文件，無需安裝，只要在命令行裡執行即可，部署和使用非常簡單，適用於對運維能力要求不高的用戶使用。和Nginx相比，有兩大優點：
- 在Windows系統上具備良好的性能，因此Windows系統推薦使用Treafik；
- 支持自動化更新反向代理和負載均衡配置；
使用文檔：windows系統安裝配置Treafik
Nginx在Linux系統下的性能和穩定性、Treafik在Windows系統下的性能和穩定性，帆軟都已經進行了測試和驗證。理論上Treafik在Linux系統上也具備較好的性能，但是為了避免方案的繁雜以及考慮維護成本，未對Treafik在Linux系統上的性能和穩定性做充分的驗證。
總的來說，Linux系統推薦選用Nginx作為負載均衡，Windows系統不建議選擇Nginx，推薦選用Treafik。
3. 選擇Redis方案
帆軟集群方案裡，狀態服務器是用Redis實現的，常用的Redis方案有Redis單機、Redis集群、Redis哨兵三種，這裡對如何選擇三種方案進行介紹。
如果公司已有Redis服務，不管是下面哪一種，都可以直接使用，這樣可以減少額外維護一個應用的成本，但是如果沒有Redis服務，我們為了使用集群，就要新安裝Redis服務了。
3.1 Redis單機
Redis單機指的是隻部署一個Redis應用，此種方案簡單易部署，運維成本低，能夠保證集群的可用性。
使用文檔：Linux 系統安裝配置單機 Redis
3.2 Redis集群
如果對於系統/方案的高可用性要求高，希望能夠避免單點故障，那麼Redis集群可以很好地滿足需求。
3.2.1 架構介紹
Redis 集群結構是N個平權主節點（master），每個主節點對應M個從節點（slave），由於Redis集群的投票機制，N須為奇數，且必須大於等於3，否則創建集群時會失敗。
業界經過大量檢驗最常用的Redis集群架構是3主3從。
3.2.2 資源需求
部署3主3從的Redis集群時，建議至少主從3臺服務器，主從節點在構建Redis集群時會進行隨機分配。
如果想要達到更加極致的高可用，避免主節點和從節點剛好分配到一臺機器並且遇到服務器宕機導致整個Redis集群不可用的情況發生，可以準備6臺服務器來做3主3從的Redis集群，這樣任何一臺服務器宕機都不會影響Redis集群對外提供服務。
3.2.3 優缺點說明
優點：
- 主節點宕機後，基於投票機制從節點可自動上升為主節點，可讓Redis服務更加高可用；
- 數據分區存儲在不同的主節點上，可以大幅度提升Redis服務的性能支撐；
缺點：
- 由於數據分區存儲，所以當一個主節點及其對應的從節點全部宕機後，整個Redis集群將不能使用；
- 當存活的主節點數小於總節點數的一半時，整個Redis集群也會無法提供服務；
- 不管是3臺服務還是6臺服務器，我們都能感受到Redis集群對資源的要求是比較多的，且運維成本也會比Redis單機更高；
使用文檔：linux系統安裝配置Redis集群
簡單總結，Redis集群方案可以讓Redis服務更加高可用，但是運維和資源成本更高，建議選擇時仔細考慮。
3.3 Redis哨兵
3.3.1 架構介紹
Redis哨兵模式是基於Redis主從模式的方案，Redis 2.8及以後版本提供了哨兵工具來實現自動化的系統監控和故障恢復功能。哨兵的作用就是監控master、slave是否正常運行，master出現故障後自動將slave轉換為master。
目前帆軟暫未提供Redis哨兵的部署方案，但是如果想自己部署Redis哨兵服務的話，建議至少使用2個哨兵（因為哨兵模式中將主服務器判斷為失效至少需要 2 個 Sentinel 同意，所以我們至少要部署兩個及以上的Sentinel ），
最常用的Redis哨兵方案為1主2從3哨兵，能夠做到較好的高可用。
3.3.2 資源需求
可以將主節點、從節點、哨兵節點部署在一臺或多臺服務器上，但是和Redis集群一樣，如果我們想要達到極致的高可用，避免一臺服務器宕機就導致整個Redis服務不可用，那麼就把每個節點部署在一個獨立的服務器上。
3.3.3 優缺點說明
優點：
- 主從可以自動切換，故障可以轉移，系統可用性更好；
- 哨兵模式是主從模式的升級，系統更健壯，可用性更高。
缺點：
- 不能支持高併發，能提供寫入功能的也就只有主節點。
說明：FineReport和FineBI產品需要安裝Redis哨兵插件來對接Redis哨兵服務，插件還在測試階段，暫未對外發布。
簡單總結，Redis哨兵模式也可以讓Redis服務更加高可用，但是也是比較耗費運維和資源的，而且與Redis集群相比最大的缺點就是性能和單機一樣，無法提升Redis服務的性能。
4. 選擇文件一致性方案
集群一致性裡有一個很關鍵的點就是文件一致性，帆軟提供了多種方案來保障節點間資源文件的一致性。我們可以基於運維能力，實際場景來進行選擇。
4.1 節點間同步
節點間同步是保障節點間資源文件一致性的最簡單的方案了。
優點：
- 無須開啟文件服務器，無須做任何配置即可使用，無運維成本，使用成本很低。
- 各個節點均存儲有文件，因此可以達到熱備的效果，具備高可用性。
缺點：
- 節點間同步方案不適用於多節點，建議僅在使用兩節點時選用節點間同步方案，因為節點越多，由於通信和同步效率等原因，可能會同步失敗或者由於同步不及時影響使用；
簡單總結，節點間自動同步的方案能夠滿足雙機熱備的需求，運維和使用成本很低，無須額外維護組件，但是不適用於多節點，建議僅在兩個節點時選用。
4.2 文件服務器
帆軟支持多種文件服務器，下面會對各個類型的文件服務器優缺點進行說明。
4.2.1 共性優缺點
先說明一下文件服務器共性的優缺點，共性優缺點指不管選擇哪種文件服務器，都具備的。
優點：
- 文件一致性高，由於各個節點都是從同一個文件服務器讀取資源文件，不涉及到同步，各個節點讀取的資源文件永遠會保持一致性；
- 適用於多節點、超多節點的場景；
缺點：
- 使用成本比節點間同步高，由於額外使用一個組件，導致部署運維成本會略高一些，需要更多的資源支撐這些組件；
4.2.2 特性優缺點
總結一下，當我們有超過2個節點時，為了保證各個節點文件的高一致性，建議使用文件服務器。基於高可用性、性能需求，以及公司實際的情況（是否已有文件服務器），再選擇對應的文件服務器。
5. 選擇緩存模式
5.1 緩存功能
緩存的資源文件：包含報表文件、儀表板文件、配置文件、地圖數據等，目前是"reportlets/" ,"resources/", "assets/"，"dashboards"四個文件夾。
主動緩存：緩存所有資源文件；
被動緩存：僅對訪問到的資源文件進行緩存；
5.2 緩存作用
優點：
- 提高文件服務器的高可用性，若使用文件服務器時開啟了緩存，當文件服務器宕機時，系統從緩存中讀取資源文件，仍可正常對外提供服務；
- 提高工程的性能，無法充分從節點下或者文件服務器中讀取文件，可大幅提高模板的訪問性能；
缺點：
- 緩存會佔用系統內存資源；
總結一下，開啟緩存功能可以大幅提高工程的性能，並且配合文件服務器使用時，可提高系統的高可用性，建議使用文件服務器時開啟緩存。
6. 選擇外置數據庫
外置數據庫在集群方案裡也是很關鍵的點，由於各個節點均使用同一個外置數據庫，因此節點間的配置可以保持一致性。FineReport和FineBI對常用的數據庫都可以支持，包括MySQL、SqlServer、Oracle、DB2，這裡不作詳細介紹。若公司已有數據庫服務，數據庫版本符合帆軟的要求則可直接使用，若需要新部署數據庫服務，則建議部署mysql，部署比較簡單。
使用文檔：配置外接數據庫
7. 通信協議
帆軟集群支持TCP和UDP兩種通信協議，目前默認是TCP協議，下面列舉兩種協議的區別：
其中需要注意的是，大部分雲服務器（阿里雲、亞馬遜雲等）都不支持UDP協議，因此只能選擇TCP協議。
若服務器對TCP/UDP協議均支持，當節點數較少時選擇TCP/UDP協議差異不大， 當節點數較多時，建議選擇UDP協議，通信效率更高。
關注我，並轉發該文章，私信回覆“報表”，即可獲得FineReport90天免費版企業抗疫應用方案。
閱讀更多 IT技術管理那些事兒 的文章
