mysql에 대한 높은 동시 쓰기 설계

최근 프로젝트를 개발했습니다. 클라이언트는 10초마다 100행의 데이터를 서버에 제출하고, 서버는 중복 여부를 확인한 후 이를 작성합니다.
수만 명 정도의 클라이언트가 있고 제출된 데이터가 상대적으로 집중되어 있어 데이터를 읽는 문제는 고려되지 않습니다.
현재 디자인은 다음과 같습니다.
데이터베이스는 클라이언트에 따라 테이블로 구분됩니다. 각 테이블의 데이터 양은 많지 않습니다.
서버는 데이터를 얻은 후 먼저 이를 Redis 대기열에 삽입한 다음 예약된 작업을 통해 데이터베이스에 삽입합니다.
질문은 다음과 같습니다.
1. 서버가 클라이언트에 제공하는 인터페이스가 동시에 데이터를 게시하는 수천 명의 클라이언트를 만족시킬 수 있습니까(클라이언트는 10초마다 한 번씩 제출)?
2. 먼저 Redis 대기열에 데이터를 저장합니다. 데이터가 수천만 개이면 Redis가 안정적인가요?
서버가 정상적으로 서비스를 제공할 수 있도록 하는 것이 기본 목표입니다.

---------보충내용------------ --------
이 프로젝트는 주로 사용자 데이터를 수집합니다. 컴퓨터를 켜면 자동으로 실행됩니다.
10초에 한 번씩 100개의 항목을 제출하는 것이 일반적입니다. 일반적으로 사용자는 하루에 10번, 즉 1,000개 이내의 데이터를 제출합니다.
각 데이터 조각은 5~6개의 값 쌍을 포함하며 100자 이내입니다.
일일 데이터의 무결성을 보장해야 합니다. 여러 클라이언트가 동일한 사용자 데이터를 수집하는 상황이 있으므로 중복을 피해야 합니다.

이제 다음을 고려하세요.
데이터 테이블은 사용자별로 테이블로 구분됩니다.
사용자가 제출한 데이터는 사용자에 따라 먼저 Redis 대기열에 저장됩니다. 즉, 각 사용자는 하루에 하나의 대기열을 가지고 있으며 데이터베이스에 저장된 후 대기열이 삭제됩니다.

답글 내용:

최근 프로젝트를 개발했습니다. 클라이언트는 10초마다 100행의 데이터를 서버에 제출하고, 서버는 중복 여부를 확인한 후 이를 작성합니다.
수만 명 정도의 클라이언트가 있고 제출된 데이터가 상대적으로 집중되어 있어 데이터를 읽는 문제는 고려되지 않습니다.
현재 디자인은 다음과 같습니다.
데이터베이스는 클라이언트에 따라 테이블로 구분됩니다. 각 테이블의 데이터 양은 많지 않습니다.
서버는 데이터를 얻은 후 먼저 이를 Redis 대기열에 삽입한 다음 예약된 작업을 통해 데이터베이스에 삽입합니다.
질문은 다음과 같습니다.
1. 서버가 클라이언트에 제공하는 인터페이스가 동시에 데이터를 게시하는 수천 명의 클라이언트를 만족시킬 수 있습니까(클라이언트는 10초마다 한 번씩 제출)?
2. 먼저 Redis 대기열에 데이터를 저장합니다. 데이터가 수천만 개이면 Redis가 안정적인가요?
서버가 정상적으로 서비스를 제공할 수 있도록 하는 것이 기본 목표입니다.

---------보충내용------------ --------
이 프로젝트는 주로 사용자 데이터를 수집합니다. 컴퓨터를 켜면 자동으로 실행됩니다.
10초에 한 번씩 100개의 항목을 제출하는 것이 일반적입니다. 일반적으로 사용자는 하루에 10번, 즉 1,000개 이내의 데이터를 제출합니다.
각 데이터 조각은 5~6개의 값 쌍을 포함하며 100자 이내입니다.
일일 데이터의 무결성을 보장해야 합니다. 여러 클라이언트가 동일한 사용자 데이터를 수집하는 상황이 있으므로 중복을 피해야 합니다.

이제 다음을 고려하세요.
데이터 테이블은 사용자별로 테이블로 구분됩니다.
사용자가 제출한 데이터는 사용자에 따라 먼저 Redis 대기열에 저장됩니다. 즉, 각 사용자는 하루에 하나의 대기열을 가지고 있으며 데이터베이스에 저장된 후 대기열이 삭제됩니다.

1. 삽입을 병합합니다. 하나씩 삽입하지 마세요. 예를 들어 동일한 삽입 작업에 해당하는 1000개의 삽입을 병합하면 상호 작용 횟수가 줄어들 수 있습니다.

2. 이 테이블이 단순 삽입 및 쿼리 작업만 수행하고 트랜잭션 지원이 필요하지 않은 경우 InnoDB와 비교하여 삽입 시 더 높은 성능을 얻을 수 있습니다.

우선 몇 가지 고려사항이 있습니다

1. 대역폭이 충분한가요

2. CPU 수, 코어가 4개이고 php-fpm 수도 4인 경우 각 요청을 처리하는 데 50~150ms가 소요됩니다. 해당 기간 내에 처리되는 대략적인 요청 수를 계산합니다.

3. 메모리는 하나의 프로세스가 10~25M 정도의 메모리를 차지합니다.

고려할 수 있는 사항으로는 로드 밸런싱 및 DNS 폴링이 있습니다. 또한 클러스터의 고가용성에 주의하세요.

둘째, 몇 가지 고려사항이 있습니다

1. 데이터 행, 행의 길이는 어떻게 되나요? Redis는 1k 이상에서는 성능이 저하됩니다.

2. 처리 속도, 큐에 데이터가 얼마나 쌓일지, 메모리를 얼마나 차지할지

3. Redis 아키텍처, 데이터가 손실되지 않도록 보장하는 방법과 고가용성을 달성하는 방법

4. 현재 리소스가 이 솔루션을 허용하는지 여부와 다른 솔루션이 있는지 여부.

동시에 글을 쓸 수 있나요? 그런 다음 활성-활성 활성-활성 모드를 사용하여 동시 쓰기 압력을 50% 줄입니다

MyCat 사용

데이터베이스 샤딩, 일관된 해싱 또는 단순 ID 간격 해싱을 수행하면 충분합니다. 번거롭다면 읽기와 쓰기를 분리하고 로드를 먼저 살펴보세요

큐를 사용해 보시겠습니까?

주제를 보면 데이터 생성이 상대적으로 집중되어 있습니다... 그렇다면 큐 작업을 사용하여 집중된 작업 기간을 약간 연장하는 것을 고려해 볼 수 있습니다... 쓰기를 부드럽게 해보세요... 쓰기를 지연하고 부드럽게 해야 합니다 그리고 읽어보세요 그냥 처리 시간 사이에 합리적인 균형점을 찾으세요... 정말 타협의 여지가 없다면 위에서 언급한 고급 방법을 사용하면 됩니다... 게다가 데이터베이스를 엉망으로 만들고 싶지 않다면 , 먼저 덤프 파일에 쓰기를 시도해 볼 수도 있습니다... 또 다른 가져오기 지원.... 이것이 와일드 경로로 간주되는지는 모르겠습니다....

-1. 한 번에 100개의 항목을 제출하고 10초 안에 처리하는 것은 분명히 상대적으로 긴급합니다. 클라이언트에서 데이터를 캐시하는 것을 고려할 수 있습니다. 사실 위험한 접근 방식입니다.) 예를 들어 항목이 200개라면 20초에 한 번씩 제출합니다.
-2. 서버는 작업 대기열을 사용하여 서버 차단을 줄여 동시성을 향상시킬 수 있습니다. (10초에 한 번씩 제출되므로 높은 동시성이 발생하기 쉽습니다)

-3. 또한 데이터를 자주 읽고 쓰는지 고려해야 합니다. 그렇지 않으면 클러스터 동기화를 수행하는 것이 좋습니다.

-4. 이러한 특수업체는 다른 업체와 서버를 공유해서는 안 됩니다.

-5. 나중에 테이블을 나누는 방법은 귀하의 비즈니스에 따라 다릅니다.