Лучшая практика подключения к кластеру Riak

Я переношу свое приложение с Riak 1.4 на Riak 2.

Раньше я размещал свое приложение на каждом узле кластера Riak. Он подключается только к локальному узлу Riak (в localhost:8087), отслеживает доступность Riak и на основе этого объявляет о своей доступности. Удаленные Haproxies отслеживают несколько из этих приложений и направляют трафик конечных пользователей на любой доступный экземпляр приложения:

enduser --network -> Haproxy --network -> pool [приложение-> riak]

Мои причины для этой архитектуры были

  • Минимально возможная задержка между приложением и Riak
  • Zero-Conf приложения, оно всегда ожидает Riak на локальном хосте
  • Хороший контроль распределения трафика в HAProxy (и только там)
  • Хорошая безопасность: protobuf был открыт только для localhost

Документация по java-client. теперь предполагает, что при подключении клиентское приложение Riak должно знать обо всех узлах кластера Riak. В свете этого, приемлем ли мой подход? Или я должен вместо этого переключиться на сценарий, в котором каждый экземпляр приложения знает о каждом узле Riak и подключен к нему?


riak java
person Hank    schedule 28.04.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я считаю, что у клиента есть несколько целей, чтобы знать о каждом узле.

  • узлы приложений по-прежнему доступны, когда один узел Riak выходит из строя
  • один перегруженный узел приложения не передает всю свою нагрузку на один узел Riak
  • есть повышение производительности (отмеченное в техническом документе Dynamo) при отправке записи непосредственно на основной узел вместо отправки на случайный узел, который затем должен пересылать запрос

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

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

person Joe    schedule 29.04.2015