性能保障策略

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

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

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

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

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

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

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

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