RocketMQ 메시지 필터 및 조회 실현

메시지 필터
RocketMQ 분포 식 메시지 큐 의 메시지 여과 방식 은 다른 MQ 미들웨어 와 달리 Consumer 에서 메 시 지 를 구독 할 때 메 시 지 를 걸 러 냅 니 다.
RocketMQ 가 이렇게 하 는 것 은 Producer 측 이 메 시 지 를 기록 하고 Consomer 측 구독 메 시 지 를 분리 저장 체제 로 실현 하 는 것 입 니까?Consumer 측 구독 메 시 지 는 ConsumeQueue 라 는 메시지 소비의 논리 적 대기 열 을 통 해 색인 을 받 은 다음 에 CommitLog 에서 실제 메시지 의 실체 내용 을 읽 어야 하기 때문에 결국은 저장 구 조 를 돌 릴 수 없습니다.
ConsumeQueue 의 저장 구 조 는 다음 과 같 습 니 다.8 개의 바이트 에 저 장 된 Message Tag 의 해시 값 을 볼 수 있 습 니 다.Tag 기반 메시지 여과 가 이 필드 값 을 기반 으로 합 니 다.

주로 다음 과 같은 두 가지 필터 방식 을 지원 합 니 다.
(1)태그 필터 방식:
Consumer 측은 메 시 지 를 구독 할 때 Topic 을 지정 하 는 것 외 에 도 TAG 를 지정 할 수 있 습 니 다.한 메시지 에 여러 개의 TAG 가 있 으 면||로 구분 할 수 있 습 니 다.
그 중에서 Consumer 측은 이 구독 요청 을 SubscriptionData 로 구축 하여 Pull 메 시 지 를 보 내 는 요청 을 Broker 측 에 보 냅 니 다.Broker 엔 드 는 RocketMQ 의 파일 저장 층 인 Store 에서 데 이 터 를 읽 기 전에 이 데이터 로 Message Filter 를 구축 한 다음 Store 에 전달 합 니 다.
Store 는 ConsumeQueue 에서 기록 을 읽 은 후에 기 록 된 메시지 tag hash 값 으로 필 터 를 합 니 다.서버 에서 hashcode 에 따라 판단 하기 때문에 tag 원본 문자열 을 정확하게 걸 러 낼 수 없 기 때문에 메시지 소비 단 에서 메 시 지 를 끌 어 낸 후에 소 거 된 원본 tag 문자열 을 비교 해 야 합 니 다.다 르 면 이 메 시 지 를 버 립 니 다.소식 소 비 를 하지 않다.
(2)SQL 92 의 필터 방식:
이러한 방식 의 대체적인 방법 은 위의 태그 여과 방식 과 마찬가지 로 Store 층 의 구체 적 인 여과 과정 이 다 를 뿐 진정한 SQL expression 의 구축 과 집행 은 rocketmq-filter 모듈 에서 책임 집 니 다.
필터 할 때마다 SQL 표현 식 을 실행 하면 효율 에 영향 을 미 치기 때문에 RocketMQ 는 BloomFilter 를 사용 하여 매번 실행 하 는 것 을 피 했다.SQL 92 의 표현 식 상하 문 은 메시지 의 속성 입 니 다.
메시지 조회
RocketMQ 는 다음 두 가지 차원("Message Id 에 따라 메시지 조회","Message Key 에 따라 메시지 조회")에 따라 메시지 조 회 를 지원 합 니 다.
MessageId 에 따라 메시지 조회
RocketMQ 의 MessageId 길 이 는 모두 16 바이트 로 메시지 저장 호스트 주소(IP 주소 와 포트),메시지 Commit Log offset 이 포함 되 어 있 습 니 다.
"MessageId 에 따라 메 시 지 를 조회 합 니 다"RocketMQ 에서 구체 적 인 방법 은 클 라 이언 트 측 이 MessageId 에서 Broker 의 주소(IP 주소 와 포트)와 Commit Log 의 오프셋 주 소 를 분석 한 후 RPC 요청 으로 봉 인 된 후 Remoting 통신 층 을 통 해 보 냅 니 다(업무 요청 코드:VIEWMESSAGE_BY_ID）。
Broker 는 Query MessageProcessor 를 가 고 있 습 니 다.메 시 지 를 읽 는 과정 에서 commitLog offset 과 size 로 commitLog 에서 진정한 기록 을 찾 아 완전한 메시지 로 해석 합 니 다.
Message Key 에 따라 메시지 조회
"Message Key 에 따라 정 보 를 조회 합 니 다"는 주로 RocketMQ 의 Index File 색인 파일 을 기반 으로 이 루어 집 니 다.RocketMQ 의 색인 파일 논리 구 조 는 JDK 에서 HashMap 의 실현 과 유사 합 니 다.
색인 파일 의 구체 적 인 구 조 는 다음 과 같다.

Index File 색인 파일 은 사용자 에 게"Message Key 에 따라 메 시 지 를 조회 합 니 다"라 는 메시지 색인 조회 서 비 스 를 제공 합 니 다.Index File 파일 의 저장 위 치 는$HOME\store\\index\${fileName}입 니 다.파일 이름 fileName 은 생 성 된 시간 스탬프 로 이름 이 붙 어 있 으 며 파일 크기 는 40+500 W\*4+2000 W\*20=4200000040 바이트 크기 와 같 습 니 다.
메시지 의 properties 에 UNIQ 가 설정 되 어 있다 면KEY 이 속성 은 topic+"\#"+UNIQKEY 의 value 는 key 로 기록 작업 을 합 니 다.
메시지 가 KEYS 속성(여러 개의 KEY 를 빈 칸 으로 구분)을 설정 하면 topic+'\#'+KEY 로 색인 을 만 듭 니 다.
이 중 색인 데 이 터 는 Key Hash/CommitLog Offset/Timestamp/nextIndex offset 네 필드 를 포함 하여 모두 20 Byte 입 니 다.
NextIndex offset 은 앞에서 읽 은 slotValue 입 니 다.hash 충돌 이 있 으 면 이 필드 로 모든 충돌 색인 을 링크 로 연결 할 수 있 습 니 다.
Timestamp 는 메시지 store Timestamp 간 의 차 이 를 기록 하 는 것 이지 절대적 인 시간 이 아니다.전체 Index File 의 구 조 는 그림 과 같 습 니 다.40 Byte 의 Header 는 전체 통계 정 보 를 저장 하 는 데 사 용 됩 니 다.4\*500 W 의 Slot Table 은 실제 색인 데 이 터 를 저장 하지 않 고 각 슬롯 에 대응 하 는 단 방향 링크 의 머리 를 저장 합 니 다.
20\*2000 W 는 진정한 색인 데이터 입 니 다.즉,하나의 Index File 은 2000 W 개의 색인 을 저장 할 수 있 습 니 다.
"Message Key 에 따라 메 시 지 를 조회 합 니 다"라 는 방식 으로 RocketMQ 의 구체 적 인 방법 은 주로 Broker 엔 드 의 Query Message Processor 비 즈 니스 프로 세 서 를 통 해 메 시 지 를 조회 하고 메 시 지 를 읽 는 과정 은 topic 과 key 로 Index File 색인 파일 의 기록 을 찾 는 것 입 니 다.그 중의 commitLog offset 에 따라 CommitLog 파일 에서 메시지 의 실체 내용 을 읽 습 니 다.
이상 은 개인 적 인 경험 이 므 로 여러분 에 게 참고 가 되 기 를 바 랍 니 다.여러분 들 도 저 희 를 많이 응원 해 주시 기 바 랍 니 다.