Что такое модель Meteor concurrency?
Я пишу серверную логику для приложения Meteor, которое должно обновлять состояние в памяти в ответ на запросы клиента. Это приложение нуждается в надежных гарантиях concurrency - в частности, я хочу быть уверенным, что за один раз выполняется только одно обновление.
Я пытаюсь выяснить, поддерживает ли модель Meteor concurrency. В документации упоминается, что Meteor многопоточен (что будет проблемой), но после поиска у меня создается впечатление, что Meteor фактически использует волокна (явно запланированные потоки). Если это правда, тогда я в безопасности, пока часть моего кода, который должен запускаться атомарно, не выполняет никаких вызовов Meteor (которые включают IO и, следовательно, обеспечивают блокировку выполнения).
Это так? Где я могу найти дополнительную информацию о модели Meteor concurrency?
Ответы
Ответ 1
Хорошо, я просмотрел источник Метеор и здесь, как все работает:
1) На стороне сервера Meteor использует только волокна для обработки concurrency. Волокна похожи на потоки, за исключением того, что контекст должен быть явно предоставлен. Это облегчает рассуждение о concurrency при (потенциальной) стоимости некоторых волокон, голодающих другими.
2) Все вызовы Meteor.call, Meteor.setInterval и любые операции коллекции завертываются в волокна. Это означает, что все эти вызовы дают контекст.
3) Кроме того, любое использование модуля волокон/фьючерсов дает.
Результатом этой структуры является то, что если вы хотите написать атомные операции, просто избегайте доступа к объектам, предоставленным средой Meteor, в блоке кода, который вы хотите сделать атомарным. Если этот блок действительно нуждается (скажем) в доступе к БД, то вы можете беспрепятственно реализовать блокировки в памяти, но для моего приложения этого знания достаточно. Моя основная функция обновления просто должна быть вызвана со всеми документами, которые ей нужны из Mongo, которые уже были прочитаны.
Ответ 2
Из метеорных документов:
В Meteor ваш код сервера работает в одном потоке за запрос, а не в стиле асинхронного обратного вызова, типичном для Node. Найдем линейную модель исполнения лучше подходит для типичного кода сервера в Meteor приложение.
http://docs.meteor.com/#structuringyourapp
Кто-нибудь знает последствия этого для производительности?
