仙丹鳳凰提醒功能

Question

我正在玩弄仙丹和鳳凰，並試圖實現提醒功能，即待辦事項與未來的日期時間，這應該提醒你在該日期時間。

我心目中以下天真的解決方案：

1）使用簡單的一對一策略，併爲每個提示創建一個進程，它將使用超時和完成後死亡

2）彙總所有提醒在單個進程中，將提醒存儲在狀態中，每隔幾秒檢查一次日期時間，並在提醒後移除。

可能有人詳細說明每個解決方案，並且可以給出更合理的一個，由於

Answer 1

我建議考慮規模。 假設你有一個處理X提醒一個服務器：

1. 在我們有X的過程，每一個都有自己的計時器的第一個解決方案，當計時器結束時它會發送消息和死亡。

2. 在第二個解決方案，我們將有一個過程，大概會找到所有相關提醒和處理它們相應

多大X？

如果x的數量是千，而提醒是短暫的，那麼也許我會說第一個解決方案更好，因爲你有更好的容錯設計，因爲'提醒'被進程分開，但如果x很多那麼它可能不能很好地擴展，你會有很多每個都有一個定時器的進程，這並不是真的推薦。

我想補充一點，如果你有很長時間的提醒，比如說一個提醒一年後，你需要讓一個進程運行一年，直到它過期，這實際上並沒有擴展。

當您處理大量提醒時，第二種解決方案可以更好地擴展爲。 你可能會有一個計時器，可能每秒運行，它會聚合相關的提醒，應該在當時大概運行並處理它們，長時間運行的提醒將不再是問題。

Answer 2

我相信第一個選擇是好得多，爲簡單起見，並且尤其是的可擴展性。 Erlang被設計用來處理大量以有效方式併發運行的輕量級進程。進程也可以分佈在集羣中的許多機器上，所以你可以基本上擴展到無限大。

由於目標非常簡單並且性能影響很小，所以啓動一個只需調用send_after/3的新進程即可，因爲目標非常簡單，並且如果出現問題並且該進程死亡，則只會丟失一個提醒。所有其他人都是孤立的，仍然會開火。

通過所有的提醒存儲在一個單一的過程中，你把自己放在一個非常不舒服的位置有以下幾個原因：

• 如果進程中止，你提醒所有都不見了。這可能是不可接受的，所以你需要想出一種將它們保存到磁盤的方法，以便從崩潰中恢復......更多工作，更復雜;
• 如果提醒數量過高，則每隔x秒遍歷整個列表將是一項昂貴的操作; send_after/3擁有更高效的調度/調度機制，並且它的構建正確性更低，工作更少，複雜性更低;
• 如果一切都在一個單一的大型過程中，則無法在羣集中的節點之間分配負載，因此受到運行該大型過程的計算機的計算能力的約束。

在大多數編程語言中，併發性是非常難以安全的方式進行的，所以人們避免它像鼠疫一樣。在Elixir和Erlang中，情況恰恰相反 - 你想盡可能多地使用它，並且通過這樣做你會看到明顯的收益。分而治之！