Блог

Я провел небольшое исследование по использованию токена сеанса в dotnet v3 sdk cosmosdb, и пока я нашел эти две ссылки, которые дают мне несколько советов о том, как его использовать: use-session-tokens и how-to-convert-session-token .

В нашем сценарии мы хотели бы иметь строгую согласованность (но мы не хотим использовать строгую согласованность для всех данных), если обновление принадлежит одному и тому же userId , чтобы, когда один экземпляр обновляет данные под этим пользователем, все остальные сразу же увидели результат. Мы также хотели бы использовать cosmosdb в качестве блокировки для другого сценария.

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

Например, если я хочу обновить данные в соответствии с определенным userId , я бы использовал {userId}:-1#1 в качестве токена сеанса. Будет ли это допустимым способом использования токена сеанса? Я также не уверен, что означают поля pkrangeid, Version, GlobalLSN и какую роль они играют, когда cosmosdb имеет дело с согласованностью.

Заранее спасибо!

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

Чтобы получить надежную согласованность в регионе или, точнее, прочитать ваши собственные гарантии записи, предоставляемые согласованностью сеанса, и использовать один экземпляр клиента Cosmos, вы уже получите свои собственные гарантии записи. Вам не нужно управлять токеном сеанса. Cosmos SDK сделает это за вас.

Если у вас есть сценарий, в котором у вас есть несколько экземпляров клиента Cosmos DB в отдельных процессах, и вы хотите прочитать свои собственные гарантии записи, у вас есть два варианта.

1. Реализовать согласованность с ограниченной несогласованностью, которая обеспечивает строгую согласованность внутри региона для всех экземпляров клиента Cosmos, считывающих и записывающих данные в этом регионе. Это делается путем чтения двух реплик. Поскольку Cosmos DB всегда выполняет запись в 3 реплики, вы гарантированно всегда будете считывать самые последние данные, поскольку Cosmos DB проверит LSN из обеих реплик и вернет данные из более высокого LSN, если они не совпадают. Преимуществом этого подхода является то, что его очень легко реализовать. Недостатком является то, что Точечные чтения (т.Е. ReadItemAsync() ) стоят в два раза дороже, потому что их чтение из двух реплик.

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