複雜事件處理兩種技術實現手段的對比，規則語言 VS 持續查詢語言

事件即事物的狀態信息變化，事物之間的作用和動作。複雜事件處理描述的就是系統如何持續地處理這些事件，即系統對變化的持續反應。不論是個體還是系統，都需要從大量的事件中過濾提取，按照既定的處理反應規則做處理。複雜事件處理產品主要採用兩種技術手段來完成事件的過濾，判斷和處理，即規則語言和持續查詢語言。
規則語言定義事件處理的規則，即條件+動作。當某些條件滿足時，執行一些處理，一些動作。規則語言定義的規則集合在運行時由規則引擎來執行，當有新的事件和對象產生，或者已有事件和對象變化時，匹配所有規則，滿足條件的規則按優先級進入執行隊列，按順序執行規則中的動作。如果該動作的處理導致事件和對象的變化，可能會有新的規則加入執行隊列，或者從執行隊列中減去一些規則。這個過程會一直執行下去，模擬了一個實體對變化的持續反應。
持續查詢語言 CQL 使用類似 SQL 的語法來描述事件和事件反應處理規則。對於內存中大量的外部事件和內部對象， CQL 通過查詢語句來做條件匹配，同時提供回調函數，當某些事件或者對象符合查詢條件，就調用回調函數做相應的處理。 CQL 提供兩種查詢方式，快照方式和持續方式。 快照查詢只做一次，持續查詢類似規則引擎中的規則，只要事件和對象有變化，就執行查詢做條件匹配，有匹配上的對象就調用相應的回調函數。這個過程一直會執行下去。同樣可以描述對事件的持續反應處理。
從幾個方面來比較一下規則語言和持續查詢語言。
（1） 兩種技術的實現手段。 規則引擎使用RETE網絡，將規則集合中的所有條件的所有模式構造成一個匹配樹，變化的對象通過這個樹進行過濾匹配，判斷有哪些條件被滿足。匹配樹的各個節點會存儲在這個節點上滿足模式的對象，這樣可以在對象變化時不需要重新匹配所有對象，大大加快匹配的速度。持續查詢語言使用的是數據庫技術，事件和對象相當於表，不論是在內存裏還是在文件裏。持續查詢相當於視圖，只要對象有變化，視圖裏就有對應的體現。通過索引來加快查詢匹配速度。抽象一點說這是過濾和查找的對比。打個比方不知道恰當與否，前一個好比是拿着所有的藥對着一排藥方配藥，後一個相當於拿着一張張的藥方對着所有的藥抓藥。
（2） 兩種技術的性能。對於這兩種技術哪個性能更好，我不知道答案。規則引擎的RETE樹通過單個模式節點的連接（joint）來做多個對象多個模式的條件判斷，查詢語言通過表之間的連接（joint）來做跨多表的查詢。誰的性能更好，需要有精通理論的人來研究試驗。對我們做應用的人來說感覺當事件和對象很多，但匹配上條件的對象佔少數時，使用規則引擎更好些。只是感覺，大家做應用時自己做試驗來判斷。
（3） 如何選擇使用哪種技術。兩種技術都能實現對事件對象的持續條件匹配和處理。從開發的角度，一個使用自定義的規則語言，一個使用類SQL的語言，差別也不大；運行時看，對內存的使用都不小。對於這個問題，我現階段沒有好的回答，之後瞭解得更深些，可能會給一個選擇推薦。個人而言，更喜歡規則語言，覺得和現實中描述一個系統的變化反應比較相似。

瞭解技術的本質，才能決定什麼樣的需求場景使用什麼樣的技術手段。不論是規則語言，還是持續查詢語言，我們用複雜事件處理技術替代普通編程語言來實現一些應用，究竟能帶來什麼好處呢。
（1） 開發時採用聲明型語言替代過程式語言。規則語言和持續查詢語言都是聲明型編程語言，只聲明事件的匹配條件和對應的處理動作，整個系統的運行由引擎來執行。這樣開發的工作量要小一些，但需要非常準確地瞭解引擎的工作原理和細節。
（2） 在對大量事件和對象的持續條件匹配和處理的過程中，複雜事件處理產品提供高效的條件匹配，對象查詢。這個是應用開發者自己難以實現的部分。
和其他技術一樣，複雜事件處理技術不只是產品提供的這些內容。其實更多的是實施的方法論，事件如何分層，如何確定事件彼此的關係，如何來做判斷推理，等等。總的來說就是如何把現實世界的一些實體和行爲來做建模，用產品工具實現要做的模擬和處理，來得到我們需要的結果。而這部分恰好是沒有標準答案的部分，是我們應用開發者在實踐中不斷思考積累的東西。