POLARDB架構簡介
PolarDB是阿裡雲ApsaraDB資料庫團隊研發的基于雲計算架構的下一代關系型資料庫(暫時僅支援MySQL，PostgreSQL正在緊鑼密鼓的開發中)，其最大的特色是計算節點(主要做SQL解析以及存儲引擎計算的伺服器)與存儲節點(主要做資料塊存儲，資料庫快照的伺服器)分離，其次，與傳統的雲資料庫一個執行個體一份資料拷貝不同，同一個執行個體的所有節點(包括讀寫節點和隻讀節點)都通路存儲節點上的同一份資料，最後，借助優秀的RDMA網絡以及最新的塊存儲技術，PolarDB的資料備份耗時可以做到秒級别(備份時間與底層資料量無關)，這三點相結合，我們可以推斷出PolarDB不但滿足了公有雲計算環境下使用者業務快速彈性擴充的剛性需求(隻讀執行個體擴充時間與底層資料量無關)，同時也滿足了網際網路環境下使用者對資料庫伺服器高可用的需求(伺服器當機後無需搬運資料重新開機程序即可服務)。
DB Server: 即資料庫程序(Polar DataBase, 簡稱PolarDB)。PolarDB資料庫核心區分執行個體角色，目前包括三種角色，Primary，Standby和Replica。Primary即為擁有讀寫權限的讀寫庫，Replica即為隻讀執行個體，僅僅擁有讀取資料的權限(背景線程也不能修改資料)，Primary和Replica采用Shared Everything架構，即底層共享同一份資料檔案和日志檔案。StandBy節點擁有一份獨立的資料和日志檔案(如圖2所示)，雖然使用者線程依然隻有讀取資料的權限，但是背景線程可以更新資料，例如通過實體複制的方式從Primary節點更新增量資料。StandBy節點主要用來機房級别的容災以及建立跨可用區的隻讀執行個體，公測階段暫時不開放。由于隻讀執行個體的擴充不需要拷貝資料，建立新的隻讀執行個體不但速度快，而且很便宜，使用者隻需要支付相應計算節點的成本即可。我們稱StandBy和Replica節點為Slave節點，Primary節點也可稱為Master節點。
User Space File System: 即使用者态檔案系統(Polar File Sytem, 簡稱PolarFS)。由于多個主機的資料庫執行個體需要通路塊存儲上的同一份資料，常用的Ext4等檔案系統不支援多點挂載，PolarDB資料庫團隊自行研發了專用的使用者态檔案系統，提供常見的檔案讀寫檢視接口，便于MySQL和相關的外圍運維工具使用檔案系統支援類似O_DIRECT的非緩存方式讀寫資料，還支援資料頁原子寫，IO優先級等優秀的特性，為上層資料庫的高性能提供了結實的保障。傳統的檔案系統，由于嵌入在作業系統核心中，每次系統檔案讀寫操作都需要先陷入核心态，完成後再傳回使用者态，造成效率低下。PolarFS以函數庫形式編譯在MySQL中，是以都運作在使用者态，進而減少了作業系統切換的開銷。
Data Router & Cache: 即塊存儲系統用戶端(Polar Store Client, 别名PolarSwitch)。PolarFS收到讀寫請求後，會通過共享記憶體的方式把資料發送給PolarSwitch，PolarSwith是一個計算節點主機次元的背景守護程序，接收主機上所有執行個體以及工具發來的讀寫塊存儲的請求。PolarSwith做簡單的聚合，統計後分發給相應的存儲節點上的守護程序。由此可見PolarSwitch是一個重資源的程序，如果處理不好，對計算節點上的資料庫執行個體有很大的影響，是以我們的管控程式對其使用了CPU綁定，記憶體預配置設定，資源隔離等一些手段，并且同時部署了高效可靠的監控系統，保證其穩定運作。
Data Chunk Server: 即塊存儲系統伺服器端(Polar Store Server, 别名ChunkSever)。上述三個部件都運作在計算節點上，這個部件則運作在存儲節點上。主要負責相應資料塊的讀取。資料塊的大小目前為10GB，每個資料塊都有三個副本(位于三台不同的存儲節點上)，兩個副本寫成功，才給用戶端傳回成功。支援資料塊次元的高可用，即如果一個資料塊發生不可用，可以在上層無感覺的情況下秒級恢複。此外，PolarStore使用了類似Copy On Write技術，支援秒級快照，即對資料庫來說，不管底層資料有多大，都能快速完成全量資料備份，是以PolarDB支援高達100T的磁盤規格。
計算節點和存儲節點之間通過25G RDMA網絡連接配接，保證資料的傳輸瓶頸不會出現在網絡上。
此外，PolarDB還有一套完善的基于docker的管控系統，處理使用者下發的建立執行個體，删除執行個體，建立賬号等任務，還包括完善詳細的監控，以及可靠的高可用切換。管控系統還維護了一套中繼資料庫，用以記錄各個資料塊的位置資訊，提供給PolarSwitch，便于其轉發。
可以說，PolarDB整個項目用了很多很多的新技術黑科技，給使用者直接的感受是，又快(性能是官方MySQL6倍)又大(磁盤規格支援高達100T)又便宜(價格隻有商業資料庫的1/10)。
實踐内容
POLARDB資料庫準備
進入雲資料庫阿裡雲POLARDB控制台進行配置：2核4GB（獨享配置）
建立後會發現有兩個執行個體，一個主執行個體，一個隻寫執行個體。
測試過程
本次場景使用HyperPacer PRO 2016版進行資料庫壓測。
配置如下：
1.進行工程配置：
初始化JDBC配置和JDBC請求：
這裡各個編輯控件和下拉控件的使用及每個選項的說明，隻要在HyperPacer的工具欄上點選幫助就可以看到。在綁定變量指派的編輯區域裡，我們看到在前兩個變量指派這裡做了參數化。
這裡需要注意的是：此處綁定變量指派的順序和個數需要和存儲過程中定義的參數保持完全一緻。
在綁定變量類型的編輯區域，這裡的類型隻可以是在java.sql.Types中定義的類型，并且要保證和我們調用的存儲過程中的參數類型保持一緻。
我們這裡說的類型保持一緻要分為兩方面來看：一方面要保證用于傳參的變量類型保持一緻，即這裡寫的JDBC類型要和SQL類型保持一緻，關于保持類型一緻的轉換映射關系可以檢視
JDK的官方文檔。
2.如下圖進行壓力資料測試配置:
參數詳解
基準使用者數：系統過載前允許的最大使用者數
最大使用者數：系統過載後允許的最大使用者數
基準使用者加壓政策：固定時間内加載固定數量的基準使用者進入系統
過載使用者加壓政策：固定時間内加載固定數量的過載使用者進入系統
持續總時長：系統過載後持續保持過載運作的時間
使用者退出政策：測試結束前多少時間内退出全部使用者
壓力閥配置：配置測算系統過載的依據，如平均CPU使用率達到99%等。