@ -61,7 +61,7 @@ See [Translations](TRANSLATIONS.md).
### Adding translations to new languages
Translations to new languages are always welcome! Keep in mind a transation must be maintained.
Translations to new languages are always welcome! Keep in mind a translation must be maintained.
* Do you have time to be a maintainer for a new language? Please see the list of [translations](TRANSLATIONS.md) and tell us so we know we can count on you in the future.
* Check the [translations](TRANSLATIONS.md), issues, and pull requests to see if a translation is in progress or stalled. If it's in progress, offer to help. If it's stalled, consider becoming the maintainer if you can commit to it.
В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такое сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
Время простоя определяется состоянием, в котором находится пассивный сервер:
@ -1320,7 +1320,7 @@ Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route 53](ht
@ -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 сервисы могут направлять трафик, используя различные методы:
* предотвращает попадание трафика на серверы, находящиеся на обслуживании
@ -1401,7 +1401,7 @@ l10n:p -->
<i><ahref=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><ahref=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
Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могу реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могут реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
<palign="center">
<imgsrc="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 -->
При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных:
* Объект удаляется из кэша, если структура данных, которую он представляет, изменилась
* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версии закэшированных объектов
* Возможна асинхронная обработка: новые объекты могут собираться из текущий версии закэшированных объектов
* 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 - это архитектурный стиль взаимодействия клиента и сервера, где клиент работает с ресурсами, управляемыми сервером. Сервер предоставляет представление ресурсов и действия для их управления, или получения нового представления. Любое взаимодействие не должно иметь состояния и должно быть кэшируемым.
@ -433,7 +433,7 @@ Generally, you should aim for **maximal throughput** with **acceptable latency**
### Source(s) and further reading
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
## Availability vs consistency
@ -461,7 +461,7 @@ Waiting for a response from the partitioned node might result in a timeout error
Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.
AP is a good choice if the business needs allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
AP is a good choice if the business needs to allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
### Source(s) and further reading
@ -597,7 +597,7 @@ DNS is hierarchical, with a few authoritative servers at the top level. Your ro
Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route 53](https://aws.amazon.com/route53/) provide managed DNS services. Some DNS services can route traffic through various methods:
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
@ -1159,7 +1159,7 @@ Your database usually includes some level of caching in a default configuration,
### Application caching
In-memory caches such as Memcached and Redis are key-value stores between your application and your data storage. Since the data is held in RAM, it is much faster than typical databases where data is stored on disk. RAM is more limited than disk, so [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) algorithms such as [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) can help invalidate 'cold' entries and keep 'hot' data in RAM.
In-memory caches such as Memcached and Redis are key-value stores between your application and your data storage. Since the data is held in RAM, it is much faster than typical databases where data is stored on disk. RAM is more limited than disk, so [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) algorithms such as [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) can help invalidate 'cold' entries and keep 'hot' data in RAM.
Redis has the following additional features:
@ -1668,12 +1668,12 @@ Handy metrics based on numbers above:
| Design a content delivery network like CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |
| Design a trending topic system like Twitter's | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
| Design a random ID generation system | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/twitter/snowflake/) |
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/cs.ucsb.edu/files/docs/reports/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
| Design a system that serves data from multiple data centers | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
| Design an online multiplayer card game | [indieflashblog.com](http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
| Design an online multiplayer card game | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
| Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
| Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implemenation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implementation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
| Add a system design question | [Contribute](#contributing) |
### Real world architectures
@ -1723,7 +1723,7 @@ Handy metrics based on numbers above:
Alex Voitau
Oleg Artamonov
dgolant
Iheb Haboubi
Anand
Chetan Nair
Kian-Meng Ang
mleers
Nnachevvv
Lawrence Chou
ayyjohn
Trần Tiến Đức
Donne Martin
Laurent Erignoux