PhxQueue — это распределенная очередь с высокой доступностью, высокой пропускной способностью и высокой надежностью, основанная на протоколе Paxos, исходный код которого открыт WeChat, гарантирует доставку по крайней мере один раз и широко поддерживает платежи WeChat, общедоступные платформы и другие важные направления бизнеса в WeChat.
Адрес с открытым исходным кодом Github:GitHub.com/Tencent/Разрушительный…
Пожалуйста, дайте phxceue звезду! Добро пожаловать, чтобы отправить свои проблемы и PRS!
Обзор очереди сообщений
Как зрелый асинхронный режим связи, очередь сообщений имеет следующие преимущества по сравнению с обычно используемым синхронным режимом связи:
- Разделение: Предотвратите введение слишком большого количества API-интерфейсов, создающих риски для стабильности системы; неправильное использование вызывающей стороной будет оказывать давление на систему вызываемой стороны, а неправильное обращение вызываемой стороной снизит скорость отклика системы вызывающей стороны.
- Пиковое сглаживание и управление потоком: производители сообщений не блокируются, пакетные сообщения буферизуются в очередях, а потребители читают сообщения в соответствии со своими фактическими возможностями.
- Мультиплексирование: публиковать несколько подписок одновременно.
Фон рождения PhxQueue
старая очередь
Распределенная очередь (называемая старой очередью), используемая на начальном этапе WeChat, является важным компонентом собственной разработки WeChat и широко используется в различных бизнес-сценариях для предоставления таких услуг, как развязка, кэширование и асинхронность.
В старой очереди в качестве механизма синхронизации используется Quorum NRW, где N=3, W=R=2, а в методе сброса используется асинхронный сброс, учитывающий производительность и доступность.
новый спрос
С развитием услуг количество видов услуг доступа увеличивается с каждым днем, а старые очереди постепенно становятся неспособными к этому.Основные недостатки заключаются в следующем:
-
Асинхронный флэш-диск, надежность данных вызывает беспокойство
Для предприятий, связанных с платежами, обеспечение надежности данных является основным требованием.
В настоящее время в большинстве решений с распределенными очередями для обеспечения надежности данных используется синхронная репликация + асинхронная очистка диска, но мы считаем, что синхронная очистка диска необходима для дальнейшего повышения надежности данных. -
Проблема с выходом из строя
Некоторые предприятия выдвигают требования к абсолютному порядку, но NRW не гарантирует порядок и не может выполнить требования.
Кроме того, в старой очереди все еще есть другие проблемы, такие как дедупликация, балансировка нагрузки и т. д., которые необходимо улучшить. Все вышеперечисленное побудило нас рассмотреть новые варианты.
Слабые стороны отраслевых решений
Kafka — широко используемая очередь сообщений в области больших данных, изначально разработанная LinkedIn на языке Scala и используемая в качестве основы для отслеживания потока операций LinkedIn и конвейера обработки данных операционной системы.
Его функции, такие как высокая пропускная способность, автоматическое аварийное восстановление и упорядоченный вход и выход, привлекли многие компании к его использованию и играют важную роль в сценариях сбора и передачи данных.Подробнее см. Powered By Kafka.
Однако мы полностью исследовали Kafka и считаем, что в сценарии сосредоточения внимания на надежности данных у нее есть следующие недостатки:
1. Противоречие между производительностью Kafka и синхронной очисткой
После того, как Kafka включил конфигурацию log.flush.interval.messages=1 и включил функцию синхронной очистки, пропускная способность резко упадет.
Это явление вызывается следующими факторами:
-
Усиление записи SSD
Средний размер деловых сообщений составляет около 1k.
Минимальная единица мигания SSD за раз — это размер страницы, а размер — 4 КБ.
Когда Kafka сбрасывает сообщение, размер которого меньше 4 КБ, фактический объем записанных физических данных в несколько раз превышает размер сообщения. В результате ресурсы пропускной способности записи на жесткий диск тратятся впустую. -
Партия производителя плохо работает в бизнес-сценариях
Проще говоря, пакет Kafka Producer состоит в том, чтобы упаковать несколько сообщений вместе и отправить их брокеру, который широко используется в сценариях с большими данными. Логически, пакетного эффекта достаточно, чтобы компенсировать эффект усиления записи.
Однако создание сообщений в бизнес-сценариях отличается от создания журналов в сценариях с большими данными.Каждый бизнес-запрос, который необходимо поставить в очередь, имеет независимый контекст в бизнес-системе, что затрудняет пакетную обработку. Даже если между бизнесом и брокером добавляется уровень агента, а источник передается на уровень агента для пакетной обработки, эффект пакетной обработки трудно улучшить из-за большого количества узлов на уровне агента, что приводит к усилению записи. что не может быть компенсировано.
2. Неадекватность схемы синхронизации реплик Kafka
Схема синхронизации реплик Kafka:
Лидер Kafka Broker отслеживает список последователей, с которыми он синхронизируется, что называется ISR (синхронизированная реплика). Если ведомый проигрывает или слишком сильно отстает, лидер удалит его из ISR.
Этот метод синхронизации ориентирован на эффективность синхронизации, но немного недостаточен с точки зрения удобства использования:
-
Уровень успеха процесса аварийного переключения брокера значительно снизился.
В сценарии 3 реплики лидеры распределяются равномерно на каждом Брокере.Если один Брокер выходит из строя, это означает, что 1/3 лидеров и фолловеров находятся в офлайне.В это время успешность чтения и записи снижается:- Для раздела с отключенным лидером временно невозможно чтение и запись, и перед восстановлением необходимо дождаться выбора контроллером нового лидера;
- Для автономного раздела фолловера временно невозможно чтение и запись.После ожидания определенного периода времени (зависит от replica.lag.time.max.ms, по умолчанию 10 с) лидер удаляет неисправный фолловер из ISR для восстановления.
То есть, когда какой-либо брокер выходит из строя, вероятность успешного чтения и записи упадет до 0 на некоторое время.
- Задержка синхронизации зависит от самого медленного узла
В сценарии синхронной репликации вам нужно дождаться, пока все узлы вернут подтверждение.
Сравнивая производительность реплики Kafka и Paxos,Мы считаем, что Paxos — лучший выбор с точки зрения синхронизации:
Поэтому на основе старой очереди мы трансформировали логику синхронизации с протоколом Paxos и провели ряд оптимизаций, включая синхронную очистку для завершения PhxQueue.
Введение в PhxQueue
В настоящее время PhxQueue широко поддерживает платежи WeChat, общедоступные платформы и другие важные бизнес-направления внутри WeChat, при этом средняя ежедневная очередь составляет 100 миллиардов человек, а пик — 100 миллионов в минуту.
Отправной точкой его проектирования является высокая надежность данных, отсутствие возможности использования и высокая пропускная способность, а также поддержка различных общих кварталов.
Функции, поддерживаемые PhxQueue, следующие:
- Синхронная очистка, данные никогда не будут потеряны, с внутренним согласованием в реальном времени
- Строго организованный вход и выход
- несколько подписок
- Ограничение скорости отправления
- Удалить из очереди повтор
- Все модули можно расширять параллельно
- Слой хранилища можно обновлять и синхронизировать в пакетном режиме для обеспечения высокой пропускной способности.
- Уровень хранения поддерживает многоцентровое развертывание в одном городе.
- Автоматическое аварийное восстановление/баланс доступа на уровне хранилища
- Автоматическое аварийное восстановление/балансировка нагрузки потребителя
PhxQueue Дизайн
Общая структура
PhxQueue состоит из следующих 5 модулей.
- Магазин - магазин очереди
В качестве хранилища очередей используется Store, а для синхронизации копий с протоколом Paxos введена библиотека PhxPaxos. Пока большинство узлов работают и взаимосвязаны, могут предоставляться линейно согласованные услуги чтения и записи.
Для повышения надежности данных синхронная очистка диска включена по умолчанию, и ее производительность не ниже, чем асинхронная очистка диска.
С точки зрения доступности, в Store есть несколько независимых групп paxos. В каждой группе paxos только мастер предоставляет услуги чтения и записи. Обычно мастера динамически и равномерно распределяются между узлами в Store, чтобы сбалансировать давление доступа. Когда узел выходит из строя, он автоматически переключает мастер на другие доступные узлы.
- Продюсер - производитель
Как производитель сообщения, Производитель определяет маршрут хранения сообщения в соответствии с ключом. Сообщения с одним и тем же ключом направляются в одну и ту же очередь по умолчанию, гарантируя, что порядок исключения из очереди такой же, как и порядок постановки в очередь.
- Потребитель - потребитель
Как потребитель, Потребитель извлекает сообщения из Магазина в пакетном режиме и поддерживает пакетную обработку сообщений в режиме с несколькими сопрограммами.
Потребитель предоставляет услуги в виде структуры услуг, а пользователи определяют конкретную логику обработки сообщений в соответствии с различными темами (темами) и различными типами обработки (обработчиками) путем реализации обратных вызовов.
- Планировщик – диспетчер потребителей (дополнительное развертывание)
Роль Планировщика заключается в сборе информации о глобальной нагрузке Потребителя и выполнении аварийного восстановления и балансировки нагрузки для Потребителя. Когда у пользователя нет этого требования, планировщик развертывания может быть опущен.В это время каждый потребитель определяет отношение обработки с очередью в соответствии с весом конфигурации.
После развертывания планировщика лидер планировщика поддерживает пульсацию со всеми потребителями и в обратном порядке регулирует отношение обработки между потребителем и очередью, собирая информацию о загрузке потребителя.
Когда лидер планировщика выходит из строя, планировщик полагается на следующую службу распределенной блокировки для выбора нового лидера.В период недоступности это влияет только на аварийное восстановление и балансировку нагрузки потребителя, но не влияет на обычное потребление потребителя.
- Блокировка — распределенная блокировка (дополнительное развертывание)
Lock – это распределенная блокировка. Его интерфейс очень общий. Пользователи могут развертывать Lock независимо друг от друга, чтобы предоставлять общие службы распределенной блокировки.
Роль Lock в PhxQueue следующая:
(1) Выберите лидера планировщика;
(2) Предотвращение одновременной обработки очереди несколькими потребителями.
Lock также является необязательным развертываемым модулем:
Если Планировщик развернут, необходимо развернуть Блокировку, чтобы выбрать лидера для Планировщика;
В противном случае, если бизнес не чувствителен к повторному потреблению, вы можете не развертывать блокировку.
Упомянутый здесь сценарий повторного потребления: если развертывание планировщика опущено, потребителю необходимо знать набор очередей, которые могут быть обработаны, путем чтения конфигурации; когда очередь изменяется (например, очередь сжимается и расширяется) , изменения конфигурации на каждой машине-потребителе должны быть изменены в первую очередь.После этого статус конфигурации, видимый каждым потребителем в одно и то же время, может быть разным, что приводит к тому, что два потребителя думают, что они должны использовать одну и ту же очередь в течение определенного периода времени. , что приводит к повторному потреблению. Развертывание блокировки позволяет избежать повторного использования в этом сценарии. (Обратите внимание, что даже если блокировка развертывания опущена, этот сценарий вызывает только повторное потребление, а не потребление не по порядку)
Процесс репликации магазина
PhxQueue Store реплицируется по протоколу PhxPaxos.
Инженерная реализация PhxPaxos разделена на три уровня: уровень приложений отвечает за обработку бизнес-запросов, уровень paxos выполняет процесс синхронизации paxos, а уровень конечного автомата обновляет бизнес-статус.
Среди них уровень приложений инициирует предложение paxos, каждый узел уровня paxos завершает подтверждение журнала paxos через протокол paxos, а затем конечный автомат использует журнал paxos в качестве входных данных для передачи состояния, обновляет состояние бизнеса, и, наконец, возвращает результат передачи состояния на уровень приложения.
Согласованный уровень конечного автомата в сочетании с согласованным вводом от уровня paxos создает согласованные переходы состояний, тем самым обеспечивая строгую согласованность между несколькими узлами.
Здесь мы хотим реализовать очередь на уровне конечного автомата на основе PhxPaxos, нам нужно сопоставить следующие понятия:
- Модель очереди не предполагает модификации данных.Это упорядоченный набор данных, что очень похоже на определение журнала paxos, поэтому данные, поступающие в очередь, могут быть напрямую использованы как журнал paxos, а конечный автомат должен только сохранить последовательность журнала paxos.
- Строго увеличивающийся характер идентификатора экземпляра делает его удобным в качестве смещения очереди.
- Данные перед смещением чтения в очереди считаются данными, которые можно удалить, что соответствует определению контрольной точки.
В целом автомат очереди и paxos прекрасно подходят друг другу.
Store Group Commit — эффективная очистка и синхронизация копирования
Неоптимизированный протокол Paxos не решает проблему увеличения записи при синхронной перепрошивке. Более того, его эффективность синхронизации реплик не так хороша, как у Kafka.
Причина в том, что синхронизация реплик Kafka осуществляется пакетно, в то время как протокол Paxos последовательно синхронизируется в единицах журналов paxos, а накладные расходы на синхронизацию каждого журнала paxos составляют 1 RTT + 1 сброс.
В сценарии развертывания с несколькими контроллерами домена задержка проверки связи может достигать 4 мс, что приведет к теоретическому максимальному значению TPS всего 250 для одной группы paxos.
Мы используем групповое развертывание с несколькими Paxos и групповую фиксацию, чтобы одновременно решить проблему увеличения записи и пропускной способности Paxos.
Как показано на рисунке выше, мы развертываем несколько групп paxos и используем группу paxos в качестве единицы групповой фиксации.Одна группа paxos соответствует нескольким очередям и объединяет данные, которые несколько очередей вошли в очередь за определенный период времени. При ожидании длительных или накопленных данных. Когда количество данных достигает порогового значения, синхронизация Paxos и синхронная очистка будут запущены один раз, а внешний интерфейс будет заблокирован в течение периода ожидания.
По сравнению с пакетной логикой Kafka Producer преимущества пакетного слияния с Group Commit на уровне хранилища заключаются в следующем:
(1) Бизнес-уровню не нужно обращать внимание на то, как организовать запросы на пакетную обработку;
(2) Эффект агрегации в единице группы paxos на уровне хранения лучше, чем на верхнем уровне.
PhxQueue против Кафки
Ниже сравниваются PhxQueue и Kafka по трем аспектам: дизайн, производительность и процесс аварийного переключения на уровне хранилища.
Сравнение дизайна
Хотя архитектура PhxQueue похожа на обычные распределенные очереди, такие как Kafka, в ней по-прежнему много уникальных конструктивных особенностей. Чтобы читателям, имеющим некоторое представление о Kafka, было проще понять PhxQueue, сравнение между ними приведено ниже.
Примечание. Следующие сравнения основаны на одном и том же сценарии надежности данных: сбой меньшинства узлов не приведет к потере данных, и все по-прежнему доступно.
Сравнение производительности
тестовая среда
CPU: 64 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Memory: 64 GB
Network: 10 Gigabit Ethernet
Disk: SSD Raid 10
Cluster Nodes: 3
Ping: 1ms
Тестовые тесты и конфигурации
Результаты теста
Запустить производственную партию:
Отключить пакет производителей:
В приведенном выше сценарии узким местом PhxQueue является процессор, а уровень использования составляет 70% ~ 80%.
резюме
- Производительность PhxQueue не уступает Kafka;
- При том же QPS среднее потребление времени у PhxQueue немного лучше, чем у Kafka, потому что нет необходимости ждать возврата самого медленного узла;
- После отключения Producer Batch производительность PhxQueue может достигать 2 раз выше, чем у Kafka в сценарии с синхронной очисткой диска.Причина в том, что уровень хранения PhxQueue делает батчи перед записью на диск, а Kafka нет, поэтому последний будет есть усиление записи.
Сравнение процессов аварийного переключения уровня хранения
В основном сравните влияние на общую пропускную способность после отключения узла уровня хранения.
Kafka
Представление:
- В период Failover степень успеха на разных этапах варьируется от 0% до 33%;
- Продолжительность аварийного переключения определяется арендой, а продолжительность аренды по умолчанию равна 10 с.
Процесс тестирования:
Измените replica.lag.time.max.ms с 10 на 60 с (увеличив время для удобства наблюдения), затем уничтожьте брокера 0, выберите 3 раздела и наблюдайте за изменениями ISR следующим образом:
第一阶段（未 kill Broker 0）：
Topic: test-dis-p100 Partition: 96 Leader: 0 Replicas: 0,1,2 Isr: 1,0,2
Topic: test-dis-p100 Partition: 97 Leader: 1 Replicas: 1,2,0 Isr: 1,0,2
Topic: test-dis-p100 Partition: 98 Leader: 2 Replicas: 2,0,1 Isr: 1,0,2
第二阶段（kill Broker 0 后持续8s）：
Topic: test-dis-p100 Partition: 96 Leader: 0 Replicas: 0,1,2 Isr: 1,0,2
Topic: test-dis-p100 Partition: 97 Leader: 1 Replicas: 1,2,0 Isr: 1,0,2
Topic: test-dis-p100 Partition: 98 Leader: 2 Replicas: 2,0,1 Isr: 1,0,2
第三阶段（持续1分钟左右）：
Topic: test-dis-p100 Partition: 96 Leader: 1 Replicas: 0,1,2 Isr: 2,1
Topic: test-dis-p100 Partition: 97 Leader: 1 Replicas: 1,2,0 Isr: 2,1,0
Topic: test-dis-p100 Partition: 98 Leader: 2 Replicas: 2,0,1 Isr: 2,1,0
第四阶段（至此入队成功率完全恢复）：
Topic: test-dis-p100 Partition: 96 Leader: 1 Replicas: 0,1,2 Isr: 2,1
Topic: test-dis-p100 Partition: 97 Leader: 1 Replicas: 1,2,0 Isr: 2,1
Topic: test-dis-p100 Partition: 98 Leader: 2 Replicas: 2,0,1 Isr: 2,1
Среди них вероятность успеха раздела, соответствующего красной отметке на втором/третьем этапе, нарушена:
- На втором этапе Partition 96/97/98 не мог быть записан, а вероятность успешного присоединения к команде упала до 0%.
- На третьем этапе раздел 96 может продолжать запись, но раздел 97/98 не может записывать, потому что запись должна ждать, пока брокер 0 ответит, но брокер 0 был убит, и вероятность успешного присоединения к очереди падает до 33%.
Фактическое наблюдение показывает, что на втором и третьем этапах пропускная способность вообще отсутствует, потому что инструмент проверки давления продолжает сообщать об ошибках соединения и прекращает запись.
Вывод инструмента стресс-тестирования:
30551 records sent, 6107.8 records/sec (0.06 MB/sec), 1733.9 ms avg latency, 5042.0 max latency.
30620 records sent, 6117.9 records/sec (0.06 MB/sec), 1771.9 ms avg latency, 5076.0 max latency.
30723 records sent, 6123.8 records/sec (0.06 MB/sec), 1745.4 ms avg latency, 5009.0 max latency.
30716 records sent, 6127.3 records/sec (0.06 MB/sec), 1841.1 ms avg latency, 5299.0 max latency.
30674 records sent, 6133.6 records/sec (0.06 MB/sec), 1621.3 ms avg latency, 4644.0 max latency.
>>> kill Broker 0 here （入队成功率受损）>>>
10580 records sent, 123.4 records/sec (0.00 MB/sec), 1537.1 ms avg latency, 84236.0 max latency. <<---吞吐下降严重
11362 records sent, 132.3 records/sec (0.00 MB/sec), 1658.3 ms avg latency, 84232.0 max latency.
11367 records sent, 132.3 records/sec (0.00 MB/sec), 1582.4 ms avg latency, 84228.0 max latency.
11236 records sent, 130.9 records/sec (0.00 MB/sec), 1694.2 ms avg latency, 84240.0 max latency.
11406 records sent, 132.8 records/sec (0.00 MB/sec), 1650.5 ms avg latency, 84233.0 max latency.
Журнал отказов средства измерения давления при подключении к Брокеру:
[2017-08-16 15:38:22,844] WARN Connection to node 0 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
[2017-08-16 15:38:22,859] WARN Connection to node 0 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
Анализ причин:
Лидер Kafka Broker избирается контроллером, а список ISR поддерживается лидером.
Аренда первого определяется контроллером, а аренда второго определяется конфигурацией брокера replica.lag.time.max.ms.
Поэтому продолжительность второго этапа меньше, что определяется временем аренды Контроллера, а продолжительность третьего этапа больше, что определяется параметром replica.lag.time.max.ms.
Когда Брокер 0 убит, первый влияет на вероятность успеха 1/3 перегородок, где Брокер 0 является лидером, а второй влияет на вероятность успеха 2/3 перегородок, где Брокер 0 является последователем.
PhxQueue
Представление:
- В период аварийного переключения вероятность успешного присоединения к команде снизилась только до 66%;
- Продолжительность аварийного переключения определяется арендой, а продолжительность аренды по умолчанию равна 5 с.
- После включения функции повторных попыток изменения очередей (подходит для служб без требований абсолютной последовательности для повышения доступности) вероятность успешного создания очередей по-прежнему составляет 90+% в течение периода отработки отказа.
Процесс тестирования:
Настройте продолжительность аренды Мастера Магазина с 10 до 60 секунд (расширенное время удобно для наблюдения), затем уничтожьте магазин 0 и наблюдайте за успешностью присоединения Продюсера к команде:
Отключите функцию повтора смены очередей:
>>> kill store 0 here （入队成功率受损）>>>
-------------------------------------------
-- total: 192323
-- time(ms): 10015
-- qps: 19203.49
-- routine_sleep: 73.88%
-- retcode cnt percent
-- -1 22097 11.49 <<--- 失败：连接失败
-- 0 125905 65.47 <<--- 成功：仍有66%成功率
-- 10102 44321 23.05 <<--- 失败：提示需要重定向到 master
-- usetime(ms) cnt percent
-- < 1 0 0.00
-- < 2 0 0.00
-- < 5 610 0.32
-- < 10 7344 3.82
-- < 20 18937 9.85
-- < 50 36067 18.75
-- < 100 6971 3.62
-- < 200 20239 10.52
-- < 500 59059 30.71
-- < 1000 30601 15.91
-- >= 1000 12495 6.50
>>> （入队成功率完全恢复）>>>
-------------------------------------------
-- total: 198955
-- time(ms): 10001
-- qps: 19893.51
-- routine_sleep: 98.00%
-- retcode cnt percent
-- 0 198955 100.00 <<--- 成功：100%成功率
-- usetime(ms) cnt percent
-- < 1 0 0.00
-- < 2 2 0.00
-- < 5 5895 2.96
-- < 10 30830 15.50
-- < 20 65887 33.12
-- < 50 95403 47.95
-- < 100 753 0.38
-- < 200 185 0.09
-- < 500 0 0.00
-- < 1000 0 0.00
-- >= 1000 0 0.00
Включите функцию повтора изменения очередей:
>>> kill store 0 here （入队成功率受损）>>>
-------------------------------------------
-- total: 134752
-- time(ms): 10001
-- qps: 13473.85
-- routine_sleep: 77.43%
-- retcode cnt percent
-- -202 14 0.01 <<--- 失败：超时
-- -1 2712 2.01 <<--- 失败：连接失败
-- 0 127427 94.56 <<--- 成功：仍有94%成功率
-- 10102 4572 3.39 <<--- 失败：提示需要重定向到 master
-- 10105 27 0.02 <<--- 失败：master 未选举出来
-- usetime(ms) cnt percent
-- < 1 0 0.00
-- < 2 4 0.00
-- < 5 3284 2.44
-- < 10 10704 7.94
-- < 20 22109 16.41
-- < 50 32752 24.31
-- < 100 4541 3.37
-- < 200 4331 3.21
-- < 500 11265 8.36
-- < 1000 19706 14.62
-- >= 1000 26056 19.34
>>> （入队成功率完全恢复）>>>
-------------------------------------------
-- total: 198234
-- time(ms): 10014
-- qps: 19795.69
-- routine_sleep: 94.36%
-- retcode cnt percent
-- 0 198234 100.00 <<--- 成功：100%成功率
-- usetime(ms) cnt percent
-- < 1 0 0.00
-- < 2 0 0.00
-- < 5 3875 1.95
-- < 10 22978 11.59
-- < 20 53000 26.74
-- < 50 87575 44.18
-- < 100 6204 3.13
-- < 200 6468 3.26
-- < 500 11963 6.03
-- < 1000 5637 2.84
-- >= 1000 534 0.27
резюме:
В процессе аварийного переключения уровня хранилища показатели успешности PhxQueue и Kafka снизились в течение определенного периода времени.Показатель успешности PhxQueue составляет 66–100%, а показатель успешности Kafka составляет 0–33%;
После того, как PhxQueue включает функцию повторной попытки изменения очереди, вероятность успешного присоединения к очереди в процессе отработки отказа остается на уровне 90+%;
И PhxQueue, и Kafka могут автоматически переключать мастера, и, наконец, вероятность успешного присоединения к очереди полностью восстанавливается.
резюме
PhxQueue приложил немало усилий на уровне хранилища: он реализует автоматическое переключение мастеров, при этом гарантирует линейную согласованность и высокую доступность в период переключения, обеспечивает пропускную способность синхронного сброса, а его производительность не ниже, чем у асинхронного сброса. .
Кроме того, реализовано большинство практических функций очереди, таких как последовательный вход и выход из очереди, множественные подписки, ограничение скорости, повтор сообщений и т. д., которые подходят для различных бизнес-сценариев.
В настоящее время PhxQueue широко используется в WeChat, а также официально имеет открытый исходный код.
Мы будем поддерживать версию PhxQueue с открытым исходным кодом в соответствии с внутренней версией, и читатели могут попробовать ее и оставить отзыв.
Адрес с открытым исходным кодом Github:GitHub.com/Tencent/Разрушительный…
Пожалуйста, дайте PhxQueue звезду!
Добро пожаловать, чтобы представить свой вопрос и PR
Перепечатано из публичной учетной записи [Tencent Open Source], официальной информации Tencent с открытым исходным кодом, с нетерпением жду вашего внимания.