Горячие точки интервью очереди сообщений: как обеспечить порядок сообщений?

Java
Горячие точки интервью очереди сообщений: как обеспечить порядок сообщений?

Эта статья написанаyanglbmeНачалось вДокументы технического сообщества GitHub, текущие звезды превысили 30k.
адрес проекта:GitHub.com/ohohgenerate/advpress…

stars

вопросы интервью

Как обеспечить порядок сообщений?

Психологический анализ интервьюера

Это тема, которую необходимо задать, когда вы спрашиваете об очередях сообщений.Во-первых, вы понимаете порядок? Во-вторых, посмотрите, есть ли у вас способ убедиться, что сообщения упорядочены? Это распространенная проблема в производственных системах.

Анализ вопросов интервью.

Позвольте мне привести пример, мы использовали mysqlbinlogДавление системы синхронизации по-прежнему очень велико, ежедневные данные синхронизации должны достигать сотен миллионов, то есть данные синхронизируются из одной базы данных mysql в другую базу данных mysql (mysql -> mysql). Общим моментом является то, что, например, команде больших данных необходимо синхронизировать базу данных mysql для выполнения различных сложных операций с данными бизнес-системы компании.

Вы добавляете, удаляете или изменяете часть данных в mysql, что соответствует трем добавлениям, удалениям и изменениям.binlogжурнал, то эти триbinlogОтправьте его в MQ, а затем потребляйте и выполняйте его последовательно.По крайней мере, убедитесь, что люди приходят по порядку, верно? В противном случае изначально было: добавить, изменить, удалить; вы просто изменили порядок удаления, изменения и добавления, не так ли все неправильно.

Изначально данные были синхронизированы, а в конце данные должны быть удалены, в итоге вы ошиблись в этом порядке, и в итоге данные сохранились, и синхронизация данных пошла не так.

Давайте рассмотрим два сценария, в которых порядок будет нарушен:

  • RabbitMQ: Одна очередь, несколько потребителей. Например, производитель отправляет три фрагмента данных в RabbitMQ в следующем порядке: данные1/данные2/данные3, и они помещаются в очередь памяти RabbitMQ. Есть три потребителя, которые потребляют одну из трех частей данных из MQ соответственно, в результате потребитель 2 завершает операцию первым, сохраняет в базе данных данные2, а затем данные1/данные3. Это явно не перепутано.

  • Kafka: Например, мы создали тему с тремя разделами. Когда производитель пишет, он может указать ключ, например, если мы укажем идентификатор заказа в качестве ключа, то данные, относящиеся к этому заказу, будут распределены в тот же раздел, и данные в этом разделе должны быть чтобы.
    Когда потребители извлекают данные из раздела, они должны быть в порядке. Здесь с порядком еще все в порядке, путаницы нет. Затем мы могли бы заняться потребительскимНесколько потоков для одновременной обработки сообщений. Потому что, если потребитель является однопоточной обработкой потребления, и обработка занимает много времени, например, обработка сообщения занимает десятки мс, то за 1 секунду можно обработать только десятки сообщений, что является слишком низкой пропускной способностью. Если несколько потоков выполняются одновременно, порядок может быть нарушен.

решение

RabbitMQ

При разделении нескольких очередей один потребитель на очередь — это просто больше очередей, что действительно проблематично, или одна очередь, но один потребитель, а затем потребитель ставится в очередь внутри с помощью очереди памяти, а затем распределяется между различными базовыми рабочими процессами.

Kafka

  • Одна тема, один раздел, один потребитель, внутреннее однопоточное потребление, однопоточная пропускная способность слишком низкая, обычно не используйте это.
  • Напишите N очередей памяти, и данные с одним и тем же ключом попадают в одну и ту же очередь памяти, тогда для N потоков каждый поток потребляет одну очередь памяти отдельно, так что последовательность может быть гарантирована.


Добро пожаловать в мою общедоступную учетную запись WeChat «Сообщество открытого исходного кода Doocs». ​​Оригинальные технические статьи будут опубликованы как можно скорее.