для чего нужны очереди сообщений
Очередь сообщений (Message Queue)
Очередь сообщений (Message Queue)
Этот пост рассказывает об очередях сообщений — почему вы должны знать о них, думать при планировании архитектуры и использовать их в вашем приложении.
Почему очереди сообщений?
Сообщения, наряду с блоками вычисления и хранения, составляют три основных блока почти в каждой блок-схеме системы. Очереди сообщений, по существу, являются связующим звеном между различными процессами в ваших приложениях и обеспечивают надежный и масштабируемый интерфейс взаимодействия с другими подключенными системами и устройствами.
О́чередь — структура данных с дисциплиной доступа к элементам «первый пришёл — первый вышел». Добавление элемента возможно лишь в конец очереди, выборка — только из начала очереди, при этом выбранный элемент из очереди удаляется.
Использование очереди сообщений
Почему SaaS?
Добавление очереди сообщений для облачных приложений имеет смысл, только если есть чистый выигрыш в плане установки и эксплуатации. Добавление дополнительного архитектурного слоя отвечающего за очереди сообщений — непростая задача, особенно если вы решили использовать собственное решение или установить на свои сервера стороннее, так как это привнесёт дополнительные затраты на мониторинг, настройку, управление и повлияет на общую надёжность и безопасность системы.
Когда очереди сообщений легки в установке, просты в использовании, высоко доступны и чрезвычайно надёжны — все становиться гораздо проще.
Тут уместна аналогия получения энергии. Прогресс шёл от ветряных мельниц и угольных печей до промышленных электростанций и линий электропередач.Этот последний шаг — индустриализация энергии — изменило лик промышленности в мире. Это снизило затраты на строительство и производство, изменило города, заводы, и дома, и позволило создать новые изобретения, услуги и виды бизнеса.
Аналогичным образом, путём подключения служб очередей сообщений, разработчики больше не должны поддерживать огромный наборов сервисов, работающих на нескольких серверах и не опасаться простоя в результате отказа систем. В современном мире поставщики услуг берут на себя ответственность за управления серверами, API и другими ресурсами, а разработчик абстрагируясь от большинства физических ограничений может сконцентрироваться на реализации своей идеи.
Преимущества перехода на облачные очереди сообщений включают в себя:
С чего начать?
PS Я надеюсь мне удалось заронить каплю сомнения в выбор «поставить свой сервер MQ или использовать сторонний сервис» и заинтересовать в существующих SaaS решениях в области очередей сообщений.
Очереди сообщений в бэкенд-архитектуре: как построить надежную систему
Очереди сообщений — устоявшаяся технология, которую разработчики применяют уже много лет. Разберемся, как она работает.
Почему понадобились очереди сообщений
Серверные сообщения обычно устроены просто и однотипно: сервер получает запрос, обрабатывает его и сразу же возвращает клиенту. Схема хорошо работает до тех пор, пока обработка запроса занимает немного времени, например доли секунды.
Но бывает, что вернуть ответ клиентскому приложению сразу невозможно. Например, когда сервер обрабатывает видео — это может занять минуты и даже часы. На время обработки большого объема данных вычислительные ресурсы сервера загружены и его способность обрабатывать входящие запросы падает.
Что такое обмен серверными сообщениями и как он устроен
Допустим, серверное приложение получило тяжелый запрос. Оно передает его другим приложениям дальше по цепочке, а само продолжает общение с клиентом.
Для передачи сообщения другим приложениям используют специальный инструмент — очереди сообщений. Эта технология решает любые инфраструктурные вопросы:
Когда в вашем бэкенд-приложении задействованы очереди, обработка видео выглядит так:
Схема асинхронного обмена сообщениями между приложениями. Источник
FIFO и LIFO (ФИФО и ЛИФО) — что это такое
Сервисы обмена сообщениями между серверами делятся на два типа:
Сервисы для организации очередей сообщений
Популярные сервисы для организации очередей сообщений — RabbitMQ, Apache Kafka и Redis. Давайте посмотрим, чем они различаются.
RabbitMQ
Сервер организации очередей сообщений, написанный на языке программирования Erlang. Это распределенный и горизонтально масштабируемый брокер сообщений. Он позволяет разным программам взаимодействовать с помощью протокола AMQP, а через дополнительные модули — и с помощью некоторых других протоколов: MQTT, HTTP и так далее.
RabbitMQ — это инструмент, который силен в маршрутизации сообщений. Система поддерживает несколько видов распределения сообщений в сети, их комбинация позволяет создавать очень хитрые правила доставки сообщений.
Apache Kafka
Apache Kafka — продукт, который реализует систему распределенного журнала событий. Kafka славится своей скоростью работы и масштабируемостью. Из-за способности передавать терабайты данных эту систему очередей сообщений любят разработчики, работающие с Big Data. Например, ее используют в Airbnb, Adidas, Cisco и PayPal.
Redis
Redis создавалась как система хранения данных в оперативной памяти. Изначальное предназначение — ускорение доступа к востребованной информации и построение систем кеширования.
Но разработчики добавили в код возможность построения простых очередей и стеков. В итоге Redis применяют в качестве сервера очередей сообщений в проектах, где нужно быстро и дешево проверить инженерные гипотезы по работе с очередями.
Зачем нужны очереди сообщений в микросервисной архитектуре: разбираем преимущества и недостатки
При проектировании микросервисов часто возникает вопрос: какой способ связи между ними выбрать.
Многие отдают предпочтение RESTful API. Однако этот подход не всегда эффективен, так как в отдельных случаях чреват долгим ожиданием на клиентской стороне и потерей информации в случае сбоев.
Мы расскажем про такой вариант для взаимодействия микросервисов, как очереди сообщений, а также попытаемся выяснить, для каких сценариев они подходят лучше всего. Разобраться в вопросе нам помог Павел Юдин, руководитель команды облачных продуктов, Tarantool / VK.
Sync vs Async: синхронное и асинхронное взаимодействие
Очереди сообщений (Message Queue) — это форма асинхронной коммуникации между сервисами. Поэтому, прежде чем говорить о них, покажем на упрощенном, немного искусственном примере разницу между синхронным и асинхронным взаимодействием.
Предположим, вы разрабатываете сайт книжного магазина и у вас есть сервис, к которому обращается пользователь, например отправка рецензии на прочитанную книгу. При нажатии кнопки «Отправить» вызывается некоторый API, который, в свою очередь, может обратиться к другим API.
При синхронном взаимодействии все запросы в этой цепочке вызовов выполняются строго друг за другом, а при выполнении последнего запроса ответы последовательно передаются в обратном направлении. В итоге пользователь вынужден пару секунд ждать сообщения о публикации своего отзыва, хотя его не интересуют особенности серверной обработки и он вполне обоснованно хочет увидеть сообщение сразу после нажатия кнопки. Конечно, время ожидания будет во многом определяться мощностью оборудования, но при пиковых нагрузках оно может стать серьезной проблемой.
Еще один недостаток такой схемы — обработка сбоев. Если на одном из шагов возникнет исключение, оно каскадно возвратится назад, и пользователь получит уведомление об ошибке с просьбой повторно отправить рецензию. Вряд ли кого-то обрадует получение подобного сообщения после длительного ожидания.
Синхронное взаимодействие на основе REST API
Описанную схему можно изменить, добавив асинхронные вызовы. Достаточно вызвать в асинхронном режиме первый REST API и параллельно вернуть пользователю сообщение о том, что его рецензия принята и будет размещена, например, в течение суток. В итоге сайт не блокируется, а вызовы всех последующих API происходят независимо от пользователя.
Но у такой схемы также есть существенный недостаток: в случае сбоя в одном из API информация, введенная пользователем, будет потеряна. Если в первом примере в случае ошибок достаточно повторно отправить рецензию, то здесь ее необходимо заполнить заново.
Вариант асинхронного взаимодействия на основе REST API
Для устранения недостатков обеих схем как раз и предназначены очереди сообщений.
Принципы работы очередей сообщений
Очереди предоставляют буфер для временного хранения сообщений и конечные точки, которые позволяют подключаться к очереди для отправки и получения сообщений в асинхронном режиме.
В сообщениях могут содержаться запросы, ответы, ошибки и иные данные, передаваемые между программными компонентами. Компонент, называемый производителем (Producer), добавляет сообщение в очередь, где оно будет храниться, пока другой компонент, называемый потребителем (Consumer), не извлечет сообщение и не выполнит с ним необходимую операцию.
Очереди поддерживают получение сообщений как методом Push, так и методом Pull:
Так как очереди могут использоваться несколькими производителями и потребителями одновременно, обычно их реализуют с помощью дополнительной системы, называемой брокером. Брокер сообщений (Message Broker) занимается сбором и маршрутизацией сообщений на основе предопределенной логики. Сообщения могут передаваться с некоторым ключом — по этому ключу брокер понимает, в какую из очередей (одну или несколько) должно попасть сообщение.
Вернемся к примеру с отправкой рецензии. Пусть та часть сервиса, к которому обращается пользователь, выступит в качестве производителя и будет направлять запросы на создание рецензий в очередь. Сразу после добавления сообщения в очередь пользователю можно направлять уведомление об успехе операции. Вся последующая логика обработки будет выполняться независимо от него на стороне потребителя, подписанного на очередь.
Завершив обработку, потребитель отправит подтверждение в очередь, после чего исходное сообщение будет удалено. Но если во время обработки произойдет сбой и подтверждение не будет получено вовремя, сообщение может быть повторно извлечено потребителем из очереди.
Вариант асинхронного взаимодействия на основе очереди сообщений
Польза и преимущества очередей сообщений в микросервисной архитектуре
Используя очереди сообщений в качестве основного средства взаимодействия микросервисов (Microservices Communication), можно добиться следующих преимуществ:
Отличительная черта микросервисов — их автономность. И очереди во многом помогают уменьшить зависимости между ними. Каждое сообщение, передаваемое в очереди, — это всего лишь массив байтов с некоторыми метаданными. Метаданные нужны для направления в конкретную очередь, а информация, содержащаяся в основной части (теле) сообщения, может быть практически любой. Брокер не анализирует данные, он выступает лишь в качестве маршрутизатора. Это позволяет настроить взаимодействие между компонентами, работающими даже на разных языках и платформах.
Очереди сообщений упрощают независимое масштабирование микросервисов. Наблюдая за состоянием очередей, можно масштабировать те сервисы, на которые приходится большая часть нагрузки. Кроме этого, очереди легко позволяют не только увеличивать число экземпляров существующих сервисов, но и добавлять новые с минимальным временем простоя. Все, что для этого требуется, — добавить нового потребителя, прослушивающего события в очереди.
Однако сами очереди также необходимо масштабировать, и это может создать дополнительные сложности.
Если один из сервисов не справляется с нагрузкой, требуется возможность запускать больше его экземпляров быстро и без дополнительных настроек. Обычно для этих целей используют балансировщик нагрузки, интегрированный с сервером обнаружения служб и предназначенный для распределения трафика. При использовании очередей сообщений сам брокер по умолчанию является балансировщиком нагрузки. Если несколько потребителей слушают очередь одновременно, сообщения будут распределяться между ними в соответствии с настроенной стратегией.
Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты.
Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.
Большинство брокеров выполняют аутентификацию приложений, которые пытаются получить доступ к очереди, и позволяют использовать шифрование сообщений как при их передаче по сети, так и при хранении в самой очереди. Таким образом, очередь снимает с ваших сервисов бремя организации авторизации запросов.
Варианты использования очередей сообщений
Очереди сообщений полезны в тех случаях, где возможна асинхронная обработка. Рассмотрим наиболее частые сценарии использования очередей сообщений (Message Queue use Cases):
Сюда можно отнести задачи, которые не связаны напрямую с основным действием пользователя сайта и могут быть выполнены в фоновом режиме без необходимости ожидания с его стороны. Это обработка изображений, преобразование видео в различные форматы, создание отзывов, индексирование в поисковых системах после изменения данных, отправка электронной почты, формирование файлов и так далее.
Очереди можно использовать в качестве буфера для некоторой массовой обработки, например пакетной вставки данных в БД или HDFS. Очевидно, что гораздо эффективнее добавлять сто записей за раз, чем по одной сто раз, так как сокращаются накладные расходы на инициализацию и завершение каждой операции. Но для стандартной архитектуры может стать проблемой генерация данных клиентской службой быстрее, чем их может обработать получатель. Очередь же предоставляет временное хранилище для пакетов с данными, где они будут храниться до завершения обработки принимающей стороной.
Многие системы очередей позволяют производителю указать, что доставка сообщений должна быть отложена. Это может быть полезно при реализации льготных периодов. Например, вы разрешаете покупателю отказаться от размещения заказа в течение определенного времени и ставите отложенное задание в очередь. Если покупатель отменит операцию в указанный срок, сообщение можно удалить из очереди.
Помещая данные в очередь, вы можете быть уверены, что данные будут сохранены и в конечном итоге обработаны, даже если это займет немного больше времени, чем обычно, из-за большого скачка трафика. Увеличить скорость обработки в таких случаях также возможно — за счет масштабирования нужных обработчиков.
Нестабильная сеть в сочетании с очередью сообщений создает надежный системный ландшафт: каждое сообщение будет отправлено, как только это будет технически возможно.
Многие брокеры поддерживают очереди FIFO, полезные в системах, где важно сохранить порядок транзакций. Если 1000 человек размещают заказ на вашем веб-сайте одновременно, это может создать некоторые проблемы с параллелизмом и не будет гарантировать, что первый заказ будет выполнен первым. С помощью очереди можно определить порядок их обработки.
Очереди часто применяют для сбора некоторой статистики, например использования определенной системы и ее функций. Как правило, моментальная обработка такой информации не требуется. Когда сообщения поступают в веб-службу, они помещаются в очередь, а затем при помощи дополнительных серверов приложений обрабатываются и отправляются в базу данных.
Если у вас есть некоторая задача для группы серверов, то вам необходимо выполнить ее на каждом сервере. Например, при редактировании шаблона мониторинга потребуется обновить мониторы на каждом сервере, использующем этот шаблон. Вы можете поставить сообщение в очередь для каждого сервера и выполнять их одновременно в виде небольших операций.
Это обработка финансовых транзакций, бронирование авиабилетов, обновление записей о пациентах в сфере здравоохранения и так далее.
Сложности использования и недостатки очередей сообщений: как с ними справляться
Несмотря на многочисленные преимущества очередей сообщений, самостоятельное их внедрение может оказаться довольно сложной задачей по нескольким причинам:
Хорошая новость в том, что многие облачные провайдеры сейчас предлагают очереди как сервис (MQ as a Service). Поэтому если у вас недостаточно ресурсов для самостоятельной настройки и поддержки очередей сообщений, то можно воспользоваться одним из готовых решений. Большинство из них включает автоматизацию настройки, масштабирование, диагностику ошибок и техническую поддержку, а также поддерживает строго однократную доставку в очередях FIFO.
В каких случаях очереди неэффективны
Конечно, очереди не являются универсальным средством для любых приложений. Рассмотрим варианты, когда очереди не будут самым эффективным решением:
Выбирая инструмент для будущего приложения, обязательно взвесьте все за и против. Не стоит использовать очереди сообщений для задач, которые могут быть решены другим, более простым в настройке и обслуживании способом. Но в тех случаях, когда запланирован переход на микросервисы и бизнес-логика допускает возможность асинхронной обработки, очереди сообщений могут стать лучшим выбором для повышения производительности и надежности вашего продукта.
Если вы заинтересованы в использовании очередей, но опасаетесь, что команда не справится с их конфигурированием и последующей поддержкой самостоятельно, всегда можно воспользоваться одним из Managed-решений, представленных на рынке.
Русские Блоги
Введение в очередь сообщений mq и общую очередь сообщений
1. Обзор очереди сообщений (MQ)
Очередь сообщений (Message Queue) является важным компонентом в распределенной системе, и ее общий сценарий использования можно просто описать так:
Когда вам не нужно сразу получать результаты, но нужно контролировать количество параллелизма, это почти когда вам нужно использовать очередь сообщений.
Очередь сообщений в основном решает проблемы связывания приложений, асинхронной обработки и сокращения трафика.
В настоящее время используются очереди сообщений RabbitMQ, RocketMQ, ActiveMQ, Kafka, ZeroMQ, MetaMq и т. Д., И некоторые базы данных, такие как Redis, Mysql и phxsql, также могут реализовывать функцию очередей сообщений.
Во-вторых, сценарии использования очереди сообщений
Очередь сообщений включает в себя следующие четыре сценария в практических приложениях:
Далее описываются вышеприведенные четыре сценария и порядок использования очереди сообщений в вышеуказанных четырех сценариях:
2.1 Асинхронная обработка
Особый сценарий: чтобы пользователь мог зарегистрироваться в приложении, система должна отправить электронное письмо с регистрацией и подтвердить SMS. Есть два способа обработки этих двух операций: последовательный и параллельный.
(1) Последовательный режим: после создания новой регистрационной информации сначала отправьте электронное письмо с регистрацией, а затем отправьте подтверждающее SMS;
Таким образом, вам необходимо, наконец, отправить проверочное SMS, прежде чем вернуться к клиенту.
(2) Параллельная обработка: после записи новой регистрационной информации она будет обрабатываться параллельно путем отправки текстовых сообщений и электронных писем;
Таким образом, отправка текстовых сообщений и электронных писем должна быть обработана перед возвратом клиенту.
Предполагая, что время обработки вышеупомянутых трех подсистем составляет 50 мс, и сетевая задержка не учитывается, общее время обработки:
Серийный номер: 50 + 50 + 50 = 150 мс
Параллельно: 50 + 50 = 100 мс
Если используется очередь сообщений:
И возвращайтесь к клиенту сразу после записи в очередь сообщений, общее время ответа зависит от времени записи в очередь сообщений, а время записи в саму очередь сообщений может быть очень быстрым, в основном незначительным, поэтому общее Время обработки увеличивается в 2 раза по сравнению с последовательным и вдвое по сравнению с параллельным;
2.2 Применение муфты
Конкретный сценарий: пользователь загружает изображение с помощью альбома QQ, и система распознавания лиц выполняет распознавание лиц на изображении. Общая практика заключается в том, что после получения изображения сервером система загрузки изображений немедленно вызывает систему распознавания лиц, а затем завершает вызов. Возврат успешен, как показано на следующем рисунке:
Этот метод имеет следующие недостатки:
Если используется очередь сообщений:
После того как клиент загрузит изображение, система загрузки изображений записывает информацию об изображении, такую как uin и batch, в очередь сообщений и возвращается непосредственно к успеху, а система распознавания лиц регулярно извлекает данные из очереди сообщений для завершения распознавания вновь добавленного изображения.
В настоящее время системе загрузки изображений не нужно заботиться о том, обрабатывает ли система распознавания лиц информацию об изображении и когда обрабатывать информацию об изображении. Фактически, поскольку пользователю не нужно знать результат распознавания лица немедленно, система распознавания лица может выбирать различные стратегии планирования для обработки информации изображения в очереди в соответствии с временем простоя, временем занятости и обычным временем.
2.3 Ограничение тока и ограничение пиков
Конкретные сценарии. Торговые сайты выполняют всплески активности, как правило, из-за чрезмерных мгновенных посещений и чрезмерного приема на сервер, что приведет к увеличению трафика, а связанные системы не могут обрабатывать запросы или даже аварийно завершать работу. После присоединения к очереди сообщений система может извлекать данные из очереди сообщений, что эквивалентно однократной буферизации очереди сообщений.
Этот метод имеет следующие преимущества:
2.4 Система управления сообщениями
Конкретный сценарий: пользователь недавно загрузил партию фотографий. Система распознавания лиц должна кластеризовать все фотографии пользователя. После завершения кластеризации система согласования восстанавливает индекс лица пользователя (для ускорения запроса). Три подсистемы соединены очередью сообщений, результаты обработки предыдущего этапа помещаются в очередь, а последний этап получает сообщения из очереди для продолжения обработки.
Этот метод имеет следующие преимущества:
3. Два режима очереди сообщений
Очередь сообщений включает два режима: точка-точка (очередь) и публикация / подписка (тема).
3.1 Режим точка-точка
В режиме «точка-точка» есть три роли:
Отправитель сообщения создает сообщение и отправляет его в очередь, а затем получатель сообщения принимает сообщение из очереди и использует сообщение. После использования сообщения в очереди больше нет хранилища, поэтому получатель сообщения не может использовать использованное сообщение.
Особенности режима точка-точка:
3.2 Модель публикации / подписки
В модели публикации / подписки есть три роли:
Издатель отправляет сообщение в тему, а система доставляет сообщение нескольким подписчикам.
Особенности модели публикации / подписки:
4. Введение общих очередей сообщений
В этом разделе в основном представлены основные функции, преимущества и недостатки четырех часто используемых очередей сообщений (RabbitMQ / ActiveMQ / RocketMQ / Kafka).
4.1 RabbitMQ
RabbitMQВыпущенный в 2007 году, этоAMQP(Advanced Message Queuing Protocol), созданный на основе многоразовой корпоративной системы обмена сообщениями, в настоящее время является одним из наиболее распространенных промежуточных программ для обмена сообщениями.
Использование RabbitMQ требует:
RabbitMQ может работать на платформах, поддерживаемых языком Erlang:
Solaris
BSD
Linux
MacOSX
TRU64
Windows NT/2000/XP/Vista/Windows 7/Windows 8
Windows Server 2003/2008/2012
Windows 95, 98
VxWorks
4.2 ActiveMQ
ActiveMQActiveMQ, разработанный Apache, представляет собой реализацию JMS-провайдера, полностью поддерживающую спецификации JMS1.1 и J2EE 1.4. Он очень быстрый, поддерживает клиенты и протоколы на нескольких языках и может быть легко встроен в среду корпоративных приложений и имеет множество расширенных функций.
Использование ActiveMQ требует:
ActiveMQ может работать на платформах, поддерживаемых языком Java.
Дружественный интерфейс: предоставляемая веб-консоль может соответствовать большинству ситуаций, и доступно множество сторонних компонентов, таких как hawtio;
Недостатки:
Активность сообщества не так высока, как RabbitMQ;
4.3 RocketMQ
RocketMQЭто продукт с открытым исходным кодом от Alibaba. Он реализован на языке Java. На него ссылались на Кафку во время проектирования и были сделаны некоторые улучшения. Надежность сообщения лучше, чем у Кафки. RocketMQ широко используется в Alibaba Group для заказа, транзакции, пополнения счета, расчета потока, отправки сообщений, обработки потока журнала, распространения бинглога и т. Д.
Использование RocketMQ требует:
RocketMQ может работать на платформах, поддерживаемых языком Java.
Поддерживается не так много клиентских языков, в настоящее время java и c ++, из которых c ++ является незрелым;
Внимание и зрелость сообщества RocketMQ не так хороши, как у первых двух;
Интерфейс веб-управления отсутствует, и для управления запросами, управлением и диагностикой различных проблем предоставляется инструмент управления CLI (интерфейс командной строки);
не реализовал JMS и другие интерфейсы в ядре mq;
4.4 Kafka
Использование Kafka требует:
4.5 Сравнение RabbitMQ / ActiveMQ / RocketMQ / Kafka
Вот различия между вышеупомянутыми четырьмя очередями сообщений:
5. Справочные материалы:
5.1 Очередь сообщений:
5.2 RabbitMQ
5.3 ActiveMQ
5.4 RocketMQ
5.5 Kafka
5.6 Сравнение RabbitMQ / ActiveMQ / RocketMQ / Kafka
подводить итоги:
Очередь сообщений использует эффективный и надежный механизм доставки сообщений для независимого от платформы обмена данными и интегрирует распределенные системы на основе обмена данными. В настоящее время в отрасли существует множество продуктов MQ, таких как RabbitMQ, RocketMQ, ActiveMQ, Kafka, ZeroMQ, MetaMq и т. Д. Также существуют случаи, когда повторное использование базы данных напрямую используется в качестве очереди сообщений. Каждый из этих продуктов очереди сообщений имеет свой собственный акцент: при фактическом выборе необходимо учитывать потребности самого себя и характеристики продуктов MQ и рассматривать их всесторонне.
Интеллектуальная рекомендация
Преобразования общих типов для передачи данных по протоколу iOS-TCP / IP (приветствуются дополнения
Раньше я работал над проектами TCP / IP. Обработка данных является наиболее сложной задачей. Каждый раз, когда встречается новый тип данных, добавляется новый класс методов, что приводит к путанице. С.
Lotus версия 0.4.1 Данные цепочки блока Copy Block снижает синхронизацию
Lotus версия Скопируйте данные с узла, который был синхронизирован высотой блока Узел паузыlotus daemonБеги, сжатый каталогdatastoreПуть кlotus/datastore Копировать каталогchainс участиемmetadataЗамен.
Маленькая программа wx: ограничение количества списков цикла for
Все мы знаем, что wx: for используется для зацикливания массива. В этом цикле будут зациклены все данные в списке. Но часто нам не нужно зацикливать все данные или мы не хотим отображать все данные. О.
Шантажировал биткойн впервые
Предисловие Новости о вымогателях всегда случались, но я всегда чувствую, что это вряд ли случится со мной. В итоге я встретился сегодня. проблема Во второй половине дня я отправлю интерфейс студентам.