我有一个用例,将有数据流到来,我不能以相同的速度消费它,需要一个缓冲区。这可以使用SNS-SQS队列来解决。我后来才知道,Kinesis解决了同样的目的,所以有什么不同?为什么我应该喜欢(或不应该喜欢)运动?
当前回答
Kinesis解决了流数据典型的映射缩减场景中的映射部分问题。而SQS并不确定这一点。如果你有需要在一个键上聚合的流数据,kinesis可以确保该键的所有数据都到一个特定的分片,并且该分片可以在单个主机上使用,这使得在键上的聚合比SQS更容易
其他回答
我还要补充一件没人提到过的事情——SQS要贵几个数量级。
对我来说,最大的优势是Kinesis是一个可重玩的队列,而SQS不是。因此,您可以有多个Kinesis的相同消息的消费者(或在不同时间的相同消费者),而在SQS中,一旦消息被ack,它就从队列中消失了。 因此,SQS更适合工作者队列。
Kinesis支持多消费者功能,这意味着相同的数据记录可以在同一时间或24小时内不同的时间在不同的消费者处处理,SQS中的类似行为可以通过写入多个队列实现,消费者可以从多个队列中读取。然而,再次写入多个队列将在系统中增加几秒(几毫秒)的延迟。
其次,Kinesis提供了路由功能,可以使用分区键将数据记录选择性地路由到不同的分片,这些分区键可以由特定的EC2实例处理,并可以启用微批处理计算{计数和聚合}。
使用任何AWS软件都很容易,但使用SQS是最简单的。使用Kinesis,需要提前提供足够的碎片,动态增加碎片数量以管理尖峰负载,并减少以节省管理所需的成本。这是运动的疼痛,SQS不需要这样的事情。SQS是无限可伸缩的。
Kinesis解决了流数据典型的映射缩减场景中的映射部分问题。而SQS并不确定这一点。如果你有需要在一个键上聚合的流数据,kinesis可以确保该键的所有数据都到一个特定的分片,并且该分片可以在单个主机上使用,这使得在键上的聚合比SQS更容易
In very simple terms, and keeping costs out of the picture, the real intention of SNS-SQS are to make services loosely coupled. And this is only primary reason to use SQS where the order of the msgs are not so important and where you have more control of the messages. If you want a pattern of job queue using an SQS is again much better. Kinesis shouldn't be used be used in such cases because it is difficult to remove messages from kinesis because kinesis replays the whole batch on error. You can also use SQS as a dead letter queue for more control. With kinesis all these are possible but unheard of unless you are really critical of SQS.
如果你想要一个好的分区,那么SQS将不会有用。
推荐文章
- 如何查看所有地区所有正在运行的Amazon EC2实例?
- 如何从命令行使用多个AWS帐户?
- 如何搜索亚马逊s3桶?
- 拒绝访问;您需要(至少一个)SUPER特权来执行此操作
- 我如何使用通配符“cp”一组文件与AWS CLI
- 我如何获得亚马逊的AWS_ACCESS_KEY_ID ?
- 如何使所有对象在AWS S3桶公共默认?
- 为什么我应该使用亚马逊Kinesis而不是SNS-SQS?
- 如何重命名AWS S3 Bucket
- AWS ECS中的任务和服务之间有什么区别?
- 亚马逊SimpleDB vs亚马逊DynamoDB
- 亚马逊ECS和亚马逊EC2有什么区别?
- 我如何知道我在S3桶中存储了多少对象?
- S3 Bucket操作不应用于任何资源
- 将AWS凭证传递给Docker容器的最佳方法是什么?