我的团队和我一直试图解决的问题涉及多个ec2实例，每个实例都具有对同一S3存储桶的独立，并行访问。当每个客户端都尝试在上述s3存储桶中下载相同文件时，该问题会作为竞争条件出现。每个客户端都尝试读取该文件，运行一些业务逻辑，然后删除该文件。由于存在很多延迟机会，因此会出现竞争状况，并且多个实例最终会运行业务逻辑。
关于工程师如何通过其s3客户端实施锁定机制的一些建议将不胜感激。
我们的头脑风暴方法：将.lock文件上载到有关哪个实例当前持有该锁的信息的s3存储桶中。当拥有锁的实例完成该过程后，它将删除其锁。（在上载锁定文件时出现问题-使用锁定机制的竞争状态）。
嗯...您现在将与锁定文件发生争用情况...多个节点将要上载相同的锁定文件！
因此，您将需要一些更复杂的功能，因为S3没有内置任何并发性，这可能非常不便。
解决此问题的明显方法是使用SQS（简单队列服务）-这是为并发而构建的。
因此，在您的情况下，所有节点都连接到同一队列，等待队列中的工作。某些东西会将元素添加到s3中需要处理的每个文件的队列中。节点之一将提取队列中的条目，处理文件，删除文件，然后删除队列中的条目。
这样一来，您就不会进行多重处理，并且可以进行优雅的缩放等。
但是，未解决的问题是首先扫描s3以便将工作放在队列中。这可能是您遇到困难的地方。
我认为您有两种选择：
使用lambda。这是相当优雅的。您可以配置一个Lambda在S3中添加内容时触发。然后，此lambda将在队列上注册一个指向文件的指针，以供ec2实例处理。
lambda的问题在于您的应用程序分布更分散。也就是说，您不能只查看行为代码，还必须查看lambda。尽管我猜想这个lambda并不是特别重量级。
让所有ec2实例监视s3，但是当它们找到要执行的工作时，会将其添加到FIFO队列中。这是来自AWS的一种相对较新的队列类型，在该队列中，您已经保证有订单，并且只需要处理一次。因此，您可以保证即使多个节点找到了相同的s3文件，也只有一个节点可以处理该文件。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句