avlasov (avlasov) wrote,
avlasov
avlasov

Category:

Мини-учебнег по распределенным системам/протоколам. Stateless и Shared Disk/DB

Допустим на какой-то сайт ходит много народу и нужно увеличить производительность системы. Стандартный и весьма популярный способ - это Stateless веб-сервера. Т.е. такой стиль реализации веб-сервера, который не хранит у себя состояния. А раз не хранит состояние, то его можно очень просто размножить - ибо не возникает проблемы с конкурентным доступом к состоянию на разных серверах.

К сожалению, у данного подхода есть некоторые недостатки, ибо сей подход не решает принципиально проблему, а переносит ее в другое место. Что впрочем может быть вполне удовлетворительным вариантов. Например, обычно состояние храниться на сервере БД, но это означает, что сервер БД становится узким местом, которому нужно как-то уметь разруливать проблемы с конкурентным доступом к разделяемому состоянию. Но вендоры БД заботятся, чтобы уметь это делать, так что это действительно часто решает проблему до какой-то степени.

Однако, если мы храним состояние в какой-то shared БД, то у нас возникает новый источник проблем с производительностью - каждый раз, когда нам нужно какое-то состояние, нам нужно лезть в БД. И это может быть очень неприятно в виде существенного снижения производительности. Например, у нас в системе много запросов на чтение (а в веб это так), которые не меняют состояние, и каждый раз лазить за ними в БД становится накладно. Гораздо лучше было бы кэшировать их на сервере, таким образом можно было бы сильно сэкономить избежав затрат связанных с коммуникацией по сети и повышением нагрузки на сервер БД. Но это противоречит идее Stateless сервера, и мы теряем легкость масштабирования.

Вобщем, очевидно что у stateless server/shared DB подхода есть существенные ограничения как в плане масштабируемости (сервер БД в какой-то момент станет боттлнеком, весьма и весьма дорогим в плане преодоления), так и в плане производительности (приходится лазить по сети в базу, даже если есть куча запросов, которые не меняют состояние, т.е. могли бы быть быстро исполнены, если бы состояние хранилось на сервере).

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

Однако, есть еще один вариант - в каких-то случаях можно хранить состояние в запросах/ответах, через которые происходит коммуникация с клиентом, а именно использовать cookies и/или кодировать инфу в url, каких-то свойствах запроса. Конечно, в большинстве случаев это может лишь частично решить проблему состояния, ибо размер состояния передаваемого таким образом невелик. Но имеет смысл о нем знать, ну и использовать по мере необходимости. Можно отметить, что через cookie/url передается session id, но не только.
В общем, вполне может быть, что проблема решается хранением небольшого кол-ва состояния в запросах/ответах. Например, иногда в url'е кодируется способ отображения, сортировка, текущая страница и проч.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments