你可以对消息正文进行gzip压缩,但是SNS消息正文仅支持UTF-8字符数据。gzip数据是二进制的,因此它与SNS不直接兼容,因为不是每个可能的字节序列也都是有效的UTF-8字符序列。所以,在对负载进行gzip压缩后,您需要使用诸如base-64之类的方案对该二进制数据进行编码。Base-64对任意二进制数据(每字节8位)仅使用64个符号(即2^6,每字节有效6位),因此通过此编码,字节数膨胀了8/6(133%)。这意味着192KB的二进制数据编码为256KB的base-64编码数据,因此在gzip之后,您的消息的最大允许大小变为192K(因为SNS限制为256KB)。但是所有的base-64符号都是有效的单字节UTF-8字符,这是为什么尽管它会增加大小,但这种编码如此常用的一个重要原因。另外,gzip通常具有远高于1.33:1的压缩比(这是gzip + base-64的平衡点)。但是,如果您的消息将被gzip压缩到192K或更低,则这绝对可以与SNS一起使用(SQS也是如此,它具有相同的字符集和大小限制)。
你已经看过这个了吗?https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html 如果您认为文件可能会随时间增加,我建议采用另一种方法。将文件放在S3存储桶中,并将S3事件通知附加到SNSTopic,以便所有消费者在准备处理新文件时都会收到通知。 换句话说,SNS的消息将是文件的位置,而不是文件本身。 好好想想。
你还可以使用SNS/SQS扩展客户端库来处理较大的消息负载。 https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-sns-launches-client-library-supporting-message-payloads-of-up-to-2-gb