Redis適合我的用例嗎？

Question

我正在寫一個基本上是facebook事件的web應用程序，但更多的即興和實時。用戶可以創建一個事件，並且該地區（半徑30英里）內的其他在線用戶應該立即看到該事件。用戶可以註冊事件，主持人應該看到邀請。主持人可以取消該事件，所有參與者都應該收到通知。沒有長時間的投票或刷新是必要的，我很可能會使用websockets（socket.io）

這個概念很容易描述，但我只是想着如何實現這一點而頭痛。尤其是如果用戶有多個會話。

Redis最近引起了我的注意。我能否收到關於我的實施計劃的建議，以確保我不會走上瘋狂的道路？

1. 我跟蹤Redis中登錄的用戶位置。
2. 用戶創建事件並將其存儲在Redis中。
3. 我發現所有位於30英里半徑事件的用戶，並通過socket.io通知他們。
4. 註冊事件的主機和用戶輸入到Redis pub/sub中進行任何類型的通知。
5. 一旦事件結束，我從Redis的和存儲在MySQL

是我實現的可行移除事件？在這裏使用Redis有意義嗎？

Answer 1

我的實現可行嗎？在這裏使用Redis有意義嗎？

是的。是的。但魔鬼在細節中。

除非你在這裏做一些巧妙的事情，否則在一定範圍內向用戶分發消息並不那麼容易。

例如，您可能會將您的世界劃分爲一些行業，每個行業都有自己的Pub/Sub渠道。這些部門的最佳規模必須通過仔細的實驗​​，基準測試和分析確定。但是每個用戶都可以爲他自己的扇區和所有相鄰扇區訂閱9個通道，獲取源自這些扇區的所有消息，並檢查消息中包含的確切座標以決定它是否在半徑範圍內。

比收聽所有消息要容易得多，而且肯定比服務器不得不將消息發送給正確的半徑用戶更容易。

使用這種方法，服務器可能不知道每個扇區甚至意味着什麼，它只是有許多通道和一些訂閱者來傳遞消息，但客戶端不必聽取所有內容，到那些可能包含有可能在半徑內的消息的頻道。

使用這個想法，你甚至可以讓不同的服務器處理不同的扇區，因爲這些服務器不必知道彼此。只有客戶需要訂閱可能會有與其相關的消息的服務器/部門。

在如此早期的階段考慮類似這樣的事情似乎是一種過早的優化，但是如果在系統中獲得任何顯着的流量，則可以確信，在不考慮方式的情況下路由消息將變得困難事先有效地做到這一點。

現在，是否使用Redis是另一個問題。如果您的數據無論如何都通過Socket.io或WebSocket傳遞，那麼一切都可以由服務器完成，除非您需要每個通道/扇區多個服務器，否則根本不需要使用Redis。但是，如果您需要將前端服務的多個實例連接到您的前端，並且這些實例需要在它們之間傳遞消息，而不是僅在客戶端之間傳遞消息，那麼您可能需要Redis或其他一些發佈/訂閱系統。

這一切都取決於它將如何擴展。但我肯定會考慮Redis在這裏。