Я перечислил некоторые альтернативы для управления соединением ниже, в порядке от минимального до рекомендуемого.
Увеличение разрешенных соединений на сервере
Общий лимит входящего соединения на сервере определяется меньшим из ограничений, установленных операционной системой или maxIncomingConnections
(иначе maxConns
в MongoDB 2.4 и более ранних версиях).
Обычно дистрибутивы Linux ограничивают файловые дескрипторы на процесс до 1024, из которых MongoDB будет использовать 80% для входящих соединений (оставляя около 819 доступных соединений).
Вы можете проверить текущие и доступные соединения в mongo
оболочке через:
db.serverStatus().connections
Для производственных систем обычно настраивают ulimit
параметры в Linux, чтобы обеспечить более параллельные соединения. Для получения дополнительной информации рекомендую ознакомиться с примечаниями к производству в руководстве MongoDB.
Предоставить API
Если вы управляете общим сервером с ограничениями ресурсов, обычно предоставляется собственный API, а не прямой доступ к базе данных. Этот подход дает вам дополнительный уровень абстракции, так что вы можете управлять использованием ресурсов и развертыванием сервера независимо от конфигурации клиента. Например, вы можете переместить свой сервер базы данных или перенастроить его из автономного набора в набор реплик, и клиенты не должны будут знать об этом. Вы также можете управлять пользовательскими ограничениями ресурсов (такими как подключения на клиента) через API, основываясь на учетных данных, которые клиент использует для подключения.
Уменьшите размер пула соединений на клиентах
MongoDB (как в версии 2.6) не имеет возможности ограничить количество подключений для каждого клиента. Обычно клиентские ограничения устанавливаются через драйвер (т. Е. Устанавливаются размеры пула соединений). Например, в драйвере JavaMongoClient
максимальный размер пула по умолчанию равен 100.
Вы уже предположили, что это нежелательный вариант, так как вы не хотите, чтобы клиенты связывались с лимитами подключения, но если вы собираетесь наложить ограничение на стороне сервера, все равно было бы разумно, чтобы они установили размер пула соответственно. В противном случае их приложения будут получать частые исключения, поскольку вы уничтожаете лишние соединения.
Мониторинг операций клиента
Если настройка ограничений на клиенте или сервере не подходит, альтернативой для рассмотрения является реализация сценария для подсчета одновременных клиентских подключений (по IP) через db.currentOp()
и уничтожения избыточных подключений через db.killOp()
. Вы должны быть очень осторожны, чтобы убить только клиентские запросы. Команда killOp()
- это команда суперпользователя, которая также позволит вам уничтожать внутренние потоки базы данных (что может привести к непредсказуемым результатам).
ПРИМЕЧАНИЕ. Этот подход будет неудачным, если ваши клиенты подключаются через общий шлюз (т. Е. Когда исходный IP-адрес не идентифицирует клиента однозначно).