1、1.1.1 性能保障策略ECIF 系統作為一個集中部署的業務應用系統，具有高并發、大數據量處理 的特點，要在性能上滿足整個系統的運行需要， 除了主機、網絡的處理能力之外， 在各應用節點（包括應用服務器、 WEB Server 等）要從高性能集群技術、降低 磁盤訪問頻率、流量控制、服務分配、交易分流各方面綜合考慮，才能更好地保 證系統高效、穩定地運行。性能設計主要依賴于兩方面，其一軟件本身限制，其二為硬件部分限制，宇 信易誠公司結合多年銀行從業經驗， 針對軟件性能設計從產品設計初期一直延續 到產品測試結束提供了完整的性能解決方案。1.1.1.1 產品高性能設計基于MDM產品經過多年積累，沉淀，針

2、對性能問題已經過多年優化。 且軟件 本身為可伸縮性系統，便于多項部署。從而提高系統本身性能。1.1.1.2 高效的數據算法針對每項數據算法， 以及數據類型選擇， 經過嚴格測試， 從優擇選以最優算 法，以及數據類型。且通過大量壓力測試，支撐產品應用。1.1.1.3 良好的接口設計系統的整體接口經過嚴格設計， 使接口設計為最優， 避免大量創建類， 保證 整個產品最優運行。1.1.1.4 低耗的磁盤 IO宇信易誠公司YC.ECIF產品中，針對所有磁盤10操作采用最低限度使用10 策略，針對某些高頻使用數據類型存儲到緩存中，盡量避免針對磁盤 IO 操作。 應用邏輯通過Cache技術直接訪問裝載在內存的

3、配置數據，降低系統對磁盤的訪 問頻率，提高系統的運行效率。1.1.1.5 細粒度的事務管理宇信易誠公司 YC.ECIF 產品中，數據訪問的事務邊界經過嚴格設計，粒度、 事務完整性以及性能之間進行平衡，從而避免了長事務的增長導致的性能瓶頸。 針對事務鎖機制，宇信易誠 ECIF 系統通過高壓測試調優，整體設計盡量避免鎖 等待瓶頸。1.1.1.6 產品的可伸縮性MDM產品設計和開發遵循了可伸縮性原則，保障ECIF系統可橫向擴展，以持續提升性能。1.1.1.7 數據庫性能設計1.1.1.7.1 索引控制在數據模型客戶化設計中， 索引經過嚴格篩選， 避免某表多索引造成的寫操 作效率低下。1.1.1.7.

4、2 SQL優化所有SQL語句均針對特定數據庫（0RACLEDB2做充分優化并通過高并發、 大數據量的壓力測試。1.1.1.8 數據庫高可用性設計1.1.1.8.1 分布式原則整體數據庫采用分布式技術， 從主機角度， 以及應用角度等采取分布式技術， 保障數據庫高效運行。將數據庫從主機角度采取分布式技術， 結合廣東農信實際情況使用數據庫數 據分布式技術，可保證在多個主機上運行數據庫業務。1.1.1.8.2 讀寫分離原則讀寫分離原則， 主要指在某節點數據庫中寫入數據， 然后把寫入的數據同步 到多節點。 而其它節點保障數據庫讀取應用。 如此可將應用的負載分布在多個不 同的數據庫節點上面。如果寫的數據庫

5、失敗，可以找一個讀的數據庫來接管。1.1.1.8.3 垂直分割原則按照應用來分割，如應用 1與應用 2是可以獨立出來的完全不同的應用，則 把它獨立出來， 分割在兩個不同的數據庫服務器上， 這樣就實現了垂直分割。 這 種情況下，如果一個應用故障，就不會影響到其他應用。1.1.1.8.4 水平分割原則數據量的分割，如有一個用戶表，可以按照一定規則，把用戶表分割成兩 個表，再分布在兩個不同的數據庫中， 當特定的用戶訪問數據庫的時候， 根據規 則就可以知道它在哪個數據庫中， 然后訪問該數據庫即可。 這種情況下， 如果一 個庫失效，受影響的只是這個庫存放的特定的用戶。1.1.1.8.5 查詢性能設計結合

6、廣東農信目前客戶數量較大的情況， ECIF 系統針對查詢的問題將其按 照用戶需要、 IT 環境的設備條件等劃分成一組問題域。下面將詳細進行描述。1.1.1.8.5.1 制約條件ECIF系統內的查詢功能一般會受以下幾點因素的影響。? 硬件 硬件是決定系統性能的關鍵因素之一，包括應用服務器和數據庫服務器的CPU內存，磁盤IO性能等，隨著系統用戶并發數量的增加，CPU和磁盤IO的壓力會相應加大，而對于JVM來說，一味加大內存堆容量，不一定會使系統吞吐 能力線性加大，同時會加劇 JVM垃圾回收的壓力。對于廣東農信 ECIF系統這樣 龐大的系統來說， 用戶數量和并發數量非常之高， 單臺服務器模式不能滿足

7、性能 方面的要求，應該考慮使用多臺服務器進行邏輯加物理的系統部署方式。? 網絡 廣東農信網點分布較廣，作為一個集中系統，從用戶終端到服務器的網絡 連通狀況是依據支行區域不同、 機構層級不同是千差萬別的。 網絡的延時直接加 大了終端與服務器之間連接保持的時長，對服務器資源的占用有很大影響。? 中間件性能 開發系統采用的技術、使用系統運行的基礎軟件環境，包括應用服務器、 數據庫等。對查詢性能也有不同程度的影響。? 系統歷史數據量 系統實時數據庫中保存數據的區間設計與性能緊密相關。數據量越大對數 據查詢的性能影響就越大。并且 ECIF 系統的數據結構的設計好壞對從大量數據 中篩選必要數據的影響也是需

8、要考慮的。1.1.1.8.5.2 優化策略? 對大數據表做“表分區” 、“索引分區”或“數據庫分區” 。? 精心設計查詢使用的索引， 避免進行 “全表掃描”。在考慮索引的字段的 同時，也要考慮使用何種索引類型（聚集索引、B+樹、位圖等）。?精心準備查詢使用SQL語句，特別要關注WHER子句中條件表達式的寫 法，一些條件表達形式是無法使用索引的，例如 like 運算符。例外， 條件表達式盡可能少地使用列函數和數據類型轉換。寫出高效SQL會涉及很多方面， 這些知識在產品手冊、 書籍、互聯網上都有較詳細的介紹。 這里強調的是，項目組有責任引導開發者明白開發高效SQL的意義，不斷提升SQL應用水平，避免開發低效率的 SQL?盡可能使用ORACL或DB2自有的性能優化策略。? 活躍數據與歷史存量數據分開。? 盡可能避免排序，若不能避免排序必須有優化措施（如排序參數設計、排序臨時空間、排序用到的索引、并行排序等） 。? 盡可能避免返回多行的結果集。? 盡量避免使用相關子查詢。? 盡量避免使用 Group 子句。?如果JOIN操作的代價過大，可以考慮使用冗余列來避免 JOIN操作。? 將“性能調優”的重點放在查詢時間長、資源消耗量大、使用又很頻繁 的SQL調用