本文通過ECS訪問ApsaraDB for MongoDB，測試並分析了ApsaraDB for MongoDB複本集執行個體中鏈式複製對執行個體效能的影響，為MongoDB執行個體效能最佳化提供參考。
鏈式複製
什麼是鏈式複製
MongoDB支援鏈式複製。當複本集中的某個從節點（Secondary節點）從另一個從節點同步資料時，就發生了鏈式複製。鏈式複製可以降低主節點（Primary節點）的負載，但可能會在不同的網路拓撲中導致更長的主從延遲。更多資訊，請參見Self-Managed Chained Replication。
鏈式複製並不意味著所有節點必須形成單一的鏈條結構，而是Secondary 節點可根據網路往返時延（Round-Trip Time，RTT）等資訊，選取Primary以外的節點作為同步源。以5節點複本集拓撲結構為例，下圖中展示的網路拓撲結構均屬於鏈式複製。
配置鏈式複製
您可以在控制台的參數設定頁面調整settings.chainingAllowed 參數，以啟用或禁用鏈式複製。如何調整參數，請參見設定資料庫參數。
在某些情況下，鏈式複製可能會導致主從同步延遲，您可以禁用鏈式複製以最佳化同步處理效能。
出於安全性考慮，您並沒有對阿里雲MongoDB執行個體執行replSetReconfig命令的相關許可權，請通過控制台調整相關參數。
執行個體效能影響測試
測試環境
建立ECS執行個體和ApsaraDB for MongoDB複本集執行個體。如何建立，請參見棄置站台集執行個體和通過控制台使用ECS執行個體（快捷版）。
ApsaraDB for MongoDB執行個體架構：標準複本集拓撲結構（三節點，包含一個主節點、一個從節點和一個隱藏節點），並通過添加從節點和唯讀節點擴充複本集節點數。
ECS執行個體和MongoDB執行個體間的網路往返時延：測試執行個體在同一地區及可用性區域下，RTT（Round-Trip Time）平均值為0.103ms。
本次測試的執行個體配置如下：
配置項 | ECS執行個體 | ApsaraDB for MongoDB雲端硬碟架構執行個體 |
地區及可用性區域 | 華北2（北京）可用性區域H | 華北2（北京）可用性區域H |
網路類型 | Virtual Private Cloud | Virtual Private Cloud |
執行個體規格類型系列 | 計算型c6 | 獨享型 |
執行個體規格 | ecs.c6.xlarge(4c8g) | ecs.c7.xlarge(4c8g) |
儲存類型 | ESSD PL0 | ESSD PL1 |
執行個體或鏡像版本 | Alibaba Cloud Linux 3.2104 LTS 64位 | 4.19.91-26.al7.x86_64 |
MongoDB核心版本 | 不涉及 | 大版本：5.0 小版本基準版本：5.0.30 |
測試載入器
本次壓力測試將採用開源社區的YCSB 0.17.0壓測工具。
YCSB是一款用Java編寫的支援多種資料庫的效能測試工具，具體安裝和使用方法請參見YCSB。
測試方法
添加白名單。登入ECS控制台，在執行個體詳情頁面的網路資訊地區查看ECS執行個體的主私網IP，將ECS執行個體的主私網IP添加到ApsaraDB for MongoDB執行個體的白名單中。
使用YCSB工具進行載入資料測試。
./bin/ycsb.sh load mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=5000000 -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin" -p table=test -threads 8參數說明：
recordcount：載入至ApsaraDB for MongoDB執行個體的資料總數。mongodb.url：ApsaraDB for MongoDB執行個體的串連地址。本文使用的資料庫帳號為test，所屬資料庫為admin。您可以登入ApsaraDB for MongoDB控制台，在資料庫連接頁面的私網串連 - 專用網路地區查看串連地址。threads：用戶端的並發線程數。
查看ycsb的測試結果以及測試執行個體的監控資訊。在監控資訊頁面的節點監控頁簽下，選擇本次測試對應的時間段，查看執行個體主節點的CPU使用率、操作QPS數、平均回應時間指標。具體操作請參見節點監控（原基本監控）。
測試結果
參數說明
Write Concern：資料持久化保證層級，決定了寫操作需要滿足哪些條件後才被認為成功完成。測試結果中相關取值介紹如下。
{w:"majority"}：預設配置，表示大多數（majority），等待寫操作被複製到複本集中大多數節點上後才確認完成。{w: 1}：表示只需要Primary節點確認完成。
測試結果詳情
3節點
複本集拓撲結構：1個主節點、1個從節點、1個隱藏節點。
writeConcern為{w:"majority"}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 5277 | 5241 |
CPU使用率 | 65% | 65% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
writeConcern為{w:1}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 15075 | 14785 |
CPU使用率 | 93% | 93% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
7節點
複本集拓撲結構：1個主節點、5個從節點、1個隱藏節點。
writeConcern為{w:"majority"}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 3005 | 4312 |
CPU使用率 | 56% | 85% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
writeConcern為{w:1}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 14414 | 11492 |
CPU使用率 | 91% | 93% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
15節點
複本集拓撲結構：1個主節點、5個從節點、1個隱藏節點、8個唯讀節點。
包括7個投票節點和8個非投票節點（唯讀節點不參與投票）。
writeConcern為{w:"majority"}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 2932 | 3123 |
CPU使用率 | 58% | 91% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
writeConcern為{w:1}
對比項 | 啟用鏈式複製 | 禁用鏈式複製 |
輸送量throughput（ops） | 14093 | 7500 |
CPU使用率 | 90% | 94% |
操作QPS數（個） |
|
|
平均回應時間RT（微秒） |
|
|
效能對比及總結
相同的節點數配置下，禁用鏈式複製是否會導致寫入效能下降，取決於writeConcern的配置。
writeConcern為
{w:1}3節點執行個體，禁用鏈式複製帶來的效能退化基本可以忽略不計。
7節點執行個體，禁用鏈式複製帶來的效能退化約為20.3%。
15節點執行個體，禁用鏈式複製帶來的效能退化達到了46.8%，而且可以明顯觀察到禁用鏈式複製後主節點上CPU使用率的提升。
writeConcern為
{w:"majority"}3節點執行個體，禁用鏈式複製帶來的效能退化基本可以忽略不計。
7節點和15節點執行個體，禁用鏈式複製反而可以帶來大約6.5%~43.5%的效能提升。
效能提升原因：禁用鏈式複製後，複本集內所有節點整體同步鏈路縮短，導致majority的條件更容易被滿足，單次寫入的延遲有所縮短。
非投票節點數的影響：隨著非投票節點的數量增加（投票節點固定7個），禁用鏈式複製帶來的效能提升會越來越不明顯，這是由於主節點上承載的主從同步負載太高導致的。
相同的chainingAllowed以及writeConcern配置下，寫入效能隨著節點數增加而下降。而且禁用鏈式複製後，寫入效能隨著節點數增加下降趨勢更加顯著。
預設配置下（
chainingAllowed:true+writeConcern:{w:"majority"}），由於複本集只能包含不超過7個投票節點，滿足majority的條件並沒有變化，因此將節點數從7個擴充到15個時，寫入效能退化並不明顯。無論是否禁用鏈式複製，
writeConcern:{w:1}效能都要明顯優於writeConcern:{w:"majority"}，符合writeConcern設計。writeConcern配置固定時，隨著節點數增加，禁用鏈式複製相比啟用鏈式複製會顯著提高主節點的CPU使用率。
最佳實務
節點數少時，您可以按需啟用或禁用鏈式複製。執行個體整體效能基本不會受到影響，CPU使用率差異不大。
節點數多時：
writeConcern為
{w:1}，建議啟用鏈式複製。writeConcern為
{w: "majority" }，需要在主節點負載（CPU使用率等）和執行個體效能之間做進一步的取捨。禁用鏈式複製有助於提升寫入效能，但相應的主節點負載也會顯著增加。