기존 시스템의 병목 현상 분석을 통해 핵심 결함이 분산된 순서 데이터 캐시에 집중되어 있어 데이터의 모든 끝에서 불일치가 발생하고, 각 데이터 간의 직접적인 연결이 발생한다는 사실을 발견했습니다. 주문 애플리케이션과 데이터베이스가 저하되어 확장성이 저하됩니다. 실습을 통해 데이터 액세스 계층을 추상화하고 통합하기 위한 미들웨어를 작성했으며, 데이터베이스 배포 아키텍처 미러를 기반으로 주문 캐시를 구축하여 핫 데이터를 균일하게 관리하고 서로 다른 엔드 간의 차이점을 해결했습니다.
그림 1.1 스토리지 시스템 아키텍처 다이어그램
주문 제출부터 각 끝의 가시성까지의 속도는 스토리지 시스템의 핵심 지표 중 하나입니다. 스토리지 서비스는 새로운 주문 동기화, 실시간 메시지 푸시, 쿼리 인덱스 구축, 데이터 플랫폼 오프라인 보관 등을 포함하는 데이터 체인의 주요 링크를 최적화하여 대규모 시스템의 데이터 도착 속도를 향상시켰습니다. 3초 이내에, 즉 사용자가 방금 주문을 한 것입니다. 이는 내 이동성의 표시 목록으로 이동합니다.
신규 사용자가 주문을 생성하면 동기화 서비스는 미들웨어를 통해 사용자 주문 데이터를 주문 라이브러리에 기록하는 데이터 링크 입구 역할을 하며 동시에 미들웨어는 주문 캐시 구성을 완료합니다.
주문이 창고 동작 및 핫스팟 데이터 구성을 완료하면 주문 정보가 실시간으로 덤프되어 각 하위 시스템에 출력됩니다.
새 주문이 데이터베이스에 입력되면 주문 세부정보의 ES 인덱스가 즉시 생성됩니다.
마지막으로 데이터 플랫폼 T+1은 당일 데이터 보관 및 제공을 구현합니다. BI 등 다양한 오프라인 비즈니스에 사용됩니다.
그림 2.1 데이터 링크
고객, 판매자, 직원 워크벤치를 지원하는 것은 주문 저장 시스템의 기본 역할입니다. 자동 주문 발행과 작업대 간의 연결은 필수입니다. 자동 주문은 고객이 주문을 제출한 후 재고를 확인하고 주문을 확인하기 위해 가능한 한 빨리 판매자에게 주문 세부 정보를 보내는 프로세스입니다. 워크벤치는 직원들이 적시에 주문을 받고 수동 이벤트를 처리하는 과정을 지원합니다.
그림 2.2 스토리지 시스템을 기반으로 한 주문 발행과 워크벤치의 관계(약식)
주문 데이터를 핵심으로 하여 크게 두 가지 사업 분야로 나누어집니다: 온라인 쿼리 및 데이터 분석 세부 쿼리를 예로 들면, 액세스 QPS는 일년 내내 높은 수준을 유지하며, 휴일 피크 기간에는 쿼리 병목 현상이 발생하기 쉽습니다. 근본 원인을 검토한 후 최적화를 위해 이 아키텍처 업그레이드를 조정했습니다. 관련 시나리오의 고가용성.
온라인 쿼리는 주로 주문 캐싱을 기반으로 하며, 쿼리 부담을 완화하기 위해 주문 제출 시 핫스팟 캐시가 구축되며 구성된 시간 매개변수에 따라 오랫동안 유효할 수 있습니다.
비온라인 쿼리 시나리오는 실시간 메시지 푸시를 통해 전달되며 Hive 데이터 웨어하우스 T+1 방식과 결합되어 장기 주문 데이터(예: 실시간 보고서)가 필요한 모든 경우에 대한 주문 메시지에 액세스할 수 있습니다. 실시간 계산. 대규모 데이터 분석 시 오프라인 BI는 Hive 테이블을 활용해 매일 이른 아침 피크 시간대에 데이터베이스에서 저주파 접근을 통해 데이터 동기화를 수행한다.
이러한 방식으로 주문 캐시, 실시간 메시징, Hive 데이터 웨어하우스의 3대 요소 뒤에 있는 기본 주문 데이터베이스에 대한 액세스를 보호하고 이를 비즈니스와 최대한 분리합니다.
씨트립의 핵심 스토리지 시스템을 업그레이드하는 과정에서 전체 과정에서 해야 할 일은 라이브 마이그레이션이며, 데이터 링크의 애플리케이션에 모든 작업을 투명하고 무손실로 만드는 것이 목표입니다. 달성. 우리의 설계는 그룹의 데이터 링크의 특성을 종합적으로 분석하여 애플리케이션과 데이터베이스 간의 직접적인 결합을 줄이기 위해 데이터베이스 미러링을 제공한 다음 미들웨어를 사용하여 SQLServer/에서 발생하는 데이터 간의 물리적 관계를 투명하게 제거합니다. MySQL은 실시간 마이그레이션을 위한 운영 공간을 애플리케이션에 제공합니다.
무손실 마이그레이션 프로세스 설계와 결합하여 각 데이터베이스 트래픽의 가시성과 제어 가능성에 중점을 두고 전체 데이터베이스, 샤드 수준, 테이블 수준 및 CRUD 작업 수준에서 트래픽 분산 전략을 지원하며 기본에 대한 충분한 구현 수단을 제공합니다. 데이터 마이그레이션. 데이터 웨어하우스 연결 설계는 데이터 플랫폼의 수백억 개의 오프라인 데이터와 이중 데이터베이스 온라인 기간 간의 동기화 문제를 해결하고 MySQL에 대한 전체 액세스 중에 발생하는 데이터 문제를 해결하는 데 중점을 둡니다.
다음은 이 과정에서 배운 경험을 세 부분으로 나누어 공유하겠습니다.
비즈니스가 발전함에 따라 사용자 수와 방문 수가 증가하고 주문 시스템 애플리케이션 및 서버에 대한 부담도 증가하고 있습니다. 주문 캐싱이 도입되기 전에는 각 애플리케이션이 독립적으로 데이터베이스에 연결되어 쿼리된 데이터가 애플리케이션 간에 공유될 수 없었고, 초당 DB 쿼리 수 및 연결 수에 상한이 있었습니다. 그러나 호텔의 핵심 트랜잭션 링크는 다음과 같습니다. DB 스토리지 기반으로 포인트 장애 단일 리스크가 있었습니다.
데이터 분석 후 주문 시스템은 일반적으로 핫 쿼리 데이터를 공유하고 DB 부하를 줄이기 위해 그림 3.1과 같이 캐시를 도입하는 것이 좋습니다. 캐시된 데이터가 있으면 결과를 직접 반환하고, 캐시에 적중이 없으면 DB를 쿼리하여 구성 정책에 따라 DB 결과 데이터를 확인합니다. , 후속 쿼리 사용을 위해 DB 데이터가 캐시에 기록되고, 그렇지 않으면 최종적으로 DB 쿼리 결과가 캐시에 기록되지 않습니다.
그림 3.1 주문 캐시의 기본 설계
새로운 캐시 구성 요소를 도입한 후의 하드웨어 오버헤드와 관련하여 각 애플리케이션의 원래 분산된 하드웨어 리소스를 통합하면 총 비용을 줄일 수 있지만 이로 인해 사용성 문제도 발생합니다. 중앙 집중 관리 데이터 정합성 등의 문제뿐만 아니라 기존 시스템에 대한 용량 평가, 트래픽 예측, 캐시 테이블 값 분석 등을 완벽하게 수행해야 합니다. 접근량이 많은 핫 데이터 테이블만 캐시합니다. 적절한 캐시 구조 설계, 데이터 압축 및 캐시 제거 전략을 통해 캐시 적중률을 극대화하고 캐시 용량, 하드웨어 비용 및 가용성 간의 균형을 잘 맞출 수 있습니다.
전통적인 캐시 설계는 하나의 데이터베이스 테이블 레코드가 하나의 캐시 데이터에 해당한다는 것입니다. 주문 시스템에서는 하나의 주문에 대해 여러 테이블을 쿼리하는 것이 매우 일반적입니다. 기존 디자인을 사용하는 경우 테이블 수가 많을수록 사용자 쿼리의 Redis 액세스 수가 증가하고 시간이 더 걸립니다. - 오래 걸립니다. 테이블 차원의 트래픽 데이터를 살펴보면, 일부 테이블은 함께 쿼리되는 경우가 많고, 비즈니스 측면에서는 30% 미만의 테이블이 쿼리 트래픽의 90% 이상을 차지한다는 사실을 발견했습니다. 추상 도메인 모델은 그림 3.2와 같이 해시 구조를 기반으로 저장되며 주문 번호를 키로, 필드 이름을 필드로, 필드 데이터를 값으로 사용합니다.
이런 방식으로 단일 테이블이든 다중 테이블 쿼리이든 각 주문은 Redis에 한 번만 액세스하면 되며, 이는 키를 줄일 뿐만 아니라 다중 테이블 쿼리 수를 줄여 성능을 향상시킵니다. 동시에 프로토타입을 기반으로 가치가 압축되어 Redis의 저장 공간과 그에 따른 네트워크 트래픽 오버헤드도 줄어듭니다.
그림 3.2 도메인 기반 저장소 구조에 대한 간략한 설명
무손실 핫 마이그레이션을 달성하는 방법은 전체 프로젝트에서 가장 어려운 부분입니다. 우리의 사전 작업은 데이터베이스와 비즈니스 레이어 애플리케이션을 분리하는 것을 목적으로 하는 미들웨어 개발을 먼저 완료하여 프로세스 설계를 수행하는 것입니다. 둘째, 추상 Dao 계층은 도메인화를 구현하고, 데이터 도메인 계층은 애플리케이션에 데이터 서비스를 제공합니다. 도메인 아래에는 SQLServer와 MySQL이라는 두 데이터베이스가 균일하게 적용되어 패키징됩니다. 이를 바탕으로 다음 공정 설계를 위해 무손실 열 마이그레이션을 구현할 수 있습니다.
SQLServer 및 MySQL 이중 데이터베이스는 온라인이며 이중 쓰기, 기본 쓰기 SQLServer 및 동기식 보조 MySQL 쓰기를 구현합니다. SQLServer 작업이 실패하면 전체 작업이 실패하고 이중 쓰기 트랜잭션이 롤백됩니다.
SQLServer와 MySQL 사이에 동기화 작업이 추가되어 SQLServer의 최신 시간 창에서 변경된 데이터를 실시간으로 쿼리하여 MySQL 항목의 일관성을 확인합니다. 차이점을 추적하여 둘 사이에 예상치 못한 불일치가 있는지 확인할 수 있습니다. 특히 이는 SQL Server 애플리케이션을 작성하기 위한 직접 연결이 있을 때 특히 유용합니다.
미들웨어는 모든 주요 쿼리 차원을 지원하고 구성에 따라 데이터 소스를 SQLServer 또는 MySQL로 정확하게 전달할 수 있으며, 읽은 후 주문 캐시에 로드할지 여부를 제어할 수 있는 구성 시스템으로 설계되었습니다. 초기 설정은 두 데이터베이스 간의 데이터 불일치로 인한 캐시 데이터 점프를 방지하기 위해 SQLServer 데이터 원본만 로드하는 것입니다. 초기 단계에서는 그레이 스케일을 설정할 수 있으며 소수의 비핵심 테이블을 MySQL에 직접 연결하여 안정성을 보장할 수 있습니다. 지연된 데이터 일관성에 대한 기대가 달성되면 주문 캐시는 지정된 데이터베이스에 대해 원하는 대로 로드될 수 있습니다.
데이터를 쿼리할 때 데이터 일관성을 보장한 후 트래픽 정책은 그림 3.3의 제어 가능한 차원에 따라 데이터베이스에 대한 단일 쓰기를 지원합니다. 실제 프로젝트에서는 단일 쓰기가 주로 테이블 차원에서 구현됩니다. 지정된 테이블이 단일 쓰기 MySQL로 구성되면 테이블과 관련된 모든 CRUD 동작이 캐시 로드 소스를 포함하여 MySQL로 전달됩니다.
마지막으로 외부로 전송되는 주문 메시지는 미들웨어를 통해 통일됩니다. 모든 메시지는 미들웨어의 CUD 연산을 기반으로 전송되며, 이러한 방식으로 물리적 데이터베이스의 데이터 소스와는 아무런 관련이 없습니다. 메시지는 투명하며 위의 모든 프로세스 작업은 연결될 수 있으며 데이터 체인은 일관성을 유지합니다.
그림 3.3 운영 프로세스 소개
생산 데이터를 데이터 웨어하우스의 ODS 계층 데이터로 마이그레이션하는 과정을 쉽게 이해하고 이를 투명하게 만들기 위해 다운스트림에서는 기존 데이터 웨어하우스 계층 시스템의 분류에 대해 간략하게 소개합니다. 일반적으로 데이터 웨어하우스는 아래 그림과 같이 주로 ODS(원본 데이터 계층), DIM(차원), EDW(엔터프라이즈 데이터 웨어하우스), CDM(공통 모델 계층), ADM(응용 모델 계층)의 5개 계층으로 나뉩니다. :
그림 3.4 데이터 웨어하우스 계층 구조
그림 3.4에서 볼 수 있듯이 데이터 웨어하우스의 각 계층은 ODS 계층의 데이터에 의존하므로 데이터 플랫폼의 모든 애플리케이션에 영향을 주지 않기 위해 전송만 하면 됩니다. 원래 주문 데이터베이스 SQL Server의 ODS 계층 데이터 소스 MySQL 라이브러리로 마이그레이션하면 됩니다.
데이터 소스만 변경하는 것만으로도 마이그레이션이 크게 번거롭지 않다는 것을 그림에서 직관적으로 알 수 있습니다. 하지만 데이터 품질을 보장하기 위해 DBA 동기화와 같은 많은 사전 작업을 수행했습니다. 프로덕션 데이터를 프로덕션 MySQL 데이터베이스로, MySQL 사전 실시간 데이터 동기화, 프로덕션 양쪽의 데이터 일관성 확인, ODS 레이어로 MySQL 측 데이터 동기화, ODS 레이어 데이터 일관성 확인 및 원본 ODS 레이어 동기화 작업 데이터 소스 전환, 등.
그 중에서 생산 양쪽의 데이터 일관성 확인과 데이터 웨어하우스의 ODS 계층에 대한 데이터 일관성 확인이 가장 복잡하고 시간이 많이 걸립니다. 각 테이블과 필드가 필요할 때만 데이터 소스를 전환해야 합니다. 일관성을 유지하십시오. 그러나 실제 작동에서는 완전히 일치할 수 없습니다. 실제 상황에 따라 시간 유형, 부동 소수점 값 정밀도 및 소수 자릿수 등을 적절하게 처리합니다.
다음은 전체 프로세스를 소개합니다.
먼저 온라인 데이터 일관성 검증을 위해 SQLServer 데이터와 MySQL 데이터를 비교하는 온라인 동기화 작업을 개발했습니다. 불일치가 발견되면 MySQL 데이터는 다음과 같습니다. 데이터는 양측의 데이터 일관성을 보장하기 위해 기준선으로 업데이트됩니다.
둘째, 오프라인 데이터 일관성 검증을 위해 데이터 웨어하우스 동료들과 협력하여 MySQL 측 데이터를 ODS 레이어에 동기화하고(데이터베이스 이름을 사용하여 SQLServer인지 MySQL 테이블인지 구별) 예약된 작업과 SQLServer를 배치했습니다. 시간에 일관성을 유지하도록 노력하세요. 양측의 데이터가 준비된 후, 데이터 웨어하우스 메타데이터를 기반으로 각 테이블에 대한 동기화 작업을 생성하고 스케줄링 플랫폼에 배포하는 오프라인 데이터 검증 스크립트 생성기를 개발했습니다.
동기화 작업은 양쪽 ODS 레이어의 동기화 데이터에 의존합니다. T+1 데이터 동기화가 완료된 후 일관성 검사가 수행되고 일관성이 없는 주문 번호가 일관성이 없는 세부 정보 테이블에 기록됩니다. 일치하지 않는 데이터의 양이 계산되고 결과가 통계 테이블에 저장됩니다. 그런 다음 셀프 서비스 보고 플랫폼에서 보고서를 작성하고 불일치 테이블의 일일 통계와 불일치 양을 메일박스로 보냅니다. 매일 불일치 테이블의 문제를 해결하여 문제를 찾고, 비교 전략을 조정하고, 비교를 업데이트합니다. 직업. 일반적인 프로세스는 다음과 같습니다.
그림 3.5 전반적인 일관성 검증 프로세스
마지막으로 온라인과 오프라인 데이터가 점차 일관성을 가지게 되면서 원본 SQLServer에서 동기화했던 데이터 소스를 ODS 계층으로 전환했습니다. Job to MySQL . 여기에 있는 일부 학생들은 다음과 같은 질문을 할 수 있습니다. MySQL 측의 ODS 계층에 있는 테이블을 직접 사용하면 어떨까요? 그 이유는 통계에 따르면 원래 ODS 레이어 테이블에 의존하는 작업이 수천 개에 달하기 때문입니다. 종속 작업이 MySQL 측 ODS 테이블로 전환되면 수정 작업량이 매우 무거워지기 때문에 원래 ODS를 직접 전환합니다. 레이어 동기화 데이터 소스를 MySQL로.
실제 작업에서는 데이터 소스를 한꺼번에 처리할 수 없습니다. 3개의 배치로 나누어서 먼저 첫 번째 배치로 덜 중요한 테이블 12개를 찾아 2주 동안 실행하고 다운스트림에서 문제를 수집합니다. 데이터. 2주 후에 첫 번째 샘플 배치가 성공적으로 분석되었으며, 다운스트림 보고서에서 데이터 문제가 접수되지 않아 샘플 데이터 품질의 신뢰성이 입증되었습니다. 그런 다음 나머지 수백 개의 테이블을 중요도에 따라 두 개의 배치로 나누고 완료될 때까지 계속 절단합니다.
이 시점에서 데이터 웨어하우스 계층에서 주문 데이터베이스를 SQLServer에서 MySQL로 마이그레이션하는 작업이 완료되었습니다.
사실 아무리 철저하게 분석하고 설계해도 실행 과정에서 다양한 난관에 부딪힐 수밖에 없습니다. 우리는 몇 가지 고전적인 문제를 요약했습니다. 이러한 크고 작은 문제가 마침내 기술적인 수단을 통해 해결되고 목표가 달성되었지만 독자 여러분은 더 나은 솔루션을 가지고 함께 배우고 발전할 수 있어서 기쁩니다.
주문 시스템에는 수많은 애플리케이션과 테이블이 포함됩니다. 하나의 애플리케이션은 1~n개의 애플리케이션에 해당합니다. 일반적으로 다대다 관계가 존재합니다. 그림 4.1에 표시된 것처럼 상위 계층 애플리케이션의 경우 하나의 SQLServer 데이터베이스에서 다른 MySQL 데이터베이스로 전환하는 경우 기본 프로세스는 작업 프로세스 장에 따라 최소한 다음 단계로 나뉩니다.
단일 쓰기 SQLServer에서 이중 쓰기 SQLServer 및 MySQL
단일 읽기 SQLServer에서 단일 읽기 MySQL로
이중 쓰기 SQLServer 및 MySQL에서 단일 쓰기 MySQL로
오프라인 SQLServer
그림 4.1 애플리케이션과 데이터베이스 및 테이블 관계 다이어그램
프로덕션 환경에서 데이터베이스 시스템을 교체하는 것은 고속도로에서 멈추지 않고 타이어를 교체하는 것과 같으며 원래 속도를 유지하고 사용자에게 둔감해야 합니다. 그렇지 않으면 결과를 상상할 수 없습니다.
전환 과정에서는 이중 쓰기, 단일 읽기 및 단일 쓰기 프로세스가 단계별로 서로 연동되고 의존적이며 지원 설계 모니터링 방법으로 진행하기 전에 이전 작업이 예상한 효과를 달성하는지 확인해야 합니다. 다음 것. 깔끔하게 전환하지 않고 건너뛰거나 성급하게 다음 단계로 진행한다면, 예를 들어 이중 쓰기가 완전히 일치하기 전에 MySQL 데이터를 읽기 시작하면 이 데이터를 찾지 못하거나 더티 데이터를 찾을 수도 있습니다! 그런 다음 각 CRUD 작업의 읽기 및 쓰기를 모니터링하고 마이그레이션 프로세스 중에 사각지대 없이 360도 시각적 트래픽 분할 제어를 달성해야 합니다. 구체적인 방법은 다음과 같습니다.
모든 애플리케이션은 미들웨어에 연결되며, CRUD는 미들웨어에 의해 제어되어 구성에 따라 어떤 DB와 어떤 테이블을 읽고 쓸 수 있습니다. 쓰기 작업은 Kibana 및 Grafana에 시각적으로 표시되며, DBTrace를 통해 각 SQL이 어떤 DB에서 실행되는지 알 수 있습니다.
애플리케이션 수준에 따라 이중 쓰기 DB를 단계별로 구성합니다. - 시간 비교, 동기화 작업을 통해 양측 DB 차이를 복구 및 기록한 후 오프라인 T+1을 통해 이중 쓰기의 최종 불일치를 확인하는 등 이중 쓰기가 일치할 때까지
이중 쓰기 후; 일관성이 있으면 SQLServer 읽기에서 MySQL 읽기로 점진적으로 전환하여 ES 모니터링 및 DBTrace를 통해 확인합니다. SQLServer 읽기가 전혀 없으면 MySQL의 자동 증가 상황을 고려하면 단일 읽기가 완료되었음을 의미합니다. 기본 키를 사용하기 위해 모든 테이블이 MySQL에만 기록될 때까지 테이블 차원에 따라 일괄적으로 SQLServer에 대한 쓰기를 중단하는 방법을 채택합니다.
요약하자면, 기본 솔루션은 미들웨어를 파이프라인으로 사용하여 액세스하는 모든 애플리케이션을 통일된 방식으로 묻어두고, 애플리케이션 레이어의 동작을 실시간으로 표시하여 트래픽 분포를 관찰하고, 회사 데이터베이스 측의 Trace 시각화 도구는 트래픽 전환 동작이 데이터베이스의 실제 QPS 및 부하 변동과 일치하여 마이그레이션 작업을 감독합니다.
호텔의 주문 데이터베이스는 수년 동안 여러 부서와 호텔 내 여러 팀이 주문 데이터베이스 SQLServer에 의존하고 있습니다. For MySQL로 전환하려면 먼저 이중 쓰기 DB 일관성 문제를 해결해야 합니다. 불일치는 주로 다음 두 가지 사항에 반영됩니다.
이중 쓰기 중에는 SQLServer만 실제로 작성되고, MySQL;
SQLServer와 MySQL의 이중 쓰기가 성공하면 동시성, 불안정한 네트워크, GC 등이 발생하면 MySQL 데이터가 SQL Server와 일치하지 않을 수 있습니다.
이중 쓰기 데이터 일관성 보장과 관련하여 동기화 작업을 사용하여 마지막 업데이트 시간을 기준으로 양쪽에서 DB 데이터를 가져와서 일치하지 않는 경우 복구합니다. MySQL 데이터를 삭제하고 일관성 없는 정보를 ES에 기록하여 근본 원인을 해결합니다.
동기화된 작업 및 장애 조치 메시지 메커니즘이 결국 데이터를 일관되게 만들 수 있지만 결국 두 번째 수준의 간격이 있고 양쪽의 데이터가 일치하지 않습니다. 그리고 많은 애플리케이션의 다양한 시나리오에서는 이는 불가피합니다. SQL Server만 작성하는 경우에는 누락되는 부분이 있습니다. MySQL에 대한 이러한 누락된 쓰기는 CUD 작업이 MySQL이 아닌 SQLServer에만 기록되는지 확인할 수 없기 때문에 DBTrace를 통해 찾을 수 없습니다. 그렇다면 MySQL이 누락된 시나리오를 미리 알아낼 수 있는 방법이 있을까요? 한 가지 알아낸 것은 데이터베이스 연결 문자열을 변경하고 미들웨어에 연결된 애플리케이션에 대해 새 연결 문자열을 사용한 다음 모든 것을 알아내는 것입니다. 이전 연결 문자열을 사용하는 작업은 MySQL이 놓친 트래픽을 정확하게 찾을 수 있습니다.
결국에는 이중 쓰기 DB 불일치 비율을 2/100,000에서 거의 0으로 줄였습니다. 왜 0에 가깝습니까? DB의 일부 기능 차이로 인해 자연스럽게 데이터 불일치가 발생하게 됩니다. 나중에 자세한 논의가 있을 것이다.
3. 주문 캐싱 도입으로 인한 데이터 동기화 문제 처리
캐시 도입 후 업계의 일반적인 관행은 다음과 같습니다. DB에 먼저 쓰고 캐시 쓰기
캐시 먼저 쓰고 DB
캐시 먼저 지우고 DB
DB 먼저 쓰고 캐시 삭제
더 이상 장단점을 비교하지 마세요. 다양한 방법의 단점이 있지만 특정 구현에서는 가능할 수 있습니다. 이중 삭제 캐시 또는 지연된 이중 삭제 캐시가 사용됩니다. DB에 먼저 쓰고 캐시를 삭제하는 방식을 채택합니다. 데이터에 민감한 테이블의 경우 지연된 이중 삭제가 수행됩니다. 백그라운드 동기화 작업은 데이터베이스 데이터와 Redis 데이터의 차이점을 정기적으로 비교, 복구 및 기록합니다. 설계를 통해 최종 성능의 일관성을 보장할 수 있지만 초기 단계에서는 여전히 데이터 불일치가 많이 발생했습니다. 주로 다음과 같은 측면에 반영됩니다.
애플리케이션이 미들웨어에 연결되지 않고 DB에서 CUD 작업을 수행한 후 캐시가 삭제되지 않는 시나리오가 있습니다.
에 쓴 후 캐시 삭제 지연; 예를 들어, 신뢰할 수 없는 네트워크, GC 등으로 인해 캐시된 더티 데이터를 읽는 경우
DB를 작성한 후 캐시를 삭제하지 못하면 Redis 마스터-슬레이브 전환 중에 캐시됩니다. , 읽기만 가능하고 쓸 수는 없습니다.
캐시 일관성 문제를 해결하기 위해 그림 4.2와 같이 원본 캐시와 DB를 기반으로 낙관적 잠금 및 CUD 구성 마커를 추가하여 동시 상황에서 서로 겹치는 캐시로 데이터를 로드하는 동작을 제한했습니다. 그리고 확인 중인 데이터에 대해 현재 수행 중인 CUD 작업에 대한 인식입니다. 낙관적 잠금을 기반으로 한 최종 작성자 승리 메커니즘을 사용하면 쿼리 트래픽을 실현하여 DB에 직접 연결하고 이 두 시나리오가 완료되지 않은 경우 경쟁 문제를 해결할 수 있습니다. 결국 캐시 불일치 비율은 백만분의 2에서 천만분의 3으로 제어되었습니다.
그림 4.2 캐시 일관성 솔루션
그림 4.2 쿼리에서 캐시가 누락되거나 현재 데이터에 대한 낙관적 잠금 또는 구성 표시가 있는 경우 캐시된 데이터가 해제될 때까지 쿼리가 DB에 직접 연결됩니다. 해당 거래가 자동 로드 기능이 완료됩니다.
프로젝트 초기에 MySQL에 대한 지난 N년간의 데이터를 일회적으로 준비한 결과 다음과 같은 두 가지 데이터 시나리오가 생성되었습니다. 이중 쓰기 단계에서는 보정할 수 없습니다:
생산 주문 데이터베이스는 거의 N년간의 데이터를 유지하도록 사전 설정되어 있기 때문에 백업 정리를 담당하는 작업이 미들웨어에 연결되기 전에 MySQL에 존재했던 데이터가 N년 동안은 정책으로 덮어쓰거나 정리할 수 없습니다.
연결 미들웨어를 적용하는 데 시간이 오래 걸립니다. 미들웨어가 이중으로 작성되기 전에는 데이터가 일치하지 않을 수 있습니다. 연결하는 미들웨어를 모두 적용하고 모든 테이블이 이중으로 작성된 후에 이전 데이터를 한 번에 복구해야 합니다. -쓴.
첫 번째로, 주문 데이터베이스에 여러 개의 샤드가 있으므로 전체 코어 스레드 수는 실제 샤드 수를 기준으로 작업 내부에서 설정되는 MySQL 데이터 정리 작업을 개발했습니다. 클리닝의 경우 여러 서버를 병렬로 실행하여 클리닝 작업을 분산시킵니다. 속도 제어는 프로덕션 데이터베이스의 부하에 영향을 주지 않고 효율성을 보장합니다.
두 번째로, 미들웨어와 모든 테이블을 연결하는 모든 애플리케이션이 이중으로 작성된 후 온라인 동기화 작업 스캔의 시작 타임스탬프를 조정하여 기존 주문 데이터를 복구할 수 있습니다. 복구할 때 너무 많은 데이터가 로드되어 주문 데이터베이스 서버 CPU가 너무 높아지는 것을 방지하기 위해 스캔한 데이터를 기간에 따라 조각으로 처리해야 한다는 사실에 특별한 주의를 기울여야 합니다.
거대한 시스템에서 데이터베이스의 실시간 마이그레이션을 수행하려면 서로 다른 데이터베이스 간의 유사점과 차이점을 깊이 이해해야 문제를 효과적으로 해결할 수 있습니다. MySQL과 SQL Server는 모두 널리 사용되는 관계형 데이터베이스이고 둘 다 표준화된 SQL 쿼리를 지원하지만 세부 사항에는 여전히 몇 가지 차이점이 있습니다. 마이그레이션 중에 직면하는 문제를 자세히 살펴보겠습니다.
1) 자동 증가 키 문제
일관되지 않은 자동 증가 일련 번호로 인해 발생하는 데이터 복구의 더 큰 위험을 방지하려면 두 데이터베이스가 동일한 자동 증가 일련 번호를 공유하는지 확인해야 합니다. 따라서 각각 자동 증가 작업을 수행하도록 허용해서는 안 됩니다. 따라서 데이터가 이중으로 기록될 때 SQLServer에서 생성된 자동 증가 ID를 다시 MySQL 자동 증가 열에 기록합니다. MySQL에만 데이터를 기록할 경우 MySQL을 사용하여 자동 증가 ID 값을 직접 생성합니다.
2) 날짜 정확도 문제
이중 쓰기 후 데이터 일관성을 보장하려면 날짜, 날짜/시간, 타임스탬프 유형의 필드는 일관성이 없는 저장 정확도로 인해 일관성을 확인해야 합니다. 비교할 때 사용되며, 비교를 위해 초 단위로 가로채는 특수 처리가 필요합니다.
3) XML 필드 문제
SQL Server에서는 XML 데이터 형식을 지원하지만 MySQL 5.7에서는 XML 형식을 지원하지 않습니다. 대신 varchar(4000)을 사용한 후 MySQL 데이터 쓰기에 실패했지만 동기화 작업에서는 SQLServer 데이터를 MySQL에 정상적으로 다시 쓸 수 있는 경우가 발생했습니다. 분석 후 프로그램은 쓰기 시 압축되지 않은 XML 문자열을 작성합니다. SQLServer XML 유형은 이를 자동으로 압축하여 저장하지만 결과적으로 MySQL은 길이가 4000을 초과하는 쓰기 작업이 실패하고 SQLServer 압축 후의 길이는 실패합니다. 4000. 미만이며 정상적으로 MySQL에 다시 쓸 수 있습니다. 이를 위해 쓰기 전에 길이를 압축 및 검증하고, 중요하지 않은 필드를 저장하기 전에 가로채고, 중요한 필드의 저장 구조를 최적화하거나 필드 유형을 변경하는 등의 대응책을 제안합니다.
다음은 마이그레이션 프로세스 중에 주의해야 할 몇 가지 일반적인 사항입니다.
당사의 조기 경보 실습은 프로젝트 진행 중 요구 사항 모니터링에만 국한되지 않고 수백억 개의 데이터에서 데이터 쓰기 이상 현상을 주기적으로 스캔하고 이중 쓰기 데이터 일관성 비율을 완료하는 방법입니다. 프로젝트 검토, 주문 라이브러리의 각 샤드에 대한 주문 쓰기량의 일반적인 추세를 실시간으로 모니터링하고 경고하는 방법, 전체 시스템의 고가용성을 정기적으로 수락/검증하는 방법은 다음 페이지에서 설명됩니다.
SQLServer에서 MySQL 데이터베이스로의 주문 데이터 마이그레이션 요구 사항을 충족하려면 데이터 품질이 마이그레이션의 필수 조건입니다. 데이터 일관성이 요구 사항을 충족하지 않으면 투명한 마이그레이션이 불가능합니다. 달성되었으므로 마이그레이션 진행과 관련하여 합리적인 검증이 설계됩니다. 데이터 검증은 온라인과 오프라인 2가지로 나누어 진행합니다:
온라인 데이터 검증 및 조기경보
마이그레이션 과정에서 작업을 동기화하고, 일치하지 않는 데이터를 계산하고, 일치하지 않는 테이블과 필드를 ElasticSearch에 작성한 다음 Kibana를 사용하여 일치하지 않는 데이터의 양과 일치하지 않는 테이블의 비율에 대한 모니터링 대시보드를 만들었습니다. 모니터링 대시보드를 통해 데이터 불일치가 높은 테이블을 실시간으로 모니터링한 후 DBA 도구를 사용하여 테이블 이름을 기반으로 테이블에 대해 CUD 작업을 수행한 애플리케이션을 파악하고 미들웨어가 누락된 애플리케이션 및 코드를 추가로 찾을 수 있습니다. .
실제 운영에서 미들웨어에 연결되지 않은 애플리케이션을 많이 발견하고 이를 변형한 결과, 미들웨어에 연결되는 애플리케이션이 많아지면서 모니터링 대시보드에서 데이터 일관성이 점차 향상되는 모습을 볼 수 있었습니다. 금액도 점차 줄어들었다. 그러나 일관성이 결코 0으로 떨어지지 않는 이유는 응용 프로그램과 동기화 작업의 동시성 때문이기도 합니다.
이중 쓰기가 완료되었으므로 동기화 작업을 중지하는 것이 어떨까요? 그 이유는 SQL Server가 주요 쓰기 방식이고 미들웨어가 다루는 CUD 범위를 벤치마크로 사용하기 때문이다. MySQL에 데이터 쓰기가 100% 성공한다는 보장도 없고, 두 개의 데이터베이스가 동일하므로 일관된 작업이 필요합니다. 데이터가 완전히 일치할 수는 없지만 동시 처리를 통해 불일치를 더욱 줄일 수 있습니다.
저희 접근 방식은 일관성 작업을 비교할 때 5초 안정성 선을 설정하는 것입니다(즉, 현재 시간으로부터 5초 이내의 데이터는 불안정한 데이터로 간주됩니다). 안정성 선 내의 주문 데이터 타임스탬프는 비교되지 않으며 안정적입니다. 라인 외부를 비교하면 주문 데이터가 안정 라인 내에 있는지 다시 계산하며, 모든 데이터가 안정 라인 외부에 있는 것으로 확인되면 비교 작업이 수행되고 일관성이 유지됩니다. 점검은 다음 일정으로 진행됩니다.
오프라인 데이터 확인 및 조기 경고
주문 데이터베이스 마이그레이션에는 수백 개의 테이블과 대량의 오프라인 데이터가 포함됩니다. 불과 1년 만에 주문 관련 데이터의 양이 수십억 개에 달해 오프라인 데이터 검사에 상당한 어려움을 안겨줍니다. 우리는 각 테이블에 대한 비교 스크립트를 생성하고 이를 스케줄링 플랫폼에 배포하기 위해 데이터 일관성 스크립트 생성기를 작성했습니다. 비교 스크립트는 업스트림 SQLServer 및 MySQL의 양쪽에서 동기화 작업에 의존합니다. 불일치 데이터를 비교하기 위해 자동으로 비교가 수행되며, 세부 테이블에 주문 번호가 기록되고, 불일치 정도가 상세 테이블을 기준으로 계산되며, 데이터 불일치가 높은 테이블은 일별 보고서 형식으로 발행됩니다. 매일 확인하고 해결합니다.
저희는 일반적으로 비교 스크립트 문제 수정, 오프라인 데이터 품질 확인 등 지속적으로 불일치 문제를 해결하고 있습니다. 오프라인 데이터의 각 테이블에 있는 각 필드를 확인하는 것은 매우 복잡합니다. 비교를 위해 UDF 함수를 작성합니다. UDF 함수의 기능도 매우 간단합니다. 새 필드 완전 외부 조인을 수행할 때 기본 키가 동일하거나 논리적 기본 키가 있는 레코드도 새 필드를 생성해야 하며, 이는 서로 다른 데이터로 간주됩니다. 여기서 우리는 날짜 필드 차단, 데이터 정확성 및 끝에 0이 있는 소수점 처리에 주의를 기울여야 합니다.
3개월 이상의 노력 끝에 우리는 미들웨어에 연결되지 않은 모든 애플리케이션을 식별하고 모든 CUD 작업을 미들웨어에 연결한 후 이중 쓰기를 활성화한 후 온라인과 오프라인 데이터의 일관성이 점차 향상되어 다음을 달성했습니다. 데이터 마이그레이션의 목표.
씨트립에는 호텔, 항공권, 무선, 하이패스 등 다양한 주문 알림을 주로 모니터링하는 통합 조기 경보 플랫폼인 Sitemon이 있습니다. 고속철도, 휴가. 온라인/오프라인, 국내/해외, 결제 방식을 기반으로 독립적인 검색 및 표시 기능을 갖추고 있으며, 모든 유형의 주문에 대한 알림 기능을 갖추고 있습니다.
SQL Server에서 MySQL로 주문 데이터를 마이그레이션하는 동안 우리는 주문 데이터베이스에 의존하는 약 200개의 조기 경보 전략을 정리했습니다. 모니터링을 담당하는 관련 동료는 SQL Server 데이터 원본의 조기 경보 전략 사본을 만들고 MySQL 데이터 소스에 연결했습니다. MySQL을 데이터 소스로 사용하는 모든 모니터링 알람을 추가한 후 알람 전략을 활성화합니다. 주문량이 비정상이면 NOC는 SQLServer 데이터 알람에서 하나, 양쪽에서 일치하는 경우 하나의 알림을 받습니다. 그레이스케일 검증이 통과되었음을 의미합니다. 그렇지 않으면 실패하며 MySQL 모니터링 문제를 조사해야 합니다.
일정 기간의 그레이스케일 검증 후에는 양쪽의 알람 데이터가 일치합니다. SQLServer 데이터 테이블이 오프라인이 되면서(즉, MySQL 데이터가 단독으로 기록됨) SQLServer를 데이터 소스로 사용하는 조기 경고 전략도 2019년에 오프라인이 됩니다. 시간.
시스템 보안을 확보하고 비상 대응 능력을 향상시키기 위해 필요한 훈련과 스트레스 테스트를 실시해야 합니다. 이를 위해 우리는 완전한 비상 계획을 개발하고 비상 훈련인 The Wandering Earth를 정기적으로 조직했습니다. 훈련 항목에는 코어/비코어 애플리케이션 회로 차단기, DB 회로 차단기, Redis 회로 차단기, 코어 방화벽, 스위치 비상 스위칭 등이 포함됩니다.
캐싱을 예로 들어 캐시 서비스의 고가용성을 보장하기 위해 드릴 중에 일부 노드나 시스템을 오프라인으로 설정하거나 전체 Redis 서비스를 차단하여 캐시 사태, 캐시 고장 및 기타 시나리오를 시뮬레이션합니다. 계획에 따르면 융합에 앞서 먼저 애플리케이션의 Redis 액세스를 차단하고 Redis 부하를 점진적으로 줄인 후 Redis를 융합하여 각 애플리케이션 시스템이 Redis 없이도 정상적으로 작동할 수 있는지 테스트할 예정입니다.
첫 번째 드릴에서 Redis가 끊어지자 애플리케이션 오류가 급격히 늘어나서 문제의 원인을 찾으면서 과감히 Drill을 중단하고 Rollback을 했습니다. 일부 애플리케이션의 Redis 운영은 획일적으로 관리되지 않고 미들웨어에 의해 제어되지 않기 때문에 Redis가 중단되면 애플리케이션이 즉시 비정상이 됩니다. 이러한 상황에 대응하여 분석 후 한편으로는 오류 보고 애플리케이션의 주문 캐시 액세스 포트를 미들웨어에 연결하는 한편, 미들웨어와 Redis 간의 약한 의존성을 강화하여 원클릭을 지원했습니다. Redis 작업 연결 해제 및 다양한 지표 모니터링이 개선되었습니다. 두 번째 훈련에서는 Redis 회로 차단기가 성공적으로 이루어졌으며 모든 비즈니스 시스템은 MySQL에 대한 전체 트래픽 액세스로 정상적으로 실행되었습니다. 최신 Wandering Earth 훈련에서 컴퓨터실 네트워크 차단 및 비핵심 응용 프로그램 차단과 같은 일련의 오류 주입 후 우리 시스템은 매우 좋은 기대 결과를 달성했습니다.
이러한 방식으로 우리는 훈련을 거듭하면서 문제를 발견하고, 경험을 요약하고, 시스템을 최적화하고, 비상 계획을 개선하고, 갑작스러운 장애에 대처할 수 있는 시스템의 능력을 단계적으로 개선하고, 비즈니스 연속성과 데이터 무결성을 보장했습니다. 전체 호텔 주문 시스템을 보호하기 위해 기본 데이터 지원을 제공합니다.
완벽한 모니터링 보드와 조기 경고 시스템을 갖추고 있지만, 회로 차단기 드릴, 자동화된 결함 드릴링, 하드웨어 오류 및 유지 관리, 예측할 수 없는 문제에 대해 만약 핵심 개발자들이 현장 작업에 제때 대응하지 못하고, 시스템이 완전히 자율적으로 다운그레이드되지 않아 응답 시간 증가 등 일부 성능 저하가 발생할 수 있는 경우가 있습니다. 앞으로는 수동 제어 대시보드를 추가할 계획입니다. 승인 후 NOC 또는 TS가 대상 작업을 수행하도록 허용할 수 있습니다. 예를 들어 Redis 클러스터 전체 또는 일부가 다운된 경우 한 번의 클릭으로 잘못된 Redis 샤드를 잘라낼 수 있습니다. 또는 Redis의 계획된 비가용 기간을 기준으로 미리 절단 시간을 설정하면 시스템 제어성을 최대한 보장할 수 있습니다.
수동으로 제어할 수 있으므로 향후 일부 핵심 지표를 모니터링하는 것도 고려합니다. 예를 들어 Redis 마스터-슬레이브 전환 중에 정상적인 상황은 몇 초이지만 일부 경험도 있습니다. Redis 10 초 이상 쓸 수 없는 경우 캐시와 데이터베이스 사이에 불일치하는 더티 데이터의 양을 모니터링할 수 있으며 Redis가 실패할 때 비정상적인 응답 시간이 소요되는 임계값을 모니터링하여 몇 가지 전략을 적용할 수도 있습니다. 미들웨어가 자동으로 다운그레이드하여 이러한 장애를 차단할 수 있다는 것입니다. 호스트는 서비스의 기본적인 안정성을 보장한 후 클러스터 지표가 안정적인지 감지한 후 점진적으로 복구를 시도합니다.
현재 주문 팀은 JAR 형식의 미들웨어를 사용하고 있으며, 미들웨어는 데이터베이스의 근본적인 차이점을 보호하고 보다 복잡한 기능을 달성하기 위해 자연스럽게 Service Mesh에 액세스할 수 있습니다. , 액세스 후 기본 업그레이드가 더 빠르고 원활하며 호출이 더 가볍고 프레임워크와의 그리드 통합이 더 좋고 클라우드 마이그레이션이 더 편리하여 Ctrip의 국제 전략 목표를 더 잘 지원할 수 있습니다.
위 내용은 SQL Server 센서리스 시스템을 MySQL로 마이그레이션하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
