должна ли бизнес-логика с высокой масштабируемостью работать в режиме реального времени (не более десяти миллисекунд для ответа) без сохранения состояния или с сохранением состояния? - PullRequest
0 голосов
/ 08 декабря 2011

Я знаю, это звучит очень общий вопрос, но я действительно заинтересован в услугах без сохранения состояния, и я хочу знать, можно ли это сделать с этими ограничениями (без сохранения состояния). например в гугле много сервисов. Меня больше волнуют сервисы, в которых они должны очень быстро возвращать результаты (не более нескольких десятков миллисекунд), и у них разбросаны огромные данные (возможно, они сохраняют сводку где-нибудь для немедленного получения). в этих случаях кто-нибудь может сказать, являются ли их серверы "бизнес-логики" не имеющими состояния или полными? Преимущество без сохранения состояния может заключаться в простоте перемещения состояния на уровень хранилища (gfs / memcached / bigtable), однако с сохранением состояния, если вы передадите запросы на один и тот же узел, вы можете получить результат из привязки из внутренней памяти. кто-нибудь имеет опыт работы с такими масштабируемыми проблемами огромного масштаба в реальном времени?

Ответы [ 2 ]

1 голос
/ 09 декабря 2011

Как уже отмечалось, службы без сохранения состояния легче масштабировать, но вы должны заметить, что без сохранения состояния означает, что вы устанавливаете состояние чьей-либо проблемы (БД, распределенный кэш и т. Д.), Если они могут справиться с нагрузкой, а задержки, пропускная способность и т. Д. все, что вы можете сделать, это сделать вашу службу без гражданства и получить преимущества.

Если в рамках ограничений вашего проекта (например, бюджета) вы не можете поручить кому-либо еще решить проблему состояния, то вам придется сделать ваши услуги государственными

1 голос
/ 09 декабря 2011

Только без гражданства.Службы Stateful Services очень трудно масштабировать, так как в этом случае вам приходится иметь дело с синхронизацией состояний.

...