我們將事件存儲在Chronicle隊列V4中，並有一個Tailer來處理它們。其中一些事件過期（不是基於時間的，但是被後來的事件所取代），因此可以在處理過程中跳過。更新摘錄在紀事隊列
有沒有辦法更新現有的摘錄，即設置一個布爾標誌「過期」爲真，所以我們可以跳過過期的事件？還是有另一種解決方案來實現Chronicle隊列？
例如，系統生成事件A1，B1和C1。現在事件B2到達，使B1過時。我們現在可以在沒有昂貴處理的情況下跳過B1。
問候， 約亨
分析您的要求
你正在寫事件隊列。活動有一個獨特的密鑰K
，而寫有可能是當前事件取代了相同的密鑰K.
要更新與舊的，已經寫事件，一個年紀大了，已經寫事件鍵K告訴一個零售商（稍後會發布）存在一個更新的版本。
我認爲這是一個非常普遍的要求，它起初看起來很有吸引力，但是（正如我經歷的那樣）它是有缺陷的。原因如下：
假設您正在處理大量事件，例如每秒100秒，這很有幫助。 Chronicle Queue在適度的硬件上可以實現這一功能。現在我還假設你只是寫隊列，你不會在其他地方記錄任何有關你的數據的東西。
關鍵點在於上面的第2項：您正在編寫一個事件，並且您意識到您需要更新一個較早的事件。你需要做什麼？您需要掃描整個隊列，可能需要很長時間/很多事件來搜索舊事件。只有這樣你才能更新它並完成新的事件。這不會縮放。
潛在的解決方案：
贛駿需要知道所有：
我假設你的零售商執行上的數據的某些行爲。 只有在確定它具有最新版本的事件K之後，才讓您的零售商運行所有事件並執行A. 評估：零售商需要爲每個事件對隊列進行全面掃描，或者需要構建一些數據結構/映射爲每個事件密鑰K
指數基於版本的地圖
你的appender時寫入事件會從紀事隊列的索引。在基於內存或基於文件的地圖（例如，Chronicle Map，MapDB ...），存儲密鑰K以及事件的最新索引。如果密鑰已經在地圖上，它只是更新它。現在，Tailer不會按順序處理隊列，但組件會從地圖中獲取所有密鑰，尋找索引，讀取事件並執行A.然後繼續執行下一個鍵。
事情要考慮
多少事件將零售商是處理在一定的時間框架？這將決定地圖大小：地圖大小：每個時間範圍的事件數量*（鍵長+ 64位索引號）
也許連續操作更好：製作動作冪等和可重複：可以像你一樣頻繁地運行希望舊版本不會更新該事件的較新版本。
恕我直言，紀事隊列的索引是一個非常好的工具，它幾乎免費:)