Listeners - Wait new key version

Ожидание новых версий ключа

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

Cтроить логику Directory Service легко, используюя wait, expire , set вместе.

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

Демонстрация

Суть в следующем. В одой консоли ждем очередную версию - зависание запроса, в другой пишем ее в ключ - в первой консоли пришел ответ на запрос.

# look : wait-version
$ curl -X GET "http://api.acapella.ru:12000/v2/kv/keys/k1:k2:k3?waitTimeout=60&n=3&r=2&w=2&waitVersion=4" -H  "accept: application/json" -H  "content-type: application/json"
# -----------------------------------------------------------------------------------------------^ 
# тут зависли - ответа нет? Ждем версию ключа ЖЕСТКО СТАРШЕ 4-й
# откуда - то пишем новую версию в ключ, 
$ curl -X PUT "http://api.acapella.ru:12000/v2/kv/keys/k1:k2:k3?waitTimeout=60&n=3&r=2&w=2" -H  "acceptson" -H  "content-type: application/json" -d "124"
{"version":"4"}
# в результате в первой консоли - все еще висим т.к. версия ключе равна 4, но не больше. пишем еше раз 

$ curl -X PUT "http://api.acapella.ru:12000/v2/kv/keys/k1:k2:k3?waitTimeout=60&n=3&r=2&w=2" -H  "acceptson" -H  "content-type: application/json" -d "124"
{"version":"5"}

в результате в первой консоли

# look : wait-version
$ curl -X GET "http://api.acapella.ru:12000/v2/kv/keys/k1:k2:k3?waitTimeout=60&n=3&r=2&w=2&waitVersion=4" -H  "accept: application/json" -H  "content-type: application/json"
{"version":"5","value":124.0}

Этим можно пользоваться как масштабируемым LongPooling звеном в вашей архитектуре.

Listener , Set and wait - use cases

Listener - уведмление о последжних изменениях.

Вы можете использовать long pooling get запросы, в параметрах к которым можно указать версию ожидаемого ключа (Если версию не указывать - возвращается последняя). Возврат значения из LongPooling можно использовать как уведмление о "очередном последнем" значении.

Поправка

если пока значение обрабатывается и устанвливается новое LP соединение значение будет установлено (set) более одного раза, то получим не несколько значений , а одно - последнее. в этом смысле данный метод "не реализует очередь"

Case: service discovery

в системах управления конфигурацией distributed, consistent key-value store for shared configuration and service discovery

Eсть такой метод установки значения: значение удаляется если клиент отключится, произошла потеря связи итд. Этот метод используется для определения состава available серверов, если ключи присутствуют, то и сервера подключены и работают.

Внутри это реализуется как серия ping операций к ключу у которого установлен expire. Мы не стали делать иной API для этого, рекомендуем прямо так и использовать.

Устанвливаете expire на ключ так, чтобы успеть за это время переподключиться и делаете пинги , через set новой версии значения. Если это приемлимо, то имеется функционал для простого service discovery.