某大型銀行深化系統之十八：性能設計之三

傳送門 ☞ 輪子的專欄 ☞ 轉載請註明 ☞ http://blog.csdn.net/leverage_1229

5報表性能

        爲不影響系統的總體性能，報表統計將經過報表服務來解決可能產生的性能問題。
        報表服務是運轉在服務端的報表服務程序，用來解析報表模板，取得報表數據，生成報表，提供對報表運行、部署和維護的強大支持。報表服務既能夠做爲獨立的服務程序運行，也能夠以嵌入運行模式，和用戶的應用一塊兒部署到應用服務器上。報表服務的實現徹底遵循J2EE 規範，能夠部署在任何遵循J2EE 規範的應用服務器上，包括WebLogic 、WebSphere、、Oracle 9i應用服務器等主流應用服務器，從而實現應用服務器的無關性。報表服務經過JDBC訪問數據庫，因此它能夠應用在任何支持JDBC規範的數據庫環境中，包括Oracle等主流數據庫系統，從而實現數據庫的無關性。
        報表服務具備以下特性：

5.1高性能

        在許多報表解決方案中，巨大的報表會消耗報表服務器的可用內存，從而使得其它較小的報表執行失敗。所以把報表單獨做爲一個服務，包含一個可擴展的報表引擎，它限制了內存的使用和與非內存限制的報表的衝突。報表性能也經過按需處理和基於實時的渲染而獲得了優化。

5.2緩存

        報表服務經過提供了報表的緩存進一步提升了性能。經過緩存常用相同的參數值進行訪問的報表，以下降渲染報表所須要的時間和空間費用。在報表處理以後，緩存拷貝就能夠用於其餘後來訪問同一個報表的用戶而不須要再做任何處理。有了這個方法，若是多個用戶打開這個報表，只有第一個請求會產生報表處理過程。而後這個報表被緩存起來，其他的用戶查看到的是這個緩存的報表。

5.3快照

        報表服務支持快照報表的建立，快照報表是按照一個預先計劃的時間間隔進行渲染，而後用於用戶查看。快照相似於緩存報表;主要的區別是快照一般是按照一個計劃按期的建立的。像緩存報表同樣，快照能夠經過按期生成複雜或耗時的報表來提升報表性能，並使得用戶能夠查看預先生成的快照而不是按需生成報表。快照報表仍是一個可維護歷史報表的有用的方法，由於每個報表實例都反映了快照產生時的數據狀況。

5.4多種文件格式

        用戶須要可以訪問和共享採用他們最熟悉的格式的報表。報表服務支持渲染最多見的文件格式，包括HTML、PDF、CSV、XML和圖像 (TIFF)，報表的格式是部分可編輯的，使用戶能夠基於這些報表建立定製的文檔。

5.5多種查詢方式

        由於報表時基於關係數據庫的，因此能夠很方便的構造出SQL查詢方式，按條件或組合條件查詢，能夠對各要素進行模糊查詢，能夠將查詢結果分類排序、分析，能夠將查詢結果打印，能夠將查詢結果輸出EXCEL文件。

5.6異步發佈數據

        報表服務支持遠程模式，這種模式下報表運行在一個遠程報表服務的報表服務器上，將須要提交的報表經過異步的方式提交給報表服務，並經過報表生成臺生成。

6海量數據處理

        性能保障是系統設計的重要環節，主要是保證在實際使用中保障系統的性能。主要考慮的因素是大數據量和多客戶端的狀況。系統壓力的產生主要在於海量數據對底層系統的壓力以及大量客戶端對應用服務的壓力。
        在採用大集中的方式下，系統的數據量很是大。天天產生的GB級的數據會對系統產生兩個方面的壓力：數據的傳輸會佔用網絡帶寬，另外數據的存儲會佔用空間。
在數據的傳輸方面，若是數據量比較大的時候，會佔用網絡帶寬，在網絡是多個業務共享使用的時候，會阻礙其餘業務的進行，對此係統在網絡傳輸方面設計成能夠指定佔用帶寬的方式，在業務繁忙的狀況下，能夠爲其餘業務釋放一些網絡資源。
在數據的存儲方面，咱們的系統的存儲設計對硬件是徹底透明的，用戶能夠根據數據量的大小，性能的要求決定採用何種存儲方式。

6.1大批量影像壓縮算法

        對於圖像壓縮而言，能夠根據壓縮的效率自底向上能夠分爲二進制壓縮、像素級壓縮、內容級壓縮等不一樣的層次。然而現有對票據類圖像的壓縮大多采用是JPEG等壓縮格式，現有技術存在的最大問題是沒有考慮到圖像之間的內容關聯關係。在票據類等內容相關的影像上，由於沒有計算圖像內容的相關性，很難實現高效的壓縮。對於幾百萬甚至上千萬個圖像的壓縮，目前來講並無更有效的壓縮方法。
鑑於上述狀況，建議採用更高的壓縮算法如NKZ，其目的是針對目前海量影像在傳輸、存儲方面的難題，利用票據類影像的特徵、在進行亞像素級和模板聚類的海量信息抽取和分析基礎上、對海量影像進行高壓縮比、高質量且高速的壓縮算法及算法。

6.2大批量影像傳輸算法

        目前來講，影像傳輸使用較多的是FTP協議，可是這裏面存在着鏈接的問題。FTP在傳輸的過程當中，每張影像須要創建一次數據鏈接。在數據集中模式下，服務器須要一天要存儲上百萬張影像，實現10次業務中轉須要上千萬次的鏈接；系統每次創建鏈接的時間至少爲10ms；以目前做業時間來計算，須要將近27小時，遠大於咱們天天8小時的工做時間。所以出現了性能的瓶頸。雖然咱們能夠經過創建多臺FTP服務器來實現均衡，可是不能從本質上解決傳輸鏈接時間過長的問題。例如，在東莞銀行中，天天僅30萬張票據，有3個崗位掃描，5臺識別服務，10個補錄崗位，每一筆業務須要傳輸100~500張票據。天天的影像在網絡中的傳輸次數就須要上百萬次鏈接請求，僅鏈接時間就佔去了3個多小時，網絡帶寬僅佔有了30%，形成了資源的浪費。
        針對目前銀行先後臺分離業務系統中的影像傳輸過程當中，票據影像文件小、數量大、鏈接耗時等問題，採用一種大批量影像數據傳輸的解決方案。其原理是鏈接複用，目的是減小鏈接創建時間，充分利用帶寬，以知足大批量影像傳輸的性能需求。

6.3異步處理機制

        系統採用的是多層結構開發。客戶端沒有業務邏輯，全部的業務邏輯都放在服務器端處理。系統採用了鏈接池，對象池，線程池技術，對服務器端的資源進行重用。在多個用戶使用的時候，可以顯著地提升系統的運行效率。