简体繁体 English

如何防止在REST api GET中将相同的数据发送到不同的客户端？

[英]How to prevent sending same data to different clients in REST api GET?

原文 2015-01-07 08:09:22 6 2 rest/ distributed-system

I have 15 worker clients and one master connected through internet. 我有15名工人客户和1名主人通过互联网连接。 Job & data are been passed through REST api in json format. 作业和数据通过json格式的REST API传递。 Jobs are not restricted to any particular client. 作业不限于任何特定客户端。 Any worker can query for the available job in regular interval(say 30 seconds), process it and will update the status. 任何工人都可以定期（例如30秒）查询可用工作，进行处理并更新状态。 In this scenario, how can I prevent same records been sent to different clients while GET request. 在这种情况下，如何防止在GET请求时将相同的记录发送到不同的客户端。

Followings are my solution approach to overcome this issue: 以下是我解决此问题的解决方法：

Take top 5 unprocessed records from the database and make it as SENT and expose via REST GET. 从数据库中获取前5条未处理的记录，并将其设置为SENT并通过REST GET公开。 But the problem is, it creates inconsistency. 但是问题是，它造成了不一致。 Some times, the client doesn't got data due to network connectivity issue. 有时，由于网络连接问题，客户端没有数据。 But in server, it will be marked as SENT. 但是在服务器中，它将被标记为SENT。 So, no other clients can get that data. 因此，没有其他客户端可以获取该数据。 It will remain as SENT forever. 它将永远保持为SENT。

Get the list from server, and reply back the list of job IDs to Server as received. 从服务器获取列表，然后将作业ID列表返回给服务器。 But in-between this time gap, some other clients also getting same set of Jobs. 但是在这段时间之间，其他一些客户也获得了相同的工作机会。

2 个解决方案

You've stumbled upon a fundamental problem in distributed systems: there is no way to know if the other side received your message. 您偶然发现了分布式系统中的一个基本问题： 无法知道对方是否收到了您的消息。 You can certainly improve the situation with TCP and ack messages. 您当然可以使用TCP和ack消息来改善这种情况。 But if you never get the ACK did the message never arrive, did it arrive but the recipient die before processesing, or did the recipient send he ACK and the ACK get dropped? 但是，如果您从未收到ACK，消息就永远不会到达，是否到达，但收件人在处理之前就死了，还是收件人发送了他的ACK并丢弃了ACK？

That means you need to design your system to handle receiving data more than once. 这意味着您需要设计系统以处理多次接收数据。

You offer two partial solutions; 您提供两个部分解决方案； if you combine them, your solution starts to look like how SQS works. 如果将它们结合起来，您的解决方案就会看起来像SQS的工作方式。 Mark the item as pending_ack with a timestamp. 将带有时间戳的项目标记为“ pending_ack 。 After client replies, it is marked sent . 客户回复后，将其标记为sent 。 Any pending_acks s past a certain time period are eligible to be resent. 超过特定时间段的任何前处理的pending_acks都可以重新发送。

Pick your time period to allow for slow network and slow clients and it boils down to only sending duplicates when you really don't know if the client died or not. 选择您的时间段以允许缓慢的网络和缓慢的客户端，并且可以归结为仅在您真的不知道客户端是否死亡时才发送重复副本。

Maybe you should reconsider the approach to blocking resources. 也许您应该重新考虑阻塞资源的方法。 REST architecture - by definition is not obliged to save information about client. REST体系结构-根据定义，没有义务保存有关客户端的信息。 Instead, you may want to consider optimistic concurrency control ( http://en.wikipedia.org/wiki/Optimistic_concurrency_control ). 相反，您可能需要考虑乐观并发控制（ http://en.wikipedia.org/wiki/Optimistic_concurrency_control ）。