有哪些技术可以在多服务设置中推动东京内阁的变更？
假设我有 N > 1 基于 TCP 的、面向连接的（阅读：不是网站）服务，在某些负载平衡/共享配置中处理来自最终用户的连接。
这些用户执行的操作会导致集中式 Tokyo Tyrant 数据存储中的一个或多个密钥更新。
您建议如何将这些更改推送给连接到同一专用网络（同一区域）上运行的不同服务实例的感兴趣用户？
User 1 Service 1 Tokyo Tyrant Service 2 User 2
------ --------- ------------ --------- ------
| | | | |
------> do something | | |
| | ---> put K 42 | |
| | | ----> Hey! K is now 42 |
| | | | ---> K was updated
一些想法：
将数据存储成功更新后的更改从服务 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 代表感兴趣的用户订阅一个队列；成功“放置”后将其发布到
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 这样的数据存储，请解释我如何连接到此类以允许验证等。我对此还不太熟悉。
Let's say I have N > 1 TCP-based, connection-oriented (read: not a website) services handling connections from end users in some load-balanced/sharing configuration.
These users do things that cause updates to one or more keys in the centralized Tokyo Tyrant datastore.
What do you recommend to push these changes to interested users connected to a different service instance running on the same private network (same colo.)?
User 1 Service 1 Tokyo Tyrant Service 2 User 2
------ --------- ------------ --------- ------
| | | | |
------> do something | | |
| | ---> put K 42 | |
| | | ----> Hey! K is now 42 |
| | | | ---> K was updated
A few ideas:
Broadcast the changes on successful update of the datastore from Service N to all other services
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
Store which Service each interested user is logged onto and send those services a message which is then relayed to the interested user; I suppose this is how IRC server-server connections work (need to research that).
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
Run a message broker (e.g. RabbitMQ); have each Service X subscribe to a queue on behalf of the interested users; post to it upon successful "put"s
User 1 Service 1 Tokyo Tyrant RabbitMQ Service 2 User 2
------ --------- ------------ -------- --------- ------
| | | | <--- subscribe --| |
------> do something | | | |
| | ---> put K 42 | | |
| | ------------------- post msg --> | |
| | | |----- notify ---->| |
| | | | | ---> K was updated
Yet another idea is to pretend to be a replication slave and connect to the master.
In general, I'm looking for a way to get "change notifications" as found in CouchDB but for Tokyo Tyrant. The idea is more general however.
If you suggest just using a message broker with persistent queues instead of a datastore like Tokyo Tyrant, please explain how I might hook into such to allow for validations, etc. I am not intimate yet with such.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的建议（以及我使用的）是消息代理方法。 RabbitMQ 跟踪订阅（取消）订阅不同队列的服务，您可以使用扇出交换。
此外，Tokyo Cabinet 有一个日志（尽管格式很奇怪），您可以使用它来获取更新并将其推送到队列中。我只尝试过使用 cron，但我认为可以使用套接字实时获取它。
My recommendation (and what I use) is the message broker approach. RabbitMQ keeps track on services (un)subscribing to different queues and you can use fanout exchanges.
Also, Tokyo Cabinet has a log (in a weird format though) which you can use to get the updates and push them to a queue. I only tried using a cron but I think it can be possible to get it in real time using a socket.