实际生产环境Apache RocketMQ消息体过大的解决方案

这篇具有很好参考价值的文章主要介绍了实际生产环境Apache RocketMQ消息体过大的解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

官方定义消息体默认大小为 4MB,普通顺序消息类型。事务、定时、延时类消息默认大小为64KB。如果超过限制则会抛出异常!

但实际工作中,需要使用到MQ进行异步解耦,传输的业务消息偶尔会遇到超过4MB,尤其在业务复杂的系统中,那么我们应该如何处理呢?

在我工作实际应用中,有以下几种解决方案。

解决方案

方案一:消息压缩

通常我们都是传递json消息数据,然后底层使用字节流进行传输。如果此时json数据超过4MB,则可以考虑进行消息压缩。

原理其实很好理解,比如我们经常使用的压缩包,可以把大文件进行压缩,依次减小文件大小。

那么我们这里需要使用到的就是字符压缩,把json字符串进行压缩,然后进行传输,原理图如下:
rocketmq消息大小限制,精选博文,Java核心技术,java笔记分享,java-rocketmq,rocketmq,java,rabbitmq,kafka
经过测试:我们原来5MB的数据可以压缩到230KB,1MB都不到,当然效果和数据以及压缩算法有关。如:大量重复字符则压缩效率就更高。

压缩解压代码如下:

@Slf4j
public class StringCompressUtils {

    /**
     * 使用gzip压缩字符串
     *
     * @param str 要压缩的字符串
     * @return 压缩结果字符
     */
    public static String compress(String str) {
        if (str == null || str.length() == 0) {
            return str;
        }
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        GZIPOutputStream gzip = null;
        try {
            gzip = new GZIPOutputStream(out);
            gzip.write(str.getBytes());
        } catch (IOException e) {
            log.error("字符串压缩异常!", e);
            e.printStackTrace();
        } finally {
            IoUtil.close(gzip);
        }
        return new sun.misc.BASE64Encoder().encode(out.toByteArray());
    }

    /**
     * 使用gzip解压缩
     *
     * @param compressedStr 压缩字符串
     * @return 解压缩字符串
     */
    public static String uncompress(String compressedStr) {
        if (compressedStr == null) {
            return null;
        }

        byte[] compressed = null;
        String decompressed = null;
        GZIPInputStream ginzip = null;
        ByteArrayInputStream in = null;
        ByteArrayOutputStream out = new ByteArrayOutputStream();

        try {
            // 先解码
            compressed = new sun.misc.BASE64Decoder().decodeBuffer(compressedStr);
            in = new ByteArrayInputStream(compressed);
            ginzip = new GZIPInputStream(in);
            byte[] buffer = new byte[1024];
            int offset = -1;

            while ((offset = ginzip.read(buffer)) != -1) {
                out.write(buffer, 0, offset);
            }

            decompressed = out.toString();
        } catch (IOException e) {
            log.error("字符串解压缩异常!", e);
            e.printStackTrace();
        } finally {
            // 关流
            IoUtil.close(ginzip);
            IoUtil.close(in);
            IoUtil.close(out);
        }

        return decompressed;
    }

压缩流程:原始字符 -> 压缩 -> 压缩字符 -> 编码
解压流程:压缩字符 -> 解码 -> 解压 -> 原始字符

方案二:消息分割

方案一基本可以解决遇到的99%消息体过大的问题,如果不行则可以使用消息分割方案。

简而言之,就是把一个大消息体,进行分割成多个小消息体进行传输。运用了化整为零的思想,至于实现方案,有很多,我简单举个例子。

  1. 一个大消息分割成多个小消息
  2. 多个小消息拥有相同的消息标识,如UUID
  3. 分割后小消息需要有一些元数据来标识自己,如 消息标识、一共分割了多少个、自己是第几个。
  4. 传输后,消费者消费,然后根据元数据进行数据聚合还原。
  5. 将还原后的消息走正常消费流程即可

方案三:OSS存储

方案一方案二几乎已经解决99.99%的场景了,如果还是不够,那就要实施核打击了。终极方案,OSS存储!此方法绝对可以解决100%的场景!

大消息 -> 写入到文件 -> 上传到文件服务器 -> 拿到URL -> 传输 -> 消费

生产者:大消息,写入文件,上传文件,拿到访问连接,发送访问连接给MQ
消费者:消费,拿到访问链接,读取文件,拿到消息,执行业务逻辑

快准狠!短平快!就是增加了中间件,其他一点毛病没有,效率更高!文章来源地址https://www.toymoban.com/news/detail-794907.html

到了这里,关于实际生产环境Apache RocketMQ消息体过大的解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 小程序内容安全检测图片过大的解决方法

    目前微信官方对小程序的内容安全审核越发严格,几乎只要涉及到输入框或者图片选择按钮都需要接入内容安全审核,不然都没办法通过审核。文本检测很简单,只要将文字直接提交到云端进行检测就可以了,但是在接入图片的时候总会有一些问题。 今天主要说一下图片审核

    2024年02月03日
    浏览(41)
  • 关于uniapp开发h5,前端字体包过大的问题

    ui给的字体包足足23.52M,还让前端压缩,让人头大…… 我在网上找了好久,这篇文章比较靠谱,但是讲的并不仔细,文章链接: 第一步:下载安装压缩工具、没有问题 npm install -g font-spider ttc2ttf @hayes0724/web-font-converter 第二步:字体文件转换为ttf格式 # 源字体文件 otf 格式 ,注

    2024年01月21日
    浏览(73)
  • 小程序:uniapp解决主包体积过大的问题

    已经分包但还是体积过大 运行时勾选“运行时是否压缩代码”进行压缩 在 manifest.json 配置(开启分包优化) 在 app.json 配置(设置组件按需注入)

    2024年02月07日
    浏览(37)
  • 深度解析Elasticsearch索引数据量过大的优化与部署策略

    目录 ​​​​​​​ 引言 1. 分片和副本策略 1.1分片策略 1.1.1 数据量 1.1.2 查询和写入负载 1.1.3 硬件资源 1.1.4 高可用性 1.2.副本策略 1.2.1 冗余和可用性 1.2.2 查询性能 1.2.3 存储需求 2. 硬件和资源配置优化 2.1 选择高性能硬件 2.1.1 存储 2.1.2 内存 2.1.3 处理器 2.1.4 网络 2.2. JVM调

    2024年01月19日
    浏览(43)
  • 关于VMware虚拟机创建时磁盘分配过大的解决方法

     写这个文章是因为在虚拟机创建之时给的硬盘空间太大,想压缩一下,到各大论坛搜索相关帖子,发现能解决问题的太少了,所幸最后成功压缩。 接下来分享一下我压缩虚拟机硬盘空间的经验 目录 1.首先打开虚拟机右键“此电脑”→“管理”→“磁盘管理”  2.找到我们要

    2024年02月05日
    浏览(41)
  • 解决gitee仓库中 .git 文件夹过大的问题

    最近,许多项目都迁移到gitee。使用的也越来越频繁,但是今天突然收到一个仓库爆满的提示。让我一脸懵逼。本文将详细为你解答,这种情况如何处理。 我收到的报错如下: 看了下,大概意思是一个仓库体积最大不能超过1GB,但是现在我已经超过3GB了。。。 我第一个想法

    2024年02月03日
    浏览(34)
  • py脚本解决ArcGIS Server服务内存过大的问题

    在一台服务器上,使用ArcGIS Server发布地图服务,但是地图服务较多,在发布之后,服务器的内存持续处在95%上下的高位状态,导致服务器运行状态不稳定,经常需要重新启动。重新启动后重新进入这种内存高位的陷阱。 打开任务管理器发现大量 ArcSOC.exe 进程,这些进程CPU使

    2024年02月09日
    浏览(39)
  • 关于Tomcat服务器catalina.out文件过大的问题

    一、问题:当服务部署Tomcat后,运行时间久了,catalina.out文件就会越来越大,最终导致服务器磁盘空间不足,影响系统的稳定性。 二、解决方案: 1、修改Tomcat的日志配置,配置日志的级别: (1)、Tomcat日志分类: catalina:标准输出和标准出错,所有输出到这两个位置的都

    2024年02月05日
    浏览(31)
  • git仓库清理瘦身解决 .git文件夹过大的问题

    git仓库清理找了很多资料和方案都没有很完美执行成功的;现在找到一个完美方案,分享给大家;希望能帮助大家 1、gitlab代码开发了仓库开发了五年了,代码只有10M;clone的时候要700多兆很浪费时间 2、创建分支和切换分支耗时,导致电脑崩溃 3、公司内部接入codereview服务;

    2024年02月02日
    浏览(47)
  • VMware 虚拟机占用磁盘空间过大的一种解决方案

    在使用VMware虚拟机的过程中,VM会自动扩大虚拟磁盘的占用空间。发现无论是VM自带的碎片整理还是压缩,这两个操作都无法明显减少虚拟机占用空间。 现在找到一种方法可以做到这点( 可能只适用于VM workstation pro,并未测试过普通版本 ),下面是方法的整理 1.正常关闭虚拟

    2024年02月13日
    浏览(65)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包