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로 메시지 수량을 늘리고 10배, 초당 대략적인 ack 수량은 4000/s로 메시지 수량을 늘린다. 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를 단독으로 실행할 뿐이다.

일반 모드: 기본 모드로 두 노드(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.htmlhaproxy 기반의 고가용 집단https://blog.csdn.net/h2604396739/article/details/89032338
rabbitMq, rocketMq, kafaka 적용 장면 비교
구조면: Kafaka는 정상적인 mq 구조로provider broker consumer를 포함합니다.kafaka는 메시지 확인 메커니즘이 없는rabbitMq의broker는 exchange,binderqueue 세 부분으로 구성되어 있는데 그 중에서 exchange와binding은 메시지의 루트 키를 구성한다.클라이언트 프로듀서는 채널과 서버를 연결하여 통신을 하고,Consumer는queue에서 메시지를 받아 소비하고,rabbit는 메시지 확인 메커니즘이 있습니다
토출량 측면: Kafaka는 zero-copy 방식을 사용한다. 즉, 데이터 저장과 획득은 로컬 디스크 순서의 대량 작업이고 O(1)의 복잡도를 가진다. 데이터 처리 효율이 매우 높고 RabbitMq는 토출량 면에서 Kafaka보다 못하다. RabbitMq는 메시지에 대한 신뢰할 수 있는 전달을 지원하고 사무를 지원하며 대량 조작을 지원하지 않는다.
가용성 측면에서 Kafaka의 브로커는 기본 모드를 사용하기 때문에 가용성이 매우 높습니다. RabbitMq는 miror queue를 지원하고 주queue가 효력을 상실하고 minor queue가 적용됩니다.
집단 부하의 경우 Kafaka는 zookeeper를 사용하여 부하 균형을 실현한다. zookeeper는 집단 중의 broker sonsumer를 관리한다. zookeeper의 조율 메커니즘을 통해 Producer는 topic에 대응하는 broker를 기록하고 broker에 대해 윤문하거나 무작위로 broker를 방문한다. 부하 균형을 실현하려면 RabbitMq는 부하 균형을 단독으로 사용자 정의해야 한다.
메시지의 정확성에 있어서 카파카는 업무를 지원하지 않고 메시지의 중복, 분실, 오류에 대해 엄격한 요구가 없다.rabbitMq는 AMQP 프로토콜을 사용하고 AMQP 프로토콜은 기업 시스템에서 더 많이 사용되며 데이터의 일치성, 안정성과 신뢰성에 대한 요구가 높은 장면이다.
rabbitMq,rocketMq는 rabbitmq보다 전체적으로 안정적이고 지연이 적습니다. rabbitMq 커뮤니티가 더욱 활발합니다. rabbitmq 관리 인터페이스가 더욱 좋습니다. rabbitmq의 토출량은 만 레벨이고 한 량급이 적습니다.