mirrors
/
system-design-primer
mirror of https://github.com/donnemartin/system-design-primer.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Translate: DNS, CDN, LB

pull/502/head
voitau 2020-04-18 21:08:07 -07:00
parent 8053fd86d4
commit f323c7332a
1 changed files with 119 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

154
README-ru.md
View File

@ -297,7 +297,7 @@ l10n:p -->
## Index of system design topics ## Index of system design topics
> Обобщение различных тем по проектирования систем, включая преимущества и недостатки. **Любое решение требует уступок**. > Обобщение различных тем по проектирования систем, включая преимущества и недостатки. **Любое решение требует компромисса**.
> >
> Каждый раздел содержит ссылки на более подробное описание. > Каждый раздел содержит ссылки на более подробное описание.
@ -574,7 +574,7 @@ l10n:p -->
* Кэширование * Кэширование
* Шардинг (sharding) базы данных * Шардинг (sharding) базы данных
Обсудите потенциальные варианты и уступки. Разберитесь с узкими местами используя [principles of scalable system design](#index-of-system-design-topics). Обсудите потенциальные варианты и компромиссы. Разберитесь с узкими местами используя [principles of scalable system design](#index-of-system-design-topics).
<!-- l10n:p <!-- l10n:p
### Back-of-the-envelope calculations ### Back-of-the-envelope calculations
@ -880,13 +880,13 @@ l10n:p -->
### Next steps ### Next steps
Далее, изучим уступки в общем виде: Далее, изучим компромиссы в общем виде:
* **Производительность** и **масштабирование** * **Производительность** и **масштабирование**
* **Задержка** и **пропускная способность** * **Задержка** и **пропускная способность**
* **Доступность** и **согласованность данных** * **Доступность** и **согласованность данных**
Помните, что **везде необходимы уступки**. Помните, что **везде необходимы компромиссы**.
Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы. Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.
@ -984,7 +984,7 @@ l10n:p -->
<i><a href=https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP>Дополнительный источник: Wikipedia</a></i> <i><a href=https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP>Дополнительный источник: Wikipedia</a></i>
</p> </p>
В распределенный системах можно обеспечить только два из трех свойств, указанных ниже: В распределённый системах можно обеспечить только два из трех свойств, указанных ниже:
* **Согласованность данных (Consistency)** - каждый запрос на чтение возвращает самые актуальные данные либо ошибку. * **Согласованность данных (Consistency)** - каждый запрос на чтение возвращает самые актуальные данные либо ошибку.
* **Доступность (Availability)** - любой запрос возвращает результат, но без гарантии, что он содержит самую актуальную версию данных. * **Доступность (Availability)** - любой запрос возвращает результат, но без гарантии, что он содержит самую актуальную версию данных.
@ -1012,7 +1012,7 @@ l10n:p -->
#### AP - availability and partition tolerance #### AP - availability and partition tolerance
При таком решении ответы на запросы возвращают данные, которые могут быть не самыми актуальными. Операция на запись может занять некоторое время, если придется ожидать восстановления потерянного соединения с одним из узлов распределенной системы. При таком решении ответы на запросы возвращают данные, которые могут быть не самыми актуальными. Операция на запись может занять некоторое время, если придется ожидать восстановления потерянного соединения с одним из узлов распределённой системы.
AP решение подходит для систем, где система должна продолжать работать несмотря на внешние ошибки и допустима [eventual consistency](#eventual-consistency). AP решение подходит для систем, где система должна продолжать работать несмотря на внешние ошибки и допустима [eventual consistency](#eventual-consistency).
@ -1038,7 +1038,7 @@ l10n:p -->
## Consistency patterns ## Consistency patterns
В распределенной системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиенстким приложением, существует несколько подходов синхронизации этих копий. В распределённой системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиенстким приложением, существует несколько подходов синхронизации этих копий.
<!-- l10n:p <!-- l10n:p
### Weak consistency ### Weak consistency
@ -1120,7 +1120,7 @@ l10n:p -->
#### Active-passive #### Active-passive
В таком режиме, активный и пассивны сервер, находящийся в режиме ожидание, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не получается, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера. В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
Время простоя определяется в каком состоянии находится пассивный сервер: Время простоя определяется в каком состоянии находится пассивный сервер:
@ -1311,7 +1311,31 @@ l10n:p -->
## Domain name system ## Domain name system
TBD <p align="center">
<img src="http://i.imgur.com/IOyLj4i.jpg"/>
<br/>
<i><a href=http://www.slideshare.net/srikrupa5/dns-security-presentation-issa>Источник: DNS security presentation</a></i>
</p>
Система домменных имен (DNS) преобразует доменное имя (например, www.example.com) в IP адрес.
DNS иерархична и имеет несколько корневых серверов. Информацию о том, какой DNS сервер надо использовать, предоставляется вашим маршрутизатором или интернет-провайдером. Нижестоящие DNS сервера кэшируют таблицы соответствия хостов и IP адресов, которые могут устаревать из-за задержки обновления. Результаты преобразования могут быть закэшированы браузером или операционной системой на определенное [Время жизни (Time to live - TTL)](https://ru.wikipedia.org/wiki/Time_to_live)
Типы записей:
* **Запись NS (name server)** - указывает DNS сервер для вашего домена/поддомена.
* **Запись MX (mail exchange)** - указывает сервера электронной почты для получения сообщений.
* **Запись A (address)** - связывает имя с IP адресом.
* **CNAME (canonical)** - связывает имя с другим именем, записью CNAME (example.com to www.example.com) или записью А.
Такие сервисы, как [CloudFlare](https://www.cloudflare.com/dns/) и [Route 53](https://aws.amazon.com/route53/) предоставляют управлемые DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:
* взвешенный циклический ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
* предотвращает попадания трафика на сервера, находящиеся на обслуживании
* балансирует трафик для кластера, размер которого может меняться
* может использоваться для A/B тестирования
* на основе задержки отклика серверов
* на основе геораспределения серверов
<!-- l10n:p <!-- l10n:p
### Disadvantage(s): DNS ### Disadvantage(s): DNS
@ -1323,7 +1347,9 @@ l10n:p -->
### Disadvantage(s): DNS ### Disadvantage(s): DNS
TBD * Запрос на DNS сервер занимает некоторое время, которое может быть сокращено, используя кэширование, описанное выше.
* Управление DNS серверами может быть трудоёмким и поэтому обычно они управляются [правительствами государств, интернет-провайдерами и большими компаниями](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)
* DNS серверы могут подвергаться [DDoS-атакам](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/), в результате пользователи не могут получить доступ к сервисам, например Twitter, не зная его IP адреса(-ов).
<!-- l10n:p <!-- l10n:p
### Source(s) and further reading ### Source(s) and further reading
@ -1335,7 +1361,9 @@ l10n:p -->
### Source(s) and further reading ### Source(s) and further reading
TBD * [DNS architecture](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)
* [Wikipedia (ru)](https://ru.wikipedia.org/wiki/DNS)
* [DNS articles](https://support.dnsimple.com/categories/dns/)
<!-- l10n:p <!-- l10n:p
## Content delivery network ## Content delivery network
@ -1356,7 +1384,13 @@ l10n:p -->
## Content delivery network ## Content delivery network
TBD <p align="center">
<img src="http://i.imgur.com/h9TAuGI.jpg"/>
<br/>
<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 запрос на сайт даст ответ на какой DNS сервер клиент должен делать запрос.
<!-- l10n:p <!-- l10n:p
### Push CDNs ### Push CDNs
@ -1368,7 +1402,7 @@ l10n:p -->
### Push CDNs ### Push CDNs
TBD Содержимое Pull CDN обновляется тогда, когда оно обновлеятся на сервере. Разработчик сайта загружает содержимое на CDN и обновляет соотвествующие URL адреса, чтобы они указывали на CDN. Далее, можно сконфигурировать время жизни содержимого в CDN и когда оно должно быть обновлено. Загружается только новое или обновленное содержимое, минимизируя трафик и увеличивая объем хранящихся данных в CDN.
<!-- l10n:p <!-- l10n:p
### Pull CDNs ### Pull CDNs
@ -1382,7 +1416,11 @@ l10n:p -->
### Pull CDNs ### Pull CDNs
TBD Pull CDN загружает новое содержимое при первом обращении пользователя. Разработчик сайта оставляет содержимое на своем сервере, но обновляет адреса, чтобы они указывали на CDN. В результате, запрос обрабатывается медленее, ожидая пока содержимое будет закэшировано в CDN.
[Время жизни (Time to live - TTL)](https://ru.wikipedia.org/wiki/Time_to_live) определяет как долго содержимое будет закэшировано. Pull CDN минимизирует объем хранящихся данных в CDN, но может привести к дополнительному трафику, если время жизни в CDN истекло, а файл на сервере изменен не был.
Pull CDN подходит для загруженных сайтов. Трафик в таком случае распределяется более равномерно и в результате в CDN хранится только то содержимое, к которому обращались недавно.
<!-- l10n:p <!-- l10n:p
### Disadvantage(s): CDN ### Disadvantage(s): CDN
@ -1394,7 +1432,9 @@ l10n:p -->
### Disadvantage(s): CDN ### Disadvantage(s): CDN
TBD * Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут если CDN не использовать.
* Содежимое в CDN может оказаться устаревшим, если оно будет обновлено до того, как истечет время жизни (TTL).
* Исходные URL ссылки должны быть изменены и указывать на CDN.
<!-- l10n:p <!-- l10n:p
### Source(s) and further reading ### Source(s) and further reading
@ -1406,7 +1446,9 @@ l10n:p -->
### Source(s) and further reading ### Source(s) and further reading
TBD * [Globally distributed content delivery](https://figshare.com/articles/Globally_distributed_content_delivery/6605972)
* [The differences between push and pull CDNs](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
* [Wikipedia (ru)](https://ru.wikipedia.org/wiki/Content_Delivery_Network)
<!-- l10n:p <!-- l10n:p
## Load balancer ## Load balancer
@ -1445,7 +1487,36 @@ l10n:p -->
## Load balancer ## Load balancer
TBD <p align="center">
<img src="http://i.imgur.com/h81n9iK.png"/>
<br/>
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Source: Scalable system design patterns</a></i>
</p>
Балансировщик нагрузки распределяет входящие клиентские запросы между серверами приложений или баз данных, возвращая ответ от конкретного сервера клиенту, от которого пришел запрос. Балансировщики нагрузки используются для:
* предотвращения запроса на неработающий сервер
* предотвращения чрезмерной нагрузки ресурсов
* избежания единой точки отказа
Балансировщики нагрузки могут быть аппаратными (дорогой вариант) или программными (например, HAProxy).
Дополнительные плюсы:
* **SSL-терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-сервера не тратят свои ресурсы на эти потенциально трудоемкие операции
* нет необходимости устанавливать [X.509 сертификаты](https://ru.wikipedia.org/wiki/X.509)
* **Сохранение сессии** - выдает куки и перенаправляет клиенсткий запрос на тот же сервер в случае, если сами веб-приложения не хранят сессии.
Для защиты от сбоев, можно использовать вместе несколько балансировщиков в [active-passive](#active-passive) или [active-active](#active-active) режиме.
Балансировщики могут направлять трафик опираюсь на различные метрики, включая:
* случайно
* наименее загруженные сервер
* сессия/куки
* взвешенный циклический ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb))
* [Layer 4](#layer-4-load-balancing)
* [Layer 7](#layer-7-load-balancing)
<!-- l10n:p <!-- l10n:p
### Layer 4 load balancing ### Layer 4 load balancing
@ -1455,7 +1526,7 @@ l10n:p -->
### Layer 4 load balancing ### Layer 4 load balancing
TBD Для распределения запросов балансировщики 4го уровня используют транспортный уровень модели OSI [transport layer](#communication). Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
<!-- l10n:p <!-- l10n:p
### Layer 7 load balancing ### Layer 7 load balancing
@ -1467,7 +1538,9 @@ l10n:p -->
### Layer 7 load balancing ### Layer 7 load balancing
TBD Для распределения запросов балансировщики 7го уровня используют прикладной уровень модели OSI [application layer](#communication). Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить запрос на видео на видео-сервер, а запрос на биллинг - на сервера с усиленной безопасностью.
Балансировка на 4м уровне быстрее и требует меньше ресусров, чем на 7м уровне, но имеет меньшую гибкость. Хотя на современном аппаратном обеспечении эта разница может быть незаметна.
<!-- l10n:p <!-- l10n:p
### Horizontal scaling ### Horizontal scaling
@ -1477,7 +1550,7 @@ l10n:p -->
### Horizontal scaling ### Horizontal scaling
TBD Балансировщики нагрузки могут быть использованы для горизонтального масштабирования, улучшая производительность и доступность. "Масштабирование вширь" используя стандартные сервера дешевле и приводит к более высокой доступности, чем "масштабирование вверх" одного сервера с более дорогим аппаратным обеспечением (**Вертикальное масштабирование**). Так же проще найти и специалиста, который умеет работать со стандартным аппаратным обеспечением, чем со специализированными Enterprise-системами.
<!-- l10n:p <!-- l10n:p
#### Disadvantage(s): horizontal scaling #### Disadvantage(s): horizontal scaling
@ -1490,7 +1563,10 @@ l10n:p -->
#### Disadvantage(s): horizontal scaling #### Disadvantage(s): horizontal scaling
TBD * Горизонтальное масштабирование увеливает сложность система и предполагает клонирование серверов:
* Сервера не должны хранить состояние, например сессию или изображение пользователя
* Сессии должны хранится в центразиванном хранилище, например в [database](#database) (SQL, NoSQL) или в [cache](#cache) (Redis, Memcached)
* С увеличением количества серверов, принимающие сервера на следующем уровне должны обрабатывать больше одновременных запросов
<!-- l10n:p <!-- l10n:p
### Disadvantage(s): load balancer ### Disadvantage(s): load balancer
@ -1502,7 +1578,9 @@ l10n:p -->
### Disadvantage(s): load balancer ### Disadvantage(s): load balancer
TBD * Балансировщик нагрузки может стать узким место в производительности системы, если он неправильно сконфигурирован или его аппаратное обеспечение слишком слабое.
* Балансировщик нагрузки позволяет избежать единой точки отказа, но увеличивает совокупную сложность всей системы.
* Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиком еще больше усложняет систему.
<!-- l10n:p <!-- l10n:p
### Source(s) and further reading ### Source(s) and further reading
@ -1518,7 +1596,13 @@ l10n:p -->
### Source(s) and further reading ### Source(s) and further reading
TBD * [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
* [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt)
* [Scalability](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
* [Wikipedia](https://en.wikipedia.org/wiki/Load_balancing_(computing))
* [Layer 4 load balancing](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
* [Layer 7 load balancing](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
* [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)
<!-- l10n:p <!-- l10n:p
## Reverse proxy (web server) ## Reverse proxy (web server)
@ -3103,26 +3187,26 @@ l10n:p -->
| Тип | Система | Ссылки | | Тип | Система | Ссылки |
|---|---|---| |---|---|---|
| Обработка данных | **MapReduce** - Распределенная обработка данных от Google | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) | | Обработка данных | **MapReduce** - распределённая обработка данных от Google | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |
| Обработка данных | **Spark** - Распределенная обработка данных от Databricks | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) | | Обработка данных | **Spark** - распределённая обработка данных от Databricks | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |
| Обработка данных | **Storm** - Распределенная обработка данных от Twitter | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) | | Обработка данных | **Storm** - распределённая обработка данных от Twitter | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) |
| | | | | | | |
| Хранилище данных | **Bigtable** - Распределенная колоночная база данных от Google | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) | | Хранилище данных | **Bigtable** - распределённая колоночная база данных от Google | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |
| Хранилище данных | **HBase** - Реализация Bigtable с открытым исходным кодом | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) | | Хранилище данных | **HBase** - Реализация Bigtable с открытым исходным кодом | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) |
| Хранилище данных | **Cassandra** - Распределенная колоночная база данных от Facebook | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666) | Хранилище данных | **Cassandra** - распределённая колоночная база данных от Facebook | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)
| Хранилище данных | **DynamoDB** - Документно-ориенитрованная база данных от Amazon | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) | | Хранилище данных | **DynamoDB** - Документно-ориенитрованная база данных от Amazon | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |
| Хранилище данных | **MongoDB** - Документно-ориенитрованная база данных | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) | | Хранилище данных | **MongoDB** - Документно-ориенитрованная база данных | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |
| Хранилище данных | **Spanner** - Глобально-распределенная база данных от Google | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) | | Хранилище данных | **Spanner** - Глобально-распределённая база данных от Google | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) |
| Хранилище данных | **Memcached** - Распределенный кэш, хранящийся в памяти | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) | | Хранилище данных | **Memcached** - распределённый кэш, хранящийся в памяти | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Хранилище данных | **Redis** - Распеределенная система кэширавния с возможностью сохранения и типами данных | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) | | Хранилище данных | **Redis** - Распеределенная система кэширавния с возможностью сохранения и типами данных | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| | | | | | | |
| Файловая система | **Google File System (GFS)** - Распределенная файловая система | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) | | Файловая система | **Google File System (GFS)** - распределённая файловая система | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
| Файловая система | **Hadoop File System (HDFS)** - Реализация GFS с открытым исходным кодом | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) | | Файловая система | **Hadoop File System (HDFS)** - Реализация GFS с открытым исходным кодом | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) |
| | | | | | | |
| Другое | **Chubby** - Система блокировки для слабосвязанных распределенных систем от Google | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) | | Другое | **Chubby** - Система блокировки для слабосвязанных распределённых систем от Google | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
| Другое | **Dapper** - Система отслеживания операций в распределенных системах | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf) | Другое | **Dapper** - Система отслеживания операций в распределённых системах | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf)
| Другое | **Kafka** - Очередь сообщений Pub/sub от LinkedIn | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) | | Другое | **Kafka** - Очередь сообщений Pub/sub от LinkedIn | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) |
| Другое | **Zookeeper** - Централизованная инфраструктура и сервисы для синхронизации распределенных систем | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) | | Другое | **Zookeeper** - Централизованная инфраструктура и сервисы для синхронизации распределённых систем | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |
| | Добавьте архитектуру | [Contribute](#contributing) | | | Добавьте архитектуру | [Contribute](#contributing) |
<!-- l10n:p <!-- l10n:p
@ -3306,7 +3390,7 @@ l10n:p -->
Заинтересованы в добавлении раздела или в завершении того, что уже в процессе? [Содействуйте!](#contributing)! Заинтересованы в добавлении раздела или в завершении того, что уже в процессе? [Содействуйте!](#contributing)!
* Распределенные вычисления с MapReduce * распределённые вычисления с MapReduce
* Согласованное хеширование * Согласованное хеширование
* Scatter gather * Scatter gather
* [Содействие](#contributing) * [Содействие](#contributing)