동시성이 높은 쓰기를 위한 커밋로그 메모리 기반 최적화
우선, Commitlog는 순차 디스크 쓰기를 사용하여 디스크에 데이터를 쓰기 때문에 성능이 크게 향상됩니다.
그러나 디스크 순차 쓰기만으로는 쓰기 성능 개선에 한계가 있으므로 매핑 파일 메모리 매핑 메커니즘, 즉 메시지 데이터를 먼저 메모리에 쓴 다음 메모리에서 디스크로 비동기적으로 플러시하는 방식이 여전히 사용되므로 디스크 순차 쓰기는 메모리 쓰기 작업에 더욱 최적화되어 있습니다.
그런 다음 아래 빨간색과 같이 메모리 매핑을 통해 쓰기 프로세스가 최적화됩니다:
요약:
따라서 여기에서는 디스크 순차 쓰기를 기반으로 매핑 파일 매핑 메커니즘을 추가하여 파일 성능을 더욱 향상시켜 메모리 쓰기에 디스크 순차 쓰기를 최적화합니다!
JVM 오프햅 기반 메모리 읽기/쓰기 분리 메커니즘
브로커 바쁨 문제
일반적으로 자바 애플리케이션이 서버에 배포된 후 애플리케이션은 서버에서 jvm 프로세스로 실행되며, 이 시점에서 메모리는 일반적으로 세 가지 유형으로 나뉩니다:
- JVM 힙 메모리: JVM에 의해 관리됨
- 오프햅 메모리: JVM 힙 외부의 메모리
- 페이지 캐시: 운영 체제에서 관리하는 메모리
그러면 메모리의 페이지 캐시에 메시지를 쓰면 메시지 쓰기 성능이 크게 향상될 수 있지만, 동시성이 높은 시나리오에서는 브로커가 너무 바빠서 일부 작업이 차단될 수 있는데, 이는 높은 동시성에서 많은 수의 읽기/쓰기 작업이 메모리에 매핑된 Commitlog 디스크 파일의 동일한 페이지 캐시에 동시에 쓰기 작업을 수행하여 경쟁에서 페이지 캐시를 너무 치열하게 사용하게 되기 때문입니다. 동시성이 높으면 메모리에 매핑된 Commitlog 디스크 파일의 동일한 페이지 캐시에서 많은 수의 읽기 및 쓰기 작업이 수행되어 이 페이지 캐시를 사용하기 위한 경쟁이 너무 치열해지기 때문입니다.
RocketMQ는 메모리 수준의 읽기/쓰기 분리를 허용하는 브로커 사용 중 문제를 해결하기 위한 transientStorePoolEnabled; 메커니즘을 제공합니다.
즉, 브로커에 쓰여진 동시성이 높은 메시지에서 메시지는 먼저 JVM의 힙 외 메모리에 쓰여지고, 백그라운드 스레드가 메시지를 페이지 캐시의 메모리로 브러시하기 위해 시간이 정해지며, 이때 JVM의 힙 외 메모리에 대한 쓰기의 동시성이 높은 MappedFile의 페이지 캐시와 소비자의 동시성이 높은 읽기 작업의 경우 최종적으로 MappedFile의 페이지 캐시에 기록됩니다. 소비자의 동시성이 높은 읽기 작업은 결국 MappedFile의 페이지 캐시에 저장되므로 동시성이 높은 읽기와 쓰기가 분리됩니다.
즉, 이 메커니즘은 높은 동시성 읽기-쓰기 분리를 달성하고, 소비자 높은 동시성 읽기는 읽기 큐에서 데이터를 읽고, 궁극적으로 높은 동시성 읽기는 transiendStorePoolEnabled 속해야 하며, 생산자 높은 동시성 쓰기는 jvm 오프헤프 오프 힙 메모리로 직접 향하는 반면, 다음과 같이 MappedFile 페이지 캐시 높은 동시성 경합 문제가 발생하지 않습니다. 그림의 보라색 부분:
시스템 설계 수준 고려 사항을 기반으로 합니다:
트랜시엔드스토어풀 활성화 메커니즘을 사용하면 동시 접속이 많은 시나리오에서 브로커의 읽기 및 쓰기 성능을 향상시킬 수 있지만, 이로 인해 일부 데이터 손실이 발생할 수 있습니다!
이 메커니즘 하에서 데이터는 먼저 jvm 오프 힙, 즉 오프 힙 메모리에 쓰여지게 되고, jvm 프로세스가 중단되면 MappedFile 페이지 캐시로 브러시 할 시간이 있기 전에 데이터의 jvm 오프 힙이 손실되어 jvm 프로세스가 중단될 확률이 상당히 높기 때문에 이 메커니즘은 데이터의 어느 정도의 신뢰성을 희생하여 jvm 프로세스의 성능을 향상시키고 있습니다. 성능 향상을 위해!
MappedFile MappedFile 페이지 캐시
