Kinesis 是否适合我的需求？ （和其他各种问题）

Question

我需要在高峰时每秒处理 100 条记录。这些记录是简单的 JSON 主体，应该收集它们，然后处理/转换为数据库。

几个问题...

1) Kinesis 适合这个吗？还是 SQS 更适合？

2) 使用 kinesis 时，我是否要使用此处所示的 python 示例：https://aws.amazon.com/blogs/big-data/snakes-in-the-stream-feeding-and-eating-amazon-kinesis-streams-with-python/ 还是应该在 KCL 中实现我的生产者和消费者？有什么区别？

3) Kinesis 是否为消费者的管理提供任何服务，还是我只是在 EC2 实例上运行它们并自己管理它们？

4) 访问数据的正确模式是什么 - 我不能错过任何记录，所以我假设我将从“TRIM_HORIZON”而不是“LATEST”获取记录。如果是这样，我如何管理重复项？换句话说，我的消费者如何从流中获取记录并处理宕机的消费者等，并且始终知道他们正在获取所有记录？

谢谢！

Answer 1

1. Kinesis 更适用于流式传输数据或当您需要消息之间的严格排序时。另一方面，您的用例似乎更像是两个服务之间的缓冲解决方案。所以，我更喜欢 SQS 而不是 Kinesis。 SQS 也更便宜、更易于使用，并且应该可以轻松处理您所需的规模。
2. 您分享的示例使用了 Kinesis 的低级 API。但是，您应该更喜欢使用 KPL 和 KCL 分别实现您的生产者和消费者，因为它们提供了更易于使用的更高级别的构造。
3. 您可以在 EC2 或 Lambda 上同时运行 Kinesis 和 SQS 生产者和消费者。在后者中，AWS 将负责您的硬件管理。
4. 是的，你应该选择TRIM_HORIZON。如果您的数据中有重复项，您的消费者应该通过自己进行一些簿记来处理它们。至于消费者倒下等情况，KCL 都会优雅地处理。