base64编码之前，记录的数据有效载荷的最大大小为1 MiB。
由于我需要处理大小可能大于1 MB的记录，因此此限制可能会成为问题。
是否有任何解决方法可以克服此限制？如果有人已经实施和使用任何经过验证的解决方案？ （我想避免“重新发明轮子”）
答案 0 :(得分：2)
您有两种选择：将有效负载分为多个记录或将其保存在流之外，例如在S3中。
对于第一个选项，您可以使用PartitionKey和SequenceNumberForOrdering（doc）。为每个源记录分配一个唯一的分区键（例如UUID）。如果需要将源分成1MB以下的块，则可以将块2..N的序列号设置为返回的上一个块的序列号。
然后，这将要求客户端检查检索到的记录的分区键，并在必要时重建原始记录。请注意，它们可能需要缓冲几个块（用于不同的源记录）。
外部化数据将简化生产者代码和使用者代码。再次，为每个源记录创建一个唯一的标识符，而不是将记录写入流中，并以该标识符作为键将其写入S3。然后将密钥写入流。当消费者从流中读取ID时，它将从S3中检索实际数据。
第二种方法确实需要更多管理：您将需要向S3添加生命周期规则以删除记录，并且需要确保该生命周期规则至少允许对象存活 ，只要保持流的有效期（由于S3便宜，我可能会设置8天的TTL，而与流的保留期无关）。
如果您只有很少的大记录，尤其是如果您有很多小记录，那么将所有内容写入S3将会效率低下。在这种情况下，您可以采用混合模型，在该模型中，您将数据结构写入包含实际数据或对外部存储的引用的流中。
答案 1 :(得分：-1)
使用 S3 方法，我能想到的最简单的解决方案是将文件存储在 S3 存储桶中。使用 Amazon S3 事件通知调用 Lambda 函数进行文件处理。当然，还会有通过生命周期管理、加密等方式删除或归档对象的额外管理。