石英彈簧設計建議

我在集羣環境中使用石英+彈簧運行的作業很少。這些作業未設置爲在集羣環境中運行，因此每個作業將根據我們所擁有的實例的數量運行多次。這些作業在AWS環境中運行。所以我們不確定會運行多少個實例，因爲我們可以動態增加或減少。所以我們正在重構代碼。石英彈簧設計建議

問題，讓我們根據一定的活動以用戶發送郵件給用戶爲例。我們每天可能會有1000個用戶需要發送電子郵件。

當前，因爲未將其設置爲在羣集環境中運行，所以每個實例都會運行作業並向用戶發送有關其活動的電子郵件。所以如果我有3個實例在運行，工作將運行3次，同樣的電子郵件發送給用戶3次。

我們決定使用石英jdbc來確保作業只運行一次。

我在尋找關於如何做下面部分的建議。

讓我說我必須發送電子郵件給300個用戶，而不是運行1個實例挑選用戶和發送電子郵件給300個用戶，我想在任何實例上獲得300個用戶從DB和後來相同的工作其他實例也參與處理這300個用戶。什麼是最好的方式來做到這一點。我不想將這300名用戶存儲在臨時表中，並且從數據庫中挑選用戶。有沒有一種方法可以將這些300個用戶存儲在全局內存中，例如memcached和job，以便從不同的實例中挑選數據（處理用戶時的負載平衡類型）。我不想使用memcache，所以可用的其他選項或最佳方式我可以繼續設計。

來源

2016-12-26 prred

它是在DB中插入記錄的應用程序嗎？或者您的應用程序僅從數據庫中選擇記錄併發送電子郵件？ –

這個應用程序將得到用戶使用休息服務的列表，併爲每個用戶調用其他休息服務發送電子郵件 – prred

幾個月前我們遇到同樣的問題。我們解決這個問題，創建一個名爲job的表，如下所示，僅用於控制正在運行的調度程序。

+-----------+--------------+------+-----+---------+----------------+ 
| Field  | Type   | Null | Key | Default | Extra   | 
+-----------+--------------+------+-----+---------+----------------+ 
| id  | bigint(20) | NO | PRI | NULL | auto_increment | 
| createdAt | datetime  | NO |  | NULL |    | 
| updatedAt | datetime  | NO |  | NULL |    | 
| version | int(11)  | YES |  | NULL |    | 
| running | tinyint(4) | YES |  | NULL |    | 
| scheduler | varchar(255) | YES | UNI | NULL |    | 
+-----------+--------------+------+-----+---------+----------------+

基本上與第一實例時啓動調度程序集「運行」屬性爲1（運行）和結束時設定爲0（停止）。

問題這種方法：

每個調度具有相同的一堆代碼來驗證表（冗餘代碼）。
如果您忘記了這一堆，調度程序無法正常工作。

不是最好的解決方案，但它與緩和作品。

來源

2016-12-26 18:30:57

感謝您的迴應，但這真的沒有幫助我，因爲我們打算使用石英jdbc支持，但我的問題主要是在處理我從第一份工作中獲得的用戶列表時如何進行負載平衡。 – prred

石英彈簧設計建議

回答

相關問題