Каково реальное использование мультизаказа на основе кафки? - PullRequest
0 голосов
/ 16 ноября 2018

Я новичок в тканевых технологиях.Я прочитал несколько статей об услугах заказа на базе Kafka и их преимуществах.В некоторых статьях говорится, что мультизаказные услуги на базе Kafka подходят для отказоустойчивости.Теперь я просто применяю 3 сервиса заказа на основе Kafka (orderer0, orderer1, orderer2).Затем я остановил 2 заказчика с помощью следующей команды

docker stop orderer1.example.com
docker stop orderer2.example.com

Теперь остальные API работают правильно.Затем я остановил orderer0, используя

docker stop orderer0.example.com

Теперь мой API api не работает. Он сталкивается с проблемой сетевого подключения. Затем я запустил orderer1, orderer2, используя следующую команду

docker start orderer1.example.com
docker start orderer2.example.com

Но мойRest api не работает ........... Он сталкивается с той же проблемой сетевого подключения.

И, наконец, я запустил orderer0, используя

docker start orderer0.example.com

Теперь сетьработает нормально.

У меня вопросы

  1. Как на самом деле используются услуги заказа на основе Kafka .. ??

  2. Какмы можем внедрить сервис заказов на основе Kafka для предотвращения проблем с заказчиком ... ??

Ткань: 1.1.0
Композитор: 0.19.16
Узел: 8.11.3
ОС: Ubuntu 16.04

Ответы [ 2 ]

0 голосов
/ 20 ноября 2018

Согласно Службам заказа Kafka

Каждый канал отображается в отдельную тему с одним разделом в Kafka

Это означает, что все сообщения втемы полностью упорядочены в том порядке, в котором они были отправлены.

и

Как минимум, [количество брокеров] должно быть установлено равным 4. (Как мы объясним в шаге 4 ниже, это минимальное количество необходимых узловчтобы продемонстрировать отказоустойчивость при сбое, т. е. с 4 брокерами можно отключить одного брокера, все каналы будут по-прежнему доступны для записи и чтения и могут быть созданы новые каналы.)

ВышеПредполагается, что коэффициент репликации Kafka равен 3, а клиент-производитель должен установить min.insync.replicas в идеале равным 2, чтобы обеспечить репликацию всех записей как минимум на два сервера.

Исходя из проблем вашей сети, для меня это звучит так, как будто вы на самом деле неправильно настроили всех трех брокеров (нужно было бы увидеть все настройки Docker и то, что на самом деле делает Dockerfile).Но, предполагая, что вы настроили всех трех посредников для этого «API REST», и есть раздел Kafka с одним разделом с 3 репликами (по умолчанию репликация равна 1, и с этим темы создаются автоматически).Итак, я предлагаю вам все это очистить, затем запустить трех брокеров, затем вручную создать тему с 1 разделом, 3 репликами, а затем запустить Hyperledger.

Если проблема связана с REST API, а не с подключением Kafka, тогда вам нужен балансировщик нагрузки, я думаю

0 голосов
/ 16 ноября 2018

У меня была такая же проблема, как и у вас, когда я хотел настроить несколько заказов.Чтобы решить эту проблему, у меня есть 2 решения:

  1. Я изменил SDK, в настоящее время ваш SDK пытается связаться с orderer0, если он терпит неудачу, он возвращает ошибку, необходимо изменить это так, чтобы цикл запросав списке заказчиков и возвращает ошибку, если нет действительного.
  2. проще: настроить балансировщик нагрузки перед заказчиками.

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

...