簡介
數據是用於管理、挖掘和操作數據的所有計算系統的核心元素。在 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 組件
WebSphere eXtreme Scale 中的一個 shard 是置於容器中的數據的一個分區。shard 有主 shard，也有副 本 shard。WebSphere eXtreme Scale 通過將復制的數據放在獨立的服務器中來提高數據的可 用性。
在該場景中，對 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 緩存方程 式
現在您既然已經理解了緩存設計的一般原則，就可以開始考慮該方程式：
Tavg = Nh × Tn + (1-Nh) × (Rh × Tr + (1-Rh) × Td)
該方程式中的每個元素都被用來計算網格處理任意請求的平均時間。讓 我們輪流看一下這些元素，然後討論在 ObjectGrid 設計中每個元素的效果。
Nh 是方程式中第一個主要因子。它代表近緩存訪問率。近緩存 是位於 ObjectGrid 客戶端內的一個小緩存 — 因此是可以最快訪問的緩存，因為使用它不必包 含對緩存的任何進程外調用，包括那些可能引發網絡訪問的調用。
Tn 是方 程式中第二個主要因子。這是從近緩存中檢索對象所需的時間。事實上，這很低；多數情況下 少於 1ms，所以您可以簡化數值計算，直接將其看作 1ms 的常量。這與圖 1 中的第 2 個項目 相對應。
Rh 是遠緩存的訪問率。遠緩存是位於網格中的緩存。訪問率代表 在遠緩存中多久能找到一個對象。
Tr 是從遠緩存中檢索對象所用的時間。 它取決於：
進程外調用的序列化開銷。
網絡延遲。
WebSphere eXtreme Scale 處理 開銷。
處理雙方請求的處理器核心的時鐘速度。
對象的大小影響這些因素的作 用。而且，頻繁進行進程外調用可能增加 JVM 的垃圾回收開銷，因此在度量中也應尋找和考慮 該因素。當然，度量意指測試，且這些指標應該在測試中根據試驗測定，因為時序隨設計的不 同而有所不同。它們還受網絡狀況、WebSphere eXtreme Scale 配置和服務器處理速度的影響 。這與圖 1 中的第 3 行相對應。
Td 是從數據庫中檢索對象所用的時間。 它也應在測試中根據試驗測定。這與圖 1 中的第 4 個項目相對應。
因此，為了解其用 法，我們將數字代入方程式中。
假定在某個 WebSphere eXtreme Scale 應用程序中， 您確定了對近緩存的訪問率大約為 70%；例如，在該 WebSphere eXtreme Scale 客戶端中，您 將使用 70% 的時間訪問最近從遠緩存中獲取的對象。同樣地，假設您對遠緩存的訪問率是 80% ；例如，與將新對象拉入網格中相比，您將使用 80% 的時間訪問從數據庫取出並放到遠緩存中 的對象。最後，您還可以通過試驗將 Tr 確定為 20ms，且將 Td 確定 為 200ms。代入這些數字之後的方程式為：
Tavg = (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%, 這將使其余組成微不足道，極大地提高應用程序的總體速度 。具體方法就是選擇緩存中的對象，從而使其展示良好的 引用局部性。不過，另一個目標可能 就是避免之前討論的緩存過時性或同步問題。如果您的應用程序需求允許使用近緩存，那麼您 就應該使用它，若不然，您就需要繼續尋找能提高總體性能的可行方法。
接下來，優化 Rh，您可以使用預加載策略或預測性加載策略提高在遠緩存中找到對象的幾率。。 預加載是一種在啟動時將整個對象集加載到緩存中的方法。而當您加載一個對象（比如緩存缺 失之後）然後推測同時還需要哪些其他相關對象並加載它們時，則需要用到預測性加載策略。 下一節 有關預加載與按需加載的描述將有助於您理解這兩種方法的權衡。
通過減少網 絡上發送的信息量優化 Tr。您可以使用一個自定義序列化方法減少網絡序列化/反 序列化開銷。您還可以優化對象設計使其去除不必要的字段，從而減小所返回的對象的大小（ 以及網絡傳輸時間）。您可能還能夠使用二級緩存等方法同時提高遠緩存訪問率和檢索率。
Td 通過使用標准數據庫調優方法獲得優化。這是總體應用程序調優流程的 一部分，您一定不會忘記。
選擇預加載或按需加載
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 中實現 索引
<bean id="MapIndexPlugin"
className="com.ibm.websphere.objectgrid.plugins.index.HashIndex">
<property name="Name" type="java.lang.String" value="SMTRSET"
description="index name" />
<property name="RangeIndex"
type="boolean" value="true" description="true for MapRangeIndex" />
<property name="AttributeName" type="java.lang.String"
value="SMTRSET" description="attribute name" />
</bean>
為展示應用索引後的影響，我們對含有約 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
<entity class-name="sample.entity.OgisCustomer" name="OgisCustomer" access="FIELD"
schemaRoot="true" >
<description>OGIS CUSTOMER Class</description>
<attributes>
<id name="SRECSEQ"/>
<basic name="SMTRSET"/>
<basic name="SGASSYOKY"/>
<basic name="SSHRKY"/>
</attributes>
</entity>
我 們的 EntityManager 查詢性能試驗表明，在這種情況下，您只需添加一個索引配置就可以獲得 比之前快 2000 倍的結果。
查詢類型 性能結果（msec） 非索引查詢 20414 索引查詢 10 MapRangeIndex 查詢 15彈性最佳實踐
目前為止呈現的最佳實踐一般都是用於提高 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 中描述的區域，不過無論在哪種情況下都要顯式指定 <zone name>。物理節點與區域之間的關聯要遵從命名規定 eplicationZoneZONENAME。 如果您的 WebSphere eXtreme Scale 安裝在一個 WebSphere Application Server 或 WebSphere Virtual Enterprise 單元上，ZONENAME 的名稱必須與單元中指定的 NodeGroup 完 全相同。
在清單 3 中，主 shard 和副本 shard 分別位於兩個節點組中，即 XNodeG 和 YNodeG。在存在兩個刀片機箱的情況下，每個刀片上都應指定每個節點組。（該規則也完全 適用於 WebSphere Virtual Enterprise。）
清單 3. 使用區域的 Shard 分布
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy
../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="LDAP_OBJECT_GRID" >
<mapSet name="mapSet1" numberOfPartitions="10" minSyncReplicas="0"
maxSyncReplicas="0" maxAsyncReplicas="1" developmentMode="false"
numInitialContainers="2"
> <map ref="PEOPLE_USER_TYPE_MAP" />
<map ref="SPECIAL_USER_TYPE_MAP" /> <map ref="ORG_GROUP_TYPE_MAP" />
<map ref="BIZ_GROUP_TYPE_MAP" />
<zoneMetadata> <shardMapping shard="P" zoneRuleRef="stripeZone"/>
<shardMapping shard="A" zoneRuleRef="stripeZone"/>
<zoneRule name="stripeZone" exclusivePlacement="true" >
<zone name="ReplicationZoneXNodeG" />
<zone name="ReplicationZoneYNodeG" />
</zoneRule> </zoneMetadata>
</mapSet>
</objectgridDeployment>
</deploymentPolicy
結束語
本文考查了大量用於提高 IBM WebSphere Extreme Scale 性能和彈性的最佳實踐，以 及有助於更好地理解 WebSphere Extreme Scale 產品的原則。這些信息能夠幫助您開發和優化 自己的 WebSphere eXtreme Scale 應用程序，並避免在您的環境中應用該產品時出現問題和失 誤。
