Presentation of 2056.ru architecture from donetsk.py

1. Архитектура высоконагруженных проектов. http://2056.ru Андрей Светлов [email_address] asvetlov.blogspot.com

3. Походовая MMORPG

4. Клиент (JavaScript + Flash)

5. Сервер (Python)

7. Много одновременных подключенных пользователей

8. Минимальное время ответа

9. Масштабируемость

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

21. Выглядывает наружу

22. Переправляет все запросы в ZeroMQ соединения

23. Сообщения в формате json???

24. Если клиент не поддерживает WebSocket — переключается на Long Polling

25. Оптимизированный С код

27. Компонент выбирается по префиксу запроса

28. Имеют connection ID (CID)

29. CID ↔ UID

30. Указав CID можно послать сообщение любому подключенному пользователю

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

33. Служат для широковещательной передачи от сервера клиентам

34. Заметно экономят процессорное время: от компонента шлется одно сообщение, которое затем тиражируется всем желающим уже кодом ZeroGW

36. Запускается в нескольких экземплярах

37. Легко масштабируется на кластер (не всегда)

38. Соединен с клиентом и другими компонентами через ZeroMQ сокеты

39. Имеет при необходимости доступ к кешу и БД

41. Блокирующе обрабатывает 1 запрос за раз

42. Все данные лежат в редисе и БД

43. Базы общие для всех однотипных компонентов одной машины, горизонтальное масштабирование (sharding) между узлами кластера

44. Смерть процесса (почти) ничего не ломает

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

47. Не взаимодействует с Редисом/БД

49. Компонент не видит кеши/базы других компонентов

50. Общается только через ZeroMQ каналы

51. Шардинг накладывает свои ограничения

53. Redis отлично справляется, пока находится в памяти

54. MySQL используется для «разогрева» кеша, запись сквозная в MySQL и Redis.

55. Redis не персистентный. Большая часть Redis'ов поднимается на лету, некоторые должны быть заполнены в процессе старта узла кластера.

57. MyISAM (нетранзактное хранилище)

58. Все операции атомарные на уровне SQL запросов.

59. MySQL как несколько усложненный вариант key-value storage

60. Способен хранить большие объемы данных

61. Для сложных структур — JSON

63. При подъеме из Redis в случае невалидных данных их можно пересобрать из БД (или просто выкинуть)

64. При загрузке невалидных данных из БД они игнорируются, оставаясь в базе + логи.

66. Notify (Push-Pull)

67. RPC ожидает ответа, блокируя вызывающую сторону

68. RPC (теоретически) может обработать ошибку, случившуюся на другой стороне

69. Notify — быстрый, неблокирующий и ненадежный

71. Пишет сериализованные объекты

72. Анализируются статистикой

73. Инструмент чтения логов

74. Могут быть показаны во множестве различных видов-представлений

75. Логируется практически всё, что происходит в системе

79. Управление игроками

81. Yaml — наше всё

82. Контент менеджер

83. Валидатор

84. Генератор статики

85. Создавать редактор — напрасно тратить время

86. Отчеты и графики, балансировка игры

88. redis-namedb

89. redis-user

90. redis-chat

91. user-1

92. user-2

93. chat

94. octopus

96. Юниттесты

97. Функциональные тесты

98. Регрессионные тесты

99. Проверка контента

100. Подсистема моделирования, отчетов и т.д.

101. Наверняка что-то забыл...

103. Более 5k подключений на узел при «стандартной» активности пользователя (походовая RPG)

104. 10k на синтетических тестах

105. Нет архитектурно узких мест — все горизонтально масштабируется

107. Довольно низкоуровневые интерфейсы (скажем «нет» фреймворкам).

108. Необходимость мониторинга и подстраивания кода под распределение нагрузок

109. Миграция данных, обращения к другим узлам кластера — стандартные проблемы шардинга

110. Забивание ZeroMQ очередей при выходе из строя отдельного компонента

112. JQuery

113. ECO templates

114. Canvas

115. Flash (ActionScript)

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