분산 시스템 코어 로그 상세 소개(그림 및 텍스트)

이 글은 분산 시스템 코어 로그에 대한 자세한 소개(그림 및 텍스트)를 제공합니다. 필요한 친구들이 참고할 수 있기를 바랍니다.

로그란 무엇인가요?

로그는 시간순으로 추가된 완전한 순서의 레코드입니다. 실제로는 특수한 파일 형식입니다. , 파일은 바이트 배열이고, 여기의 로그는 기록 데이터이지만, 파일에 비하면 여기의 각 기록은 상대적인 시간순으로 배열되어 있다는 점에서 로그가 가장 간단한 저장 모델이라고 할 수 있습니다. 예를 들어, 메시지 대기열은 일반적으로 로그 파일을 선형적으로 기록하고 소비자는 오프셋부터 순차적으로 읽습니다.

로그 자체의 고유한 특성으로 인해 레코드는 왼쪽에서 오른쪽으로 순차적으로 삽입됩니다. 이는 왼쪽의 레코드가 오른쪽의 레코드보다 "오래된" 레코드라는 의미입니다. 시스템 시계에 의존할 필요가 없습니다. 이 기능은 분산 시스템에 매우 중요합니다.

로그 애플리케이션

데이터베이스에 애플리케이션 로그# 🎜🎜 #

로그가 언제 등장했는지는 알 수 없습니다. 개념상 너무 단순할 수도 있습니다. 데이터베이스 분야에서 로그는 MySQL의 리두 로그와 같이 시스템이 충돌할 때 데이터와 인덱스를 동기화하는 데 더 많이 사용됩니다. 리두 로그는 시스템이 충돌할 때 데이터의 정확성과 완전성을 보장하는 데 사용되는 디스크 기반 데이터 구조입니다. 예를 들어, 작업을 실행하는 동안 리두 로그가 먼저 작성된 다음 실제 변경 사항이 적용됩니다. 이렇게 하면 시스템이 충돌 후 복구될 수 있습니다. 다시 실행 로그를 기반으로 다시 작성하여 데이터를 복원합니다(초기화 프로세스 중에는 현재 클라이언트 연결이 없습니다). 로그는 데이터베이스 마스터와 슬레이브 간의 동기화에도 사용할 수 있습니다. 기본적으로 데이터베이스의 모든 작업 기록이 로그에 기록되기 때문에 마스터를 달성하려면 슬레이브에 로그를 동기화하고 슬레이브에서 재생하기만 하면 됩니다. -슬레이브 동기화. 여기서는 리두 로그를 구독하여 데이터베이스의 모든 변경 사항을 얻을 수 있으며 이를 통해 감사, 캐시 동기화 등과 같은 개인화된 비즈니스 로직을 구현할 수 있습니다.

분산 시스템에서 로그 적용

#🎜 🎜# 분산 시스템 서비스는 본질적으로 상태 변경에 관한 것이며, 이는 상태 머신으로 이해될 수 있습니다. 일관된 입력이 주어지면 두 개의 독립적인 프로세스(시스템 시계, 외부 인터페이스 등과 같은 외부 환경에 의존하지 않음)가 일관된 결과를 생성합니다. 궁극적으로 일관된 상태를 유지하며 로그는 고유한 순서로 인해 시스템 시계에 의존하지 않으므로 변경 순서 문제를 해결하는 데 사용할 수 있습니다.

우리는 이 기능을 사용하여 분산 시스템에서 직면하는 많은 문제를 해결합니다. 예를 들어 RocketMQ의 대기 노드에서는 메인 브로커가 클라이언트의 요청을 받아 로그를 기록한 후 이를 슬레이브에 실시간으로 동기화하여 마스터가 전화를 끊으면 슬레이브가 이를 계속해서 재생할 수 있습니다. 쓰기 요청을 거부하고 읽기 요청을 계속하는 등 요청을 처리합니다. 로그는 데이터를 기록할 수 있을 뿐만 아니라 SQL 문과 같은 작업을 직접 기록할 수도 있습니다.

로그는 일관성 문제를 해결하기 위한 핵심 데이터 구조입니다. 로그는 일련의 작업과 같습니다. 널리 사용되는 Paxos, Raft 프로토콜은 모두 로그를 기반으로 구축된 일관성 프로토콜입니다.

Message Queue의 로그 적용

로그를 사용하면 각 데이터의 유입 및 유출을 쉽게 처리할 수 있습니다. 소스는 자체 로그를 생성할 수 있습니다. 여기서 데이터 소스는 특정 이벤트 스트림(페이지 클릭, 캐시 새로 고침 알림, 데이터베이스 binlog 변경)과 같은 다양한 측면에서 로그를 클러스터 및 구독자에 저장할 수 있습니다. 오프셋을 기반으로 로그의 각 레코드를 읽고, 각 레코드의 데이터 및 작업을 기반으로 고유한 변경 사항을 적용합니다.

여기서의 로그는 메시지 큐로 이해될 수 있으며, 메시지 큐는 비동기식 디커플링 및 전류 제한 역할을 할 수 있습니다. 디커플링이라고 말하는 이유는 무엇입니까? 소비자와 생산자의 경우 두 역할의 책임이 매우 명확하기 때문에 데이터베이스의 변경 로그인지 특정 이벤트인지 누가 다운스트림인지 업스트림인지 신경 쓰지 않고 메시지를 생성하고 소비하는 역할을 담당합니다. 특정 당사자에 대해 전혀 신경 쓸 필요가 없습니다. 내가 관심 있는 로그와 로그의 각 기록에만 주의하면 됩니다.

우리는 데이터베이스의 QPS가 확실하고 상위 계층 애플리케이션이 일반적으로 수평으로 확장될 수 있다는 것을 알고 있습니다. 이때 Double 11과 같은 갑작스러운 요청 시나리오가 발생하면 데이터베이스가 압도될 수 있으므로 도입할 수 있습니다. 메시지 큐를 생성하고 각 큐를 데이터베이스에 추가합니다. 데이터베이스의 작업은 로그에 기록되며, 다른 애플리케이션은 이러한 로그 레코드를 사용하여 데이터베이스에 적용하는 역할을 담당합니다. 데이터베이스가 중단되더라도 계속해서 처리할 수 있습니다. 복원 시 마지막 메시지의 위치(RocketMQ와 Kafka 모두 Exactly Once 의미 체계 지원) 여기서는 생산자의 속도가 소비자의 속도와 다르더라도 로그는 영향을 미치지 않습니다. 여기에는 모든 레코드를 로그에 저장하고 정기적으로 슬레이브 노드에 동기화할 수 있습니다. 이렇게 하면 로그 쓰기가 마스터 노드에서 처리되기 때문에 메시지 백로그 용량이 크게 향상될 수 있습니다. 하나는 소비 속도가 쓰기 속도를 따라갈 수 있다는 의미인 테일 읽기(tail-read)입니다. 이러한 종류의 읽기는 캐시로 직접 이동할 수 있고, 다른 종류는 쓰기 요청보다 뒤처지는 소비자입니다. 따라서 IO 격리와 페이지 캐시, 캐시 사전 읽기 등과 같은 운영 체제와 함께 제공되는 일부 파일 정책을 통해 성능이 크게 향상될 수 있습니다.

수평적 확장성은 분산 시스템에서 매우 중요한 기능이며, 문제를 해결하기 위해 기계를 추가하는 것은 문제가 되지 않습니다. 그렇다면 수평 확장이 가능한 메시지 큐를 구현하는 방법은 무엇입니까? 독립형 메시지 큐가 있는 경우 주제 수가 증가하면 IO, CPU, 대역폭 등이 점차 병목 현상이 발생하고 성능이 서서히 저하됩니다. 그럼 여기서는 어떻게 진행해야 할까요?

1.topic/log sharding 기본적으로는 쓰기 횟수가 늘어날수록 단일 머신이 로그 기록이 됩니다. 이때 단일 주제를 여러 하위 주제로 나누고 각 주제를 다른 머신에 할당할 수 있습니다. 이런 식으로 메시지가 많은 주제는 머신을 추가하여 해결할 수 있으며, 일부 메시지의 경우 더 작은 것들은 동일한 머신에 할당되거나 분할되지 않을 수 있습니다.

2.그룹 커밋(예: Kafka의 생산자 클라이언트)은 메시지를 쓸 때 먼저 로컬 메모리 큐에 쓴 다음 메시지가 요약됩니다. 서버 측이나 브로커 측에서는 이 방법을 사용하여 먼저 페이지 캐시에 쓴 다음 정기적으로 디스크를 플러시할 수도 있습니다. 플러시 방법은 비즈니스에 따라 결정될 수 있습니다. 금융업무로는 동기식 플러싱 방식을 채택할 수 있습니다.

3. 쓸모 없는 데이터 복사 방지

4.IO 격리

결론#🎜 🎜 #

로그는 분산 시스템에서 매우 중요한 역할을 하며 분산 시스템의 다양한 구성 요소를 이해하는 데 핵심이 됩니다. 이해가 깊어질수록 많은 분산 미들웨어가 로그를 기반으로 구축된다는 것을 알 수 있습니다. Kafka, RocketMQ, Google Spanner 등, 심지어 Redis, MySQL 등과 같은 데이터베이스의 마스터-슬레이브는 로그 동기화를 기반으로 하며 공유 로그 시스템을 사용하므로 많은 시스템을 구현할 수 있습니다. 노드 간 데이터 동기화 , 동시 업데이트 데이터 순서 문제(일관성 문제), 지속성(시스템 충돌 시 시스템이 계속해서 다른 노드를 통해 서비스를 제공할 수 있음), 분산 잠금 서비스 등이 있습니다. 연습과 많은 논문 읽기를 통해, 확실히 더 깊은 이해가 될 것입니다.

위 내용은 분산 시스템 코어 로그 상세 소개(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!