먼저 시스템이 분산을 사용하는 이유를 이해해야 합니다. 인터넷의 발전으로 인해 기존 단일 프로젝트 프로젝트의 많은 성능 병목 현상이 더욱 두드러졌습니다. 성능 병목 현상에는 여러 측면이 있을 수 있습니다. 1. 애플리케이션 서비스 계층: 사용자 수가 증가함에 따라 동시성 양이 증가하며, 단일 프로젝트는 이러한 대규모 동시 요청으로 인한 성능 병목 현상을 견딜 수 없습니다. 2. 기본 데이터베이스 계층: 비즈니스가 발전함에 따라 데이터베이스에 대한 부담이 증가하여 성능 병목 현상이 발생합니다. 위의 두 가지 점에 대해서는 두 가지 측면에서 해결될 수 있다고 생각합니다. 애플리케이션 서비스 계층: 애플리케이션 서비스 계층에는 여러 가지 솔루션이 있습니다. 애플리케이션 시스템 클러스터: 가장 간단한 애플리케이션 시스템 클러스터는 Tomcat 클러스터와 같은 서버 클러스터입니다. 시스템 클러스터를 적용할 때 더욱 두드러지는 문제는 세션 공유가 서버 플러그인을 통해 해결될 수 있다는 것입니다. 다른 하나는 redis와 같은 미들웨어를 통해서도 구현할 수 있습니다. 서비스 기반 분할: 서비스 기반 분할은 현재 매우 인기 있는 방법입니다. 이제 모두가 마이크로서비스에 대해 이야기하고 있습니다. 기존 프로젝트를 서비스로 분할함으로써 서비스를 독립적으로 분리할 수 있고, 단일 서비스를 수평적으로 확장할 수 있습니다. 서비스 분할에서 발생하는 고전적인 문제는 분산 트랜잭션 문제입니다. 현재 일반적으로 사용되는 분산 트랜잭션 솔루션에는 메시지 최종 일관성, TCC 보상 트랜잭션, 최선의 알림 등이 있습니다. 자세한 내용은 이 블로그 분산 트랜잭션 솔루션을 참조하세요. 기본 데이터베이스 계층: 시스템의 성능 압박이 데이터베이스에 나타나면 읽기-쓰기 분리, 데이터베이스 등의 솔루션으로 이를 해결할 수 있습니다. 테이블 파티셔닝 등이 있습니다. 이 분야에 대한 경험이 부족하므로 다른 문서를 참조하시면 됩니다. Mycat 데이터베이스 샤딩 및 테이블 샤딩 미들웨어 MySQL 고가용성 읽기-쓰기 분리 클러스터
초대해 주셔서 감사합니다. 저는 마스터가 아니며, 질문자의 질문이 너무 크고 답변하기 어려운 것 같습니다.
그러나 제가 아는 한 기술 면접은 일반적으로 점진적이며 면접관은 지원자의 기술 시스템의 깊이를 테스트하므로 이론적으로는 주제에 대해 많이 이야기할수록 대표성이 높아집니다. 당신은 후보자의 능력이 더 좋습니다. 많은 높은 동시성 및 분산 처리 문제는 실제로 경험적 문제입니다. 다양한 비즈니스 시나리오와 다양한 데이터 양의 높은 동시성 처리 상황이 완전히 다르며 완전히 보편적인 솔루션이 없기 때문입니다. .
그래서 면접에서는 면접관이 설명하는 비즈니스 시나리오를 이해하는 것이 매우 중요합니다. 이는 또한 성능 병목 현상을 분석하는 핵심 정보이기도 합니다.
간단한 예로 비즈니스가 성장함에 따라 데이터베이스에 직접 연결된 서버 클러스터에서 성능 병목 현상이 발생하면 어떻게 해결해야 할까요?
이때, 먼저 성능 병목 현상이 어디에 있는지 분석해야 합니다. 먼저 데이터베이스 자체의 설계가 합리적인지, 인덱스가 역할을 하고 있는지, SQL 실행 계획을 분석하고 데이터베이스가 가능한지 여부를 고려해야 합니다. 수평 또는 수직으로 분할하여 스트레스를 공유하세요.
분산된 읽기-쓰기 분리 데이터베이스를 사용할 수 있는지 분석하는 것도 필요하며, 이로 인해 데이터 동기화를 수행하는 방법, 데이터 분산 등의 문제가 발생합니다.
데이터베이스 계층을 분석한 후 애플리케이션 계층에서도 분석할 수 있습니다. 일반적으로 캐싱은 캐시 적중률 문제, 캐시 업데이트 문제, 캐시된 다중 노드 해시 문제 등을 포함하는 쿼리 성능을 향상하는 데 사용됩니다.
일반적으로 비즈니스 시나리오를 이해한 다음 특정 문제에 대한 해결책을 모색해야 합니다. 예를 들어 Sina Weibo는 푸시 모드를 사용합니까, 아니면 풀 모드를 사용합니까? 푸시 모드라면 수천만 명의 팬을 거느린 빅 뷔가 수천만 명에게 웨이보 게시물을 올리는 걸까요? 풀모드라면 한 사람이 너무 많은 사용자를 팔로우할 때마다 성능 문제가 발생하나요?
배포 유형은 다양합니다. 예를 들어 프로젝트를 여러 모듈로 나누는 경우 각 모듈에는 rpc 호출을 통해 전체 작업을 완료하는 것이 있습니다. 예를 들어 단일 Redis 서버는 이를 견딜 수 없습니다. 또는 캐싱을 위한 메모리가 너무 많지 않으면 분산된 Redis 클러스터를 구축할 수 있습니다. 또 다른 예로, 데이터베이스만으로는 현재 데이터 볼륨이나 동시성을 충족할 수 없는 경우 데이터베이스를 나눌 수 있습니다. JTA를 통해 테이블로 변환하고 트랜잭션을 구현합니다. 배포, 로그 동기화, 로드 밸런싱, 데이터 백업을 저장하기 위한 HDFS 추가, 로그 저장, 로그 분석 및 검색을 위한 eslaticsearch 추가 등을 모두 논의할 수 있습니다.
일반적인 질문을 할 때, 답변자가 일반적인 질문을 따르면 실패할 것입니다... 논리적으로 대답하는 것이 좋습니다. 저라면 두 가지를 할 것입니다. 1. 이전에 했던 프로젝트를 찾아 그와 병목 현상에 대해 논의한 다음 이론적 지식을 소개하고 마지막으로 해결책을 제시합니다. 이 접근 방식을 사용하면 자신에 대해 쉽게 이야기할 수 있으며 면접관과 어느 정도 상호 작용을 하는 것이 가장 좋습니다. 대화 중 면접관의 질문에 주목하고 면접관이 무엇을 묻는지 명확하게 확인하세요
2. 두 번째 접근 방식은 카드를 먼저 보여주고 트래픽 부하와 같은 보다 고전적인 분산 문제를 꺼내는 것입니다. 사업 보장. . . . 그런 다음 문제에 대한 비즈니스 시나리오를 제공하십시오.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
먼저 시스템이 분산을 사용하는 이유를 이해해야 합니다.
인터넷의 발전으로 인해 기존 단일 프로젝트 프로젝트의 많은 성능 병목 현상이 더욱 두드러졌습니다. 성능 병목 현상에는 여러 측면이 있을 수 있습니다.
1. 애플리케이션 서비스 계층: 사용자 수가 증가함에 따라 동시성 양이 증가하며, 단일 프로젝트는 이러한 대규모 동시 요청으로 인한 성능 병목 현상을 견딜 수 없습니다.
2. 기본 데이터베이스 계층: 비즈니스가 발전함에 따라 데이터베이스에 대한 부담이 증가하여 성능 병목 현상이 발생합니다.
위의 두 가지 점에 대해서는 두 가지 측면에서 해결될 수 있다고 생각합니다.
애플리케이션 서비스 계층:
애플리케이션 서비스 계층에는 여러 가지 솔루션이 있습니다.
애플리케이션 시스템 클러스터:
가장 간단한 애플리케이션 시스템 클러스터는 Tomcat 클러스터와 같은 서버 클러스터입니다. 시스템 클러스터를 적용할 때 더욱 두드러지는 문제는 세션 공유가 서버 플러그인을 통해 해결될 수 있다는 것입니다. 다른 하나는 redis와 같은 미들웨어를 통해서도 구현할 수 있습니다.
서비스 기반 분할:
서비스 기반 분할은 현재 매우 인기 있는 방법입니다. 이제 모두가 마이크로서비스에 대해 이야기하고 있습니다. 기존 프로젝트를 서비스로 분할함으로써 서비스를 독립적으로 분리할 수 있고, 단일 서비스를 수평적으로 확장할 수 있습니다. 서비스 분할에서 발생하는 고전적인 문제는 분산 트랜잭션 문제입니다. 현재 일반적으로 사용되는 분산 트랜잭션 솔루션에는 메시지 최종 일관성, TCC 보상 트랜잭션, 최선의 알림 등이 있습니다. 자세한 내용은 이 블로그 분산 트랜잭션 솔루션을 참조하세요.
기본 데이터베이스 계층:
시스템의 성능 압박이 데이터베이스에 나타나면 읽기-쓰기 분리, 데이터베이스 등의 솔루션으로 이를 해결할 수 있습니다. 테이블 파티셔닝 등이 있습니다. 이 분야에 대한 경험이 부족하므로 다른 문서를 참조하시면 됩니다.
Mycat 데이터베이스 샤딩 및 테이블 샤딩 미들웨어
MySQL 고가용성 읽기-쓰기 분리 클러스터
초대해 주셔서 감사합니다. 저는 마스터가 아니며, 질문자의 질문이 너무 크고 답변하기 어려운 것 같습니다.
그러나 제가 아는 한 기술 면접은 일반적으로 점진적이며 면접관은 지원자의 기술 시스템의 깊이를 테스트하므로 이론적으로는 주제에 대해 많이 이야기할수록 대표성이 높아집니다. 당신은 후보자의 능력이 더 좋습니다. 많은 높은 동시성 및 분산 처리 문제는 실제로 경험적 문제입니다. 다양한 비즈니스 시나리오와 다양한 데이터 양의 높은 동시성 처리 상황이 완전히 다르며 완전히 보편적인 솔루션이 없기 때문입니다. .
그래서 면접에서는 면접관이 설명하는 비즈니스 시나리오를 이해하는 것이 매우 중요합니다. 이는 또한 성능 병목 현상을 분석하는 핵심 정보이기도 합니다.
간단한 예로 비즈니스가 성장함에 따라 데이터베이스에 직접 연결된 서버 클러스터에서 성능 병목 현상이 발생하면 어떻게 해결해야 할까요?
이때, 먼저 성능 병목 현상이 어디에 있는지 분석해야 합니다. 먼저 데이터베이스 자체의 설계가 합리적인지, 인덱스가 역할을 하고 있는지, SQL 실행 계획을 분석하고 데이터베이스가 가능한지 여부를 고려해야 합니다. 수평 또는 수직으로 분할하여 스트레스를 공유하세요.
분산된 읽기-쓰기 분리 데이터베이스를 사용할 수 있는지 분석하는 것도 필요하며, 이로 인해 데이터 동기화를 수행하는 방법, 데이터 분산 등의 문제가 발생합니다.
데이터베이스 계층을 분석한 후 애플리케이션 계층에서도 분석할 수 있습니다. 일반적으로 캐싱은 캐시 적중률 문제, 캐시 업데이트 문제, 캐시된 다중 노드 해시 문제 등을 포함하는 쿼리 성능을 향상하는 데 사용됩니다.
일반적으로 비즈니스 시나리오를 이해한 다음 특정 문제에 대한 해결책을 모색해야 합니다. 예를 들어 Sina Weibo는 푸시 모드를 사용합니까, 아니면 풀 모드를 사용합니까? 푸시 모드라면 수천만 명의 팬을 거느린 빅 뷔가 수천만 명에게 웨이보 게시물을 올리는 걸까요? 풀모드라면 한 사람이 너무 많은 사용자를 팔로우할 때마다 성능 문제가 발생하나요?
배포 유형은 다양합니다. 예를 들어 프로젝트를 여러 모듈로 나누는 경우 각 모듈에는 rpc 호출을 통해 전체 작업을 완료하는 것이 있습니다. 예를 들어 단일 Redis 서버는 이를 견딜 수 없습니다. 또는 캐싱을 위한 메모리가 너무 많지 않으면 분산된 Redis 클러스터를 구축할 수 있습니다. 또 다른 예로, 데이터베이스만으로는 현재 데이터 볼륨이나 동시성을 충족할 수 없는 경우 데이터베이스를 나눌 수 있습니다. JTA를 통해 테이블로 변환하고 트랜잭션을 구현합니다. 배포, 로그 동기화, 로드 밸런싱, 데이터 백업을 저장하기 위한 HDFS 추가, 로그 저장, 로그 분석 및 검색을 위한 eslaticsearch 추가 등을 모두 논의할 수 있습니다.
일반적인 질문을 할 때, 답변자가 일반적인 질문을 따르면 실패할 것입니다... 논리적으로 대답하는 것이 좋습니다.
저라면 두 가지를 할 것입니다.
1. 이전에 했던 프로젝트를 찾아 그와 병목 현상에 대해 논의한 다음 이론적 지식을 소개하고 마지막으로 해결책을 제시합니다. 이 접근 방식을 사용하면 자신에 대해 쉽게 이야기할 수 있으며 면접관과 어느 정도 상호 작용을 하는 것이 가장 좋습니다. 대화 중 면접관의 질문에 주목하고 면접관이 무엇을 묻는지 명확하게 확인하세요
2. 두 번째 접근 방식은 카드를 먼저 보여주고 트래픽 부하와 같은 보다 고전적인 분산 문제를 꺼내는 것입니다. 사업 보장. . . . 그런 다음 문제에 대한 비즈니스 시나리오를 제공하십시오.