rabbitmqの性能テストと比較、高可用性クラスタ構築

説明:ここでは簡単な圧力測定と高可用性クラスタの構想を提供した.時間の問題のため、筆者は高可用性クラスタを詳細にテストし、構築していない.

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数量を増大して、10倍増大して、毎秒大体のack数量4000/s message数量、10倍増大して不変で、生産を停止して、ただ消費を見るだけで、毎秒大体の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を単独で実行するだけです.

通常モード:デフォルトモードで、2つのノード(rabbit 01、rabbit 02)を例に説明します.Queueの場合、メッセージエンティティは1つのノードrabbit 01(またはrabbit 02)にのみ存在し、rabbit 01とrabbit 02の2つのノードは同じメタデータ、すなわちキューの構造しか存在しない.メッセージがrabbit 01ノードのQueueに入ると、consumerがrabbit 02ノードから消費すると、RabbitMQは一時的にrabbit 01、rabbit 02間でメッセージ伝送を行い、A中のメッセージエンティティを取り出してB経由でconsumerに送信する.したがってconsumerは、できるだけ各ノードに接続し、そこからメッセージを取得する必要があります.すなわち、同じ論理キューに対して、複数のノードで物理Queueを確立する.そうでなければconsumer連rabbit 01またはrabbit 02にかかわらず、出口は常にrabbit 01であり、ボトルネックが発生する.rabbit 01ノードが障害を起こした後、rabbit 02ノードはrabbit 01ノードでまだ消費されていないメッセージエンティティを取得できません.メッセージの永続化を行うと、rabbit 01ノードの回復を待たなければ消費されません.永続化がなければ,メッセージが失われる現象が生じる.

ミラーモード:必要なキューをミラーキューとし、複数のノードとRabbitMQに属するHAスキームが存在する.このモードは、クライアントがデータを取得するときに一時的に抽出するのではなく、メッセージエンティティがミラーノード間で同期する点で、実質的に通常モードとは異なる一般モードの問題を解決します.このモードがもたらす副作用も明らかであり、システム性能の低下に加えて、ミラーキューの数が多すぎて、大量のメッセージが入ると、クラスタ内部のネットワーク帯域幅がこのような同期通信によって大幅に消費される.従って信頼性に対する要求が高い場合に適用される.

haproxyベースの高可用性クラスタ

またrabbitMqの高可用性クラスタスキーム:一般クラスタ、ミラークラスタhttps://www.cnblogs.com/knowledgesea/p/6535766.htmlhaproxyベースの高可用性クラスタhttps://blog.csdn.net/h2604396739/article/details/89032338

rabbitMq,rocketMq,kafaka適用シーンコントラスト

アーキテクチャの面:Kafakaは正常なmqアーキテクチャであり、provider broker consumerを含む.kafakaはメッセージ確認メカニズムrabbitMqのbrokerがexchange、binder queueの3つの部分から構成され、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スループットは万レベルで、1桁少ない