rabbitmq的性能测试与对比，高可用集群搭建

最新推荐文章于 2023-05-31 10:45:23 发布

深山猿

最新推荐文章于 2023-05-31 10:45:23 发布

阅读量3.6k

点赞数

分类专栏： mq mq 文章标签： rabbitmq 高可用性能

本文链接：https://blog.csdn.net/h2604396739/article/details/89032148

版权

mq 同时被 2 个专栏收录

10 篇文章 1 订阅

订阅专栏

8 篇文章 0 订阅

订阅专栏

说明：这里提供了简单的压测与高可用集群思路，因为时间问题，笔者并没有详细测试并搭建高可用集群。

rabbitMq压测方案

rabbitmq压测性能代码

public class Send2 {
    //消息队列名称
    private final static String QUEUE_NAME = "helloword2";

    public static void main(String[] args) throws Exception {
        /**
         * 创建连接连接到MabbitMQ 
         */
        ConnectionFactory factory = new ConnectionFactory();
        //设置MabbitMQ所在主机ip或者主机名  
        factory.setHost("127.0.0.1");
        //指定用户 密码
        factory.setUsername("springcloud");
        factory.setPassword("springcloud");
        //指定端口
        factory.setPort(AMQP.PROTOCOL.PORT);
        //创建一个连接
        Connection connection = factory.newConnection();
        //创建一个频道  
        Channel channel = connection.createChannel();
        //指定一个队列  
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        //发送的消息  
        String message = "hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!";
//        String message = "hello world!";
        //往队列中发出一条消息
        channel.basicPublish("", QUEUE_NAME, null, message.getBytes());

        for(int i=0;i<3000000;i++){
            channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
        }
        //关闭频道和连接
        channel.close();
        connection.close();
    }
}

就是不断的写入消息

启动消费者代码，然后启动上面的生产者，queue不同，看合计每秒大概的ack数量，我的mac大概12000条/s
增大message体量，增大十倍，每秒大概的ack数量4000/s
message体量，增大十倍不变，停止生产，单独看消费，每秒大概的ack数量7000/s
然后看停止消费者，单纯写入，写入速度40000/s,但是好像不稳定，有时会出现几千每秒。
可以借鉴https://www.cnblogs.com/yulia/p/6369894.html

采用jmeter进行压测可以参考
https://www.cnblogs.com/xpp142857/p/8457068.html或
jmeter的安装与使用
https://www.cnblogs.com/dyh2025/p/9461964.html ---jmeter的使用
https://www.cnblogs.com/by-dream/p/5611555.html

rabbitMq集群类别与搭建方案

单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已。
普通模式：默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。
镜像模式:把需要的队列做成镜像队列，存在与多个节点属于RabbitMQ的HA方案。该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。
基于haproxy的高可用集群

还有rabbitMq的高可用集群方案：
普通集群、镜像集群 https://www.cnblogs.com/knowledgesea/p/6535766.html
基于haproxy的高可用集群 https://blog.csdn.net/h2604396739/article/details/89032338

rabbitMq,rocketMq，kafaka适用场景对比

架构方面：
Kafaka是正常的mq架构，包括provider broker consumer。，kafaka没有消息确认机制
rabbitMq 中的broker由exchange、binder queue三部分组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费，rabbit有消息确认机制

吞吐量方面：
Kafaka采用zero-copy方式，即数据存储和获取是本地磁盘顺序批量操作，具有O（1）复杂度，数据处理效率很高
RabbitMq在吞吐量方面不如kafaka，RabbitMq支持对消息可靠的传递，支持事务，不支持批量的操作。

可用性方面
Kafaka的broker采用主备模式，所以可用性很高
RabbitMq支持miror queue，主queue失效，minor queue生效

集群负载方面
Kafaka使用zookeeper实现负载均衡，zookeeper管理集群中的broker sonsumer，通过zookeeper的协调机制，producer会记录topic对应的broker，对broker进行轮询或者随机访问broker，实现负载均衡
RabbitMq需要单独自定义负载均衡

消息准确性方面
kafaka不支持事务，对消息的重复、丢失、错误没有严格要求；rabbitMq采用AMQP协议，AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景

rabbitMq,rocketMq对比
rabbitmq整体更稳定，延迟更小
rabbitMq社区更活跃
rabbitmq管理界面更好
rabbitmq吞吐量为万级别，少一个量级