Какие методы вызывают изменения в шкафу tokyo в настройке мультисервиса?

Question

Предположим, у меня есть N> 1 TCP-based, ориентированный на соединение (читайте: не сайт), обслуживающие соединения от конечных пользователей в некоторой конфигурации с балансировкой нагрузки/совместного использования.

Эти пользователи выполняют действия, которые вызывают обновление одного или нескольких ключей в централизованном хранилище данных Tokyo Tyrant.

Что вы рекомендуете push эти изменения заинтересованным пользователям, подключенным к другому экземпляру службы, работающему в той же частной сети (тот же colo.)?

User 1  Service 1  Tokyo Tyrant  Service 2   User 2 
------  ---------  ------------  ---------   ------ 
    |   |    |    |     | 
    ------> do something   |    |     | 
    |   |  ---> put K 42   |     | 
    |   |    |  ----> Hey! K is now 42  | 
    |   |    |    |   ---> K was updated 

Несколько идей:

Broadcast изменения на успешном обновлении хранилища данных от службы N для всех других услуг

User 1  Service 1  Tokyo Tyrant  LAN Broadcast  Service 2  User 2 
------  ---------  ------------  -------------  ---------  ------ 
    |   |    |    |     |    | 
    ------> do something   |    |     |    | 
    |   |  ---> put K 42   |     |    | 
    |   |  -----------------> Hey! K is now 42  |    | 
    |   |    |    |   --> Hey! K is now 42  | 
    |   |    |    |     |   ---> K was updated 

магазин, который Обслуживание каждый заинтересованный пользователь зарегистрирован на и отправить тех обслуживает сообщение, которое затем передается заинтересованному пользователю; Я полагаю, что так работают серверные серверы IRC (нужно исследовать это).

User 1  Service 1  Tokyo Tyrant  Service 2   User 2 
------  ---------  ------------  ---------   ------ 
    |   |    |    |     | 
    ------> do something   |    |     | 
    |   |  ---> put K 42   |     | 
    |   |  ---> who cares?   |     | 
    |   | <--- User 2 on Service 2  |     | 
    --------------------------------------> Hey! K is now 42  | 
    |   |    |    |   ---> K was updated 

Запустить брокера сообщений (например, RabbitMQ); каждый сервис X подписывается на очередь от имени заинтересованных пользователей; отправлять к нему на успешный «поставить» s

User 1  Service 1  Tokyo Tyrant  RabbitMQ   Service 2 User 2 
------  ---------  ------------  --------   --------- ------ 
    |   |    |    | <--- subscribe --|   | 
    ------> do something   |    |     |   | 
    |   |  ---> put K 42   |     |   | 
    |   | ------------------- post msg -->     |   | 
    |   |    |    |----- notify ---->|   | 
    |   |    |    |     | ---> K was updated 

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

В общем, я ищу способ получить «уведомления об изменениях», как в CouchDB, но для Tokyo Tyrant. Однако идея более общая.

Если вы предлагаете только с помощью брокера сообщений с постоянными очередями вместо из датастора как Tokyo Tyrant, объясните, пожалуйста, как я могу подключить в такой, чтобы позволить валидации и т.д. Я не интимным еще с такими.

Answer 1

Моя рекомендация (и то, что я использую) - это подход посредника сообщений. RabbitMQ отслеживает сервисы (un), подписываясь на разные очереди, и вы можете использовать обмен разветвления.

Кроме того, в Tokyo Cabinet есть журнал (в странном формате), который вы можете использовать для получения обновлений и нажатия их в очередь. Я только пытался использовать cron, но я думаю, что можно получить его в реальном времени с помощью сокета.