Мини-учебнег по распределенным системам/протоколам. Stateless и Shared Disk/DB
Допустим на какой-то сайт ходит много народу и нужно увеличить производительность системы. Стандартный и весьма популярный способ - это Stateless веб-сервера. Т.е. такой стиль реализации веб-сервера, который не хранит у себя состояния. А раз не хранит состояние, то его можно очень просто размножить - ибо не возникает проблемы с конкурентным доступом к состоянию на разных серверах.
К сожалению, у данного подхода есть некоторые недостатки, ибо сей подход не решает принципиально проблему, а переносит ее в другое место. Что впрочем может быть вполне удовлетворительным вариантов. Например, обычно состояние храниться на сервере БД, но это означает, что сервер БД становится узким местом, которому нужно как-то уметь разруливать проблемы с конкурентным доступом к разделяемому состоянию. Но вендоры БД заботятся, чтобы уметь это делать, так что это действительно часто решает проблему до какой-то степени.
Однако, если мы храним состояние в какой-то shared БД, то у нас возникает новый источник проблем с производительностью - каждый раз, когда нам нужно какое-то состояние, нам нужно лезть в БД. И это может быть очень неприятно в виде существенного снижения производительности. Например, у нас в системе много запросов на чтение (а в веб это так), которые не меняют состояние, и каждый раз лазить за ними в БД становится накладно. Гораздо лучше было бы кэшировать их на сервере, таким образом можно было бы сильно сэкономить избежав затрат связанных с коммуникацией по сети и повышением нагрузки на сервер БД. Но это противоречит идее Stateless сервера, и мы теряем легкость масштабирования.
Вобщем, очевидно что у stateless server/shared DB подхода есть существенные ограничения как в плане масштабируемости (сервер БД в какой-то момент станет боттлнеком, весьма и весьма дорогим в плане преодоления), так и в плане производительности (приходится лазить по сети в базу, даже если есть куча запросов, которые не меняют состояние, т.е. могли бы быть быстро исполнены, если бы состояние хранилось на сервере).
Итого, для роста производительности и масштабирования нам нужно вводить ту или иную форму репликации состояния. Одни из самых простых и распространенных вариантов - это кэширование. Рассмотрим его в следующем посте.
Однако, есть еще один вариант - в каких-то случаях можно хранить состояние в запросах/ответах, через которые происходит коммуникация с клиентом, а именно использовать cookies и/или кодировать инфу в url, каких-то свойствах запроса. Конечно, в большинстве случаев это может лишь частично решить проблему состояния, ибо размер состояния передаваемого таким образом невелик. Но имеет смысл о нем знать, ну и использовать по мере необходимости. Можно отметить, что через cookie/url передается session id, но не только.
В общем, вполне может быть, что проблема решается хранением небольшого кол-ва состояния в запросах/ответах. Например, иногда в url'е кодируется способ отображения, сортировка, текущая страница и проч.
К сожалению, у данного подхода есть некоторые недостатки, ибо сей подход не решает принципиально проблему, а переносит ее в другое место. Что впрочем может быть вполне удовлетворительным вариантов. Например, обычно состояние храниться на сервере БД, но это означает, что сервер БД становится узким местом, которому нужно как-то уметь разруливать проблемы с конкурентным доступом к разделяемому состоянию. Но вендоры БД заботятся, чтобы уметь это делать, так что это действительно часто решает проблему до какой-то степени.
Однако, если мы храним состояние в какой-то shared БД, то у нас возникает новый источник проблем с производительностью - каждый раз, когда нам нужно какое-то состояние, нам нужно лезть в БД. И это может быть очень неприятно в виде существенного снижения производительности. Например, у нас в системе много запросов на чтение (а в веб это так), которые не меняют состояние, и каждый раз лазить за ними в БД становится накладно. Гораздо лучше было бы кэшировать их на сервере, таким образом можно было бы сильно сэкономить избежав затрат связанных с коммуникацией по сети и повышением нагрузки на сервер БД. Но это противоречит идее Stateless сервера, и мы теряем легкость масштабирования.
Вобщем, очевидно что у stateless server/shared DB подхода есть существенные ограничения как в плане масштабируемости (сервер БД в какой-то момент станет боттлнеком, весьма и весьма дорогим в плане преодоления), так и в плане производительности (приходится лазить по сети в базу, даже если есть куча запросов, которые не меняют состояние, т.е. могли бы быть быстро исполнены, если бы состояние хранилось на сервере).
Итого, для роста производительности и масштабирования нам нужно вводить ту или иную форму репликации состояния. Одни из самых простых и распространенных вариантов - это кэширование. Рассмотрим его в следующем посте.
Однако, есть еще один вариант - в каких-то случаях можно хранить состояние в запросах/ответах, через которые происходит коммуникация с клиентом, а именно использовать cookies и/или кодировать инфу в url, каких-то свойствах запроса. Конечно, в большинстве случаев это может лишь частично решить проблему состояния, ибо размер состояния передаваемого таким образом невелик. Но имеет смысл о нем знать, ну и использовать по мере необходимости. Можно отметить, что через cookie/url передается session id, но не только.
В общем, вполне может быть, что проблема решается хранением небольшого кол-ва состояния в запросах/ответах. Например, иногда в url'е кодируется способ отображения, сортировка, текущая страница и проч.