2.1.3　影子庫與影子表

影子庫與影子表的建設思路是類似的，兩者都是將壓測數據轉存至一個獨立的數據區域，與真實數據隔離開，只不過影子庫是基于數據庫維度建立這個數據區域的，而影子表則是基于數據表維度建立這個數據區域的。然而，雖然建設思路類似，但是兩者的技術實現方案還是有所差異的，影子庫的實現更容易理解，改造成本可控，但需要花費雙倍的數據庫資源（哪怕是只讀表也需要冗余資源）；影子表的實現相對復雜，需要中間件支持，但冗余成本低（即冗余的資源少）。

我們先來看影子庫的技術實現步驟，如下所示。

（1）創建一個新的數據庫作為影子庫，影子庫的名稱沒有特別的要求，但推薦在原數據庫名中增加前綴或后綴作為影子庫的名稱，以便統一管理。例如，原數據庫名為Foo，影子庫可以命名為SFoo。影子庫建立完成后，我們會得到一個新的數據源。

（2）在影子庫中建立與真實表結構完全一致的數據表，并將真實表的數據脫敏或偏移后全部寫入新的數據表，保證兩者數據規模一致。

（3）根據壓測標識實現數據源的動態切換，確保壓測請求觸發的數據操作都能命中影子庫。

其中，第（3）步的實現比較關鍵，我們希望壓測盡可能減少對業務代碼的侵入性。一種常見的第（3）步的實現方法是將數據源切換的功能集成到一個SDK中，業務代碼使用這個SDK連接數據源，達到動態獲取數據源的目的，這樣改動的業務代碼量非常少。還有一種更先進的實現方法是通過字節碼增強技術，在代碼運行時改變連接的數據源，從而達到根據壓測標識動態切換數據寫入區域的目的，這樣幾乎不需要改動業務代碼，當然，這種方法實現難度更大一些。

安全起見，影子庫一般需要在獨立的實例上搭建。部分企業在實踐中會將影子庫與真實庫建立在同一個實例上以節省成本，但這樣做會帶來一定的風險，一旦影子庫的流量壓力過高，可能會影響真實庫的性能，因此需要對相關指標進行嚴密的監控。

我們再來看一下影子表。通俗地說，影子表就是一張與真實表結構一致的新數據表，我們需要確保兩者存儲的數據規模是一致的，否則會影響壓測結果的可信度。

如圖2.4所示，影子表的建立過程可以參照以下步驟：

● 針對某張真實表建立相應的影子表，兩者的表名可以通過在影子表的表名上增加前綴或后綴區分，例如，原表名為User，影子表名可以設為TUser；

● 將真實表的數據進行脫敏，部分ID類字段需要進行偏移，以免字段增長后與真實表的字段沖突，例如，真實表中的訂單號均以1開頭，那么影子表中的訂單號可以偏移為以9開頭；

● 將脫敏和偏移后的數據導入影子表；

● 進行完整性檢查（如數據量、表結構等內容），確保數據無誤。

圖2.4　影子表的建立過程

影子表建立過程中的各環節，需要在數據庫中間件或獨立平臺中實現并串聯。此外，根據壓測標識將數據操作路由至相應影子表，也需要改造數據庫中間件或在ORM框架中定制路由邏輯，可見影子表所需的改造工作量較大。我們通過表2.1看一看影子庫和影子表的對比情況。

表2.1　影子庫和影子表的對比情況

對于影子庫和影子表的選型，筆者給出的建議是：如果數據庫中只讀表的數量明顯高于需要執行寫操作的表的數量，可以選擇影子表的技術實現方案，可節省成本；反之，選擇影子庫的技術實現方案，可降低配置和改造成本。

最后，還要提醒一點，我們無論是采用影子庫還是影子表的技術實現方案，在數據準備完畢后，都需要使用小流量執行一次全鏈路壓測，這樣一方面可以檢查數據的正確性，另一方面也可以作為一種預熱操作。影子表中的數據都是“冷”數據，它們不像真實表中的數據一樣會被加載到緩沖池里以提升訪問和操作的性能，如果不執行預熱操作，很容易得出“偏劣”的性能結論。