Alex Voitau
GitHub
commit
44eb5f3310
62
README-ru.md
62
README-ru.md
|
|
@ -1130,7 +1130,7 @@ l10n:p -->
|
|||
|
||||
#### Активный-пассивный
|
||||
|
||||
В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
|
||||
В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такое сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
|
||||
|
||||
Время простоя определяется состоянием, в котором находится пассивный сервер:
|
||||
|
||||
|
|
@ -1320,7 +1320,7 @@ Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route 53](ht
|
|||
* [Geolocation-based](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo)
|
||||
l10n:p -->
|
||||
|
||||
## Систем доменных имен
|
||||
## Система доменных имен
|
||||
|
||||
<p align="center">
|
||||
<img src="images/IOyLj4i.jpg">
|
||||
|
|
@ -1339,7 +1339,7 @@ DNS иерархична и имеет несколько корневых се
|
|||
* **Запись A (address)** - связывает имя с IP адресом.
|
||||
* **CNAME (canonical)** - связывает имя с другим именем, записью CNAME (example.com to www.example.com) или записью А.
|
||||
|
||||
Такие сервисы, как [CloudFlare](https://www.cloudflare.com/dns/) и [Route 53](https://aws.amazon.com/ru/route53/) предоставляют полностью управляемые сервис DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:
|
||||
Такие сервисы, как [CloudFlare](https://www.cloudflare.com/dns/) и [Route 53](https://aws.amazon.com/ru/route53/) предоставляют полностью управляемые DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:
|
||||
|
||||
* взвешенный циклический ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
|
||||
* предотвращает попадание трафика на серверы, находящиеся на обслуживании
|
||||
|
|
@ -1401,7 +1401,7 @@ l10n:p -->
|
|||
<i><a href=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Источник: Why use a CDN</a></i>
|
||||
</p>
|
||||
|
||||
Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой CDN сервер клиент должен делать запрос.
|
||||
Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которая доставляет содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой CDN сервер клиент должен делать запрос.
|
||||
|
||||
Раздача содержимого из CDN может значительно улучшить производительность по двум причинам:
|
||||
|
||||
|
|
@ -1567,7 +1567,7 @@ l10n:p -->
|
|||
|
||||
### Горизонтальное масштабирование
|
||||
|
||||
Балансировщики нагрузки могут быть использованы для горизонтального масштабирования, улучшая производительность и доступность. "Масштабирование вширь" используя стандартные сервера дешевле и приводит к более высокой доступности, чем "масштабирование вверх" одного сервера с более дорогим аппаратным обеспечением (**Вертикальное масштабирование**). Так же проще найти и специалиста, который умеет работать со стандартным аппаратным обеспечением, чем со специализированными Enterprise-системами.
|
||||
Балансировщики нагрузки могут быть использованы для горизонтального масштабирования, улучшая производительность и доступность. "Масштабирование вширь", используя стандартные сервера, дешевле и приводит к более высокой доступности, чем "масштабирование вверх" одного сервера с более дорогим аппаратным обеспечением (**Вертикальное масштабирование**). Так же проще найти и специалиста, который умеет работать со стандартным аппаратным обеспечением, чем со специализированными Enterprise-системами.
|
||||
|
||||
<!-- l10n:p
|
||||
#### Disadvantage(s): horizontal scaling
|
||||
|
|
@ -1661,8 +1661,8 @@ l10n:p -->
|
|||
|
||||
Дополнительные преимущества:
|
||||
|
||||
* **повышенная безопасность** - скрывает информацию о бэкенд-серверах, блокирует IP адреса, ограничивает допустимое количество соединений на клиента
|
||||
* **повышенная масштабируемость и гибкость** - клиентское приложение знает только IP адрес прокси-сервера, таким образом можно менять количество серверов или изменять их конфигурацию
|
||||
* **Повышенная безопасность** - скрывает информацию о бэкенд-серверах, блокирует IP адреса, ограничивает допустимое количество соединений на клиента
|
||||
* **Повышенная масштабируемость и гибкость** - клиентское приложение знает только IP адрес прокси-сервера, таким образом можно менять количество серверов или изменять их конфигурацию
|
||||
* **SSL терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-серверы не тратят свои ресурсы на эти потенциально трудоемкие операции
|
||||
* нет необходимости устанавливать [X.509 сертификаты](https://ru.wikipedia.org/wiki/X.509)
|
||||
* **Сжатие** - сжатие ответов сервера клиенту
|
||||
|
|
@ -1737,7 +1737,7 @@ l10n:p -->
|
|||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
|
||||
</p>
|
||||
|
||||
Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложения, но необязательно на веб-уровне. **Принцип единственной ответственности** подразумевает создание небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
|
||||
Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложения, но необязательно на веб-уровне. **Принцип единственной ответственности** подразумевает создание небольших и автономных сервисов, которые работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
|
||||
|
||||
Worker-сервера на уровне приложений позволяют поддерживать [Асинхронность](#асинхронность).
|
||||
|
||||
|
|
@ -1862,7 +1862,7 @@ l10n:p -->
|
|||
|
||||
#### Репликация Master-Slave
|
||||
|
||||
Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могу реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
|
||||
Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могут реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/C9ioGtn.png">
|
||||
|
|
@ -1916,7 +1916,7 @@ l10n:p -->
|
|||
|
||||
##### Недостатки репликации Master-Master
|
||||
|
||||
* Необходим балансировщик нагрузки или понадобиться изменить логику приложение для определения куда будет идти запись.
|
||||
* Необходим балансировщик нагрузки или понадобиться изменить логику приложения для определения куда будет идти запись.
|
||||
* Большинство систем "Master-Master" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
|
||||
* При возрастании количества серверов для записи данных (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
|
||||
* См. [Недостатки репликации](#недостатки-репликации) для пунктом, характерных для подходов "Master-Slave" и "Master-Master".
|
||||
|
|
@ -1934,7 +1934,7 @@ l10n:p -->
|
|||
##### Недостатки репликации
|
||||
|
||||
* Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
|
||||
* Операции записи реплицируются на ведомый сервера. Если совершается много операций записи, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций чтения.
|
||||
* Операции записи реплицируются на ведомые сервера. Если совершается много операций записи, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций чтения.
|
||||
* С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
|
||||
* На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
|
||||
* Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
|
@ -2026,7 +2026,7 @@ l10n:p -->
|
|||
|
||||
Шардирование распределяет данные между разными базами данных так, что каждая база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые серверы (шарды).
|
||||
|
||||
Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшению производительности и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
|
||||
Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшению производительности и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нет централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
|
||||
|
||||
Распространённый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.
|
||||
|
||||
|
|
@ -2074,9 +2074,9 @@ l10n:p -->
|
|||
|
||||
#### Денормализация
|
||||
|
||||
Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которое выполняют задачу хранения избыточных данных и поддержку их согласованности.
|
||||
Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторые СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которое выполняют задачу хранения избыточных данных и поддержку их согласованности.
|
||||
|
||||
При использовании [Федерализации](#федерализация) и [Шардирования](#шардирование), данные становятся распределенными. В результате выполнение операций соединения данных, которые могут находится в разных дата-центрах, усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.
|
||||
При использовании [Федерализации](#федерализация) и [Шардирования](#шардирование), данные становятся распределенными. В результате выполнения операций соединения данных, которые могут находится в разных дата-центрах, усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.
|
||||
|
||||
В большинстве систем, количество операций чтения значительно больше операций записи (100:1, или даже 1000:1). Операция чтения в результате сложного соединения данных может быть очень ресурсоемкой и требовать значительного времени, потраченного на операции c жестким диском.
|
||||
|
||||
|
|
@ -2124,7 +2124,7 @@ l10n:p -->
|
|||
Очень важно проводить **бенчмарки** и **профилирование** для имитации и обнаружения узких мест.
|
||||
|
||||
* **Бенчмарк** - эталонный тест производительности, имитация высокой нагрузки с помощью таких средств, как [ab](http://httpd.apache.org/docs/2.2/programs/ab.html).
|
||||
* **Профилирование** - отслеживание проблем производительность с помощью таки средства, как [slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)
|
||||
* **Профилирование** - отслеживание проблем производительность с помощью таких средства, как [slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)
|
||||
|
||||
Проведение бенчмарков и профилирования может указать на следующие шаги оптимизации.
|
||||
|
||||
|
|
@ -2150,7 +2150,7 @@ l10n:p -->
|
|||
* Используйте `TEXT` для больших фрагментов текста (например, блог-посты). `TEXT` позволяет делать булевый поиск. Использование поля типа `TEXT` приводит к хранению указателя на диске, которые используется для поиска этого блока.
|
||||
* Используйте `INT` для больших чисел до 2^32.
|
||||
* Используйте `DECIMAL` для денежных единиц для избежания ошибок, связанных с представлением в формате с плавающей точкой.
|
||||
* Избегайте хранения больших `BLOBS`, вместо храните указатель на объект.
|
||||
* Избегайте хранения больших `BLOBS`, вместо этого храните указатель на объект.
|
||||
* Установите ограничения `NOT NULL`, где возможно, для улучшения производительности ([improve search performance](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)).
|
||||
|
||||
|
||||
|
|
@ -2167,10 +2167,10 @@ l10n:p -->
|
|||
##### Используйте хорошие индексы
|
||||
|
||||
* Запрос столбцов (включая операторы `SELECT`, `GROUP BY`, `ORDER BY`, `JOIN`) может быть быстрее с индексами.
|
||||
* Индексы обычно представляют собой самобалансирующиеся [B-деревья](https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE), которые хранят данные отсортированными, позволяют поиск, последовательный доступ, вставку и удаление с логарифмической сложностью.
|
||||
* Индексы обычно представляют собой самобалансирующиеся [B-деревья](https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE), которые хранят данные отсортированными, позволяют делать поиск, последовательный доступ, вставку и удаление с логарифмической сложностью.
|
||||
* Добавление индекса может потребовать хранения данных в памяти, требуя больше места.
|
||||
* Операции записи могут быть медленнее, так как индекс тоже необходимо обновлять.
|
||||
* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции. индексы в таком случае обновляются после загрузки данных.
|
||||
* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции, индексы в таком случае обновляются после загрузки данных.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Avoid expensive joins
|
||||
|
|
@ -2234,7 +2234,7 @@ l10n:p -->
|
|||
|
||||
### NoSQL
|
||||
|
||||
NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой база данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойства транзакций и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
|
||||
NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой базы данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойства транзакций и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
|
||||
|
||||
Для описания свойств NoSQL баз данных используют **BASE** свойства. Согласно [Теореме CAP](#теорема-cap), BASE придерживается доступности данных, а не их согласованности.
|
||||
|
||||
|
|
@ -2242,7 +2242,7 @@ NoSQL - это набор данных, представленных в виде
|
|||
* **Неокончательное (soft) удаление** - состояние ситемы может со временем измениться, даже без дополнительных операций.
|
||||
* **Согласованность в конечном счете (eventual consistency)** - данные в системе станут согласованными в течение некоторого времени, если в течение этого времени не будут приходить новые данные.
|
||||
|
||||
Вместе с выбором между [SQL или NoSQL](#sql-или-nosql), надо сделать выбор типа NoSQL базы данных, которая подходит для вашего сценария использования. В следующей секции представлены **базы ключ-значение**, **документориентированные базы данных**, **колоночные базы данных** или **графовые база данных**.
|
||||
Вместе с выбором между [SQL или NoSQL](#sql-или-nosql), надо сделать выбор типа NoSQL базы данных, которая подходит для вашего сценария использования. В следующей секции представлены **базы ключ-значение**, **документориентированные базы данных**, **колоночные базы данных** или **графовые базы данных**.
|
||||
|
||||
<!-- l10n:p
|
||||
#### Key-value store
|
||||
|
|
@ -2258,11 +2258,11 @@ l10n:p -->
|
|||
|
||||
#### Хранилище типа ключ-значение
|
||||
|
||||
> Абстракция: хэщ-таблица
|
||||
> Абстракция: хэш-таблица
|
||||
|
||||
Хранилище типа ключ-значение обычно позволяет выполнять операции чтение и записи со сложностью O(1) и используют оперативную память или SSD. Эти хранилища могут поддерживать [лексикографический порядок](https://ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%BA%D1%81%D0%B8%D0%BA%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA), позволяя эффективно выполнять запросы на диапазон ключей. Базы этого типа позволяют хранить мета-данные вместе с данными.
|
||||
Хранилище типа ключ-значение обычно позволяет выполнять операции чтения и записи со сложностью O(1) и используют оперативную память или SSD. Эти хранилища могут поддерживать [лексикографический порядок](https://ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%BA%D1%81%D0%B8%D0%BA%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA), позволяя эффективно выполнять запросы на диапазон ключей. Базы этого типа позволяют хранить мета-данные вместе с данными.
|
||||
|
||||
Такие хранилища имеют высокую производительность и обычно используют для простых моделей данных или для быстро изменяющихся данных, таких как кэши, находящейся в оперативной памяти. Обычно они предоставляют ограниченный набор действий. Поэтому сложность смещается на уровень приложение в том случае, если необходимы дополнительные действия.
|
||||
Такие хранилища имеют высокую производительность и обычно используют для простых моделей данных или для быстро изменяющихся данных, таких как кэши, находящиеся в оперативной памяти. Обычно они предоставляют ограниченный набор действий. Поэтому сложность смещается на уровень приложение в том случае, если необходимы дополнительные действия.
|
||||
|
||||
Хранилища типа ключ-значение являются основой для более сложных систем, таких как хранилище документов и, в некоторых случаях, графовые базы данных.
|
||||
|
||||
|
|
@ -2400,7 +2400,7 @@ l10n:p -->
|
|||
|
||||
> Абстракция: граф
|
||||
|
||||
В графовой базе данных, каждый узел это запись, а ребра это связь между двумя узлами. Графовые базы данных оптимизированы для представление сложных связей с множеством внешних ключей или связей многих ко многим.
|
||||
В графовой базе данных, каждый узел это запись, а ребра это связь между двумя узлами. Графовые базы данных оптимизированы для представления сложных связей с множеством внешних ключей или связей многих ко многим.
|
||||
|
||||
Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью [REST API](#rest-representational-state-transfer).
|
||||
<!-- l10n:p
|
||||
|
|
@ -2664,7 +2664,7 @@ l10n:p -->
|
|||
При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных:
|
||||
|
||||
* Объект удаляется из кэша, если структура данных, которую он представляет, изменилась
|
||||
* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версии закэшированных объектов
|
||||
* Возможна асинхронная обработка: новые объекты могут собираться из текущий версии закэшированных объектов
|
||||
|
||||
Что можно кэшировать как объекты:
|
||||
|
||||
|
|
@ -2828,7 +2828,7 @@ def set_user(user_id, values):
|
|||
* Most data written might never be read, which can be minimized with a TTL.
|
||||
l10n:p -->
|
||||
|
||||
##### Недостатки кэширование Write through
|
||||
##### Недостатки кэширования Write through
|
||||
|
||||
* Когда добавляется новый сервер из-за отказа другого, либо в результате масштабирования, его кэш не содержит никаких элементов, пока данные не обновятся в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
|
||||
* Большая часть записываемых данных может вообще не использоваться. Использование времени жизни данных (TTL) может смягчить последствия этой проблемы.
|
||||
|
|
@ -3022,7 +3022,7 @@ l10n:p -->
|
|||
|
||||
### Обратное давление
|
||||
|
||||
Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэше, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
|
||||
Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэше, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди, поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
|
||||
|
||||
<!-- l10n:p
|
||||
### Disadvantage(s): asynchronism
|
||||
|
|
@ -3161,9 +3161,9 @@ TCP - это протокол с установкой соединения, ра
|
|||
|
||||
Если отправитель не получает правильного ответа, пакеты будут отправлены повторно. Если время ожидания истекает несколько раз, соединение разрывается. TCP также реализует [контроль потока](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0) и [отслеживание перегрузок](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control). Такие гарантии вызывают задержки и обычно приводят к менее эффективной передаче по сравнению с UDP.
|
||||
|
||||
Для поддержки высокой пропускной способности, веб-сервера могут содержать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером [Memcached](https://memcached.org/). В этом случае может помочь использование [пула соединений](https://en.wikipedia.org/wiki/Connection_pool) и UPD там, где он может быть применим.
|
||||
Для поддержки высокой пропускной способности, веб-сервера могут содержать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером [Memcached](https://memcached.org/). В этом случае может помочь использование [пула соединений](https://en.wikipedia.org/wiki/Connection_pool) и UDP там, где он может быть применим.
|
||||
|
||||
TCP подходит для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
|
||||
TCP подходит для приложений, которым необходимы высокая надежность, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
|
||||
|
||||
Используйте TCP (а не UDP) в случаях, когда необходимо:
|
||||
|
||||
|
|
@ -3325,7 +3325,7 @@ l10n:p -->
|
|||
|
||||
* клиентские приложения RPC становятся сильно связанными с сервисной реализацией.
|
||||
* необходимо делать новое API для каждой новой операции или сценария использования.
|
||||
* отладка (debug) вызов RPC может быть непростой.
|
||||
* отладка (debug) вызовов RPC может быть непростой.
|
||||
* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах систем кэширования таких, как, например, [Squid](http://www.squid-cache.org/).
|
||||
|
||||
<!-- l10n:p
|
||||
|
|
@ -3354,7 +3354,7 @@ l10n:p -->
|
|||
|
||||
### REST (Representational state transfer)
|
||||
|
||||
REST - это архитектурный стиль взаимодействия клиента и сервера, где клиент работает с ресурсами, управляемыми сервером. Сервер предоставляет представление ресурсов и действия для их управления, или получения нового представления. Любое взаимодействие не должно иметь состояния и быть кэшируемым.
|
||||
REST - это архитектурный стиль взаимодействия клиента и сервера, где клиент работает с ресурсами, управляемыми сервером. Сервер предоставляет представление ресурсов и действия для их управления, или получения нового представления. Любое взаимодействие не должно иметь состояния и должно быть кэшируемым.
|
||||
|
||||
Существует четыре характеристики REST-интерфейса:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue