我試圖重新發明輪子並在Redis中存儲一些統計信息。有多少個HINCRBY電話是合理的？
我正在考慮在每個新事件（它可能每秒發生幾次）之後急切地彙總所有相關計數器。
它需要調用HINCRBY每個事件5-50次，而我的目標是每秒5-100個事件。
對Redis來說太多了嗎？ 如果是這樣，我是否應該瞄準一些下限（每個事件10次？只有一次？）？ 如果不是，它是否可以在任何這些參數中進行縮放（我更喜歡縮放到1000個事件？10000？）？
我明顯也會收集垃圾。我打算通過調用EXPIRE來獲得每個事件所需的每個散列（不超過2-5次，因爲某些計數器在同一個散列中）。可以嗎？
堅果。如果硬件支持它，Redis將能夠處理負載。顯然你應該儘可能快地嘗試原型並進行嘗試，但這絕對是Redis應該能夠處理的事情。
雖然我建議你考慮縮放比例。解決擴展問題要比等待問題變得更容易。 Redis還沒有任何集羣解決方案，並且你受RAM（和一個CPU）的限制，所以最終你需要一些擴展到更多服務器的方式。
要做到這一點的方法是客戶端分片，也就是說，對於每個操作，您散列您的密鑰，並查看它所在的服務器，然後與該服務器交談（這顯然使得使用多個密鑰的操作非常難以執行，所以你可能不得不圍繞這個設計）。 Ruby客戶端支持一些開箱即用的功能，但如果您使用其他驅動程序（and Salvatore has a guide, too），則自己並不難（儘管不方便）。我建議先在同一臺機器上運行兩個或四個Redis實例（每個CPU一個，或類似的東西），再加上另一臺運行從機的機器以實現冗餘和故障切換（您也可以在每個機器上運行兩個主設備和兩個從設備服務器）。這樣，如果需要增長，將實例移動到其他服務器的工作量並不是很大。如果你有四個實例，你將能夠移動到四臺機器，而不會有太大的麻煩，因爲你所要做的就是在新機器上設置一個從機，等待它同步，然後用它作爲主機。如果您沒有四個實例，移動到新機器意味着手動移動按鍵，這可能需要很多工作。