2056
Download as odp, pdf1 like1,357 views
Документ описывает архитектуру высоконагруженных проектов на примере браузерной игры MMORPG, использующей технологии JavaScript, Flash и Python. Рассматриваются особенности масштабируемости, надежности и производительности системы, включая использование Redis, MySQL и ZeroMQ для управления соединениями и данными. Также упоминаются тестирование, управление игровым контентом и статистикой, а также потенциальные проблемы, связанные с низкоуровневыми интерфейсами и шардированием.
![Архитектура высоконагруженных проектов. http://2056.ru Андрей Светлов [email_address] asvetlov.blogspot.com](https://image.slidesharecdn.com/2056-120220103211-phpapp02/85/2056-1-320.jpg)
2056
- 1. Архитектура высоконагруженных проектов. http://2056.ru Андрей Светлов [email_address] asvetlov.blogspot.com
- 4. Клиент (JavaScript + Flash)
- 6. Особенности Постоянное соединение с сервером
- 7. Много одновременных подключенных пользователей
- 10. Разумный компромисс между производительностью и надежностью
- 12. ZeroMQ
- 13. Redis
- 14. MySQL
- 15. MsgPack
- 16. ZeroGW
- 17. ProcessBoss
- 18. Пользователь Chat GlobalMap Service Components ZeroGW User User Battle Battle Battle
- 19. Node2 Node1 ZeroMQ Device FrontNode Battle2 Chat User2 Battle1 User1 User2 Chat Battle2 User1 Battle1 Octopus1 Octopus2 MySQL2 MySQL1 ZeroGW Redis 1 Redis 2
- 20. ZeroGW Frontend server для работы по протоколу WebSocket (GET/POST/статику тоже умеет)
- 22. Переправляет все запросы в ZeroMQ соединения
- 23. Сообщения в формате json???
- 24. Если клиент не поддерживает WebSocket — переключается на Long Polling
- 26. Соединения ZeroGW: output Пользователь ↔ компонент
- 27. Компонент выбирается по префиксу запроса
- 28. Имеют connection ID (CID)
- 29. CID ↔ UID
- 30. Указав CID можно послать сообщение любому подключенному пользователю
- 31. Отключение по таймауту, перебрасывание сессии между закладками браузера и т.д.
- 32. Соединения ZeroGW: topic ID канала -> подписанные пользователи
- 33. Служат для широковещательной передачи от сервера клиентам
- 34. Заметно экономят процессорное время: от компонента шлется одно сообщение, которое затем тиражируется всем желающим уже кодом ZeroGW
- 35. Компонент Отдельный однопоточный процесс (прощай, GIL)
- 36. Запускается в нескольких экземплярах
- 37. Легко масштабируется на кластер (не всегда)
- 38. Соединен с клиентом и другими компонентами через ZeroMQ сокеты
- 39. Имеет при необходимости доступ к кешу и БД
- 40. Типичный компонент Ничего не хранит в памяти
- 41. Блокирующе обрабатывает 1 запрос за раз
- 42. Все данные лежат в редисе и БД
- 43. Базы общие для всех однотипных компонентов одной машины, горизонтальное масштабирование (sharding) между узлами кластера
- 44. Смерть процесса (почти) ничего не ломает
- 45. Боёвка Хранит состояние в памяти
- 46. При уничтожении процесса теряются все идущие в нем бои, пользователи выбрасываются туда, откуда пришли
- 47. Не взаимодействует с Редисом/БД
- 48. Принцип разделения Минимизация потоков данных между разными типами компонентов
- 49. Компонент не видит кеши/базы других компонентов
- 50. Общается только через ZeroMQ каналы
- 51. Шардинг накладывает свои ограничения
- 52. Кеширование Почти все лежит в кеше (msgpack)
- 53. Redis отлично справляется, пока находится в памяти
- 54. MySQL используется для «разогрева» кеша, запись сквозная в MySQL и Redis.
- 55. Redis не персистентный. Большая часть Redis'ов поднимается на лету, некоторые должны быть заполнены в процессе старта узла кластера.
- 58. Все операции атомарные на уровне SQL запросов.
- 59. MySQL как несколько усложненный вариант key-value storage
- 60. Способен хранить большие объемы данных
- 61. Для сложных структур — JSON
- 62. Надежность данных Redis всегда можно очистить
- 63. При подъеме из Redis в случае невалидных данных их можно пересобрать из БД (или просто выкинуть)
- 64. При загрузке невалидных данных из БД они игнорируются, оставаясь в базе + логи.
- 65. Общение компонентов RPC (Request-Reply)
- 67. RPC ожидает ответа, блокируя вызывающую сторону
- 68. RPC (теоретически) может обработать ошибку, случившуюся на другой стороне
- 69. Notify — быстрый, неблокирующий и ненадежный
- 70. Логи Свой формат бинарного лога
- 74. Могут быть показаны во множестве различных видов-представлений
- 75. Логируется практически всё, что происходит в системе
- 76. Статистика и админка collectd
- 77. Своя подсистема сбора игровой статистики Извещение от компонентов
- 78. Чтение логов Компонент админки Таблицы, графики и т.д.
- 80. Игровой контент База данных не лучшее решение
- 81. Yaml — наше всё
- 82. Контент менеджер
- 83. Валидатор
- 85. Создавать редактор — напрасно тратить время
- 86. Отчеты и графики, балансировка игры
- 88. redis-namedb
- 89. redis-user
- 90. redis-chat
- 91. user-1
- 92. user-2
- 93. chat
- 94. octopus
- 95. Разработка Многопоточный однопроцессный сервер
- 96. Юниттесты
- 100. Подсистема моделирования, отчетов и т.д.
- 102. Достоинства Быстро, весело, экономно
- 103. Более 5k подключений на узел при «стандартной» активности пользователя (походовая RPG)
- 104. 10k на синтетических тестах
- 105. Нет архитектурно узких мест — все горизонтально масштабируется
- 107. Довольно низкоуровневые интерфейсы (скажем «нет» фреймворкам).
- 108. Необходимость мониторинга и подстраивания кода под распределение нагрузок
- 109. Миграция данных, обращения к другим узлам кластера — стандартные проблемы шардинга
- 110. Забивание ZeroMQ очередей при выходе из строя отдельного компонента
- 111. Клиент Coffee script
- 112. JQuery
- 113. ECO templates
- 114. Canvas
- 115. Flash (ActionScript)
- 116. Пузомерка (SLOC) Python: 33k (+2k)
- 117. Python tests: 20k
- 118. Coffee: 19k
- 119. Coffee tests: 5k
- 120. ActionScript: 19k
- 121. Yaml: 57k
- 122. C (OpenSource): 15k
- 123. Art: 1.5GB
- 124. Вопросы? Архитектура высоконагруженных проектов. http://2056.ru Андрей Светлов [email_address] asvetlov.blogspot.com