在接下來的20個工作日中，我將堅持翻譯或者略翻譯Esper的官方文件。

為什麼需要學習Esper，因為我們需要理解複合事件處理 Complex Event Processing (CEP)。在量化交易系統中，CEP是必不可少的。它負責處理海量的實時事件。

關於CEP更多知識，大家可以翻閱網路相關資料。我這裡集中在學習開源的CEP系統，Esper。。

今天開始第一篇：技術概覽。

1. CEP和事件序列分析

Esper引擎主要解決現實中某類應用對事件的分析和響應的需求。這類需求的典型代表有： 1）商業管理和自動化（商業事件監聽，BAM，異常事件緊急處理） 2）金融（程式化交易，欺詐檢測，風險管理） 3）網路和應用的監管（入侵檢測，SLA監管） 4）感測網路應用（RFID讀取，生產線的控制和排程，空中航線監管） 這類應用的共同點就是需要實時地處理事件Event（訊息Message），或者至少是接近實時。這種系統也叫Complex Event Processing(CEP)，或者事件序列分析。這類系統的關鍵特性是吞吐量、延遲性和複雜邏輯的需求。 1）高吞吐量 - 應用需要處理大量的事件（每秒處理1000至100K） 2）低延時 - 應用需要在事件發生時立即做出響應（從幾毫秒到數秒內） 3） 複合計算 - 應用支援對事件的複雜處理，例如事件之間的模式(Patterns among events)，過濾事件(Filter events)，合併特定時間視窗或者長度視窗的事件，事件序列的合併，基於事件缺失的觸發處理。 Esper 引擎就是為了簡化應用實現CEP功能而生。

2. CEP和關係型資料庫

關係型資料庫和SQL語言主要是面向絕大多數資料是靜態資料，大多數查詢是簡單查詢的場景。大多數資料庫也是將資料儲存在磁碟上（除了in-memory 資料庫），它們的優化也是針對磁碟存取的。 為了從資料庫中獲取資料，那麼必須對資料庫進行查詢。如果應用每秒需要得到資料10次，那麼勢必觸發10次資料庫查詢，這中方法很難擴充套件到每秒成千上萬的查詢量。 當資料的資料需要更新時，資料庫的trigger會被激發，然後這種資料庫觸發器執行速度很慢，並且不擅長複雜的條件檢測和邏輯處理。 In-memory資料庫比傳統的關係型資料庫更適合CEP應用，因為它具備更好的效能。但，它並沒有為CEP的實時查詢結果以及事件序列分析進行設計和優化。 3. Esper作為CEP引擎 Esper和關係型資料不一樣的點在於，它並不儲存資料，相反，它儲存查詢。而資料是通過查詢來處理。當一個數據（Event）來到時，它將通過我們預訂的查詢語句，決定下一個動作。 Esper提供兩種機制處理事件流：事件模板(event patterns)和事件流查詢（event stream queries） Esper提供事件模板語言，用於基於表示式(expression-based)的事件模板匹配。模板匹配引擎是通過狀態機來實現的。這種方法可以處理預料的事件序列、事件缺失和事件融合。它也提供了事件在時間方面上的相關性分析。 Esper也提供了事件序列查詢方法，用於滿足CEP應用對事件序列的分析需求。事件序列查詢(Event series queries)提供視窗(window)，統計(aggregation)，合併(join)和分析函式，用於處理事件流。這些查詢遵循EPL語法。EPL有點類似與SQL，但它是處理檢視（View）的，而非表格（Table）。檢視，代表了對一個事件序列的處理以及產生新的事件序列。 Esper 採用統一的API介面提供的這兩種方法。

4. 需要的第三方庫

Esper需要如下第三方庫： 1）ANTL 2） CGLIB 3） Apache commons logging ，Log4J. 4）Junit 5）Mysql的連線庫 本章完畢。。。