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

169 KiB
Raw Blame History

English | 日本語 | Русский | 简体中文 | 繁體中文

Пособие по проектированию систем

WARNING: the document is currently being translated. If you want to contribute:

  • choose a task for a section which you want to translate in the Project
  • assign it to yourself and move it to In progress
  • do not change original text in comments
  • make PR to this fork. When translation is complete, all changes will go into one PR to main repository.

ВНИМАНИЕ: статья находится в процессе активного перевода. Если вы хотите поучастововать:

  • выберите доступную задачу с секцией для перевода в Проекте
  • переведите ее состояние в In progress
  • не изменяйте оригинальный текст, находящийся в комментариях
  • сделайте PR в этот fork. Когда перевод будет готов, все изменения вместе будут предложены в основной репозиторий.


Мотивация

Узнайте, как проектировать крупномасштабные системы.

Подготовьтесь к собеседованию по проектированию системы.

Научитесь проектировать крупномасштабные системы

Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.

Проектирование систем - это широкая тема. В сети есть огромное количество ресурсов по принципам проектирования систем.

Этот репозиторий представляет собой организованную коллекцию ресурсов, которые помогут вам научиться создавать системы на большом масштабе.

Учитесь у сообщества по разработке ПО с открытым исходным кодом

Это постоянно обновляемый проект с открытым исходным кодом.

Contributions очень приветствуются!

Подготовка к собеседованию по проектированию системы

В дополнение к интервью по написанию кода, проектирование систем является обязательным компонентом процесса технического интервью во многих технологических компаниях.

Практикуйте общие вопросы по проектированию систем и сравнивайте свои результаты с примерами решений: обсуждения, код и диаграммы.

Дополнительные темы для подготовки к собеседованию:

Anki flashcards


Предоставленные карточки Anki могут быть использованы для повторения и запоминания ключевых концепций проектирования систем.

Отлично подходят для использования на ходу.

Coding Resource: Interactive Coding Challenges

Ищете ресурсы для подготовки к Coding Interview?


Посмотрите другой репозиторий Interactive Coding Challenges, который тоже содержит колоду карт Anki:

Contributing

Учитесь у сообщества.

Не стесняйтесь отправлять запросы на:

  • Исправление ошибок
  • Улучшение разделов
  • Добавление новых разделов
  • Перевод

Контент, который нуждается в некоторой полировке, помещается в раздел В разработке.

Ознакомьтесь с Принципами Содействия.

Index of system design topics

Обобщение различных тем по проектирования систем, включая преимущества и недостатки. Любое решение требует уступок.

Каждый раздел содержит ссылки на более подробное описание.


Study guide

Предлагаемые темы для повторения в зависимости от того, сколько у вас есть времени для подготовки к интервью (мало, средне, много)

Imgur

Вопрос: Надо ли мне знать все из этого документа для интервью?

Ответ: Нет, не обязательно.

То, что вас будут спрашивать на интервью, зависит от:

  • Вашего опыта - сколько времени и чем вы занимались
  • Должности, на которую вы собеседуетесь
  • Компания, в которую вы собеседуетесь
  • Удача

Ожидается, что более опытные кандидаты в общем случае знают больше о проектировании систем, а архитекторы и руководители комманд знают больше, чем индивидуальные разработчики. Топовые IT компании скорее всего будут проводить один или более этапов собеседования по проектированию систем.

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

  • Короткий срок - настраиватесь на широту покрытия тем. Тренируйтесь отвечать на некоторые вопросы.
  • Средний срок - настраиватесь на широту и немного глубины покрытия тем. Тренируйтесь отвечать на многие вопросы.
  • Длительный срок - настраиватесь на широту и больше глубины покрытия тем. Тренируйтесь отвечать на большинство вопросов.
Малый срок Средний срок Длительный срок
Читайте System design topics, чтобы получить общее понимание, как работают системы 👍 👍 👍
Почитайте несколько статей из блогов компаний, в который вы собеседуетесь Company engineering blogs 👍 👍 👍
Посмотрите несколько Real world architectures 👍 👍 👍
How to approach a system design interview question 👍 👍 👍
System design interview questions with solutions Немного Много Большинство
Object-oriented design interview questions with solutions Немного Много Большинство
Additional system design interview questions Немного Много Большинство

How to approach a system design interview question

Как отвечать на вопросы на интерьвю по проектированию систем

Это интервью является открытой беседой. Ожидается, что вы возьмете инициативу по его ведению на себя.

Изучите раздел System design interview questions with solutions и используйте шаги, описанные ниже.

Step 1: Outline use cases, constraints, and assumptions

Соберите требование и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.

  • Кто будет использовать решение?
  • Как его будут использовать?
  • Сколько пользователей?
  • Что система должна делать?
  • Что система получает на вход, и что должно быть на выходе?
  • Какое количество данных система должна обрабатывать?
  • Сколько ожидается запросов в секунду?
  • Какое соотношение количества операций на чтение и запись?

Step 2: Create a high level design

Сделайте набросок проекта с наиболее важными компонентами:

  • Выделите главные компоненты и связи между ними
  • Обоснуйте ваши идеи

Step 3: Design core components

Детализируйте каждый компонент. Например, если вас попросили разработать design a url shortening service, обсудите следующие моменты:

  • Генерация и хранения хэша оригинального URL
    • MD5 и Base62
    • Коллизии хэш-функции
    • SQL или NoSQL
    • Схема базы данных
  • Перевод хэшированного URL в оригинальный URL
    • Поиск в базе данных
  • API и объектно-ориентированное проектирование

Step 4: Scale the design

Определите узкие места и разберитесь с ними, учитывая данные ограничения. Например, для решение проблем с масштабируемостью, может ли вам понадобиться что-то из:

  • Балансировщик нагрузки
  • Горизонтальное машстабирование
  • Кэширование
  • Шардинг (sharding) базы данных

Обсудите потенциальные варианты и уступки. Разберитесь с узкими местами используя principles of scalable system design.

Back-of-the-envelope calculations

Вас могу спросить сделать оценку решения по некоторые параметрам. Некоторые разделы Appendix могут с этим помочь:

Source(s) and further reading

Посмотрите следующие ссылки, чтобы понять, что можно ожидать (внешние ссылки без перевода):

System design interview questions with solutions

Распространенные задачи с обсуждением, кодом и диаграммами.

Решение находятся в директории solutions/.

Задача на проектирование
Pastebin.com (или Bit.ly) Решение
Лента и поиск в Twitter (или Facebook) Решение
Веб-сканер Решение
Система управление личными финансами Mint.com Решение
Структура данных для социальной сети Решение
Хранилище типа ключ-значение для поисковика Решение
Рейтинг продаж по категориям в Amazon Решение
Система, которая масштабируется до миллиона пользователей на AWS Решение
Добавьте задачу Решение

Design Pastebin.com (or Bit.ly)

Требования и решение

Imgur

Design the Twitter timeline and search (or Facebook feed and search)

Требования и решение

Imgur

Design a web crawler

Требования и решение

Imgur

Design Mint.com

Требования и решение

Imgur

Design the data structures for a social network

Требования и решение

Imgur

Design a key-value store for a search engine

Требования и решение

Imgur

Design Amazon's sales ranking by category feature

Требование и решение

Imgur

Design a system that scales to millions of users on AWS

Требования и решение

Imgur

Object-oriented design interview questions with solutions

Распространенные задачи с обсуждением, кодом и диаграммами.

Решение находятся в директории solutions/.

Внимание, этот раздел находится в стадии разработки

Задачи на проектировние
Хэш таблица Решение
Кэширование с удалением давно используемых (Least recently used - LRU) Решение
Центр обработки звонков Решение
Колода карт Решение
Парковка Решение
Чат сервер Решение
Циклический массив Contribute
Добавьте задачу Contribute

System design topics: start here

Только начинайте изучать проектирование систем?

Для начала, вам понадобится понимание базовых принципов, как они используются, их преимущества и недостатки.

Step 1: Review the scalability video lecture

Лекция по масштабированию в Гарварде

  • Темы:
    • Вертикальное масштабирование
    • Горизонтальное масштабирование
    • Кэширование
    • Балансировка нагрузки
    • Репликация баз данных
    • Секцирование (Partitioning) баз данных

Step 2: Review the scalability article

Масштабирование

Next steps

Далее, изучим уступки в общем виде:

  • Производительность и масштабирование
  • Задержка и пропускная способность
  • Доступность и согласованность данных

Помните, что везде необходимы уступки.

Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.

Performance vs scalability

Сервис считается масштабируемым, если его производительность растет пропорционально добавленным ресурсам. Обычно под увеличением производительности подразумевают увеличение количества обрабатываемых единиц работы. Однако, это может быть и обработка более крупных единиц работы, как, например, при росте объема данных.1

Иначе говоря:

  • если у вас проблемы с производительностью, ваша система медленная для одного пользователя;
  • если у вас проблемы с масштабируемостью, ваша системы быстрая для одного пользователя, но становится медленной под большой нагрузкой.

Source(s) and further reading

Latency vs throughput

Задержка - это время, необходимое для выполнения действия или достижения некоторого результата.

Пропускная способность - это количество такие действий или результататов в единицу времени.

Обычно следует стремиться к максимальной пропускной способности, при этом сохраняя задержку приемлимой.

Source(s) and further reading

Availability vs consistency

CAP theorem


Источник: CAP theorem revisited
Дополнительный источник: Wikipedia

В распределенный системах можно обеспечить только два из трех свойств, указанных ниже:

  • Согласованность данных (Consistency) - каждый запрос на чтение возвращает самые актуальные данные либо ошибку.
  • Доступность (Availability) - любой запрос возвращает результат, но без гарантии, что он содержит самую актуальную версию данных.
  • Устойчивость к разделению (Partition Tolerance) - система продолжает работать, несмотря на произвольное разделение узлов системы из-за проблем с сетью.

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

CP - consistency and partition tolerance

При таком подходе ожидание ответа от узла может привести к ошибке - истечению времени ожидания (timeout error). CP решение хорошо подходит для систем, где необходима атомарность операций чтения и записи.

AP - availability and partition tolerance

При таком решении ответы на запросы возвращают данные, которые могут быть не самыми актуальными. Операция на запись может занять некоторое время, если придется ожидать восстановления потерянного соединения с одним из узлов распределенной системы.

AP решение подходит для систем, где система должна продолжать работать несмотря на внешние ошибки и допустима eventual consistency.

Source(s) and further reading

Consistency patterns

В распределенной системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиенстким приложением, существует несколько подходов синхронизации этих копий.

Weak consistency

После операции записи данных, операция чтения может увидеть эти данные, а может и не увидеть. Используется подход, при котором можно сделать как можно лучше, но с учетом данной ситуации.

Этот подход используеются в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и игры реального времени на несколько игроков.

Eventual consistency

После операции записи данных, операция чтения в конечном счете увидит эти данные (обычно в течение нескольких миллисекунд). Данных в таком случае реплицируются асинхронно.

Такой подход используется в таких системах, как DNS и электронная почта. Согласованность в конечном счете хорошо подходит для систем с высокой доступностью.

Strong consistency

После операции записи данных, операция чтения увидит эти данны. Данные реплицируются синхронно.

Такой подход используеются в файловых системаях и реляционных БД. Сильная согласованность хорошо подходит для систем, где требуются транзакции.

Source(s) and further reading

Availability patterns

Для обеспечения высокой доступности существует два основных паттерна: отказоустойчивость и репликация.

Fail-over

Active-passive

В таком режиме, активный и пассивны сервер, находящийся в режиме ожидание, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не получается, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.

Время простоя определяется в каком состоянии находится пассивный сервер:

  • горячее (hot) ожидание - сервер уже работает
  • холодное (cold) ожидание - сервер должен быть запущен.

Только активный сервер может обрабатывать клиентские запросы.

Active-active

В таком режиме, оба сервера обрабатывают клиентские запросы, распределяют нагрузку между собой.

Если сервера имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если сервера находятся во внутренней сети, то клиентское приложение знать про оба сервера.

Режим "активный-активный" также известен как "ведущий-ведущий".

Disadvantage(s): failover

  • Отказоустойчивость делает систему более сложной и требует большего количества аппаратного обеспечения.
  • Существует вероятность потери данных, если данных не успели реплицироваться во время переключения активного и пассивного серверов.

Replication

Master-slave and master-master

Эта тема обсуждается далее в разделе Database:

Availability in numbers

Доступность обычно измеряется как сотношение времени, когда система доступна ко всему промежутку времени измерения. Обычно это количество девяток. Говорят, что сервис с доступностью 99.99%, имеет доступность в четыре девятки.

99.9% availability - three 9s

Длительность Допустимое время простоя
Время простоя в год 8ч 45мин 57сек
Время простоя в месяц 43мин 49.7сек
Время простоя в неделю 10мин 4.8сек
Время простоя в день 1мин 26.4сек

99.99% availability - four 9s

Длительность Допустимое время простоя
Время простоя в год 52мин 35.7сек
Время простоя в месяц 4мин 23сек
Время простоя в неделю 1мин 5сек
Время простоя в день 8.6сек

Availability in parallel vs in sequence

Если сервис состоит из нескольких компонентов, которые могут отказать в обслуживании, доступность сервиса зависит от того, как связаны эти компоненты - последовательно или параллельно.

In sequence

Общая доступность уменьшается, если два компонента (например, Foo и Bar) с доступностью менее 100% связаны последовательно:

Доступность (Общая) = Доступность (Foo) * Доступность (Bar)
In parallel

Общая доступность увеличивается, если два компонента с доступностью менее 100% связаны параллельно:

Доступность (Общая) = 1 - (1 - Доступность (Foo)) * (1 - Доступность (Bar))

Domain name system

TBD

Disadvantage(s): DNS

TBD

Source(s) and further reading

TBD

Content delivery network

TBD

Push CDNs

TBD

Pull CDNs

TBD

Disadvantage(s): CDN

TBD

Source(s) and further reading

TBD

Load balancer

TBD

Layer 4 load balancing

TBD

Layer 7 load balancing

TBD

Horizontal scaling

TBD

Disadvantage(s): horizontal scaling

TBD

Disadvantage(s): load balancer

TBD

Source(s) and further reading

TBD

Reverse proxy (web server)

TBD

Load balancer vs reverse proxy

TBD

Disadvantage(s): reverse proxy

TBD

Source(s) and further reading

TBD

Application layer

TBD

Microservices

TBD

Service Discovery

TBD

Disadvantage(s): application layer

TBD

Source(s) and further reading

TBD

Database

TBD

Relational database management system (RDBMS)

TBD

Master-slave replication

TBD

Disadvantage(s): master-slave replication

TBD

Master-master replication

TBD

Disadvantage(s): master-master replication

TBD

Disadvantage(s): replication

TBD

Source(s) and further reading: replication

TBD

Federation

TBD

Disadvantage(s): federation

TBD

Source(s) and further reading: federation

TBD

Sharding

TBD

Disadvantage(s): sharding

TBD

Source(s) and further reading: sharding

TBD

Denormalization

TBD

Disadvantage(s): denormalization

TBD

Source(s) and further reading: denormalization

TBD

SQL tuning

TBD

Tighten up the schema

TBD

Use good indices

TBD

Avoid expensive joins

TBD

Partition tables

TBD

Tune the query cache

TBD

Source(s) and further reading: SQL tuning

TBD

NoSQL

TBD

Key-value store

TBD

Source(s) and further reading: key-value store

TBD

Document store

TBD

Source(s) and further reading: document store

TBD

Wide column store

TBD

Source(s) and further reading: wide column store

TBD

Graph database

TBD

Source(s) and further reading: graph

TBD

Source(s) and further reading: NoSQL

TBD

SQL or NoSQL

TBD

Source(s) and further reading: SQL or NoSQL

TBD

Cache

TBD

Client caching

TBD

CDN caching

TBD

Web server caching

TBD

Database caching

TBD

Application caching

TBD

Caching at the database query level

TBD

Caching at the object level

TBD

When to update the cache

TBD

Cache-aside

TBD

Disadvantage(s): cache-aside

TBD

Write-through

TBD

Disadvantage(s): write through

TBD

Write-behind (write-back)

TBD

Disadvantage(s): write-behind

TBD

Refresh-ahead

TBD

Disadvantage(s): refresh-ahead

TBD

Disadvantage(s): cache

TBD

Source(s) and further reading

TBD

Asynchronism

TBD

Message queues

TBD

Task queues

TBD

Back pressure

TBD

Disadvantage(s): asynchronism

TBD

Source(s) and further reading

TBD

Communication

TBD

Hypertext transfer protocol (HTTP)

TBD

Source(s) and further reading: HTTP

TBD

Transmission control protocol (TCP)

TBD

User datagram protocol (UDP)

TBD

Source(s) and further reading: TCP and UDP

TBD

Remote procedure call (RPC)

TBD

Disadvantage(s): RPC

TBD

Representational state transfer (REST)

TBD

Disadvantage(s): REST

TBD

RPC and REST calls comparison

TBD

Source(s) and further reading: REST and RPC

TBD

Security

TBD

Source(s) and further reading

TBD

Appendix

TBD

Powers of two table

TBD

Source(s) and further reading

TBD

Latency numbers every programmer should know

TBD

Latency numbers visualized

Source(s) and further reading

Additional system design interview questions

Распространенные задачи на интервью по проектированию систем со ссылками на решение.

Задача Ссылки
Design a file sync service like Dropbox youtube.com
Design a search engine like Google queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu
Design a scalable web crawler like Google quora.com
Design Google docs code.google.com
neil.fraser.name
Design a key-value store like Redis slideshare.net
Design a cache system like Memcached slideshare.net
Design a recommendation system like Amazon's hulu.com
ijcai13.org
Design a tinyurl system like Bitly n00tc0d3r.blogspot.com
Design a chat app like WhatsApp highscalability.com
Design a picture sharing system like Instagram highscalability.com
highscalability.com
Design the Facebook news feed function quora.com
quora.com
slideshare.net
Design the Facebook timeline function facebook.com
highscalability.com
Design the Facebook chat function erlang-factory.com
facebook.com
Design a graph search function like Facebook's facebook.com
facebook.com
facebook.com
Design a content delivery network like CloudFlare figshare.com
Design a trending topic system like Twitter's michael-noll.com
snikolov .wordpress.com
Design a random ID generation system blog.twitter.com
github.com
Return the top k requests during a time interval cs.ucsb.edu
wpi.edu
Design a system that serves data from multiple data centers highscalability.com
Design an online multiplayer card game indieflashblog.com
buildnewgames.com
Design a garbage collection system stuffwithstuff.com
washington.edu
Design an API rate limiter https://stripe.com/blog/
Add a system design question Contribute

Real world architectures

Статья о том, как спроектированы действующие системы.


Источник: Twitter timelines at scale

*Не вдавайтесь в мельчайшие подробности, вместо этого:

  • Определите основные принципы, общие технологии и шаблоны, которые встречаются в этих статьях
  • Изучите, какие проблемы решаются каждым компонентом, где это работает, а где нет
  • Обратите внимание секции, описывающие полученный опыт и работу над ошибками
Тип Система Ссылки
Обработка данных MapReduce - Распределенная обработка данных от Google research.google.com
Обработка данных Spark - Распределенная обработка данных от Databricks slideshare.net
Обработка данных Storm - Распределенная обработка данных от Twitter slideshare.net
Хранилище данных Bigtable - Распределенная колоночная база данных от Google harvard.edu
Хранилище данных HBase - Реализация Bigtable с открытым исходным кодом slideshare.net
Хранилище данных Cassandra - Распределенная колоночная база данных от Facebook slideshare.net
Хранилище данных DynamoDB - Документно-ориенитрованная база данных от Amazon harvard.edu
Хранилище данных MongoDB - Документно-ориенитрованная база данных slideshare.net
Хранилище данных Spanner - Глобально-распределенная база данных от Google research.google.com
Хранилище данных Memcached - Распределенный кэш, хранящийся в памяти slideshare.net
Хранилище данных Redis - Распеределенная система кэширавния с возможностью сохранения и типами данных slideshare.net
Файловая система Google File System (GFS) - Распределенная файловая система research.google.com
Файловая система Hadoop File System (HDFS) - Реализация GFS с открытым исходным кодом apache.org
Другое Chubby - Система блокировки для слабосвязанных распределенных систем от Google research.google.com
Другое Dapper - Система отслеживания операций в распределенных системах research.google.com
Другое Kafka - Очередь сообщений Pub/sub от LinkedIn slideshare.net
Другое Zookeeper - Централизованная инфраструктура и сервисы для синхронизации распределенных систем slideshare.net
Добавьте архитектуру Contribute

Company architectures

Компания Ссылки
Amazon Amazon architecture
Cinchcast Producing 1,500 hours of audio every day
DataSift Realtime datamining At 120,000 tweets per second
DropBox How we've scaled Dropbox
ESPN Operating At 100,000 duh nuh nuhs per second
Google Google architecture
Instagram 14 million users, terabytes of photos
What powers Instagram
Justin.tv Justin.Tv's live video broadcasting architecture
Facebook Scaling memcached at Facebook
TAO: Facebook’s distributed data store for the social graph
Facebook’s photo storage
How Facebook Live Streams To 800,000 Simultaneous Viewers
Flickr Flickr architecture
Mailbox From 0 to one million users in 6 weeks
Netflix A 360 Degree View Of The Entire Netflix Stack
Netflix: What Happens When You Press Play?
Pinterest From 0 To 10s of billions of page views a month
18 million visitors, 10x growth, 12 employees
Playfish 50 million monthly users and growing
PlentyOfFish PlentyOfFish architecture
Salesforce How they handle 1.3 billion transactions a day
Stack Overflow Stack Overflow architecture
TripAdvisor 40M visitors, 200M dynamic page views, 30TB data
Tumblr 15 billion page views a month
Twitter Making Twitter 10000 percent faster
Storing 250 million tweets a day using MySQL
150M active users, 300K QPS, a 22 MB/S firehose
Timelines at scale
Big and small data at Twitter
Operations at Twitter: scaling beyond 100 million users
How Twitter Handles 3,000 Images Per Second
Uber How Uber scales their real-time market platform
Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories
WhatsApp The WhatsApp architecture Facebook bought for $19 billion
YouTube YouTube scalability
YouTube architecture

Company engineering blogs

Вопросы могут быть связаны с архитектурой компаний, в которые вы собеседуетесь.

Source(s) and further reading

Хотите добавить блог? Во избежание дублирования, добавьте его в этот репозиторий:

Under development

Заинтересованы в добавлении раздела или в завершении того, что уже в процессе? Содействуйте!!

  • Распределенные вычисления с MapReduce
  • Согласованное хеширование
  • Scatter gather
  • Содействие

Credits

Источники указаны в самом документе.

Особая благодарность:

Contact info

Сообщайте мне, если вы хотите обсудить любые проблемы, вопросы или комментарии к этому документу.

Моя контактная информация доступна здесь: GitHub page.

License

I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/