У меня есть стандартное приложение Erlang, построенное на принципах otp. Я планирую разместить свои узлы erlang в производстве, как описано ниже:
Все это работает очень хорошо, однако в случае HTTP-транзакций на основе сеанса, скорее всего, один из узлов erlang получит запрос, а процессы, связанные с сеансом, находятся на другом узле erlang.
Мои вопросы связаны с лучшей стратегией работы в таких случаях:
1), 2) довольно просты в использовании и настройке, однако я прочитал и протестировал, что балансировка на основе source / cookie / url_param не обеспечивает равную балансировку между бэкэндами.
3) достижимо с использованием мощности репликации мнезии внутри эрланга. С 3) я, вероятно, получу случай, когда один узел erlang внутренне общается с другим узлом erlang, прежде чем он, наконец, предоставит ответ на запрос.
Хотелось бы узнать, что предпочтительнее и почему? Будет ли 3) лучшим выбором в долгосрочной перспективе, учитывая, что мое приложение otp обрабатывает много данных в реальном времени (протокол xmpp).
Я думаю, это во многом зависит от того, какую нагрузку может выдержать один из ваших узлов с точки зрения сеансов. Хеширование IP и файлов cookie, по крайней мере, с точки зрения HTTP, довольно хорошо справляется с поддержанием баланса с большим количеством недолго сессий.
Так, например, за одним IP-адресом может быть много клиентов (хеширование на основе файлов cookie должно помочь в этом). Если один узел может обрабатывать только относительно небольшое количество одновременных сеансов, узел может быть перегружен. Также, если сеансы являются долгими, может быть заметен дисбаланс хеширования. С другой стороны, если количество сеансов велико и недолговечно, относительная значимость одного узла, имеющего несколько дополнительных подключений, скорее всего, на самом деле не имеет большого значения.
Теоретически я также ожидал, что с некоторой формой балансировки на основе источников или файлов cookie вы получите лучшие коэффициенты попадания в кеш. Еще одна вещь, которую следует учитывать, заключается в том, что если у вас, скажем, 3 узла, то, если один узел выйдет из строя, каждый из других узлов будет иметь на ~ 16% больше нагрузки на каждый из них даже при идеальной балансировке нагрузки. Таким образом, вы также должны учитывать обеспечение.
Если вы можете обрабатывать множество запросов на одном узле, то третий вариант для меня звучит так, как будто вы решаете проблему, которой у вас нет и вряд ли возникнет, когда возможен гораздо более простой вариант.