Я использую Lucene API на своем веб-портале, который будет иметь 1000 одновременных пользователей. Наш веб-сервер будет вызывать Lucene API, который будет сидеть на сервере приложений. Мы планируем использовать 2 сервера приложений для балансировки нагрузки. Учитывая это, какова должна быть наша стратегия для тиражирования индексов lucene на 2-м сервере приложений?Репликация индекса и балансировка нагрузки
Вы можете использовать solr, который содержит встроенную репликацию. Это, возможно, самое лучшее и простое решение, поскольку, вероятно, потребуется большая работа по реализации вашей собственной схемы репликации.
Тем не менее, я собираюсь сделать именно это, для проекта, над которым я работаю. Разница в том, что, поскольку мы используем PHP для интерфейса, мы реализовали lucene на сервере сокетов, который принимает запросы и возвращает список первичных ключей db. Мой план состоит в том, чтобы вносить изменения в сервер и хранить их в очереди, где я сначала буду хранить их в индексе памяти, а затем сбросить индекс памяти на диск, когда загрузка будет достаточно низкой.
Тем не менее, это сложная задача, и я собираюсь сделать довольно много работы, прежде чем у нас будет стабильное окончательное решение, которое достаточно надёжно.
Из опыта работы Lucene не должно быть проблем с масштабированием для тысяч пользователей. Тем не менее, если вы используете только второй сервер приложений для балансировки нагрузки, а не для ситуаций с ошибкой, вы должны быть хорошо размещены Lucene только на одном из этих серверов и получать доступ к нему через NDS (если у вас есть среда unix) или совместно (в среде Windows) со второго сервера.
Опять же, это зависит от конкретной ситуации. Если вы говорите о том, что у вас есть миллионы (5 или более) документов в вашем индексе, и вам нужно, чтобы ваш индекс lucene был доступен для перехода на другой ресурс, вы можете захотеть изучить Solr или Katta.
Мы работаем над аналогичной реализацией с тем, что вы описываете как доказательство концепции. То, что мы рассматриваем как конечный продукт для нас, состоит из трех отдельных серверов для этого.
Существует сервер публикации, который отвечает за формирование индексов, которые будут использоваться. Существует реализация службы, которая обрабатывает рабочие процессы, используемые для построения этих индексов, а также возможность завершения сигнала (пользовательский API управления, открытый через веб-службы WCF).
Есть два «связанных с сайтом» серверов Lucene.NET. Доступ к API предоставляется через службы WCF на сайт. Они сидят за балансировщиком физических нагрузок и периодически «пингируют» сервер публикации, чтобы узнать, есть ли более новый набор индикаторов, чем тот, который в настоящее время работает. Если это так, он запрашивает блокировку с сервера публикации и обновляет локальные индексы, инициируя передачу в локальную «входящую» папку. Как только там, это просто вопрос приостановки поискового устройства, пока индекс привязан. Затем он освобождает свою блокировку, а другой сервер доступен для этого.
Как я уже сказал, мы только приближаемся к доказательству концепции с этим, в качестве замены нашего текущего решения, которое представляет собой сбалансированный по нагрузке кластер Endeca. Размер индексов и количество времени, которое потребуется для фактического завершения требуемых задач, - это большие вопросы, которые еще предстоит доказать.
Просто некоторые случайные вещи, которые мы рассматриваем:
Простои данного сервера могут быть уменьшены, если две локальные папки используются на каждой машине, получающие данные для достижения «циклического» подхода.
Мы смотрим, позволяет ли балансировщик нагрузки использовать программный доступ для удаления узла и добавления его из кластера. Это уменьшит вероятность того, что пользователь почувствует зависание, если он или она обратится во время обновления.
Мы смотрим на «запрос переадресации» в том случае, если манипуляции с кластерами невозможны.
Мы также посмотрели на solr. Хотя многие из них просто работают из коробки, у нас есть некоторое время для изучения этого пути в качестве учебного упражнения - изучение таких вещей, как Lucene.NET, улучшение навыков WF и WCF и внедрение ASP.NET MVC для управления -конец. В худшем случае, мы идем с чем-то вроде solr, но приобрели опыт в некоторых навыках, которые мы хотим улучшить.
Я создаю Индексы на публикацию Backend-машин в файловой системе и копируем их в маркетинг. Таким образом, каждый отдельный, нагрузка & не сбалансирован, узел имеет собственный индекс без латентности сети.
Недостатком является то, что вы не должны пытаться воссоздать индекс в реплицированной папке, так как у вас будет файл блокировки, лежащий на каждом узле, блокирующий указатель индекса до тех пор, пока ваш reindex не закончится.