11  /  22

Использование сторонних решений

Просмотров: 18091
Дата последнего изменения: 17.04.2024
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
1
2
3
4
5

  Сторонние приложения

Для веб-проектов с индивидуальными и редкими бизнес-требованиями целесообразно расширить стандартный функционал инструментов веб-кластера и использовать дополнительные решения.

Нередко приходится автоматизировать взаимодействие компонентов веб-кластера, если:

  • Отказывает программный или аппаратный сервис
  • Разделяется сеть
  • Резко повышается нагрузка
  • Необходима балансировка

Для этих случаев можно подобрать подходящие open source инструменты. При жестких корпоративных стандартах оперативной технической поддержки и безопасности целесообразно использовать коммерческие утилиты.

  NoSQL

Благодаря «ослаблению» требований ACID и согласно теореме CAP, иногда NoSQL эффективнее решает задачу веб-проекта, чем использование реляционной базы данных MySQL.

Модуль Highload-блоков Модуль позволяет создавать сущности для хранения произвольных данных, причем каждая сущность хранится в отдельной таблице базы данных. Таким образом, для каждого Highload-блока определяется свой набор полей, которые являются пользовательскими свойствами ядра и конструируются в административном разделе.

Подробнее ...
эффективно работает в парадигме NoSQL, используя интерфейс MySQL InnoDB HandlerSocket, что обеспечивает очень высокую скорость операций в режиме «ключ-значение». Инструмент рекомендуется использовать, если не требуются аналитические выборки, «хитрые» сортировки и фильтрации, группировки.

Часто используют для решения подобных задач кластера Apache Cassandra или Apache HBase.

  Расширенная аналитика

Для задач по расширенной аналитике, которые решаются в продуктах класса OLAP, будут полезны column-oriented инструменты:

  • Druid
  • Amazon Redshift
  • Google BigQuery
  • Vertica
  • И аналоги

Подобные продукты решают задачи агрегации и группировки. Они могут выполняться на кластерах и позволяют обрабатывать большие объемы данных.

  Очереди

При обработке интенсивных асинхронных потоков данных:

  • сжатие изображений,
  • выгрузка и загрузка файлов,
  • обмен сообщениями

подходят парадигмы ограниченной/полной упорядоченности, вплоть до producer-consumer.

Решать эти задачи через MySQL не всегда удобно, поэтому популярны:

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

Обратите внимание на требование к упорядоченности сообщений в очереди. Строгая последовательность доставки, как в TCP/IP, может наложить жесткие ограничения на пропускную способность подсистемы: обработка одного сообщения может заблокировать обработку следующих.

  Дальнейшая кластеризация кэша

Некоторым веб-проектам необходима устойчивость системы при отказе одного или нескольких элементов слоя кэширования – memcached-сервисов. Если не предпринять дополнительных мер, может возрасти нагрузка на реляционный слой: базу данных MySQL. Иногда важно обеспечить легкое и незаметное добавление memcached-сервисов без изменений характера нагрузки системы. Для предотвращения подобных рисков применяют кластерные продукты класса Couchbase.

Благодаря master-master архитектуре кластер справится с отказом узлов без заметной деградации производительности слоя кэширования.

  Внешний обратный индекс

Для поддержки задач с интенсивным поиском и использованием обратного индекса целесообразно выгрузить данные во внешний кластеризуемый «движок» типа Sphinx (имеется поддержка на уровне ядра 1С-Битрикс) или Lucene/ElasticSearch/Solr.

Иногда выгрузка каталога в подобные системы используется для массовых фасетных выборок и фильтраций, которые неудобно делать через реляционную модель. В некоторых случаях целесообразно использовать Redis – сетевое журналируемое хранилище, которое поддерживает основные структуры данных и подходит для быстрых алгоритмов по выборке, фильтрации и сортировке.

  Выбор нового master

Если отказывает одна из slave БД – веб-кластер автоматически переключается на «живую» slave БД.

При отказе мастер БД необходимо автоматически (событие может происходить ночью в праздник и т.п.)

  1. Настроить одну из текущих slave
  2. Прописать ее настройки в модуль Веб-кластер
  3. Сделать ее master БД

Для этого подходят системы управления кластерами:

  • etcd
  • Apache Curator
  • ZooKeeper
  • Pacemaker

Они принимают решение о наличии «живых» машин и выбрают кандидата.

В простых кейсах может быть достаточно Nagios и обработчика события о недоступности master БД.

  Итог

Дополнительный инструмент для работы с веб-кластером необходимо выбирать после проверки всех возможностей стандартного веб-кластера и виртуальной машины «1С-Битрикс».

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

Рекомендуем:

  • Внимательно изучить документацию.
  • Понять тип поддержки дополнительного программного обеспечения, способ его обновления и технику настройки.
  • Отработать сценарии на прототипе с нагрузкой.


1
Курсы разработаны в компании «1С-Битрикс»