Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Горизонтальное масштабирование маленьких Web-приложений на Java (вопросы собеседований)

Anna | 1.06.2014 | нет комментариев
Эта тема была поднята в ходе нескольких (3 ) собеседований тот, что я прошёл за последние полтора месяца — в различных вариациях но приблизительно об одном. Казалось бы, вестимые вещи — но собрав все результаты и объяснения какие я давал (и кое-что что нашёл позднее в гугле), решил сберечь их не у себя в гугл-драйве, а написать короткий обзор.

Речь шла о маленьких и типовых приложениях Enterprise / Web на Java, каких пишется уйма (ну такие, на 10-100 тысяч заказчиков, миллион посещений и т.п.). Пускай это будет обобщённый диалог в виде вопросов и результатов.

В: Возможен, у вас есть приложение (самое обыкновенное — JSP, Spring, Hibernate скажем) развернутое на томкате (Apache Tomcat) и вы некогда примечаете что сервер с томкатом загружен на 80% в среднем. Что делать?

О: Поставим несколько томкатов на отдельных серверах в паралель. Они будут по-бывшему применять одну базу на одном сервере.

В: Но как же пользователь будет заходить на ваши несколько серверов?

О: Используем load-balancer, скажем перед томкатами может стоять апач (Apache httpd) с mod_proxy — он будет распределять (проксировать) запросы приходящие к нему между всеми нашими томкатами.

В: Но чай может получиться что пользователь залогинится на одном томкате, а дальнейший запрос load-balancer пошлёт на иной, где пользователь не залогинен!

О: Это мы говорим о том как организовать сессию. Скажем, делаем sticky sessions (скажем когда load-balancer добавляет к запросу куку с указанием на какой томкат он данный запрос проксирует — а все дальнейшие запросы с этой кукой направляет непременно на тот же самый сервер. Таким образом всякий обособленный пользователь будет трудиться только с одним сервером.

В: А если данный определенный сервер упадёт?

О: Сессия пользователя потеряется. Следственно отличнее применять хранение сессий в кэше. Томкат «из коробки» может беречь их в memcached скажем. То есть мы дописываем строчку в конфиг и на отдельном сервере запускаем memcached — сейчас все томкаты хранят сессии на нём и если пользователь попал с очередным запросом на иной сервер, он этого не подметит — сессия будет трудиться все равно.

В: Какие ещё превосходства у кэша для сессий?

О: Скажем, дозволено деплоить новую версию приложения только на один из нескольких томкатов, так что скажем 25% пользователей видят новую страницу входа и поспеют высказать нам пожелания если им это не нравится, т.е. они нечаянно поработают бета-тестерами :)

В: Но если версии приложения по-различному применяют базу?

О: Мы можем проектировать метаморфозы базы так Дабы поддерживать обратную совместимость между двумя соседними версиями. Это несложно. Добавлять колонки, скажем, необходимо совместно с новой версией, а вот удалять непотребные только при дальнейшем релизе.

В: Отлично, сейчас у нас тесным местом становится база. Что мы будем делать при возрастании нагрузки на неё?

О: В первую очередь между базой и томкатами пригодно сделать кэш. Ещё прежде видимо мы используем кэш на ярусе ORM (скажем, 2-й ярус кеша в Hibernate). Всеобщий толк в том что в течение сессии пользователь использует ограниченный комплект данных, следственно их комфортно кэшировать.

В: Ну а всё-таки, возможен даже кэш нас не выручает. Как дозволено уменьшить нагрузку на базу?

О: У нас есть несколько путей. Скажем дозволено часть базы (какую-нибудь особенно насосную таблицу возможен) выделить в иную базу на отдельном сервере, может даже в NoSQL хранилище либо какой-нибудь особый кэш. Безусловно, отличнее это распределение сделать ещё при проектировании :)

В: А какие есть другие пути? Какие решения на ярусе самой базы данных?

О: Дозволено применять шардинг — при этом таблицы разбиваются на несколько серверов и обращение к надобному происходит, скажем, по части id-шника. В некоторых случаях дозволено поделить сразу, возможен, сделки, транзакции, электронные документы и т.п. касающиеся одного пользователя от того что традиционно пользователь не работает с чужими документами — а значит все его данные дозволено комфортно беречь на одном сервере.

В: Какой недочет этого подхода?

О: С такими таблицами позднее будет труднее трудиться — join с таблицей лежащей на нескольких серверах видимо будет менее результативен — вообще усложняется индексирование, запросы по критериям и т.п. Вообще само проектирование ощутимо усложняется.

В: Отлично, знаете ли вы ещё варианты?

О: Самый примитивный это настроить репликацию, скажем так что база содержит копии на нескольких серверах, из них один применяется для записи, а остальные для чтения. Эти последние стремительно синхронизируют своё содержимое при апдейтах. Получается что всеобщее количетсво запросов к базе сейчас распределяется по нескольким машинам. Безусловно это благотворно именно когда чтения огромнее чем записи.

В: Какие последующие пути масштабирования вы могли бы предложить?

О: Скажем, очереди сообщений. Скажем, пользователь сберегает новую транзакцию — но мы не пишем её в базу сами. Взамен этого отсылаем сообщение в очередь (скажем RabbitMQ) что такие-то данные обязаны быть сохранены. Это сообщение будет выдано одному из нескольких серверов осуществляющих обработку и сохранение в базу. Наращивать число таких серверов (при применении распределённой / реплицированной базы либо кеша) вообще дюже легко. Впрочем сама по себе зодчество на таком ярусе теснее требует огромнее внимания и размышлений — допустимо даже это тот момент когда приложение стоит переписать целиком :)

В: Хорошо, с этим ясно, давайте побеседуем о другом… (и здесь могут начать про гарбаж-коллекторы, либо попросить написать двоичный поиск в массиве — проверка на вшивость — но это теснее не значимо)

Поделившись своими «слежениями» по собеседованиям я буду рад безусловно дополнениям, исправлениям и т.п. которые могут оказаться пригодными и мне и иным коллегам :)

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB