Eventual consistency

Обсуждаем, как правильно строить приложения
zelenin
Сообщения: 9925
Зарегистрирован: 2013.04.20, 11:30

Re: Eventual consistency

Сообщение zelenin » 2017.01.06, 18:37

sda писал(а):zelenin, я не понимаю. НанесенУдар - затрагивает 2 разных агрегата (на самом деле еще больше). Одному агрегату нужно добавить опыта, другому агрегату нужно вычесть жизни.
учимся разделять контексты.
НанесенУдар - это не событие игрока. Это событие ИГРЫ.
В Личном кабинете у тебя User модуля UserModule.
Во время игры у тебя User (лучше Player) модуля CompetitionModule - сущность агрегата Game. Соответственно ты меняешь агрегат Game, меняя все дочерние сущности.
sda писал(а):DDD говорит о том, что не следует сохранять более одного агрегата за раз
не сохраняй. Агрегат один - Game.
sda писал(а):что для таких кейсов следует пользоваться EC. Я не понимаю чем может помочь event sourcing. Будет точно такая же проблема "Читаем хранилище событий > обрабатываем событие в котором сохраняем агрегат, генерируем и сохраняем еще 1 событие". Приходим к той же самой проблеме, как атомарно сохранить агрегат + событие в nosql.
в ES не надо заботиться о консистентности. В ES нет состояния сущности, из чего следует, что сущность нельзя сохранить. Сохраняем только события, а итоговое состояние сущности строим из потока сохраненных событий.

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.06, 21:39

zelenin, у меня так и есть. Две разные сущности User и Player. Но Player это самостоятельный агрегат, а не дочерняя сущность агрегата Game, так как нет никаких инвариантов, которые нужно было бы поддерживать между ними. Все что Player знает о Game, это его id.

И я не могу засунуть Player в Game. Вон Вернон пишет, что если инвариантов нет, то и нет смысла вкладывать сущности друг в друга. Делайте отдельными агрегатами и ссылайтесь по id. Это имеет смысл. В моем случае в игре может участвовать сразу несколько тысяч игроков. Загружать агрегат Game с тысячами объектов Player внутри него, это не правильно. Да и не получится, монго без хаков позволяет хранить документ размером не более 16 мб.

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

zelenin
Сообщения: 9925
Зарегистрирован: 2013.04.20, 11:30

Re: Eventual consistency

Сообщение zelenin » 2017.01.06, 23:14

sda писал(а):zelenin, у меня так и есть. Две разные сущности User и Player. Но Player это самостоятельный агрегат, а не дочерняя сущность агрегата Game
серьезно, я около десяти раз тебе говорил, что одна сущность может быть корнем одного агрегата, но дочерней сущностью другого. Тут так и есть.
sda писал(а):нет никаких инвариантов, которые нужно было бы поддерживать между ними. Все что Player знает о Game, это его id.
у тебя происходящие процессы говорят о том, что идет Игра из двух игроков. То, что одно событие ИГРЫ должно отнять рейтинг у одного игрока и прибавить другому, и есть своего рода инвариант, происходящий только атомарно.
sda писал(а):В моем случае в игре может участвовать сразу несколько тысяч игроков. Загружать агрегат Game с тысячами объектов Player внутри него, это не правильно. Да и не получится, монго без хаков позволяет хранить документ размером не более 16 мб.
ты сейчас правда начинаешь делать ddd, отталкиваясь от реализации или все же ddd мы будем делать, абстрагируясь от нее?
Тебе надо продумать дизайн домена. Я называю ИГРОЙ игровое взаимодействие двух ИГРОКОВ. Если у тебя в игре может быть тысячи игроков, назовем это ПАРОЙ. Я не знаю как работает твоя игра, поэтому не могу спроектировать корректно в твоих терминах.
sda писал(а):Соответственно, я не могу сгенерировать только 1 событие и сохранить его в сторадж. Нужно генерировать несколько событий на 1 действие пользователя, а атомарно это сделать невозможно ни с ES ни без него, на сколько я понимаю.
Очевидно, что ПАРУ хранить не надо, но с ее помощью мы защищаем инвариант.
вот такой вариант например:

Код: Выделить всё

$pair = $game->interaction($player1, $player2); // возвращает Pair
$pair->hitPlayer1(); // бьем Игрока1, генерим 3 события: для лога игры и по событию на игрока.  

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.09, 11:38

zelenin, я могу каждое действие пользователя на сайте сохранять как событие в хранилище, а затем если в момент обработки события произошла ошибка, то перенакатить это событие заново. Но тогда наверное события должны быть детерминированными (однозначными), т.е. хранить окончательное значение, вместо значения которое необходимо прибавить к текущему. Что вы об этом думаете?

zelenin
Сообщения: 9925
Зарегистрирован: 2013.04.20, 11:30

Re: Eventual consistency

Сообщение zelenin » 2017.01.09, 14:45

не понял откуда такой вывод. второй вариант удобнее.

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.09, 21:54

zelenin, классический пример перевода денег. Создаем и сохраняем недетерминированное событие с такими данными

Код: Выделить всё

{
	senderId: 1,
	recipientId: 2,
	sum: 20
}
Теперь обработчику события необходимо обновить 2 документа в монго коллекции. Пусть у отправителя будет 100 денег, а у получателя 10 денег. Тогда по окончанию у отправителя должно остаться 80 денег, а у получателя 30 денег.

Что может произойти:
После того, как счет отправителя был изменен на 80 денег система упала. После восстановления, так как событие недетерминированное, то мы находимся в ситуации неопределенности. Мы не можем заново перенакатить это событие, потому что тогда результат будет неверный: отправитель - 60 денег, получатель - 30 денег. Мы не можем откатить это событие, потому что результат будет тоже неверный: отправитель - 100 денег, получатель - -10 денег. Мы не можем откатить, а затем перенакатить событие, так как результат будет тот же, что был на момент сбоя.

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

P.S не понял, какой второй вариант имеется ввиду.

Аватара пользователя
ElisDN
Сообщения: 4443
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Eventual consistency

Сообщение ElisDN » 2017.01.09, 22:36

sda писал(а):После того, как счет отправителя был изменен на 80 денег система упала. После восстановления, так как событие недетерминированное, то мы находимся в ситуации неопределенности.
В случае ES вернулись к утреннему снапшоту и накатили заново все события за день. Все балансы сошлись.

А если используете Монгу как основное хранилище - сами знаете, на что шли.
Не забудьте пройти мастер-класс по Yii2.

zelenin
Сообщения: 9925
Зарегистрирован: 2013.04.20, 11:30

Re: Eventual consistency

Сообщение zelenin » 2017.01.09, 23:06

ElisDN писал(а):
2017.01.09, 22:36
sda писал(а):После того, как счет отправителя был изменен на 80 денег система упала. После восстановления, так как событие недетерминированное, то мы находимся в ситуации неопределенности.
В случае ES вернулись к утреннему снапшоту и накатили заново все события за день. Все балансы сошлись.
именно. у нас поток событий, мы можем с любого момента перенакатить все события и все сойдется.

в идеале работает так: за 2 года например у нас 5000 событий, касающихся одной сущности. Мы можем в любой момент "переиграть/replay" все события за 2 года и получить итоговое состояние сущности, и никакая потеря нам не страшна.
На практике: 5000 событий переигрывать - оверхед. Поэтому вводим понятие snapshot - раз в день/неделю/месяц итоговое состояние на момент времени сохраняем в SnapshotEvent. Теперь для получения итогового состояния нам нужно переиграть все события с момента последнего снэпшота. При откате события до снэпшота мы удаляем все поздние снэпшоты, пересчитываем состояние - и вот наша сущность опять консистентна.
В общем это идеальная система для событийных бизнес-процессов (не crud).

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.10, 02:55

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

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

Даже простейшая репликация базы в реалтайм проектах рожает кучу проблем. Кто-то обновил мастер и всем клиентам были разосланы обновленные данные по вебсокету, они обновили свой UI. В это время кто-то открывает сайт и читает начальное состояние с одной из реплик. Затем реплика синхронизируется с мастером, но UI клиента до сих пор со старыми данными. В итоге ничего толком не работает. Репликация работает для обычных сайтов по http протоколу, в парадигме запрос > ответ.

Поэтому я думаю, что распределенные реалтайм приложения сегодня - это похоже миф, чем реальность. Похоже единственный вариант это возвращаться на рсубд и упираться в производительность сервера, на котором она крутится. Других вариантов, к сожалению, найти не получается. Чего только уже не пробовал.

Аватара пользователя
rugabarbo
Сообщения: 914
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Eventual consistency

Сообщение rugabarbo » 2017.01.10, 10:24

sda писал(а):
2017.01.10, 02:55
Проблема то в монге, она не может атомарно ничего изменить
Может. Об этом написано выше.
sda писал(а):
2017.01.10, 02:55
поэтому ни в один момент времени нет гарантии, что снапшот, который снимается с базы находится в консистентном состоянии.
Неясно, что вы называете снапшотом и о какой консистентности ведёте речь. Но навскидку спрошу: а кто умеет? Разве MySQL умеет какие-то "консистентные снапшоты" возвращать с базы? Мне казалось, что как раз-таки у монги куда больше возможностей по целостной обработке коллекций документов (гарантирует неизменность коллекций во время применения к ним функций).
sda писал(а):
2017.01.10, 02:55
Мне кажется я вообще пытаюсь сделать невозможное.
Именно. Куча требований без компромиссов: и надёжно, и быстро, и распределённо. Так не бывает.
sda писал(а):
2017.01.10, 02:55
Походу реалтайм проекты никто не масштабирует.
Я до сих пор не пойму, что вы называете "масштабированием"? Можно масштабировать:
* вычисления - спрятать сервера под балансировщик
* кэш
* базу данных - шардить/реплицировать
* файловые операции - распределяя физические хранилища

Вы же говорите о каком-то сферическом "масштабировании" без конкретной задачи и профиля нагрузки. Где у вас затык? Что масштабируете?

Ну и если говорить про реалтайм-проекты, то там (как нигде в других местах) всё масштабируют: и кэши, и вычисления, и базы данных.
sda писал(а):
2017.01.10, 02:55
Потому что если посмотреть любую онлайн игру, то везде куча отдельных серверов не связанных между собой и все имеют ограничение по количеству игроков на сервер.
Именно. Потому что важна целостная обработка данных в одной конкретной локации (или в одном мире). На этот мир обычно пишется какой-нибудь C++ демон, который крутит всё в памяти. Соответственно, все расчёты очень быстро происходят в памяти. А уже демон сам разруливает, когда и как ему осуществлять сохранение данных в БД на бэкенде. Соответственно, игрок делает какое-то действие, это действие в неблокирующем режиме разруливается демоном. Если ударить сервер по питанию, то часть игровых данных за последние N минут потеряется. Никаких таких надёжных решений (чтобы каждый ход сохранялся) не существует. Целостность обработки данных обеспечивается на уровне демонов (внутри него).
sda писал(а):
2017.01.10, 02:55
Даже простейшая репликация базы в реалтайм проектах рожает кучу проблем. Кто-то обновил мастер и всем клиентам были разосланы обновленные данные по вебсокету, они обновили свой UI. В это время кто-то открывает сайт и читает начальное состояние с одной из реплик. Затем реплика синхронизируется с мастером, но UI клиента до сих пор со старыми данными. В итоге ничего толком не работает. Репликация работает для обычных сайтов по http протоколу, в парадигме запрос > ответ.
1. Даже в обычном http-сайте есть способы справиться с задержками репликации (некоторое время читать записанное с мастера, а не с реплик).
2. В таком виде реплику в скоростных реалтайм-вычислениях никто не использует. В реалтайм используют демоны, сообщающиеся между собой по сокетам.
sda писал(а):
2017.01.10, 02:55
Поэтому я думаю, что распределенные реалтайм приложения сегодня - это похоже миф, чем реальность.
Опять же неясно, про "распределённость" чего и где вы говорите. Какая-то сферическая распределённость. Базы? Серверов? Демонов? Бывают ведь и многопоточные демоны - вот вам и распределённость. Но только она по потокам, а не по чему-то там.
sda писал(а):
2017.01.10, 02:55
Похоже единственный вариант это возвращаться на рсубд и упираться в производительность сервера, на котором она крутится. Других вариантов, к сожалению, найти не получается. Чего только уже не пробовал.
Есть ещё второй вариант - найти наконец-таки профильную литературу по организации многоклиентских реалтайм-вычислений и посмотреть, что пишут эксперты этой области. Можно даже конкретно по играм найти книги с описанием типовых архитектурных подходов. А не пытаться построить своё решение на скорую руку.

Одно могу сказать точно: одним PHP вам не обойтись.

P.S.: в прошлом я работал в геймдеве. Тема очень сложная, даже форум по её исследованию вы выбрали неправильно. Как минимум, вам сюда: https://www.gamedev.net/

Аватара пользователя
rugabarbo
Сообщения: 914
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Eventual consistency

Сообщение rugabarbo » 2017.01.10, 10:37

Вот, пожалуйста, 5 минут поиска на предложенном форуме:
* https://www.gamedev.net/topic/668816-rt ... hitecture/
* https://www.gamedev.net/topic/480912-mm ... -movement/
* https://www.gamedev.net/topic/678539-br ... with-pics/

И т.д.

Неясно, что вы вообще делаете на форуме Yii2 с геймдев-интересами. Ну и ещё добавлю, что DDD-таки применим. Просто его нужно внутри демонов делать на компилируемом языке (C/C++/Java/Go), а не на связке PHP+MongoDB.

zelenin
Сообщения: 9925
Зарегистрирован: 2013.04.20, 11:30

Re: Eventual consistency

Сообщение zelenin » 2017.01.10, 12:14

да, все так:
- клиент, общающийся с демоном
- быстрый демон, обсчитывающий клиентов в риалтайм без участия бэкенда и моментально отправляющий события в шину
- бэкенд, сохраняющий изменения из шины в БД

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.11, 06:50

rugabarbo, спасибо за ответ. Про PHP ничего не говорил. Пишу на другом языке. DDD внутри демона. На форуме Yii2 потому что здесь обсуждаются вопросы архитектуры. Строить на скорую руку ничего не пытаюсь. Наоборот хочу разобраться. Речь о масштабировании базы и консистентности данных. Последняя ссылка от вас, подтверждает, что базу делают целой и не делимой в такого рода проектах. Масштабируются путем создания отдельных независимых копий приложения каждый со своей базой данных. Если можно было бы в такого рода проектах горизонтально масштабировать все звенья цепи без головной боли, никто бы не делал отдельные копии приложения. Лучше иметь 1 густонаселенный мир, чем разбивать его на 10 отдельных. Но видимо, на сегодняшний день это нереализуемая задача для реалтайм проектов, раз никто еще этого не сделал.

Аватара пользователя
rugabarbo
Сообщения: 914
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Eventual consistency

Сообщение rugabarbo » 2017.01.11, 07:51

sda писал(а):
2017.01.11, 06:50
На форуме Yii2 потому что здесь обсуждаются вопросы архитектуры. Строить на скорую руку ничего не пытаюсь. Наоборот хочу разобраться.
sda, по вопросам архитектуры игр рекомендую общаться на геймдев-форумах. Всё-таки сайтостроение и игростроение сильно различаются: первое - stateless, второе - наоборот.

Есть ещё русскоязычный ресурс: http://www.gamedev.ru

Вот, посмотрите, там люди задаются схожими вопросами:
* http://www.gamedev.ru/code/forum/?id=181490
* http://www.gamedev.ru/code/forum/?id=181302

Но на зарубежных форумах-таки аудитория игроделов больше.
sda писал(а):
2017.01.11, 06:50
Речь о масштабировании базы и консистентности данных.
Отлично. С этим разобрались.

Теперь вопрос: почему так уверены, что её вообще придётся масштабировать? Может быть под ваши нагрузки будет достаточно взять MySQL и запихнуть его в SSD? Откуда уверенность, что будут какие-то невероятные затыки уровня БД?

Во-вторых, масштабирование бывает разным. Если большая нагрузка на чтение - нужно реплицировать базу. Если на запись - шардить/партиционировать. Вам какое масштабирование нужно? И почему именно такое?
sda писал(а):
2017.01.11, 06:50
Последняя ссылка от вас, подтверждает, что базу делают целой и не делимой в такого рода проектах.
Вы опять же все карты перепутали. Целым и неделимым делают "хранилище данных" под один конкретный участок игры (мир, локацию). Но саму базу данных чисто технически вполне себе при необходимости можно делить на шарды/реплики/партиции.

Если на картинках БД изображена как одна единственная "бочка", то это не значит, то там один единственный БД-сервер. Это просто условное изображение хранилища данных.
sda писал(а):
2017.01.11, 06:50
Если можно было бы в такого рода проектах горизонтально масштабировать все звенья цепи без головной боли, никто бы не делал отдельные копии приложения.
В любого рода проектах горизонтально масштабировать можно всё. Вопрос в стоимости разработки архитектуры, стоимости оборудования и поддержки. Для тех же БД есть кластеры промышленного уровня.

И отдельные копии приложений делают исходя из возможностей проекта (финансовых, интеллектуальных), а не исходя из того, что это невозможно.
sda писал(а):
2017.01.11, 06:50
Лучше иметь 1 густонаселенный мир, чем разбивать его на 10 отдельных.
Кому лучше? О_о
Мне казалось от задачи зависит.
sda писал(а):
2017.01.11, 06:50
Но видимо, на сегодняшний день это нереализуемая задача для реалтайм проектов, раз никто еще этого не сделал.
Как выявлено, что "никто" не сделал? Может быть просто такой задачи не стоит перед игроделами? Кому нужны эти ваши "бесконечные" миры? Игры - это такие же бизнес-проекты, там есть конкретные бюджеты и сроки окупаемости. Миры делают ровно такими, какие они целесообразны для достижения окупаемости проекта.

- - -

sda, я думаю ваша проблема куда проще: не обижайтесь, но вы решаете абстрактные задачи. "Хочу всё масштабируемо, консистентно, надёжно, чтобы каждый узел горизонтально раскладывался на 100 нод". Только зачем? Где ваши графики пинбы, которые показывают, что надо масштабировать именно этот кусок системы? (:

sda
Сообщения: 292
Зарегистрирован: 2013.12.19, 09:29

Re: Eventual consistency

Сообщение sda » 2017.01.11, 10:27

rugabarbo, вы пытаетесь меня поучать, неявно заявляя о своем превосходстве и некомпетентности собеседника. Я сюда не за этим пришел. Я не идиот и я понимаю, что может означать бочка на изображении, но я прочитал всю тему и по внешним ссылкам тоже всё почитал и понимаю, о чем там идет речь.

Я понимаю, как "чисто технически" масштабировать базу данных. Все эти методы известны и эксплуатируются фейсбуками и иже с ними. Проекты, вроде фейсбука могут бесконечно масштабироваться засчет того, что могут принять от вас данные, а другим пользователям отдать эти данные только через N минут, да и то только по запросу клиента. Как всё это делается, я прекрасно знаю.

В реалтайм проекте невозможно использовать такую архитектуру. Ничего не будет работать. И это косвенно подтверждается тем фактом, что реалтайм миры всегда имеют явный или неявный лимит по количеству пользователей онлайн. И бизнес здесь не причем, так как если бы могли, масштабировались бы теми же самыми средствами, что и фейсбуки. Но не могут из-за требований к реалтайму. Поэтому и масштабируются целиком клонируя приложение, создавая кучи отдельных миров. И я понимаю, что можно реализовать перемещение пользователя с одного мира в другой. С одной базы данных в другую. Но устроить сражение в реалтайме с одновременным участием миллионов пользователей - нет. Если вы знаете как, тогда поделитесь ссылками на материал, чтобы узнать какие подходы используются для достижения такого результата.

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

Аватара пользователя
rugabarbo
Сообщения: 914
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Eventual consistency

Сообщение rugabarbo » 2017.01.11, 10:54

sda писал(а):
2017.01.11, 10:27
rugabarbo, вы пытаетесь меня поучать, неявно заявляя о своем превосходстве и некомпетентности собеседника.
Проблема вашего восприятия. Не более.
sda писал(а):
2017.01.11, 10:27
Я понимаю, как "чисто технически" масштабировать базу данных. Все эти методы известны и эксплуатируются фейсбуками и иже с ними. Проекты, вроде фейсбука могут бесконечно масштабироваться засчет того, что могут принять от вас данные, а другим пользователям отдать эти данные только через N минут, да и то только по запросу клиента. Как всё это делается, я прекрасно знаю.
Очевидно, не знаете, потому что фейсбук ничего подобного не делает (не отдаёт другим пользователям данные через N минут). У них нет такой тормозной репликации. Бешенная производительность достигается за счёт агрессивнейшего кэширования динамических объектов (memcache), компилируемого PHP (HipHop), использования MySQL в качестве key-value (отказ от Join-ов), а также многочисленных "допилов" всех этих инструментов "под себя". Насколько я помню, репликацию FB как раз-таки не использует.
sda писал(а):
2017.01.11, 10:27
В реалтайм проекте невозможно использовать такую архитектуру. Ничего не будет работать. И это косвенно подтверждается тем фактом, что реалтайм миры всегда имеют явный или неявный лимит по количеству пользователей онлайн. И бизнес здесь не причем, так как если бы могли, масштабировались бы теми же самыми средствами, что и фейсбуки. Но не могут из-за требований к реалтайму. Поэтому и масштабируются целиком клонируя приложение, создавая кучи отдельных миров. И я понимаю, что можно реализовать перемещение пользователя с одного мира в другой. С одной базы данных в другую.
Ну это уже пустое опять. "Невозможно использовать такую архитектуру", "Ничего не будет работать", "Если бы, да кабы", "Пытаюсь реализовать невозможное", "Я всё понимаю" - и т.п. Вы свою задачу опишите сначала, тогда поговорим.
sda писал(а):
2017.01.11, 10:27
Но устроить сражение в реалтайме с одновременным участием миллионов пользователей - нет. Если вы знаете как, тогда поделитесь ссылками на материал, чтобы узнать какие подходы используются для достижения такого результата.
Это и есть ваша задача? Устроить реалтайм сражение с участием миллионов пользователей? Я вам про это и пишу: определитесь с задачей. А вы мне в ответ: "задуманное невозможно, недостижимо, феерично!" - и ни слова о конкретной задаче.
sda писал(а):
2017.01.11, 10:27
Поэтому я думаю, что изначально пытаюсь реализовать невозможное на сегодняшний день. И хочу найти это подтверждение у других разработчиков, которые подумают и тоже придут к выводу, что сегодня это невозможно сделать или если же они считают иначе, то поделятся информацией, а не будут пытаться поучать.
Прежде чем найти подтверждение чего-либо у других разработчиков, нужно для начала это "что-либо" другим разработчикам озвучить.

И ещё раз говорю: вас никто не поучает. От вас пытаются добиться ответа на вопрос: где у вас бутылочное горло? Что именно и для чего вы масштабируете?

Аватара пользователя
rugabarbo
Сообщения: 914
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Eventual consistency

Сообщение rugabarbo » 2017.01.11, 11:09

Ну и, кстати, задам ещё свой любимый вопрос: "Зачем?"

В современных онлайн играх максимальный онлайн не поднимается до миллионов. Не технически, а чисто потребности такой нет. Даже у крупнейших игроков рынка максимальные онлайны по 200-300к игроков.

Проще говоря, где набрать миллионы одновременного онлайна для сражений собираетесь? Или мы про чисто-гипотетическую задачу говорим?

К тому же есть ведь ещё и клиентская сторона вопроса. Например, в том же Lineage во время крупных осад затык происходит на клиентах - они тупо не могут отрендерить гигантское количество полигонов, даже на крутых видеокартах случаются коллапсы.

Так что ваши миллионы онлайна гипотетически ещё и на клиенте как-то разрулить нужно.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя