最终一致性和消息传递
我遇到了这个问题，到目前为止，似乎唯一的解决方案是更强的一致性模型。该服务是 Amazon S3，它提供最终一致性。我们使用它作为 blob 存储后端。
问题是，我们向应用程序引入了消息传递模式，并且我们喜欢它。它的好处是毫无疑问的。不过，似乎需要更强的一致性。场景：
- 子系统从用户获取数据，
- 数据保存到S3
- ，消息发送
- ，消息被另一个子系统接收，
- 数据从S3读取
- ……蟋蟀。这是旧数据吗？有时是这样。
所以。我们尝试了显而易见的方式，发送消息中的数据以避免从 S3 读取不一致。但这是一件非常令人讨厌的事情，消息变得不必要的大，并且当接收器太忙或出现故障时，并且在已经有新数据可用的情况下接收消息较晚时，它就会失败。
有没有解决方案，或者我们真的需要转储 S3 以使用 RDBMS 或 MongoDB 等更一致的后端吗？
I came across this problem, and so far it seems that the only solution is stronger consistency model. The service is Amazon S3, which provides eventual consistency. We use it as blob storage backend.
The problem is, we introduced messaging pattern to our application, and we love it. There's no doubt about it's benefits. However, it seems that it demands stronger consistency. Scenario:
- subsystem acquires data from user
- data is saved to S3
- message is sent
- message is received by another subsystem
- data is read from S3
- ...crickets. Is this the old data? Sometimes it is.
So. We tried to the obvious, send the data in the message to avoid inconsistent reading from S3. But that's pretty nasty thing to do, the message get unnecessarily big, and when the receiver is too busy or goes down, and receives the message late while there's already new data available, it fails.
Is there a solution to this or do we really need to dump S3 for some more consistent backend like RDBMS or MongoDB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的场景允许您的数据始终使用新密钥写入 S3（通过始终创建新对象），那么您可以依赖 Amazon 的写入后读取一致性。
以下是亚马逊对这种一致性模型的描述：
If your scenario allows for your data to always be written on S3 under a new key (by always creating new objects) then you can rely on Amazon's read-after-write consistency.
Here is Amazon's description that describes this consistency model: