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

ゝ一世哀愁。 2022-02-24 18:53 366阅读 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方案][RabbitMQ_HA]。**该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。
 *  基于haproxy的高可用集群

还有rabbitMq的高可用集群方案：  
普通集群、镜像集群  https://www.cnblogs.com/knowledgesea/p/6535766.html  
基于haproxy的高可用集群  [https://blog.csdn.net/h2604396739/article/details/89032338][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吞吐量为万级别，少一个量级

[RabbitMQ_HA]: http://www.rabbitmq.com/ha.html
[https_blog.csdn.net_h2604396739_article_details_89032338]: https://blog.csdn.net/h2604396739/article/details/89032338