構建高效能和高彈性 WebSphere eXtreme Scale 應用程式的原則和最佳實踐

簡介： IBM® WebSphere® eXtreme Scale 是一種通用、高速的快取解決方案，可在各種不同的設計中予以配置和使用。不過，您不能盲目地使用 WebSphere eXtreme Scale 提供的 API，並想當然地認為它會減輕資料庫的工作重負，使您的應用程式更快地執行。作為提高應用程式效能的一種策略，快取應當被明智謹慎地應用。同樣地，您不能想當然地認為您的應用程式可以彈性地應對硬體故障，除非您為此籌備了有意識的計劃。本文考查了大量最佳實踐，幫助您構建高效能和高彈性的 WebSphere eXtreme Scale 應用程式。 本文來自於 IBM WebSphere Developer Technical Journal 中文版。

簡介

資料是用於管理、挖掘和運算元據的所有計算系統的核心元素。在 Internet 年代，應用程式不僅要求即時訪問資料，通常還以壓倒性的近乎同步的請求嘗試該訪問。儘管資料庫技術有了很大提高，集中式資料儲存對這種需求和響應能力的應用程式來說還是存在問題。

IBM WebSphere eXtreme Scale 為高容量和高 SLA（服務級別協議）應用程式提供集中式資料訪問選擇。WebSphere eXtreme Scale 通過快取技術將資料拉近應用程式。將資料移近應用程式可獲得以下優勢：

• 本地資料可改善應用程式的效能。 這既包括快取資料使其接近應用程式，又包括複製靠近（分割槽）資料的應用程式邏輯，以實現並行處理。
• 為頻繁訪問的資料提供快取可以節省時間或降低資料庫的爭用和總體請求容量。 這轉而降低資料庫級的硬體和許可成本，且可為共享該資源的應用程式提高資料庫總體響應能力。
• 將資料拉近應用程式可提高可用性。WebSphere eXtreme Scale 還提供了複製整個環境中的資料的特性，從而進一步提高彈性。
• 與訪問基於 SQL 的資料相比，以最終的本機應用程式形式（物件）快取資料可減小路徑長度。
• 快取複雜業務邏輯的結果可加快後續呼叫，並降低總體解決方案成本。

WebSphere eXtreme Scale 是一種通用、高速的快取解決方案，可在各種不同的設計中予以配置和使用。不過，您不能盲目地使用 WebSphere eXtreme Scale 提供的 API，並想當然地認為它會減輕資料庫的工作重負，使您的應用程式更快地執行。作為提高應用程式效能的一種策略，快取應當被明智謹慎地應用。同樣地，您不能想當然地認為您的應用程式在遇到硬體故障時具有彈性，除非您為此籌備了有意識的計劃。本文考查了大量最佳實踐，幫助您構建高效能和高彈性的 WebSphere eXtreme Scale 應用程式。

當您想知道如何在一個快取解決方案中使用 WebSphere eXtreme Scale 時，需要考慮的一個首要設計原則很簡潔但很重要：

WebSphere eXtreme Scale 不是一個關聯式資料庫。

然而，很多首次 WebSphere eXtreme Scale 實現都會犯假設這樣一個通病。但怎麼會有這種想法產生呢？有時它是因未考慮 WebSphere eXtreme Scale API 不同方面的效能影響而產生的。

WebSphere eXtreme Scale 有兩個不同的 API，用於定義將物件放入快取和從快取中獲取物件的方式：

• 第一個是 Map API，它基於 java.util.Map API。在使用 Map API 時，您要有效對待網格中的物件，如同它們是本地雜湊對映中的物件一樣。使用 insert()、put() 和 get() 等方法將物件放到網格中並從網格中檢索它們。有了 Map API，網格的最合理用法就變得一清二楚：您僅需在合適的鍵處將物件放入，並使用同一個鍵查詢物件。當考慮第二個可用 WebSphere eXtreme Scale API，即 EntityManager API 時，就會產生資料庫混亂。
• EntityManager API 是仿照 JPA (Java™ Persistence API) 實體模型建模的。使用 EntityManager API 時，會使用註釋描述置入 WebSphere eXtreme Scale 快取中的實體。使用 EntityManager.persist() 方法將物件儲存到網格中，與對 JPA 所做的處理一樣。不過，與 JPA 的相似性有時致使開發人員做出一些效率低下的選擇，從而導致對產品的次佳使用。您可以使用 find() 方法或查詢方法來查詢實體，前者根據物件的鍵檢索物件，而後者根據一系列屬性值查詢物件。

首次使用 WebSphere eXtreme Scale 的使用者可能過多依賴於 WebSphere eXtreme Scale EntityManager API 的查詢功能，特別是在將 WebSphere eXtreme Scale 納入專為資料庫訪問定製的現有應用程式時。WebSphere eXtreme Scale 基本上是一個快取提供者。查詢功能是產品的一個便捷特性，但它不受高階資料庫中所有高階查詢優化器的支援。因此，WebSphere eXtreme Scale 最精於根據物件的鍵查詢物件，而不是根據查詢定位該物件。這又涉及到另一個主要原則：

到網格中任何物件的主要訪問方式應該是通過 Map API 或使用物件主鍵的 EntityManager find() 方法。

這個簡單的設計原則能消除設計 WebSphere eXtreme Scale 應用程式時的許多效能問題。應用程式在這裡也可以使用 WebSphere eXtreme Scale 的查詢特性，但對於高效能路徑或全部高效能應用程式，推薦的訪問方式是 Map API 或 find() 操作。（有關查詢的索引和其他優化 — 如果您的應用程式用得到 — 將在 後面 介紹。）

總而言之，您需要使用快取來優化資料的高容量和高訪問頻率。要實現快取的效能優勢以及減少到中央資料庫的流量，最好的方式就是最大化快取的命中率；在 WebSphere eXtreme Scale 中，尤其包括了近快取（near cache）（即與客戶端在同一個記憶體空間）。因此，要利用該優勢，必須經常訪問快取中的資料。圖 1 顯示了為實現高效能訪問的一個物件網格解決方案概貌。

圖 1. ObjectGrid 元件

在該場景中，對 ObjectGrid API (1) 的一個客戶端呼叫首先引起對近快取 (2) 的搜尋。如果未找到結果，ObjectGrid 會定位合適的 ObjectGrid 伺服器，以及該伺服器中應包含結果 (3) 的這個 shard。如果它不存在，那麼結果可能會是一個正被呼叫的載入程式，它會從一個後端資料儲存 (4) 載入值。為了量化這個過程，接下來需要檢查 WebSphere eXtreme Scale 快取解決方案各方面的作用。不過在此之前，我們要先討論快取設計的一些一般原則。

尋找正確的快取時效性

使用快取是對時間與記憶體大小之間的一個平衡行為。快取的一個關鍵原則是用記憶體換取其他效能，比如更好的響應時間和/或增加的彈性，和/或其他系統中降低的成本佔用。因此，管理快取中物件的生命週期很重要。快取中物件的生命週期由跨越一組資料訪問的快取中的資料一致性決定。

對於每個應用程式，其資料都有一個可接受的 “過時” 程度。由於其實現，WebSphere eXtreme Scale 從不允許在其快取中有同一資料的不同版本。它保證每個快取中只存在每個物件的同一版本，除非使用了一個近快取。這使 WXS 甚至在快取讀/寫資料時都很有用。例如，您不會在批處理作業執行時更改其中使用的資料集。不過，在一個互動式應用程式中，對資料的更改可能更動態；如果使用者已經登入了很長時間，那麼他會希望在發生資料變更時有所反映。因此在第一種情況下，快取中物件的最短生命週期就是批處理作業的生命週期。在第二種情況下，它根據使用者希望多快看到資料變更而有所不同。不管在哪種情況下，您都應該儘量選擇簡單的收回（eviction）策略，比如生存時間（time-to-live）。在上述兩種情況下，這可簡單實現，只需選擇一個適合正開發的應用程式需求的時間；對於批處理應用程式來說時間較長（例如，比最長的批處理作業稍長一些），對於線上應用程式來說時間稍短一些。當然，由多個使用者或所有批處理作業以只讀方式共享的元素能贏得一個更長的快取生命週期。WebSphere eXtreme Scale 還採用各種方式來使變更資料的處理更智慧，能夠在發生實際變更時做出反應。

不過，在考慮近快取的情況下，究竟資料是否過時這個問題會有所不同。記住，近快取對於每個 WebSphere eXtreme Scale 客戶端都是獨特的，不像主 ObjectGrid 快取一樣被共享。鑑於此原因，近快取中的資料相互之間可以不同步，與主 ObjectGrid 快取也可以不同步。因此，您的選擇通常有兩個，要麼為近快取中的資料設定一個非常短的生存時間（這會降低效用），要麼完全不使用近快取而僅依賴於主 ObjectGrid 快取（這不會涉及過時性問題）。

近快取也只有在它含有大量足夠空間可用的時候才有用。如果一個 WebSphere eXtreme Scale 快取在快取 200 GB 的資料，那麼近快取可能就因為客戶端沒有足夠的記憶體而不容納該資料的子集來提高利用率。

最後，當考慮到對過時性的設計和容差時，您需要確定哪些實際記錄系統在總應用程式設計中。如果 ObjectGrid 是您的記錄系統，那麼您可以使用後臺寫（write-behind）資料庫更新或將快取設定為一個連續寫入（write-through）快取。這樣做的好處就是快取中絕不會有過時資料，因為快取是資料的權威來源。另一方面，如果資料庫是記錄系統，那麼您可以使用開放式鎖定或 ObjectGrid 的內建 SCN 支援來檢測和處理快取中的過時資料。

ObjectGrid 快取方程式

現在您既然已經理解了快取設計的一般原則，就可以開始考慮該方程式：

T_avg = N_h × T_n + (1-N_h) × (R_h × T_r + (1-R_h) × T_d)

該方程式中的每個元素都被用來計算網格處理任意請求的平均時間。讓我們輪流看一下這些元素，然後討論在 ObjectGrid 設計中每個元素的效果。

• N_h 是方程式中第一個主要因子。它代表近快取訪問率。近快取 是位於 ObjectGrid 客戶端內的一個小快取 — 因此是可以最快訪問的快取，因為使用它不必包含對快取的任何程式外呼叫，包括那些可能引發網路訪問的呼叫。
• T_n 是方程式中第二個主要因子。這是從近快取中檢索物件所需的時間。事實上，這很低；多數情況下少於 1ms，所以您可以簡化數值計算，直接將其看作 1ms 的常量。這與圖 1 中的第 2 個專案相對應。
• R_h 是遠快取的訪問率。遠快取是位於網格中的快取。訪問率代表在遠快取中多久能找到一個物件。
• T_r 是從遠快取中檢索物件所用的時間。它取決於：
  • 程式外呼叫的序列化開銷。
  • 網路延遲。
  • WebSphere eXtreme Scale 處理開銷。
  • 處理雙方請求的處理器核心的時鐘速度。
  物件的大小影響這些因素的作用。而且，頻繁進行程式外呼叫可能增加 JVM 的垃圾回收開銷，因此在度量中也應尋找和考慮該因素。當然，度量意指測試，且這些指標應該在測試中根據試驗測定，因為時序隨設計的不同而有所不同。它們還受網路狀況、WebSphere eXtreme Scale 配置和伺服器處理速度的影響。這與圖 1 中的第 3 行相對應。
• T_d 是從資料庫中檢索物件所用的時間。它也應在測試中根據試驗測定。這與圖 1 中的第 4 個專案相對應。

因此，為了解其用法，我們將數字代入方程式中。

假定在某個 WebSphere eXtreme Scale 應用程式中，您確定了對近快取的訪問率大約為 70%；例如，在該 WebSphere eXtreme Scale 客戶端中，您將使用 70% 的時間訪問最近從遠快取中獲取的物件。同樣地，假設您對遠快取的訪問率是 80%；例如，與將新物件拉入網格中相比，您將使用 80% 的時間訪問從資料庫取出並放到遠快取中的物件。最後，您還可以通過試驗將 T_r 確定為 20ms，且將 T_d 確定為 200ms。代入這些數字之後的方程式為：

T_avg = (0.7 * 1ms + (1-0.7) * (0.8 * 20ms + (1-0.8) * 200ms) = 17.5ms

我們可以看一下，它在多大程度上取決於訪問率的係數；例如，只將近快取訪問率小幅增加到 80%，平均響應時間就變為 12ms — 提高了 30%。不過，同樣需要意識到，70% 的訪問率對應的響應時間是 1ms。但是，較大的極端值（200ms）與平均值很不對稱，因此在整體描述應用程式的行為時必須將所有因素考慮在內，這很重要；它真正歸結於您的使用者希望且能容許有什麼樣的效能，同時從平均響應時間和快取在 “大部分時候” 的效果等方面考慮。

從快取方程式得出的最佳實踐

我們已經瞭解了 WebSphere eXtreme Scale 解決方案的每個組成的作用，現在需要應用一些從該方程式中各因子推斷得出的最佳實踐：

• 仔細考慮一下使用近快取的優缺點。這裡的問題是您可能在應用程式中有兩個相互矛盾的目標。一個目標就是在設計應用程式時儘量合理地使 Nh 接近 100%, 這將使其餘組成微不足道，極大地提高應用程式的總體速度。具體方法就是選擇快取中的物件，從而使其展示良好的 引用區域性性。不過，另一個目標可能就是避免之前討論的快取過時性或同步問題。如果您的應用程式需求允許使用近快取，那麼您就應該使用它，若不然，您就需要繼續尋找能提高總體效能的可行方法。
• 接下來，優化 R_h，您可以使用預載入策略或預測性載入策略提高在遠快取中找到物件的機率。。預載入是一種在啟動時將整個物件集載入到快取中的方法。而當您載入一個物件（比如快取缺失之後）然後推測同時還需要哪些其他相關物件並載入它們時，則需要用到預測性載入策略。下一節 有關預載入與按需載入的描述將有助於您理解這兩種方法的權衡。
• 通過減少網路上傳送的資訊量優化 T_r。您可以使用一個自定義序列化方法減少網路序列化/反序列化開銷。您還可以優化物件設計使其去除不必要的欄位，從而減小所返回的物件的大小（以及網路傳輸時間）。您可能還能夠使用二級快取等方法同時提高遠快取訪問率和檢索率。
• T_d 通過使用標準資料庫調優方法獲得優化。這是總體應用程式調優流程的一部分，您一定不會忘記。

選擇預載入或按需載入

WebSphere eXtreme Scale 能實現比過去更大的快取容量。70 到 140 GB 之間的基於記憶體的快取是 WebSphere eXtreme Scale 使用者常使用的。它的實現方式是將來自多個 JVM 的記憶體聚合以形成全域性快取。這也意味著，可以在多個 JVM 上分佈較小的快取，從而在需要每個 JVM 快取所有資料時較以前減少每個 JVM 的記憶體量。一般來說，與傳統快取相比，WebSphere eXtreme Scale 使用者預期對每個 JVM 使用更少的記憶體。

這就是說，您應該儘量按需使用記憶體。工作集是指在特定時間段內應用程式將訪問的最小結果集，以使應用程式更高效地工作。工作集的大小和組成由應用程式的設計決定；在重複多個操作的批處理應用程式中，工作集可能比沒有可簡單預測訪問模式的線上應用程式更大（且壽命更長）。

如果您可以及早識別一個工作集，且它適合可用記憶體，那麼最簡單的策略通常就是預載入工作集。該策略特別適用於這種情況，即工作集中表格尺寸太小，因而逐項載入表格花費的時間遠遠大於一次載入所有表格所用的時間。

如果您不能及早識別一個工作集，則延遲載入就是填補快取的下一個最佳選擇。延遲載入策略的構想是，如果將一個資料載入到了快取中，就有可能再次用到它。WebSphere eXtreme Scale 直接通過其載入程式工具支援延遲載入。該策略的一個變體就是預測性載入策略，它在任何時候有針對特定資料的請求時載入相關資料。例如，如果一個快取收到一個客戶資料請求，該請求基於目前不在快取中的一個特定客戶編號，那麼您可能認為客戶帳戶快取也會從對該客戶帳戶資料的預先填充中獲益。

需要注意，一個延遲載入的快取不適合查詢，這通常是與快取有關的一個不爭的事實（不管是 WebSphere eXtreme Scale 還是另一型別）：您只能針對完整的快取（有完整的資料集）執行查詢。如果快取不完整，您需要返回到資料庫執行查詢。

如果您費力去預載入資料集，應該同時將其複製，以避免出錯時需要重新載入它。WebSphere eXtreme Scale 也支援為獲得彈性而複製延遲載入的資料。這在以下情況下很有用：

• 資料不經常地相對於請求容量發生變化。例如，在一個 eCommerce 站點中，受歡迎的專案可能會有每小時上千次的檢索量，而商家可能一天只更新目錄一次。
• 如果資料請求容量整體較高，複製或分佈資料可以潛在地降低容量爭用。
• 如果對源資料庫的訪問不可靠，在快取層爭取彈性可能會提高讀密集型應用程式的總體穩定性。

其他設計原則

然而，並非所有的 WebSphere eXtreme Scale 最佳實踐都可從快取方程式中獲得。在 WebSphere eXtreme Scale 解決方案的開發過程中有大量元素可用於處理資料檢索、資料分佈，以及需要考慮的其他方面的問題。

選擇正確的方式來查詢資料

在設計一個網格時，您需要仔細選擇分割槽鍵。為了有效訪問大小為 >~1 GB 的資料，分割槽應沿著合理的鍵進行。如果根據兩個或多個鍵查詢一個物件，進行分割槽所依據的最合理的鍵將是最常用的鍵。使用其他鍵進行查詢時，考慮使用全域性反向索引。

一個全域性反向索引僅僅是一個設計，其中建立的對映的鍵是搜尋關鍵詞，且其值是包含屬性與搜尋關鍵詞的鍵列表。因此，一個索引查詢會產生一個返回鍵列表的 Map.get(value)。然後該鍵列表可以使用 WXSUtils.getAll（一個按原始碼提供的 WebSphere eXtreme Scale 幫助庫，包括常見任務的許多常規幫助）快速大批量獲取資料。您現在有了更好的解決方案。該系統的吞吐量比並行搜尋實現要好很多。每個索引查詢使一個 PRC 只對應一個資料庫。因此，一個資料庫可以執行 N 個查詢。M 個伺服器可以執行 M * N 個查詢，從吞吐量角度來看，您現在的索引查詢有更好的響應時間和線性伸縮性。

最後一種情況是使用 ObjectGrid 查詢，僅當處於某種原因不能應用反向索引或應用它會使設計更復雜時，才考慮使用這種查詢。在這種情況下，您應該使用合適的查詢索引（下一節）提高查詢的效能。

應用查詢索引

如同在關聯式資料庫中一樣，WebSphere eXtreme Scale 支援使用索引提高查詢速度。索引名稱與對應的編入索引的屬性名稱相同，且通常是一種 MapRangeIndex 索引型別。可以使用 Entity 類中的 @index 註釋或 ObjectGrid 描述符 XML 檔案中的 HashIndex 外掛配置指定每個索引。清單 1 顯示瞭如何在一個 objectGrid.xml 檔案中指定一個索引配置。

清單 1. 在 objectgrid.xml 中實現索引

為展示應用索引後的影響，我們對含有約 680,000 個儲存在 ObjectGrid 6.1.0.3 單一分割槽中的物件執行了一些測試，測試目標是非主鍵查詢效能，包括非索引查詢、索引查詢和 MapRangeIndex 查詢。在該測試中，物件返回的數目在所有情況下都是 10。（該測試在一個 Intel Core Duo T7700 (2.40 GHz) 上執行，它含有 2GByte 記憶體，JVM Heap 設為 768 MB，且 HDD 為 100GB，7200rpm。）

在該測試中，我們建立了一個名為 OgisCustomer 的實體，它有包括主鍵（SRCSEQ）在內的 4 個成員屬性。其中一個成員屬性（SMTRSET）設定為含有一個如上面 ObjectGrid.xml 中所示的一個索引。清單 2 顯示了描述屬性的 entity.xml 檔案。

清單 2. entity.xml

				
 
		OGIS CUSTOMER Class 
		 
			
			
			
			
		

我們的 EntityManager 查詢效能試驗表明，在這種情況下，您只需新增一個索引配置就可以獲得比之前快 2000 倍的結果。

彈性最佳實踐

目前為止呈現的最佳實踐一般都是用於提高 WebSphere eXtreme Scale 應用程式的效能。不過，也有其他最佳實踐與結果應用程式的整體彈性相關。

何時使用副本 shards

在應用程式中要考慮的最簡單的問題是，網格彈性是否是應用程式中的一個問題。為便於理解，您需要考慮網格中資料的價值。畢竟在多數網格中，網格是一個快取，而不是 “記錄系統”。因此，如果快取缺失，總是可以還原快取中的值。問題在於，重新建立快取的成本（時間或 CPU）太高就會導致在快取失敗時應用程式不能滿足其服務級別協議。這就又涉及到下一個原則：

如果快取中的資料值得預載入，那麼就值得在快取中建立資料副本。

雖然這不是值得建立副本的惟一情況，但絕對是主要情況。在考慮預載入時，節省試圖重新建立快取的時間和精力將是一個設計目標。

這裡的另一個因素是，許多使用者使用網格是因為資料庫跟不上載入。如果出於日常維護對網格的一部分加以迴圈利用，在沒有副本的情況下就會致使一些快取資料丟失。資料的丟失可能造成資料庫負荷過多，因為快取不再充當資料子集的緩衝區。因此，使用快取幫助資料庫減負的系統通常需要通過複製來避免這些情況。

實現區域配置

一般來說，WebSphere eXtreme Scale 不會將一個主 shard 和副本 shard 放在有相同 IP 地址的 JVM 上。但這不一定表示，它會確保每種情況下都高度可用，特別是在刀片環境中。如果您有兩個不同的刀片機箱，WebSphere eXtreme Scale 的區域功能允許您將主 shard 和副本 shard 放在不同的機箱中。您可以使用 IBM WebSphere Virtual Enterprise 或非 WebSphere Virtual Enterprise 環境下支援的區域特性啟動 WebSphere eXtreme Scale 伺服器。除此之外，如果您的 WebSphere eXtreme Scale 應用程式在 IBM WebSphere Application Server Network Deployment 上執行，您可以在 objectGridDeployment 配置檔案中指定區域後設資料，使其更加高度可用。

有多種方式可實現 WebSphere eXtreme Scale wiki 中描述的區域，不過無論在哪種情況下都要顯式指定 。物理節點與區域之間的關聯要遵從命名規定 eplicationZoneZONENAME。如果您的 WebSphere eXtreme Scale 安裝在一個 WebSphere Application Server 或 WebSphere Virtual Enterprise 單元上，ZONENAME 的名稱必須與單元中指定的 NodeGroup 完全相同。

在清單 3 中，主 shard 和副本 shard 分別位於兩個節點組中，即 XNodeG 和 YNodeG。在存在兩個刀片機箱的情況下，每個刀片上都應指定每個節點組。（該規則也完全適用於 WebSphere Virtual Enterprise。）

清單 3. 使用區域的 Shard 分佈

結束語

本文考查了大量用於提高 IBM WebSphere Extreme Scale 效能和彈性的最佳實踐，以及有助於更好地理解 WebSphere Extreme Scale 產品的原則。這些資訊能夠幫助您開發和優化自己的 WebSphere eXtreme Scale 應用程式，並避免在您的環境中應用該產品時出現問題和失誤。

原文連結:http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_brown/1004_brown.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-669861/，如需轉載，請註明出處，否則將追究法律責任。