用于跟踪远程值的架构

时间:2018-01-26 10:16:56

标签: architecture distributed-system

问题如下: 在A点(比如服务器或数据库),我们可以查询/聚合一个需要时间(可能是几秒)的值。一旦我们知道了该值,我们就希望能够发送有关值的变化的事件从A点到B点.B是跟踪该值的远程位置。

因此,B一次查询A值,然后消耗一个diff事件流,以使B处的值收敛到A处的正确值。

问题是这个消息流是持久的(例如Kafka主题中的消息)。节点B可能崩溃并需要重新启动,并且不得应用任何差异两次或错过任何差异事件。

此应用程序的架构有哪些可能的替代方案?时间戳检查忽略差异将引入片状,并且很难理解整个系统。而且,那将是错误的

如果这个问题不适合stackoverflow,那么如果你能评论并让我知道一个更好的地方就会很棒。

有多个A实例独立运行并更新共享存储中的值。具有多个源实例的版本控制差异使得它很难,因为源实例会触发并忘记diff事件。

举个例子: 让我们说我们的任务是维护在公司支持团队中工作的代理的优先级队列。将为这些代理分配工作票。他们解决门票。我们必须每天向代理商分配问题。因此,我们需要维护当前分配给每个代理的问题的数量。每张票都有受让人。因此,为了获得分配给代理的票证计数,我们在票证表中查询受让人是代理人的行。一旦我们查询了表,我们就会消耗diff事件(每次为代理分配新票证或解析现有票证时都会发出)。

1 个答案:

答案 0 :(得分:1)

通过散列(或版本控制)应用diff的值(以及使用diff发送散列),可以避免两次不发送差异的问题。因此,如果散列/版本与B的当前值的散列/版本匹配,则B应仅应用传入的diff。这样A可以多次自由发送相同的差异。

如果B处于没有传入差异与B的当前值的散列/版本匹配的状态,则B可以决定从A重新获取全部值。或者A或者A可以周期性地广播出全部值(如果它可能被压缩)很大程度上'重新''所有B'。

如果所有这些努力都是必要的,并且实际上你是否可以简单地广播全部值(可能是压缩的),也值得考虑。如果要广泛分发数据,您可以在每个区域中使用缓存服务器(您也可以使用diff方法执行此操作)。