概述
JDBC Adapter(簡稱 Adapter)入站服務被廣泛應用於需要對數據庫中業務數據表進行監控的企業應用集成中。由於企業應用的規模不同,對 Adapter 入站服務的性能要求也不同,如何配置 Adapter 入站服務以提高 Adapter 處理事件的性能在實際應用中極其重要。本文將全面介紹如何通過調整 Adapter 入站服務配置,以滿足各種企業集成中對 Adapter 入站服務的性能需求。
JDBC Adapter 入站服務簡介
JDBC Adapter 是符合 J2CA 規范,運行在 WebSphere Process Server 上的,提供各種數據庫廠商與應用程序間連接的適配器。Adapter 使數據庫和應用程序間擁有雙向連接的能力,包括從應用程序到數據庫的出站連接能力,以及從數據庫到應用程序的入站連接能力。使用 Adapter 的入站服務,應用程序可以監控數據庫業務數據表的變化,因此被廣泛應用於各種以數據庫為中心的企業應用的集成整合中。圖 1 展示了典型的 Adapter 入站服務的基本工作原理。各種構建於數據庫之上的應用程序,按已有應用程序的業務邏輯向業務數據表寫入數據。Adapter 利用事件觸發器(Trigger)或者各種數據庫特有的事件通知機制,比如 Oracle 數據庫的 DBMS_NOTIFICATION 程序包,透明的監控各種應用程序的業務數據變化,並將事件緩存於事件記錄表中。部署於服務器的 Adapter 入站服務定期輪詢事件記錄表並將新發現的數據庫事件傳送給處理事件的模塊。
圖 1. JDBC Adapter 入站服務基本工作原理
除了提供基本的入站連接能力, Adapter 為數據庫事件監控提供了完善的事件轉發保證、數據一致性、事務性支持,可以確保業務數據事件被安全正確的處理。在實際應用中,由於業務規模不同,系統對業務數據事件處理的性能要求各異,為此 Adapter 提供了豐富的性能配置選項,以滿足各種應用程序對事件處理的性能需求。本文將在後續章節中詳細介紹 Adapter 各種性能選項。
調節基本性能參數
Adapter 提供了兩個基本的性能參數可以方便的調節 Adapter 的事件處理能力。在 WebSphere 集成開發環境中,用戶可以在 Adapter 入站服務接口的 屬性視圖 下的 端點配置 下的 高級激活屬性 配置中找到這兩個參數的配置項,如圖 2 所示。
圖 2. JDBC Adapter 基本性能參數配置
輪詢周期之間的時間間隔 是指每次輪詢事件表的間隔,它以毫秒為單位,默認時間間隔為 2000 毫秒。輪詢周期中的最大事件數 是指每次輪詢提取的最大事件數,默認最大事件數位為 10 。輪詢間隔越小, Adapter 的平均事件處理能力越強,而每次輪詢事件數越大, Adapter 的平均事件處理能力越強。
默認配置下每秒鐘 Adapter 最多能處理 5 個業務數據事件,這對於事件處理能力要求較高的應用顯然是不夠的。我們可以通過適當降低 輪詢時間間隔 以及提高 輪詢事件數 來提高 Adapter 的事件處理能力。對於突發事件較多而平均事件數量較少的系統,我們可以適當增加 輪詢事件數 並延長 輪詢時間間隔,以達到大的突發事件處理能力,並且減少事件較少時對數據庫壓力。而對於事件數量隨時間較均勻分布的系統,我們可以適當減少 輪詢時間間隔 以增加事件處理能力並減少事件延遲。
選擇事件交互類型
Adapter 事件交互 是指當入站服務發現事件後如何將事件傳遞給接收事件的模塊。Adapter 入站服務與接收事件的組件間有兩種交互樣式,同步交互 和 異步交互,如圖 3 所示。
圖 3. JDBC Adapter 事件交互方式配置
同步交互 是指當 Adapter 傳遞完當前事件後,等待事件處理組件處理完事件後再繼續傳遞發送余下事件。異步交互 是指當 Adapter 傳遞發送事件後,不等待接收事件的組件處理事件,而是在確認事件發送後,馬上繼續傳遞剩余事件。
對於單個事件處理時間較長的系統,異步交互 能夠使 Adapter 入站服務達到更大的事件傳遞發送吞吐量。如果使用 異步交互 方式, Adapter 傳遞事件後,事件的後續處理的可靠性由應用服務器(WebSphere Process Server)保證;而如果使用 同步交互,如果事件處理失敗,Adapter 會馬上收到通知,並可以將相應事件記錄標記為處理失敗,系統管理員可以查詢到失敗事件,並且根據實際情況決定是否重新提交事件,因此同步交互事件處理會有更高可靠性。在實際應用中,用戶應該根據系統的實際需求選擇使用合適的事件交互類型。
選擇事件傳遞類型
Adapter 入站服務的 事件傳遞 類型是指當 Adapter 從事件表中取到多條事件記錄後,以何種工作方式將事件傳遞給接收事件的模塊。它是影響入站服務處理能力的重要選項,如圖 4 所示 Adapter 提供了三種事件傳遞類型。
圖 4. JDBC Adapter 事件傳遞類型配置
ORDERED 是指 Adapter 嚴格按輪詢到的事件順序處理各個事件,它可以確保事件處理的有序性;UNORDERED 是指 Adapter 不會嚴格按輪詢到的順序處理事件,而會啟用多個線程並發處理輪詢到的事件,因此可以明顯提高 Adapter 的事件處理能力;ORDEREDBYKEY 是指 Adapter 將事件按業務數據主鍵分組,相同業務數據主鍵值的事件將被分為相同組,不同組間並發發送,而相同組的事件順序發送。
ORDERED 和 UNORDERED 是最常使用的兩種事件傳遞類型。 Adapter 默認使用 ORDERED 傳遞類型,Adapter 在 ORDERED 傳遞模式下,僅使用一個線程處理事件,因此可以確保事件處理的有序性。但如果單個事件處理時間較長,那麼無論如何配置 輪詢時間間隔 及 最大事件數,也難以提高 Adapter 事件處理的能力。此時,如果系統對事件處理的順序沒有嚴格的要求,可以選擇使用 UNORDERED 事件傳遞類型。UNORDERED 事件傳遞類型的工作原理,如圖 5 所示。
圖 5. JDBC Adapter UNORDERED 事件傳遞類型工作原理
當使用 UNORDERED 傳遞類型時, Adapter 仍會使用一個連接來輪詢事件表,但會並行處理輪詢到的事件。因此,如果服務器事件處理組件的並發處理能力較強,采用 UNORDERED 傳遞類型可以顯著提高 Adapter 的事件處理能力。
當使用 UNORDERED 傳遞類型時 Adapter 自身會維護一個連接池,並使用 WebSphere 應用服務器提供的標准 J2EE 組件 WorkManager 作為工作線程池提供者。Adapter 向 WorkManager 提交 工作(Work) 前先從連接池中獲取一個連接,WorkManager 管理的線程會並行的處理接收到的 工作,當 工作 被處理完成後,Adapter 會收回工作者線程中的連接,因此每個工作者線程會占用一個連接。通過配置事件處理的連接數用戶可以直接控制事件處理的並發數,如圖 6 所示。
圖 6. JDBC Adapter 連接數配置
需要注意的是,這裡的連接是指由 Adapter 管理的連接,並不等同於一個數據庫連接,當使用預定義 DataSource 作為數據庫連接提供者時,每個連接除了固定占用一個數據庫連接外,在處理事件中還需要動態的獲取一個額外的數據庫連接來操作事件表,以保證事件表操作的事務獨立性。因此此時要保證 Adapter 入站服務正常運行,需要確保 DataSource 中有足夠的數據庫連接資源。我們將在介紹數據庫連接類型信息選擇時詳細介紹各種數據庫連接方式的工作方式及資源需求。
另外,由於 Adapter 使用 WorkManager 作為事件傳遞的線程提供者,因此需要確保 WorkManager 中有足夠的線程資源用於事件傳遞。WorkManager 的配置如圖 7 所示:
圖 7. WorkManager 的配置
在圖 7 中,DefaultWorkManager 一共有三種作用范圍,分別是 Cell,Node,Server,他們分別作用於 Cell,Node,Server 之上。但是這三種作用范圍的 DefaultWorkManager 所對應的線程池都是 Default 線程池。Default 線程池的配置見圖 8。
圖 8. 線程池的配置
圖 8 中顯示 Default 線程池 最小線程數 為 20,最大線程數 也為 20。這個線程池的 最大線程數 決定著入站服務所能達到的最大的並行處理能力。如果 WorkManager 啟動的線程總數超過 最大線程數,WorkManager 將不會再為接收到的 工作 產生新的線程,因此接收到的 工作 將會暫時阻塞等待。很可能出現這種情況,當選擇 UNORDERED 事件傳遞方式,同時 UNORDERED 允許的最大連接數設置為 30,那麼理論上 Adapter 最大允許 30 個線程並發處理事件,但是實際情況是最多只有 20 個並行線程在處理事件,這是因為 Default 線程池的最大允許線程數為 20,所以雖然同時提交 工作 為 30 個,但真正並發執行 工作 的線程只有 20 個,其他工作則阻塞等待。此時可以更改 Default 線程池的配置增加線程池的大小,如圖 9 顯示:
圖 9. 線程池的屬性配置
選擇數據庫連接類型
Adapter 自身會管理、維護到數據庫的連接。數據庫連接類型 是指 Adapter 入站如何創建數據庫連接。Adapter 入站服務可以選擇兩種創建數據庫連接的方式,如圖 10 所示。
圖 10. JDBC Adapter 連接類型配置
指定數據庫連接信息 是指通過在激活屬性中指定連接數據庫的 URL,驅動程序類等信息來創建數據庫連接;指定預定義 DataSource 是指通過在激活屬性中指定服務器中預定義的 DataSource 來指定數據庫連接提供者。
如前文所述,如果使用 UNORDERED 事件傳遞類型,Adapter 內部會創建獨立的連接池以重用具有傳遞能力的入站連接。這樣可以顯著降低入站連接的創建開銷,提高 Adapter 性能。當采用指定數據庫連接信息方式創建數據庫連接時,Adapter 會使用內部連接池獨立管理、重用數據庫連接資源。而如果使用預定義 DataSource 作為數據庫連接方式,Adaper 將與 DataSource 一起聯合管理數據庫連接資源。
對於 指定數據庫連接信息 的數據庫連接類型,每個入站連接占用一個數據庫連接;而對於 指定預定義 DataSource 的連接類型,每個入站連接除了固定占用一個數據庫連接外,為了保證對事件表操作的事務獨立性,每個入站連接在傳遞事件時需要動態的向 DataSource 申請和釋放連接。因此,假設用於事件傳遞的最大連接數是 N,那麼采用 指定數據庫連接信息 時 Adapter 最大需要創建 N 個數據庫連接;而當使用 指定預定義 DataSource 時,DataSource 中最大連接數必須大於 N+1,Adapter 才能正常工作。由於每次事件傳遞,Adapter 需要從 DataSource 中動態申請和釋放數據庫連接,為此 Adapter 需要額外的性能開銷。因此對於 Adapter 入站服務,采用 指定數據庫連接信息 作為數據庫連接創建方式會占用更少資源且有更好的性能。
配置多個 Adapter 共同處理事件
為了保證事件處理的正常工作,一個 Adapter 入站服務只能在一個節點中被激活,這在某些大型應用中可能會成為事件處理的性能瓶頸。Adapter 可以支持多個入站服務同時輪詢相同事件表,並發處理業務數據事件。其原理如圖 11 所示。
圖 11. 多個 JDBC Adapter 入站服務並行工作原理
分布在多台服務器中的多個入站服務,或者多個入站服務分別在集群環境中被激活,他們獨立並行的工作,並且輪詢相同事件表;當輪詢到事件記錄後,多個入站服務同時並行的傳遞服務;事件可以直接傳遞至事件處理組件,或者先傳遞至隊列,然後由隊列轉發至事件處理組件。通常這種工作方式適用於系統對事件處理的吞吐量有非常高的要求,而事件處理邏輯復雜單個事件處理事件較長,僅有一個入站服務難以滿足要求的應用場景。由於多個入站服務並行工作,這種工作方式可以使得系統整體事件處理能力得到極大提高。但為了避免不同入站服務同時處理相同事件記錄導致事件重復發送或者導致事件處理並發異常,需要恰當的配置入站服務以確保不同入站服務處理不同的事件記錄。基於適配器實例的事件過濾屬性是 Adapter 為這種多個入站服務同時工作所提供的支持。它和產生事件的觸發器一起靈活配置以達到多個入站服務的負載平衡。比如典型應用中,事件表的主鍵 EVENT_ID 是一個均勻分布的自增長序列,因此可以利用 EVENT_ID 使得事件均勻分布於不同適配器實例,以達到不同適配器實例處理不同事件且不同入站服務達到的負載平衡的目的。假設,如圖 11 所示,共有三個入站服務同時工作,那麼代碼列表 1 給出了如何在 Oracle 數據庫中編寫觸發器以利用 EVENT_ID 的特性,使事件均勻分布於各個入站服務中的 SQL 代碼示例。
清單 1. 觸發器示例
create or replace
TRIGGER CUSTOMER_EVENT_DELETE AFTER DELETE ON CUSTOMER
REFERENCING OLD AS O NEW AS N
FOR EACH ROW
declare
p_event_id number;
p_conector_id varchar(10);
BEGIN
select event_seq.nextval into p_event_id from dual;
select '00'||(mod(p_event_id, 3) + 1) into p_conector_id from dual;
INSERT INTO wbia_jdbc_eventstore (event_id, object_key, object_name,
object_function, event_priority, event_status, connector_id)
VALUES (p_event_id,:O.pkey, 'SampleCustomer', 'Delete', 1, 0, p_conector_id);
END;
我們可以在 WebSphere 集成開發環境中為不同入站服務配置不同事件過濾適配置實例,如圖 12 所示。
圖 12. 配置 JDBC Adapter 事件過濾適配器實例
假如我們為入站服務 1 配置 用於事件過濾適配器實例 為 001,為入站服務 2 配置 用於事件過濾適配器實例 為 002,,為入站服務 3 配置 用於事件過濾適配器實例 為 003;因此不同入站服務可以互不干擾的並行的處理相同事件表,使得系統的事件處理能力得到極大提升。
在實際應用中,用戶可以根據應用需求,利用 Adapter 入站服務特性並結合數據庫觸發器、事件表等靈活配置以實現多個入站服務並行工作。
總結
表 1. 影響 JDBC Adapter 入站服務性能的因素
名稱 對入站服務的性能影響 輪詢周期之間的時間間隔 輪詢間隔短入站服務事件處理能力越強,默認值為 2000 毫秒 輪詢周期中的最大事件數 最大事件數越大入站服務事件處理能力越強,默認值為 10 事件交互類型 共支持兩種交互方式同步交互及異步交互;異步交互有更好的性能,同步交互則有更高可靠性。 事件傳遞類型 共支持三種事件傳遞類型 ORDERED、UNORDERED、ORDEREDBYKEY;ORDERED 可以保證事件順序傳遞,一般用於對性能要求不高的場合;UNORDERED 不能嚴格保證事件順序傳遞,但有更高性能,一般用於對性能要求較高場合,但需要保證服務器有足夠資源。ORDEREDBYKEY 可以保證相同 KEY 值事件有序發送,不同 KEY 值事件並發發送,是介於 ORDERED 和 UNORDERED 間的事件傳遞類型。 數據庫連接類型 入站服務支持兩種連接方式指定數據庫連接信息及指定預定義 DataSource;指定數據庫連接信息占用資源較少且有更好性能。 部署方式 Adapter 支持多個入站服務並發處理相同事件表,但需要保證不同入站服務處理不同事件記錄。表 1 總結了本文介紹的影響 Adapter 入站性能的所有因素。實際應用中可以根據業務需求合理利用這些參數已達到系統對入站服務的性能需求。