2009-08-25 57 views
0

我正在向我的用戶發送通知,具體取決於每個用戶的訂閱類型。訂閱 - 如何處理大量內容和訂閱金額?

例如:

  • User A訂閱訂閱所有評論
  • User C所有新聞文章
  • User B訂閱了一切,這是在網站上新

我有一個腳本每5分鐘運行一次(除非腳本仍在運行)誰執行以下操作:

  1. 獲取新信息「內容」自上次運行
  2. 對於每個結果的評論(評論,新聞文章等),取誰訂閱了「內容」
  3. 對於每一個用戶的每一個用戶,發送通知

我擔心的是,如果我有1,000個新的「內容」,並且我的用戶訂閱了50%,我的腳本將永久完成或將崩潰我的服務器。

我想出的是每次只選擇100個新的「內容」並通知用戶。我仍然有可以訂閱的用戶數量的問題。

比我想象的,我可以將我選擇的用戶數量也限制爲100,而不是迭代,直到我到達所有用戶。

這是正確的做法嗎?有沒有更簡單的方法來做到這一點?大型網站如何處理用戶通知?

回答

1

能夠處理(併發送郵件)批次的用戶可能在架構方面很方便,就好像單個進程/服務器的工作變得太多了,你可能有多個「工作」都在他們自己的批處理。

這就是說我不確定你對腳本的擔心需要很長時間才能運行或崩潰服務器。我認爲這是您在代碼中完成的一個問題。分析代碼和你正在做的數據庫查詢是必須的。

如果您確實採用批量路線,您最終必須嘗試跟蹤您向哪些用戶發送的通知。我強烈建議你不要爲每個用戶內容對保留一行表格。如果您只是簡單地存儲發送給用戶的最後一個事件(文章或評論發佈時間)的時間,那麼將很容易計算出您仍然需要發送的內容,而且您最終不會得到一張巨大的表格。

重新迭代我建議將代碼和查詢分析爲研究任務,並通過該路線找出最有效的方法。

0

在知道如何設置數據庫的情況下,很難知道如何回答這個問題。使用正確的設置,應該可以編寫單個查詢,爲您提供需要收到有關新內容通知的所有用戶。

喜歡的東西:

SELECT u.user_email 
FROM user_table AS u 
LEFT JOIN subscription_table AS s 
ON s.user_id = u.user_id 
LEFT JOIN content_table AS c 
ON c.content_type = s.content_type 
WHERE c.add_time > LAST_RUN_TIME 

會告訴你如何開始。