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.