base64 编码前记录的数据负载最大尺寸为 1 MiB。
由于我需要处理大小可能大于 1 MB 的记录，因此此限制可能是一个问题。
有什么解决方法可以克服这个限制吗？如果任何人已经实施和使用任何经过验证的解决方案？ （我想避免“重新发明轮子”）
您有两种选择：将有效负载分成多个记录或将其保存在流外部，例如保存在 S3 中。
对于第一个选项，您可以使用
PartitionKeySequenceNumberForOrdering然后，这将要求客户端检查检索到的记录的分区键，并在必要时重建原始记录。请注意，他们可能需要缓冲多个块（针对不同的源记录）。
外部化数据将简化生产者和消费者代码。再次，为每个源记录创建一个唯一标识符，但不是将记录写入流，而是使用该标识符作为其键将其写入 S3。然后将密钥写入流中。当消费者从流中读取 ID 时，将从 S3 检索实际数据。
第二种方法确实需要更多的管理：您需要向 S3 添加生命周期规则来删除记录，并且您需要确保此生命周期规则让对象至少只要流的存在时间就存在。保留期（无论流保留期如何，我可能会设置 8 天的 TTL，因为 S3 很便宜）。
如果您只有不常见的大记录，特别是如果您有大量小记录，那么将所有内容写入 S3 的效率将会很低。在这种情况下，您可以采用混合模型，在该模型中，您可以将数据结构写入流，其中包含实际数据或对外部存储的引用。
您可以采取的其他方法是，在两者之间使用转换 lambda。所以你可以做的步骤是。发送大消息到 S3，然后让转换 lambda 读取 S3 指针并获取实际消息。
Firehose仅在Put时有硬限制，转换后就没有这样的限制。
此方法已经过验证和测试。
注意：通过此方法，您会将当前限制从 1MB 更改为 6MB。由于 Lambda 响应大小硬限制，上限为 6MB。