1.MappedByteBuffer VS FileChannel 孰强孰弱？
2.Mqtt开发笔记：windows下C++ ActiveMQ客户端介绍、项目编译和使用
3.RocketMQ消息中间件从入门到高级实战教程，源码源码让你轻松掌握速来学习！分析
4.如何使用Jmeter实现MQ数据的项目发送和接收？性能测试实战篇
5.消息驱动交易系统单中心假死--ActiveMQ不生产也不消费

MappedByteBuffer VS FileChannel 孰强孰弱？

        Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相关的类，使得 Java 程序员可以抛弃基于 Stream ，从而使用基于 Block 的方式读写文件，另外，JDK 还引入了 IO 性能优化之王—— 零拷贝 sendFile 和 mmap。但他们的性能究竟怎么样？ 和 RandomAccessFile 比起来，快多少？ 什么情况下快？到底是 FileChannel 快还是 MappedByteBuffer å¿«......

        (零拷贝参考 Zero Copy I: User-Mode Perspective )

        天啊，问题太多了！！！！！！

        让我们慢慢分析。

        我们知道，Java 世界有很多 MQ：ActiveMQ，kafka，RocketMQ，去哪儿 MQ，而他们则是 Java 世界使用 NIO 零拷贝的大户。

        然而，他们的性能却大相同，抛开其他的因素，例如网络传输方式，数据结构设计，文件存储方式，我们仅仅讨论 Broker 端对文件的读写，看看他们有什么不同。

        下图是楼主查看源码总结的各个 MQ 使用的文件读写方式。

        那么，到底是 MMAP 强，还是 FileChannel 强？

        MMAP 众所周知，基于 OS 的 mmap 的内存映射技术，通过 MMU 映射文件，使随机读写文件和读写内存相似的速度。

        那 FileChannel 呢？是零拷贝吗？很遗憾，不是。FileChannel 快，只是因为他是基于 block 的。

        接下来，benchmark everything —— 徐妈.

        如何 Benchmark？ Benchmark 哪些？

        既然是读写文件，自然就要看读写性能，这是最基本的。但，注意，通常 MQ 会使用定时刷盘，防止数据丢失，MMAP 和 FileChannel 都有 force 方法，用于将 pageCache 的数据刷到硬盘上。force 会影响性能吗？ 答案是会。影响到什么程度呢？ 不知道。每次写入的数据大小会影响性能吗，毫无疑问会，但规则是什么呢？FileOutputStream 真的一无是处吗？答案是不一定。

        一直以来，文件调优都是艺术，因为影响性能的因素太多，首先，SSD 的出现，已经让传统基于 B+ tree 的树形结构产生了自我疑问，第二，每个文件系统的性能不同，Linux ext3 和 ext4 性能天壤之别（删除文件的性能差距在 倍左右）。而 Max OS 的 HFS+ 系统被 Linus 称之为“有史以来最垃圾的文件系统”，幸运的是，苹果终于在 年推送了 macOS High Sierra 和 iOS .3 系统，这个两个系统都抛弃了 HFS+，换成了性能更高的 APFS。而每个文件系统又可以设置不同的调度算法，另外，还有虚拟内存缺页中断带来的性能毛刺.......

        （tips：良心的 RocketMQ 提供了 Linux IO 调优的脚本，这点做的不错 ：）

        跑题了。

        楼主写了一个小项目，用于测试 Java MappedByteBuffer & FileChannel & RandomAccessFile & FileXXXputStream 的读写性能。大家也可以在自己的机器上跑跑看。

        CPU：intel i7 4æ ¸8线程 4.2GHz

        内存：GB DDR4

        磁盘：SSD 读写 2GB/s 左右

        JDK1.8

        OS：Mac OS ..6

        虚拟内存： 未关闭，大小 9GB

        测试注意点：

        1GB 文件：

        测试 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.

        从这张图里，我们看到，mmap 性能完胜，特别是在小数据量的情况下。其他的流，只有在4kb 的情况下，才开始反杀 mmap。因此，读 4kb 以下的数据，请使用 mmap。

        再放大看看 mmap 和 FileChannel 的比较：

        根据上图，我们看到，在写入数据包大于 4kb 以上的情况下，FileChannel 等一众非零拷贝，基本完胜 mmap，除了那个一次读 1G 文件的 BT 测试。

        因此，如果你的数据包大于 4kb，请使用 FileChannel。

        1GB 文件：

        测试 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.

        从上图，我们可以看出，mmap 性能还是一样的稳定。FileChannel 也不差，但是在 字节数据量的情况下，还差点意思。

        再看缩略图：

        我们看到，字节 是 FileChannel 和 mmap 性能的分水岭，从 字节开始，FileChannel 一路反杀，直到 BT 1GB 文件稍稍输了一丢丢。

        因此，我们建议：如果你的数据包大小在 字节以上，请使用 FileChannel 写入。

        我们知道，RocketMQ 使用异步刷盘，那么异步 force 对性能有没有影响呢？benchmark everything。我们使用异步线程，每 kb 刷盘一次，看看性能如何。

        mmap 一直落后，且性能很差，除了在 字节那里有一点点抖动，基本维持 在 左右，而没有 force 的情况下，则在 左右。而 FileChannel 则完全不受 force 的影响。在我的测试中，1GB 的文件，一次 force 需要 毫秒左右。buffer 越大，时间越多，反之则越小。

        说个题外话，Kafka 一直不建议使用 force，大概也有这个原因。当然，Kafka 还有自己的多副本策略保证数据安全。

        这里，我们得出结论，如果你需要经常执行 force，即使是异步的，也请一定不要使用 mmap，请使用 FileChannel。

        基于以上测试，我们得出一张图表：

        假设，我们的系统的数据包在 - 左右，我们应该使用什么策略？

        答：读使用 mmap，仅仅写使用 FileChannel。

        再回过头看看 MQ 的实现者们，似乎只有 QMQ 是 这么做的。当然，RocketMQ 也提供了 FileChannel 的写选项。但默认 mmap 写加异步刷盘，应该是 broker busy 的元凶吧。

        而 Kafka，因为默认不 force，也是使用 FileChannel 进行写入的，为什么使用 FileChannel 读呢？大概是因为消息的大小在 4kb 以上吧。

        这样一揣测，这些 MQ 的设计似乎都非常合理。

        最后，能不用 force 就别用 force。如果要用 force ，就请使用 FileChannel。

Mqtt开发笔记：windows下C++ ActiveMQ客户端介绍、编译和使用

       前话

       项目需求驱使我们转向 MQTT 协议的源码源码实现，由于 QtMqtt 库不支持队列模式（点对点），分析板王指标源码而只能使用订阅/发布者模式，项目我们决定采用 C++ ActiveMQ 进行开发。源码源码

       MQTT 协议

       MQTT，分析即消息队列遥测传输协议，项目是源码源码一种基于发布/订阅模式的轻量级通讯协议，IBM 在 年发布。分析其优点在于，项目以极低的源码源码代码量和带宽消耗提供即时可靠的消息服务，广泛应用于物联网、分析小型设备和移动应用。

       设计原则与特点

       MQTT 的核心特点是发布/订阅消息模式，实现一对多的消息发布，减少应用程序间的耦合。它对负载内容进行屏蔽的高效传输，基于 TCP/IP 提供网络连接，支持三种消息发布服务质量。它的小型传输、低开销和客户端异常中断机制，使其非常适合物联网领域，尤其适用于传感器与服务器间的通信，以及信息收集。

       发布/订阅者模式

       MQTT 是周期指标 源码基于客户端-服务器的消息发布/订阅传输协议，适用于受限环境，如机器与机器通信、物联网应用，特别适合传感器和服务器通信，以及小型设备的运算能力和带宽相对不足的情况。

       MQTT 服务器

       MQTT 协议中的服务器角色称为“消息代理”，可以是应用程序或设备，位于消息发布者和订阅者之间，负责数据推送。

       MQTT 协议中的方法

       MQTT 定义了一系列方法（动作），用于操作服务器上的资源，包括数据处理和生成。主要方法包括读取、写入、订阅和发布等。

       CMS 客户端

       CMS API 是一种类似 JMS 的 C++ API，用于与消息代理进行交互，如 Apache ActiveMQ，它使客户端代码更加整洁、易于维护。

       下载与编译 ActiveMQ-CPP

       下载 ActiveMQ-CPP 的最新 Windows 版本源码，推荐访问官网或 CSDN 下载页面。使用 VS 编译 ActiveMQ-CPP。

       编译步骤

       1. 解压下载的压缩文件至专用文件夹。

       2. 使用 VS 打开编译工程文件。

       3. 编译“avtivemq-cpp”时遇到“/ZI”和“/Gy-”命令行选项不兼容的错误。

       4. 通过手动更改“/Zi”和“/Gy”命令为兼容版本来解决。网页源码接口

       5. 继续编译工程生成 debug 和 release 版本。

       6. 编译通过，切换到 release 版本后，需要重新配置包含头文件属性并编译。

       编译 APR-1.7.0 库

       ActiveMQ 依赖 APR 库，其相关信息在源码根目录的 README.txt 中提供。首先下载 APR 库，解压至专用编译文件夹，使用 CMake 配置工程，生成 VS 工程文件。然后，使用 CMake 生成 APR 库，通过 VS 打开并编译工程，最终完成头文件和库文件的归类整理。

RocketMQ消息中间件从入门到高级实战教程，让你轻松掌握速来学习！

       《消息队列三部曲》的最后篇章，今日重磅推出《消息队列三部曲之RocketMQ》。在深入探讨消息队列的作用前，让我们通过一个实际案例来理解消息队列的重要性。假设我们需要实现用户注册功能，包括信息存入数据库、发送激活邮件与注册短信。采用同步方案，每步ms，总耗时ms。优化后，当天涨停源码数据库与邮件、短信并发执行，耗时降至ms。

       进一步优化，引入消息队列，数据库操作后向队列发送通知，各模块异步处理邮件与短信，实现整体任务ms完成。消息队列不仅提升了项目性能，还实现了业务模块间的解耦。至此，消息队列的作用已清晰可见。

       学习ActiveMQ、RabbitMQ后，RocketMQ的探索将较为轻松。RocketMQ在阿里巴巴高并发场景中经受多年实战考验，其性能与稳定性在众多消息队列中脱颖而出。本套视频教程内容丰富，从源码深入解读，为你揭示消息队列的精髓。

       RocketMQ的独特优势，结合《消息队列三部曲》的系统教学，构成了不可多得的消息队列经典教程。视频课程内容精心设计，情节紧凑，带你领略消息队列的奥秘。

       欲知更多详情，psd源码水印请访问课程链接。此教程将带你深入了解RocketMQ，助你提升项目性能，实现业务模块解耦。别犹豫，立即开始学习吧！分享你的学习心得，关注、点赞、收藏，共同探索消息队列的无限可能。

如何使用Jmeter实现MQ数据的发送和接收？性能测试实战篇

       JMeter是一个广泛用于性能测试的开源工具，尤其擅长压力测试。它提供了丰富的扩展插件以满足不同场景下的性能测试需求。消息队列（Message Queue，简称MQ）作为现代分布式系统中的关键组件，被大量应用在软件或程序中。在进行测试时，遇到MQ系统改造的情况，需要使用JMeter来实现MQ数据的发送和接收，以完成性能测试工作。本文将基于实际项目经验，介绍如何利用JMeter的一个扩展插件Mqmeter进行MQ性能测试。

       消息队列在分布式系统中扮演重要角色，主要解决应用耦合、异步消息和流量削峰等问题，确保高性能、高可用、可伸缩和最终一致性架构的实现。常见的MQ系统包括ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ和RocketMQ等。

       JMeter作为Apache项目下的开源性能测试工具，支持多种服务类型的测试，并允许用户通过插件扩展来满足特定的定制化需求，网络上提供了多种开源插件供测试人员使用。

       本文结合实际测试中遇到的MQ测试需求，介绍如何使用Mqmeter插件来实现对IMB MQ队列的数据发送和接收。通过Mqmeter，测试人员能够利用JMeter完成MQ的压力测试，实现MQ的多并发操作。

       为了执行性能测试，首先需要准备JMeter运行环境和Mqmeter插件。JMeter运行依赖Java环境，Maven环境用于编译Java源代码形成可执行的JAR包。本文详细说明了环境部署步骤，包括JDK安装、环境变量配置以及Maven和Mqmeter插件的安装过程。

       在环境准备完成后，进行性能测试的具体执行步骤如下：

       启动JMeter，添加线程组和取样器，选择Mqmeter作为Java请求取样器。

       填写取样器参数，包括MQ管理器名称、队列名称、等待间隔、主机名、端口号、通道名称、用户ID和密码等。

       配置参数化变量，实现向不同MQ队列发送不同消息内容的功能。

       设置汇总报告、TPS监听器、响应时间监听器等，开始性能测试。

       在测试过程中，利用Mqmeter插件进行MQ性能监控，实时查看MQ队列的深度，确保系统交易链路的可用性，并定性评估MQ本身的读写性能。通过脚本化指令，实现对MQ性能的实时监控，提高测试效率。

       总结，Mqmeter插件提供了强大的功能，帮助测试人员高效地进行MQ性能测试。本文提供的步骤和方法，旨在为从事MQ性能测试的同行提供参考，同时指出了一些可能的不足之处，如从消息队列取消息的具体方法和量化性能的详细方法，有待进一步探索和完善。

消息驱动交易系统单中心假死--ActiveMQ不生产也不消费

       面对交易系统单中心假死的挑战，运维同事迅速应对，将生产流量引导至备用中心，确保了系统在短暂停顿后的稳定运行。然而，这一事件揭示了ActiveMQ作为消息中间件的核心地位，以及在特定架构下可能出现的隐患。为了解决这一问题，我们分析了问题现象、故障证据，并逐步深入故障定位，最终找到并解决根本原因。

       一、问题现象

       系统单中心假死，ActiveMQ消息队列中积压了大量未被消费的消息，消费者无法继续消费，生产者也无法继续生产，导致大量新订单积压，影响了系统的处理效率。这一现象的出现，暴露了ActiveMQ在特定架构下的瓶颈，以及系统设计中的潜在风险。

       二、故障证据

       通过日志分析，我们发现ActiveMQ的流量控制机制触发了内存限制，导致生产者被阻塞。这表明，尽管系统配置了较大内存值，但在特定条件下，消息队列的积压仍可能引发性能问题。

       三、故障定位

       在排查过程中，我们发现ActiveMQ的内存设置存在问题，导致流量控制机制过早激活。深入分析代码后，我们发现ActiveMQ通过限制生产者在内存满载时的生产速率来避免队列积压，以及在消费者无法进行有效消费时，主动暂停生产者的生产行为，以达到平衡队列中消息的流动。然而，这一机制在我们的特定场景下未能有效发挥作用，原因在于消费者未能及时确认消费的消息，导致生产者被无限制地阻塞。

       四、问题深挖

       通过深入源码分析，我们发现ActiveMQ客户端在接收到服务端的流量控制信号后，会阻塞在等待锁的获取过程中，从而导致消费者无法确认消息已被消费，进而影响生产者的正常运行。这一问题的根源在于ActiveMQ客户端与服务端之间的通信机制，以及在特定情况下锁管理的不足。

       五、问题解决

       为了解决上述问题，我们采取了以下措施：

       1. 调整ActiveMQ的内存设置与流量控制参数，以适应系统负载变化。

       2. 对数据库执行计划进行优化，确保在不同负载下都能选取最优执行路径。

       3. 为生产者与消费者使用不同的连接，避免共享连接时的性能瓶颈与同步问题。

       通过这些措施，我们不仅解决了单中心假死的问题，还提升了系统的整体性能与稳定性，确保了交易系统的高效运行。这一事件也提醒我们，在设计和优化系统时，需要充分考虑消息中间件的特性与限制，以及系统架构的潜在风险，以确保系统的稳定与高效。