diff --git a/README-ru.md b/README-ru.md index 4af4acd9..1fa3990f 100644 --- a/README-ru.md +++ b/README-ru.md @@ -2522,7 +2522,15 @@ l10n:p --> ## Cache -TBD +

+ +
+ Источник: Scalable system design patterns +

+ +Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на сервера и базы данных. При таком подходе, диспетчер сначали проверяет, делался ли запрос ране, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса. + +Базы данных работают оптимальным образом при равномерном распределении операций чтения и записи между их партициями (partitions). Популярные элементы могут нарушить равномерность распределения, создавая узкие места. Добавление системы кэширование перед базой данных может позволить сгладить неравномерность поступающего трафика. ### Client caching -TBD +Системы кэширования могут находиться на клиентской стороне (ОС или браузер), [server side](#reverse-proxy-web-server), или в выделенном уровне для кэширования. ### CDN caching -TBD +[CDNs](#content-delivery-network) считаются одним из видов кэширования. ### Web server caching -TBD +[Reverse proxies](#reverse-proxy-web-server) и системы такие системы кэширование как [Varnish](https://www.varnish-cache.org/) могут выдавать как статический, так и динамический контент. Веб-сервера тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений. ### Database caching -TBD +База данных обычно включает какое-то кэширование в конфигурации по умолчанию, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных шаблонов использования данных может еще больше увеличить её производительность. ### Application caching -TBD +Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данных хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому [алоритмы очистки кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), как например [вытеснение давно неиспользуемых (Least recently used, LRU)](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#Least_recently_used_(%D0%92%D1%8B%D1%82%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%B2%D0%BD%D0%BE_%D0%BD%D0%B5%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC%D1%8B%D1%85)) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие". + +Redis включает дополнительную функциональность: + +* возможность сохранения данных (из памяти на диск) +* встроенные структуры данных, например сортированные множества или списки + +Существует несколько уровней кэширования, которые можно обобщить в две категории: "запросы к БД" и "объекты": + +* записи БД +* запросы +* сформированные сериализуемые объекты +* сформированный HTML + +Как правило, стоит избегать кэширования файлов, так как такой подход усложняет клонирование и автоматическое масштабирование. ### Caching at the database query level -TBD +При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запросы в базу данных. Такой подход имеет ряд недостатков: + +* Тяжело удалить закэшированный результат сложных запросов +* Если меняется значение одной ячейки данных, необходимо удалить все запросы, который могут содержать эти данные ### Caching at the object level -TBD +При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных: + +* Объект удаляется из кэша, если структура данных, которую он представляет, изменилась +* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версий закэшированных объектов + +Что можно кэшировать как объекты: + +* Пользовательские сессии +* Полностью сформированные веб-страницы +* Потоки активности +* Графовые данные пользователя ### When to update the cache -TBD +Для каждого сценария использования необходимо определять, какая стратегия очистки кэша подходит наилучшим образом, так как количество данных, которые можно хранить в системе кэширования, ограничено. #### Cache-aside -TBD +

+ +
+ Источник: From cache to in-memory data grid +

+ +Приложение читает данных из хранилища и записывает в него. Система кэширования не взаимодействует с хранилищем. Приложение выполняет следующие действия: + +* Ищет элемент в кэше, которой там ещё нет +* Загружает данные из БД +* Добавляет элемент в кэш +* Возвращает результат клиенту + +```python +def get_user(self, user_id): + user = cache.get("user.{0}", user_id) + if user is None: + user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id) + if user is not None: + key = "user.{0}".format(user_id) + cache.set(key, json.dumps(user)) + return user +``` + +Обычно так используется [Memcached](https://memcached.org/). + +Последующие запросы на чтение данных, находящиейся в кэши, выполняются быстро. Также такой подход известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит его заполнения данными, которые не запрашиваются. ##### Disadvantage(s): cache-aside -TBD +* Если запришиваемые данные отсутствуют в кэше, выполняется три дополнительных действия, которые могут привести к заметной задержке +* Данные могут устареть, если они обновляются в БД. Для смягчение последствий этой проблемы используют время жизни (TTL), которое вызывает обновление элемента в кэше, либо делают сквозную запись +* Когда выходит из строя сервер кэширования, он заменяется новым сервером с пустым кэшем, что увеличивает задержку. #### Write-through -TBD +

+ +
+ Источник: Scalability, availability, stability, patterns +

+ +Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данных из БД: + +* Приложение добавляет и обновляет элемент в системе кэширования +* Система кэширования синхронно записывает данные в БД +* Возвращается результат + +Код приложения: + +```python +set_user(12345, {"foo":"bar"}) +``` + +Код системы кэширования: + +```python +def set_user(user_id, values): + user = db.query("UPDATE Users WHERE id = {0}", user_id, values) + cache.set(user_id, user) +``` + +В целом, подход со сквозной записью является медленным из-за операции записи, но последующие операции чтения выполняются быстро. Пользователи предпочитают такие системы из-за допустимой задержки при обновлении данных, но не их чтении. Данные в системе кэширования не устаревают. ##### Disadvantage(s): write through -TBD +* Когда добавляется новый сервер из-за отказа другого, либо масштабироавние, его кэш не содержит никаких элементов, пока данные не будут обновляеться в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы +* Большая часть записываемых данных может вообще не использоваться. Использование времени жизни данных (TTL) может смягчить последствия этой проблемы. #### Write-behind (write-back) -TBD +

+ +
+ Источник: Scalability, availability, stability, patterns +

+ +При таком подходе приложение делает следующее: + +* Добавляет/обновляет элемент в системе кэширования +* Асинхронно делает запись в БД, улучшая скорость записи ##### Disadvantage(s): write-behind -TBD +* Возможна потеря данных, если система кэширования выйдет из строя до сохранения данных в БД. +* Такую систему сложнее реализовать, чем "отдельный" или "сквозной" кэш. #### Refresh-ahead -TBD +

+ +
+ Источник: From cache to in-memory data grid +

+ +При таком подходе можно настроить автоматическое обновление закэшированных данных, к которым недавно обращались, не ожидая истечения их срока действия. + +Кэширование методом "предварительного обновление" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем. ##### Disadvantage(s): refresh-ahead -TBD +* Неточное определение элементов, которые могут понадобиться в будущем, может привести к ухудшению производительности. ### Disadvantage(s): cache -TBD +* Необходимость поддерживать согласованность данных в кэше и источнике данных, таком как БД, с помощью [инвалидации кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). +* Инвалидация кэша является сложной задачей, и включаещей дополнительную задаче по определению времени, когда кэш нужно обновлять. +* Необходимы изменения в приложении, например, добавление Redis или Memcached. ### Source(s) and further reading -TBD +* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast) +* [Scalable system design patterns](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html) +* [Introduction to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale/) +* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) +* [Scalability](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache) +* [AWS ElastiCache strategies](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html) +* [Кэш - Wikipedia](https://ru.wikipedia.org/wiki/%D0%9A%D1%8D%D1%88) ## Asynchronism -TBD +

+ +
+ Источник: Intro to architecting systems for scale +

+ +Асинхронные процессы позволяют сократить время запросов для трудоёмких операций по сравнению со случаями, когда эти операции выполняются синхронно. Они также могут помочь с выполением времязатратных операций, таких как периодическое агрегирование данных. ### Message queues -TBD +Очереди сообщений позволяют принимать, хранить и доставлять сообщения. Если операция слишком медленная для синхронного выполнения, можно использовать очередь сообщений со следующим рабочим процессом: + +* Приложение отправляет задачу в очередь, затем оповещает пользователя о состоянии задачи +* Рабочий процесс (воркер) берет задачу из очереди, выполняет её и посылает сообщение о том, что задача выполнена + +При таком подходе пользователь не заблокирован и задача выполняется в фоне. В это время, клиентское приложение может частично обработать данные и сделать видимость выполнения. Например, сразу после публикации вашего сообщения в соц. сети, оно может появится в вашей ленте, но фактическая доставка этого сообщения фоловерам может занять некоторое время. + +**[Redis](https://redis.io/)** - может использоваться как простой брокер сообщений (message broker), но сообщения могут быть утеряны. + +**[RabbitMQ](https://www.rabbitmq.com/)** - широко распространен, но потребует адаптации к "AMQP" протоколу и поддержки серверов для его развертывания. + +**[Amazon SQS](https://aws.amazon.com/sqs/)** - сервис, может иметь большую задержку и возможность доставки сообщений дважды. + ### Task queues -TBD +Очереди сообщений принимают задачи и связанные с ними данные, выполняют их, и затем доставляет их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне. + +Планирование есть в **Celery**, который в основном поддерживается на Python. ### Back pressure -TBD +Если очередь достигает больших размеров, ее размер может стать больше память, что приведет к запросам элементов, которых нет в кэши, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](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). ### Disadvantage(s): asynchronism -TBD +* Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей добавит задержку и усложнят систему. ### Source(s) and further reading -TBD +* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4) +* [Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) +* [Закон Литтла](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D1%82%D1%82%D0%BB%D0%B0) +* [What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function) ## Security -TBD +Этот параграф было бы хорошо дополнить. [contributing](#contributing)! + +Обеспечение безопасноcти - это обширная тема. Если у вас нет значительного опыта в безопасности, либо вы не подаётесь на вакансию, которая требует знаний по безопасности, возможно вам будет достаточно основ: + +* Шифруйте данные во время передачи и при хранении +* Очищайте входные данные пользователи и любые параметры, которые доступны пользователю для избежания [межсайтового скриптинга](https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D1%81%D0%B0%D0%B9%D1%82%D0%BE%D0%B2%D1%8B%D0%B9_%D1%81%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%B8%D0%BD%D0%B3) и [внедрения SQL-кода](https://ru.wikipedia.org/wiki/%D0%92%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_SQL-%D0%BA%D0%BE%D0%B4%D0%B0). +* Используйте параметризуемые запросы для предотвращения внедрения SQL-кода +* Используйте [принцип минимальных привилегий](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BC%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85_%D0%BF%D1%80%D0%B8%D0%B2%D0%B8%D0%BB%D0%B5%D0%B3%D0%B8%D0%B9) ### Source(s) and further reading -TBD +* [API security checklist](https://github.com/shieldfy/API-Security-Checklist) +* [Security guide for developers](https://github.com/FallibleInc/security-guide-for-developers) +* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)