mysql은 메시지 순서를 어떻게 보장합니까?

예를 들어보겠습니다. 이전에 mysql binlog 동기화 시스템을 구축했는데 일일 동기화 데이터가 수억 개에 도달해야 한다는 부담이 여전히 매우 높습니다. mysql 라이브러리에서 그대로 동기화됩니다. 다른 mysql 라이브러리(mysql -> mysql)로 이동합니다. 공통점은 예를 들어 빅 데이터 팀이 회사 비즈니스 시스템의 데이터에 대해 다양하고 복잡한 작업을 수행하려면 mysql 라이브러리를 동기화해야 한다는 것입니다. binlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作。

你在 mysql 里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog

mysql에서 데이터를 추가, 삭제, 수정하면 추가, 삭제, 수정에 따라 세 개의 binlog 로그가 생성됩니다. MQ로 전송된 후 순차적으로 소비되고 실행됩니다. 최소한 사람들이 순서대로 오도록 해야겠죠? 그렇지 않으면 원래는 추가, 수정, 삭제였는데 순서만 바꿔서 삭제, 수정, 추가로 실행한 것 뿐이죠.

원래는 이 데이터를 동기화할 때 마지막에 데이터를 삭제했어야 했는데, 결과적으로 순서를 잘못 입력하셔서 결국 데이터가 유지가 되면서 데이터 동기화가 잘못됐는데요.

먼저 주문이 잘못되는 두 가지 시나리오를 살펴보겠습니다.

• RabbitMQ: 하나의 대기열, 여러 소비자. 예를 들어, 생산자는 data1/data2/data3 순서로 세 개의 데이터를 RabbitMQ로 보내고, 그 내용은 RabbitMQ의 메모리 큐에 푸시됩니다. MQ의 세 가지 데이터 중 하나를 소비하는 세 명의 소비자가 있습니다. 결과적으로 소비자 2가 먼저 작업을 완료하고 data2를 데이터베이스에 저장한 다음 data1/data3을 저장합니다. 이것은 확실히 엉망이 아닙니다.

• 
  Kafka: 예를 들어, 세 개의 파티션이 있는 주제를 만들었습니다. 생산자가 글을 작성할 때 실제로 키를 지정할 수 있습니다. 예를 들어 주문 ID를 키로 지정하면 이 주문과 관련된 데이터는 확실히 동일한 파티션에 배포되며 이 파티션의 데이터는 거기에 있어야 합니다. 명령이다.

  소비자가 파티션에서 데이터를 꺼낼 때는 순서가 맞아야 합니다. 이 시점에서는 순서가 여전히 괜찮고 혼란이 없습니다. 다음으로 소비자에서 메시지를 동시에 처리하기 위해 여러 스레드를 생성할 수 있습니다. 왜냐하면 소비자가 단일 스레드에서 소비하고 처리하는 데 시간이 많이 걸리기 때문입니다. 예를 들어 메시지를 처리하는 데 수십 ms가 걸리면 1초에 수십 개의 메시지만 처리할 수 있어 처리량이 너무 낮습니다. . 여러 스레드가 동시에 실행되면 순서가 엉망이 될 수 있습니다.

솔루션

RabbitMQ

여러 대기열을 분할하면 각 대기열에 하나의 소비자가 있는데 이는 단지 더 많은 대기열입니다. 이는 실제로 문제가 되는 지점입니다. 또는 대기열은 하나만 있지만 하나의 소비자에 해당하며 이 소비자는 대기열을 위해 내부적으로 메모리 대기열을 사용합니다. 그런 다음 이를 처리하기 위해 다른 기본 작업자에게 배포합니다.

카프카

• 토픽, 파티션, 소비자, 내부 단일 스레드 소비, 단일 스레드 처리량이 너무 낮아 일반적으로 사용되지 않습니다.

• N개의 메모리 큐를 작성하면 동일한 키를 가진 데이터가 동일한 메모리 큐로 이동합니다. 그런 다음 N개의 스레드에 대해 각 스레드는 각각 하나의 메모리 큐를 소비하므로 순서가 보장됩니다.

🎜

위 내용은 mysql은 메시지 순서를 어떻게 보장합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!