Tech talk for BSUIR students. TechWeek http://fksis.bsuir.by/other-info/bulletin-board/stud-gov/2015-03-22+adv+teamspark+techweek

1. Высоконагруженные проекты:
что нужно знать, чтобы этим
заниматься
Божко Светлана,
Adform BY

2. Кто я?
• Scala Backend Developer
• Data Processing Team

3. BigData & HighLoad

4. Service-­‐oriented Architecture (SOA) &
Microservices
• Каждая часть отвечает за что-­‐то одно. Они разделены.
• Один упал -­‐> продолжаем работать без него.
• Почта.
• Профили.
• Лента.
• Видео.

5. Функциональная декомпозиция

6. Кеширование
• Эффективность кеша.
• Hit ratio.
• Какова вероятность того, что требуемые данные попадут в кеш?
• Устаревание и когерентность кеша.

7. Вертикальное масштабирование

8. Горизонтальное масштабирование
• Не имеющие ничего общего исполнители.
• Выступают как единая сущность.
• Равноправные.
• Не храним состояния.
• Нет общих узлов.
• Нет единой точки отказа.

9. Балансировщики нагрузки
• Domain Name System (DNS).
• Алгоритм Round Robin.
• Различные программные или
аппаратные решения, а также их
комбинации.

10. Децентрализованные распределенные
системы
• Принцип «равный равному» (peer-­‐to-­‐peer, P2P).
• Компонентам системы не нужно знать об
общей структуре всей сети.
• Распространение информации внутри системы
возможно по принципу «молвы», то есть
цепного распространения через «соседей».
• BitTorrent.
• Gossip protocol (Cassandra).
• Алгоритмы консенсуса: Raft, Paxos, Byzantine.
• Net split, split brain.
• CAP.

11. Асинхронность, очереди задач
• Множество задач не требует немедленного
выполнения (статистика, почта, обновление
френдленты)
• Парадигма «подписка/публикация»
• Шина данных
• Для выполнения ресурсоемких/длительных задач
(конвертация фото/видео)
• Независимость от ЯП

12. Шардинг
• Разделение данных на уровне ресурсов.
Концепция шардинга заключается в
логическом разделении данных по
различным ресурсам исходя из требований к
нагрузке.
• F(key) = hash(key) % nSrv.
• Виртуальный шардинг.
• Альтернатива – центральный диспетчер,
который умеет разбивать запросы
пользователей.

13. Репликация
• Синхронное/асинхронное копирование данных с ведущих
серверов на ведомые (или возможно тоже ведущие) сервера.
• Ведущие сервера называют мастерами (master), ведомые —
слейвами (slave).
• Введение избыточности: NoSql (профили) + RDBMS (для
статистики).

14. Денормализация данных
• Какие данные нужны сервису?
• Как часто он будет их запрашивать?
• Например, анкета, где малая часть полей показывается везде.
• Избыточные данные.
• Например, разная логика. Настолько, что таблицы нужно по-­‐
разному оформить.

15. Партиционирование таблиц
• Разбиение больших таблиц на
логические части по выбранным
критериям.
• Чтение в большинстве случаев
приходится только на самую последнюю
часть таблиц (т.е. активно читаются те
данные, которые недавно появились).
• Блог — на первую страницу (это
последние 5…10 постов) приходится
40…50% всей нагрузки. Или новостной,
или системы личных сообщений.

16. Потоки данных
• Параллельное выполнение.
• Например, поисковик. Как думаете, сколько машин выполняют
ваш запрос?
• Дерево ответственностей. Разделение чтения и записи. CQRS.
• MapReduce.

17. О чем думать при
проектировании/разработке?
• Бизнес-­‐логика. Что может делать пользователь/клиент? Правила
обработки информации.
• Что является проблемой? Какие особенности движения данных
будем использовать?
• Объем хранимых данных. Скорость их прироста. Соотношение
чтения/записи.
• Чем можно пренебречь? Допустимая деградация системы.
• Не забыть сломать систему! J Load/Crash Testing

18. Что почитать по теме?
• http://book.mixu.net/distsys/

19. Спасибо за внимание! Вопросы!
• Светлана Божко
• svt.bozhko@gmail.com
• s.bozhko@adform.com
• @SBozhko
• http://devzen.ru/