AWS SNS中的延迟和吞吐量是否足以取代pub/sub的专用MQ？
var*_*tec 16 message-queue publish-subscribe zeromq amazon-web-services
为了HA,我正在考虑从自托管解决方案(ZeroMQ)切换到应用程序中pub/sub的AWS Simple Notification Service.这是应用程序的后端,因此应该是合理的实时.
什么是我可以期待SNS的延迟和吞吐量？
该应用程序将在EC2上托管吗？如果是这样,延迟将大大减少,因为通信渠道将通过亚马逊的连接,而不是通过互联网.
如果您打算从非EC2托管的方框调用AWS服务,这里有一个很酷的网站,它试图让您了解您与各种AWS服务和位置之间的延迟.
您如何衡量HTTP Ping请求延迟？
我们正在向PING的AWS服务端点(如EC2,SQS,SNS等)发出HTTP GET请求,并测量所有区域的观察延迟.
至于吞吐量,这取决于你.您可以使用各种策略来提高吞吐量,例如多线程,批处理消息等.
请记住,您必须编写一些副作用的代码,例如可能两次看到相同的消息(至少一次交付),并且不能依赖FIFO.
- 相当酷的网站,但我没有看到HTTP ping如何形成我的位置到SNS端点转换为服务的延迟. (6认同)
| 归档时间： |
|
| 查看次数： |
6515 次 |
| 最近记录： |