是否有API允許在集羣應用程序中訂購事件？

鑑於以下事實，有沒有實現的算法使事件的重現性排序在集羣環境中的現有的開放源代碼的Java API（可能是由於一些更大的產品的一部分）：正式是否有API允許在集羣應用程序中訂購事件？

1) There are N sources of events, each with a unique ID. 
2) Each event produced has an ID/timestamp, which, together with 
    its source ID, makes it uniquely identifiable. 
3) The ids can be used to sort the events. 
4) There are M application servers receiving those events. 
    M is normally 3. 
5) The events can arrive at any one or more of the application 
    servers, in no specific order. 
6) The events are processed in batches. 
7) The servers have to agree for each batch on the list of events 
    to process. 
8) The event each have earliest and latest batch ID in which they 
    must be processed. 
9) They must not be processed earlier, and are "failed" if they 
    cannot be processed before the deadline. 
10) The batches are based on the real clock time. For example, 
    one batch per second. 
11) The events of a batch are processed when 2 of the 3 servers 
    agree on the list of events to process for that batch (quorum). 
12) The "third" server then has to wait until it possesses all the 
    required events before it can process that batch too. 
13) Once an event was processed or failed, the source has to be 
    informed. 
14) [EDIT] Events from one source must be processed (or failed) in 
    the order of their ID/timestamp, but there is no causality 
    between different sources.

少

，我有那些接收事件的服務器。他們從相同的初始狀態開始，並且應該通過同意按哪個順序處理哪個事件來保持同步。幸運的是，這些事件不是儘快處理的，而是「一點點」，以便我有一段時間讓服務器在截止日期前達成一致。但我不確定這是否會對算法產生真正的影響。如果所有服務器都同意所有批次，那麼它們將始終保持同步，因此在查詢時會呈現一致的視圖。

儘管我對Java API感到非常滿意，但如果可以從Java調用它，我還會接受其他的東西。如果沒有開源的API，但是算法清晰，我也會將其作爲答案並嘗試自己實現。

來源

2012-06-02 Sebastien Diot

您是否熟悉分佈式算法？（第一課是你不會讓多臺計算機的時鐘同步） –

我不是100％確定我真的明白你在問什麼，但是IMO像演員模型那樣可能會讓你走上正軌。有很多實現。你可能也想看看功能如何（如Clojure）。 –

@LouisWasserman我剛纔問了ServerFault：http://serverfault.com/questions/394967/what-is-a-realistic-average-time-difference-between-servers-in-the-same-lan預期的區別是10-20ms，遠低於1秒。批次不必完全在同一時間處理，只需要按照相同的內容和順序進行處理。 –

看問題和你的後續可能「不是」一個API來滿足您的要求。一天，你可以看看卡夫卡（從LinkedIn）

Apache Kafka

和「日誌」實體的一般概念，什麼人喜歡稱之爲「大數據」：

The Log: What every software engineer should know about real-time data's unifying abstraction

其實你的問題，我會與有關的「日誌」的博客開始。在我而言它的工作方式 - 與卡夫卡並不是唯一的包出去做日誌處理 - 原理如下：

取而代之的是基於隊列的消息傳遞的/發佈 - 訂閱
卡夫卡使用消息的「日誌」
用戶（或終端）可以消耗日誌
日誌保證是「按序」;它處理千兆數據，是保證快速
- 仔細檢查，通常有一種折衷的可靠性
你剛纔讀的日誌，我想讀是破壞性的作爲默認值。
如果有用戶組，每個人都可以在日誌輸入消失之前「讀取」。

日誌的基本處理（計算）過程是一個Map-Reduce-Filter模型，因此您可以閱讀 - 一切都非常快;只保留你想要的東西;處理它（減少）產生結果。

缺點似乎是你需要羣集和東西，使其真正閃耀。由於提到了不同的服務器或網站，我認爲我們仍然處於正軌。我發現它是一個挑剔的起步和運行的Apache下載，因爲往往假定非Windows環境（ho hum）。

其他「快」的辦法是

Apache Apollo

這將需要你做的管道，用於連接不同的服務器。由於要求包括...

接收事件的服務器。他們從相同的初始狀態開始，並且應該通過同意按哪個順序處理哪個事件來保持同步。幸運的是，該事件不被儘快處理，但「在一個位」，讓我有一些時間來讓服務器在最後期限之前同意

我建議看着"Getting Started" example or tutorial with Kafka，然後找在類似的ZooKeeper組織的消息/日誌軟件中。祝你好運，享受！

來源

2015-01-17 13:00:01 will

到目前爲止，我還沒有明確的答案，但我認爲這將是有用的人有興趣看到我發現。

Conflict-free Replicated Data Types

一個做多concurent過程等待對方，這我可以用同步的「批」的方式是一個分佈式屏障。一個Java實現似乎在Hazelcast之上可用，另一個用於ZooKeeper

我發現的一個更簡單的替代方法是使用數據庫。每個進程都將其收到的所有事件插入到數據庫中。例如，根據數據庫設計，這可以完全併發和無鎖，例如在VoltDB中。然後以一秒鐘的規律間隔運行一些「定時任務」，選擇並標記下一批次中要處理的事件。作業可以在每臺服務器上運行。第一個爲一個批次運行作業修復了一系列事件，以便其他人可以使用第一個定義的列表。就像那樣，我們保證所有批次在所有服務器上都包含相同的一組事件。如果我們可以在整個批處理中使用完整的訂單（cron作業可以指定它自己），那麼服務器的狀態將保持同步。

來源

2012-06-03 09:56:22

是否有API允許在集羣應用程序中訂購事件？

回答

相關問題