Linux에서 효율적인 로그 라이브러리 적용

로그 자체의 특성상 왼쪽에서 오른쪽으로 순차적으로 기록이 삽입되는데, 이는 왼쪽의 기록이 오른쪽의 기록보다 "오래된" 기록이라는 의미입니다. 즉, 의존할 필요가 없습니다. 시스템 시계. 이 기능은 배포에 매우 중요합니다.

데이터베이스에 로그 적용

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

분산 시스템에 로그 적용

분산 시스템 서비스는 본질적으로 상태 변경에 관한 것이며, 이는 상태 머신으로 이해될 수 있습니다. 두 개의 독립적인 프로세스(시스템 시계, 외부 인터페이스 등과 같은 외부 환경에 의존하지 않음)는 일관된 입력이 주어지면 일관된 출력을 생성합니다. 일관된 상태이며 로그는 고유한 순서로 인해 시스템 시계에 의존하지 않으므로 변경 순서 문제를 해결하는 데 사용할 수 있습니다.
우리는 이 기능을 사용하여 분산 시스템에서 발생하는 많은 문제를 해결합니다. 예를 들어 RocketMQ의 대기 노드에서는 메인 브로커가 클라이언트의 요청을 받아 로그를 기록한 후 이를 슬레이브에 실시간으로 동기화하여 마스터가 전화를 끊으면 슬레이브가 이를 계속해서 재생할 수 있습니다. 쓰기 요청을 거부하고 읽기 요청을 계속하는 등 요청을 처리합니다. 로그는 데이터를 기록할 수 있을 뿐만 아니라 SQL 문과 같은 작업을 직접 기록할 수도 있습니다.

로그는 일관성 문제를 해결하는 핵심 데이터 구조입니다. 로그는 작업 순서와 같습니다. 예를 들어 널리 사용되는 Paxos 및 Raft 프로토콜은 모두 로그를 기반으로 구축된 일관성 프로토콜입니다.

Message Queue에 로그 적용

로그는 데이터 유입 및 유출을 처리하는 데 쉽게 사용할 수 있습니다. 각 데이터 소스는 이벤트 스트림(페이지 클릭, 캐시 새로 고침 알림, 데이터베이스 binlog 변경)과 같은 다양한 측면에서 생성될 수 있습니다. ), 로그를 클러스터에 중앙 집중식으로 저장할 수 있으며, 가입자는 오프셋을 기반으로 로그의 각 레코드를 읽고, 각 레코드의 데이터 및 작업을 기반으로 자체 변경 사항을 적용할 수 있습니다.
여기서 로그는 메시지 대기열로 이해될 수 있으며, 메시지 대기열은 비동기식 분리 및 전류 제한 역할을 할 수 있습니다. 디커플링이라고 말하는 이유는 무엇입니까? 소비자와 생산자의 경우 두 역할의 책임이 매우 명확하기 때문에 데이터베이스의 변경 로그인지 특정 이벤트인지 누가 다운스트림인지 업스트림인지 신경 쓰지 않고 메시지를 생성하고 소비하는 역할을 담당합니다. 특정 당사자에 대해 전혀 신경 쓸 필요가 없습니다. 내가 관심 있는 로그와 로그에 있는 각 기록에만 주의하면 됩니다.

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

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

1. 토픽/로그 샤딩은 기본적으로 토픽별로 작성된 메시지가 로그 기록이기 때문에 단일 머신이 서서히 병목 현상을 일으키게 됩니다. 각 주제를 다른 컴퓨터에 할당합니다. 이러한 방식으로 메시지가 많은 주제는 컴퓨터를 추가하여 해결할 수 있지만, 메시지가 적은 일부 주제는 동일한 컴퓨터에 할당되거나 파티션 처리되지 않을 수 있습니다.
Kafka의 생산자 클라이언트와 같은 그룹 커밋은 메시지를 작성할 때 먼저 로컬 메모리 큐에 기록한 다음 각 파티션 및 노드에 따라 메시지를 요약하여 일괄적으로 제출할 수 있습니다. 이 방법을 사용하면 페이지 캐시를 먼저 쓴 다음 정기적으로 디스크를 플러시합니다. 플러시 방법은 비즈니스에 따라 결정될 수 있습니다. 예를 들어 금융 서비스에서는 동기식 플러시 방법을 채택할 수 있습니다.
쓸데없는 데이터 복사를 피하세요
IO 격리
4. 
   

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

위 내용은 Linux에서 효율적인 로그 라이브러리 적용의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!