SQS
- 对于应用解耦（Decouple）能够很好的提供弹性和消除流量尖峰的作用
- SQS有自己的Access Policy来规定谁有权限读取或写入Queue
- 有Standard和FIFO模式
- Standard模式有无限的TPS，而且提供“至少一次”消息传递保证，这意味着消息可能会被重复传递，也不保证消息唯一性，所以适合拿来做日志的处理，可以容忍一定程度的消息重复
- FIFO模式，顺序先进先出的消息模式，保证消息的唯一性，适合用于订单处理，金融交易，消息通知
- FIFO可以保证消息唯一性，可以根据Message ID在整个Queue或是在Message Group当中保持唯一性（Deduplication）
SQS – Message Visibility Timeout
- 当一个消息被一个consumer读取的时候，其他的consumer就无法读取相同的消息，必须消息重复执行
- Visibility Timeout设置太短的话在消息还没执行完就被其他consumer给读取了，设置太长的话如果consumer崩溃需要等待消息重新出现在Queue当中就必须花费更长的时间来等待了
SQS – Long Polling
- 当没有消息可供消费者接收时，SQS的接收操作将立即返回空响应。这种情况下，如果消费者需要频繁地检查队列以查看是否有新消息，可能会产生不必要的请求开销
- Long Polling通过延长接收操作的超时时间来解决这个问题。当使用Long Polling时，如果队列中没有消息可供接收，接收操作将保持打开状态，直到有消息可供消费或者达到设定的超时时间。这样做可以减少对队列的轮询请求，降低了对SQS服务的负载，并且减少了消费者的请求成本
- Long Polling可以设定1-20秒，基本上是越长越好
SQS With Auto Scaling Group (ASG)
- 可以用CloudWatch Metric来监控Queue的数量，如果达到一定的量就报Alarm，然后告诉ASG进行集群扩容，反之就是缩容
SNS
- 是Pub / Sub的运作机制
- 有FIFO和Standard模式（和SQS一样）
- 订阅的方式有Email，SMS，HTTP，Lambda, SQS, Kinesis Data Firehose
- 有自己的Access Policy来规定谁能够public message到SNS，或是Subscribe Message
- 如果你的程序需要发送多个SQS的话，担心程序崩溃无法做到一致性的话，可是把消息传送到SNS先，然后分发到SQS
- 可以使用S3 Event进行监听，然后往SNS发送消息，来生产thumbnail或是图片压缩
- 可以结合Kinesis Data Firehose来进行大数据的传输
SNS – Message Filtering
- 是一个Json格式来把消息进行过滤，然后再把特定的消息给特定的订阅者，如果没有filter的话，那么所有的消息都会分发给订阅者
Facebook评论