У меня есть установка 72 машин, которые занимают рабочие места из очередей RabbitMQ и выполняют операции CRUD на осколоченном MongoDB на 4 машинах и Arbeiter, я хочу знать, имеет ли смысл иметь смысл только одна машина обрабатывает операции CRUD, все работает в одной сети.Mongodb кластер машин, выполняющих задания
на стороне заметьте причину, по которой я думаю об этом, потому что он облегчает отслеживание.
Четыре случая были бы легкими для оштукатуренного решения, возможно, вы говорите о Replication?
В MongoDB концепция репликации используется для высокой доступности, а не для производительности. Минимальной рекомендуемой конфигурацией будет три узла, один первичный, один вторичный и арбитр. Цель арбитра заключается в том, чтобы обрабатывать выборы, над которыми узел является Первичным, по сути нарушая тупик на двух узлах, передавая большинство голосов одному. У более стабильных наборов реплик есть по крайней мере три узла Первичного, Вторичного, Вторичного ... и, возможно, арбитров, где арбитр снова в основном используется для have an odd number of votes, давая большинство одному узлу на выборах.
В конфигурации Sharded коллекция делится на определенный shard key через осколки кластера. Основная цель оштрафования - это когда ваши данные имеют working set, которые больше, чем доступная оперативная память на одном узле. Он позволяет распределять запросы по кластеру или нацеливаться на осколок, содержащий требуемые данные, в любом случае распределяя нагрузку или не связывая ресурсы любого данного узла.
Швартование также требует дополнительных узлов, известных как config servers. Эти узлы содержат метаданные относительно местоположения данных на осколках и опрошены router, чтобы направлять запросы на каждый осколок. В производстве у вас будет три конфигурационных сервера для защиты от одного спуска.
В любом случае осколочные кластеры, как правило, состоят из набора реплик внутри каждого осколка. Из набора реплик только первичный узел принимает соединения для операций чтения/записи. Вы можете настроить подключения, чтобы разрешить чтение из вторичных узлов, если вы можете жить с данными, которые могут быть непоследовательными, но только один узел будет каждый принимать записи, а затем реплицироваться на другие вторичные узлы. С осколками записи будут отправляться на первичную часть осколков или осколков в зависимости от выбранного ключа осколка.
Таким образом, количество серверов, участвующих в операциях CRUD, полностью зависит от вашей конфигурации.
Можете ли вы предоставить более подробную информацию по вашему вопросу? Итак, у вас есть 72 машины, чтобы хрустить очередь RabbitMQ и 4-х осколочный Mongo-кластер для размещения данных? Проанализировали ли вы какой-либо анализ, чтобы понять, что является узким местом в системе. Это кроличковая обработка или CRUD на БД? Также, как только вы окунетесь, если ваши ключи будут распределены равномерно, операции CRUD будут распределены по всем вашим черепам монго.