AWS SNS中的延遲和吞吐量是否足夠替代專用於發佈/訂閱的MQ？

爲了HA的緣故，我正考慮從自我託管的解決方案（ZeroMQ）切換到AWS Simple Notification Service，以便在應用程序中發佈/訂閱。哪一個是應用程序的後端，因此應該是合理實時的。AWS SNS中的延遲和吞吐量是否足夠替代專用於發佈/訂閱的MQ？

什麼是SNS的延遲和吞吐量？

2013-02-08 vartec

只是好奇：你爲什麼選擇SQS的SNS？對於高可用性，SQS可以允許多個潛艇分割請求。 – PBelzile 2013-02-16 02:19:56

@Pelzile：首先，SQS沒有真正的pub/sub模型。 SQS中pub/sub的標準方式是使用SNS + SQS端點。其次，我不喜歡SQS主動投票。第三，從我的經驗我知道，SQS的延遲是高和不可預測的。 – vartec 2013-02-17 15:06:33

該應用將在EC2上託管嗎？如果是這樣，延遲將大大減少，因爲溝通渠道將通過亞馬遜的連接，而不是通過互聯網。

如果你打算從EC2上沒有舉辦過箱調用AWS服務，這裏有一個cool site試圖給你各種AWS服務和位置之間的延遲量的想法。

enter image description here

你是如何測量的HTTP Ping請求延遲？

我們正在HTTP GET請求到AWS服務端點（如EC2， SQS，SNS等）用於PING並測量所觀察到的延遲爲它在所有區域。

至於吞吐量，這是留給你的。您可以使用各種策略來提高吞吐量，如多線程，批量消息等。

請記住，您將不得不編碼一些副作用，例如可能會看到相同的消息兩次（至少一次傳遞），而且不能依靠FIFO。

2013-02-15 00:30:51 GalacticJello

相當酷的網站，但是我沒有看到HTTP ping如何形成我的位置到SNS端點轉換爲服務的延遲。 – vartec 2013-02-15 16:39:48

是的，這看起來不是合適的答案。這是從不同地區的瀏覽器到服務的等待時間，但不測量服務是否是「實時」。 – Mobigital 2017-05-09 23:17:19

回答