應堅持Drools的知識會話

Question

我工作的一個學區，我們計劃使用Drools的實現以下類型的地區組成學校的學生人數規則：

• 如果學生有3個在一年的缺勤期間，他們的出勤率指標進入WARN狀態。
• 如果學生在一年內有6次缺課，則他們的出勤指標將進入CRITICAL狀態。
• 如果學生在一年內有3個主要行爲事件，他們的行爲度量將轉爲WARN狀態。
• 如果學生在一年內有2次輕微和2次重大行爲事件，他們的行爲指標將轉爲CRITICAL狀態。
• ......這些只是我頭頂的例子，但還有更多類似性質的規則。

所有這些規則都可以用Drools專家簡單地表達。另外，學生的規則處理不需要是同步的。我有幾個關於實現這個最好方法的問題。

1. 從一個角度來看，這可以被視爲一個事件流的監控系統。這讓我想到創建一個有狀態的會話，每個新事件都將插入到該會話中。然而，這些事件在9個月內發生，並且相對罕見。另外，我們可以爲每個學校建立一個會話，或者爲每個學生創建一個會話

   • 會在內存中保持一個會話很長時間會成爲問題嗎？
   • 如果服務器發生故障，我們是否需要從頭開始重建會話狀態，或者建議您定期拍攝快照並恢復自快照時間以來發生的事實。

2. 另一種選擇是在爲該學生處理事件後爲每個學生保留一個會話。當下一個事件進入時，我們將從存儲中檢索他們的會話並插入新的事實。這樣我們就不需要檢索引擎每次運行的所有事實來獲得學生的狀態。會支持這樣的配置嗎？有沒有這樣做的缺點？

3. 第三種方法是通過檢索規則需要運行的所有其他事實來響應學生的新事實，創建新的KnowledgeSession並運行規則。

任何意見什麼可能是最好的方法將不勝感激。

戴夫

Answer 1

我會去解決方案2號：每個學生一個會話。鑑於您不會與會話過多交互，我會將其保留在數據庫中，並且只在需要時才恢復：新的缺席/事件到達，該學生的會話從數據庫恢復，事實插入時，將執行規則並檢索結果狀態。

我在這種情況下看到的主要缺點是創建關於多個學生的規則並不簡單，您必須將您的事實提供給多個會話。例如，如果您想要在單個課程中擁有超過10名具有CRITICAL狀態的學生，請提醒。在這種情況下，每個類的會話就足夠了。所以，正如你所看到的，你必須決定什麼對你更好。但不管你選擇的「單位」（學校，班級，學生），我仍然會向你推薦我前面提到的執行流程。

Drools已經支持使用JPA的數據庫持久性。您可以在此處獲得有關此功能的更多信息：http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/#d0e3961

基本思路是，不要使用kbase.newStatefulKnowledgeSession()創建ksessions，而是使用名爲JPAKnowledgeService的幫助程序類。這個類將返回一個StatefulKnowledgeSession的包裝器，它將在每個方法調用後保持其狀態。在本課程中，您將找到2種重要的方法：newStatefulKnowledgeSession()，創建新的ksession並從loadStatefulKnowledgeSession()中檢索數據庫中的現有會話。

希望它有幫助，

Answer 2

懶惰我會去第三種方法。我將把所有事件存儲在一個數據庫中，然後我將按照每天，每週，每月（如果需要）批量處理所有學生。這將允許您創建一個包含多個學生，課程等的規則的會話。 如果您沒有3 +百萬名學生，那麼您會很好，並且它將會是一個高性能的應用程序。

Answer 3

感謝您的建議和意見。我傾向於＃2的一對夫婦的原因：

• 我覺得收集了所有的事實爲給定的學生從頭開始重新運行它們每一個進來將是一個重量級的過程事件我寧願避免。
• 用例我將模型作爲一個運行時間非常長的監視過程，讓我相信（在閱讀Fusion的用例之後），將事件插入持久的KnowledgeSession是一種可行的方法。
• 我不認爲問題空間的範圍（即學生vs教室，學校或整個地區）是一個問題。如果我們需要教室指標，那麼我們只會爲類也消耗相關事件（測試，缺席等）的新規則庫

一個警告是，如果規則改變，我們需要重新評估所有受影響的學生反對新的規則庫，這意味着收集所有事實並從學年開始。這應該不會發生多少，但如果它變得更頻繁，那麼我可能會轉向第三種方法。

再次感謝您的幫助。

Answer 4

有第四個選項使維護更簡單。爲所有學生建立一個針對整個學區的單一有狀態知識課程。在每個事件被成功處理後，堅持會話以防JVM失敗時需要重建工作內存。您將需要更大的RAM和堆空間分配，但在今天的時間內RAM很便宜。 （我們使用32 GB RAM並分配16 GB XM和Xmx）如果您有24x7服務器，最有可能的是，您的JVM永遠不會關閉。