另一件事:Kinesis可以触发Lambda，而SQS不能。因此，对于SQS，您要么必须提供一个EC2实例来处理SQS消息(并在失败时处理它)，要么必须有一个预定的Lambda(它不能扩大或缩小—每分钟只能得到一个)。

编辑:这个答案不再正确。自2018年6月起，SQS可以直接触发Lambda

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

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将不会有用。

Kinesis用例

日志和事件数据收集 实时分析 移动数据采集 “物联网”数据馈送

SQS用例

应用程序集成 解耦microservices 将任务分配给多个工作节点 将实时用户请求与密集的后台工作分离 批处理消息以供将来处理

另一件事:Kinesis可以触发Lambda，而SQS不能。因此，对于SQS，您要么必须提供一个EC2实例来处理SQS消息(并在失败时处理它)，要么必须有一个预定的Lambda(它不能扩大或缩小—每分钟只能得到一个)。

编辑:这个答案不再正确。自2018年6月起，SQS可以直接触发Lambda

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

摘自AWS文档:

We recommend Amazon Kinesis Streams for use cases with requirements that are similar to the following: Routing related records to the same record processor (as in streaming MapReduce). For example, counting and aggregation are simpler when all records for a given key are routed to the same record processor. Ordering of records. For example, you want to transfer log data from the application host to the processing/archival host while maintaining the order of log statements. Ability for multiple applications to consume the same stream concurrently. For example, you have one application that updates a real-time dashboard and another that archives data to Amazon Redshift. You want both applications to consume data from the same stream concurrently and independently. Ability to consume records in the same order a few hours later. For example, you have a billing application and an audit application that runs a few hours behind the billing application. Because Amazon Kinesis Streams stores data for up to 7 days, you can run the audit application up to 7 days behind the billing application. We recommend Amazon SQS for use cases with requirements that are similar to the following: Messaging semantics (such as message-level ack/fail) and visibility timeout. For example, you have a queue of work items and want to track the successful completion of each item independently. Amazon SQS tracks the ack/fail, so the application does not have to maintain a persistent checkpoint/cursor. Amazon SQS will delete acked messages and redeliver failed messages after a configured visibility timeout. Individual message delay. For example, you have a job queue and need to schedule individual jobs with a delay. With Amazon SQS, you can configure individual messages to have a delay of up to 15 minutes. Dynamically increasing concurrency/throughput at read time. For example, you have a work queue and want to add more readers until the backlog is cleared. With Amazon Kinesis Streams, you can scale up to a sufficient number of shards (note, however, that you'll need to provision enough shards ahead of time). Leveraging Amazon SQS’s ability to scale transparently. For example, you buffer requests and the load changes as a result of occasional load spikes or the natural growth of your business. Because each buffered request can be processed independently, Amazon SQS can scale transparently to handle the load without any provisioning instructions from you.

Kinesis支持多消费者功能，这意味着相同的数据记录可以在同一时间或24小时内不同的时间在不同的消费者处处理，SQS中的类似行为可以通过写入多个队列实现，消费者可以从多个队列中读取。然而，再次写入多个队列将在系统中增加几秒(几毫秒)的延迟。

其次，Kinesis提供了路由功能，可以使用分区键将数据记录选择性地路由到不同的分片，这些分区键可以由特定的EC2实例处理，并可以启用微批处理计算{计数和聚合}。

使用任何AWS软件都很容易，但使用SQS是最简单的。使用Kinesis，需要提前提供足够的碎片，动态增加碎片数量以管理尖峰负载，并减少以节省管理所需的成本。这是运动的疼痛，SQS不需要这样的事情。SQS是无限可伸缩的。