在企業應用中，通常單個計算機的配置是有限的，而企業應用又是高并發的需求，這個時候會通過計算機集群的方式來提高并發數，從而提高整體應用服務的性能。集群是將多臺計算機作為一個整體來提供相關應用的服務。FineBI支持多計算機服務的集群部署，通過集群部署利用有限的計算機資源來有效提高整體應用的并發性能。本文主要介紹整體FineBI集群的思路。
FineBI采用負載均衡集群的模式，將多臺服務器創建為一個集群服務器。這里碰到這幾個問題：1）web工程的存儲問題：FineBI在集群中，由于自身的問題需要多臺服務器讀取同一個web工程。因此要實現web工程分享。2）系統數據一致性：在FineBI的運行過程中，存在讀寫的操作，同時有部分的數據的配置文件要寫入數據庫。需要保證集群的情況下，系統數據的一致性。3）負載均衡：一方面通過負載均衡來處理session的問題，另一方面達成負載均衡的集群環境，使用代理服務器可以將請求轉發給集群內部的服務器，可以將負載均衡和代理服務器的高速緩存技術結合在一起，提供有益的性能。4）FS平臺集群：如FineBI使用FS平臺，則FS平臺的各種配置也需要進行集群配置。
如下圖是一個FineBI進去的架構的案例示意圖，這種方式通過NFS文件共享來處理web工程。
Web工程存儲問題
Web工程的存儲，我們要解決的是多個服務器保證讀取同一個web工程。我們可以通過ceph做到多塊物理硬盤組件一塊邏輯硬盤，從而實現所有節點都是在訪問同一地址；也可以通過linux本身帶有的nfs共享文件服務來達成訪問同一web工程。無論使用哪一種方式，我們要保證：
<!--[if !supportLists]-->1）<!--[endif]-->訪問同一web工程
<!--[if !supportLists]-->2）<!--[endif]-->Cube存儲地址是一致的
因為同一個web工程下，要求cube的存儲地址是一致的，因此要求cube存儲地址一定要一樣。
而真正使用的時候，ceph的實現需要至少三臺計算機來實現，而實際企業應用中，比較少使用三臺；而nfs均可以且是linux本身的，因此使用“nfs”方案。
系統數據配置
單節點的情況下，利用緩存和通過操作系統的文件系統來保存數據的方式，在集群模式下不再合適。主要原因在于數據的一致性問題，多個節點可能進行同時讀寫，更改系統數據，最終勢必會造成整體數據不一致。最好的解決方案是系統配置數據全部交給MySQL等關系型數據庫來管理。但由于這樣工程量好大，更主要的原因為許多代碼缺少維護，貿然更改可能帶來意想不到的bug。于是我們采用一種折中的做法。在集群中選出一臺幾點作為主節點，簡稱M。其余節點擔當子節點，簡稱S。當S上所有與更改系統配置相關的操作，全部發送到M上進行處理。M負責來更改系統狀態，維護整個系統到底一致的狀態。S節點放棄全部的緩存數據，讀取狀態的時候，不再通過讀取自身數據，而是通過向M發送讀取請求，獲得M上的數據。M節點自身可以存在緩存數據。其他數據S節點與M節點時等同的，不存在從屬關系。
因此按上述原由我們提供如下解決方案：
<!--[if !supportLists]-->1）<!--[endif]-->mysql數據庫：原web工程中存在finedb的配置信息轉存到mysql數據庫中。因為finedb數據庫只能有一個連接，無法多節點同時讀取，而mysql數據庫則不存在。Logdb也需遷移；
<!--[if !supportLists]-->2）<!--[endif]-->主子節點：我們使用主子節點的方式來配置集群，系統數據的更改均在主節點上進行，子節點只讀取主節點上的數據；
<!--[if !supportLists]-->3）<!--[endif]-->Zookeeper：為了保證讀寫情況下，主子節點保證數據一致性，還需要zookeeper進行通信，充當文件鎖的功能。
負載均衡
在FineBI的集群環境中，我們可以使用任何支持負載均衡的服務器來完成輪發的任務，并保證session粘滯。此處我們使用的是nginx反向代理，使用IP標識輪發，保證同一個用戶在同一個session。（在一個服務器一個節點的情況下，同一個IP就保證session粘滯）。
FS平臺集群
使用FS平臺集群插件，將FS平臺配置能夠滿足集群需求。在FS平臺集群中，FS平臺的所有操作都是發到主節點上來操作；子節點只是作計算服務器。