分布式列表中的冲突解决

发布于 2024-12-22 18:08:52 字数 310 浏览 3 评论 0原文

我想维护分布在 N 个负载平衡服务器之间的对象列表:每当客户端更改一台服务器上的列表时,我希望这些更改迁移到其他服务器。所以,我猜这是主主复制的情况。 处理这个问题最简单的方法是什么?一个简单的事实是,对列表中对象的每次更改都会附加一个相关的递增版本号。因此,如果某个项目在两个不同的服务器上发生更改,并且这两个增量到达第三个服务器,则可以解决冲突。

编辑:澄清:我非常熟悉像 Memcached 和 Redis 这样的分布式键值存储。这不是这里的问题;我感兴趣的是一种解决共享列表中冲突的机制:例如,如果服务器 A 更改列表中的某个项目,而服务器 B 删除该项目,如何以编程方式解决冲突。

I would like to maintain a list of objects that is distributed between N load balanced servers: whenever a client changes the list on one server, I would like these changes to migrate to the other servers. So, I guess this is a case of master-master replication.
What is the simplest way of handling this? One simplifying fact is that each change to an object in the list has an associated increasing version number attached to it. So, it is possible to resolve conflicts if an item was changed on two different servers, and these two deltas make their way to a third server.

Edit: clarification: I am quite familiar with distributed key-value stores like Memcached and Redis. That is not the issue here; what I am interested in is a mechanism to resolve conflicts in a shared list: if server A changes an item in the list, and server B removes the item, for example, how to resolve the conflict programmatically.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

二货你真萌 2024-12-29 18:08:52

我建议使用memcached。这是一个分布式服务器缓存系统,似乎完全满足您的需求。查看此链接:

您使用哪种 .NET Memcached 客户端使用,EnyimMemcached 与 BeITMemcached?

如果传递整个列表不适合你(我不知道 memcached 是否聪明)足以区分您的列表)那么我建议看一下旧的 DataSet 对象,因为如果您的数据集很大,它的 diff 克应该非常适合仅传递增量。

I suggest memcached. It's a distributed server cache system that seems to fit your needs perfectly. Check out this link:

Which .NET Memcached client do you use, EnyimMemcached vs. BeITMemcached?

If passing the entire list doesn't suit you (I don't know if memcached is smart enough to diff your lists) then I would suggest giving the old DataSet object a look, as its diff grams should be well suited for passing about just deltas if your data set is large.

吻安 2024-12-29 18:08:52

将您的更改放入队列中。让每个服务器查看队列并对其采取行动。

例如,队列可以具有:

  • 添加项目 #33
  • 删除项目 #55
  • 更新项目 #22
  • 等等

进行更改后,写入队列,并让每个服务器从队列中拾取项目并据此更新其列表。

我用这种方法做了内存数据库,它在多个“服务器”上完美运行。

编辑:

当服务器想要相互更新时,必须发生这种情况:

每个更新的服务器都会将更新(或添加或删除)请求放入所有其他服务器的队列中。每个服务器还应该存储源自它的排队请求列表,这样它就不会从队列中加载自己的更新。

Put your changes in a queue. Have each server look at the queue, and act upon it.

For example, queue could have:

  • add item #33
  • remove item #55
  • update item #22
  • and so on

Upon doing a change, write to the queue, and have each server pick up items from the queue and update its list according to that.

I did in-memory database with such method, and it worked perfectly on multiple 'servers'.

EDIT:

When servers want to update each other, that has to happen:

Each server that updates will put an UPDATE (or ADD or DELETE) request into the queue for all other servers. Each server should also store the list of queued requests that originated from it so it will not load its own updates from the queue.

故笙诉离歌 2024-12-29 18:08:52

每个服务器是否都有自己的本地缓存 List 版本,还是计划使用集中式缓存层?

正如所建议的,您可以拥有一个集中式“推送”流程,该流程在集中式队列中工作。任何服务器提交的任何更改都会排队,并且“推送”过程可以通过某种远程处理/WebService 机制将更新推送到所有服务器。

这提供了以下优点:任何更改/更新/删除都可以立即(或及时)应用于所有服务器,并在需要时进行集中验证或日志记录。这也解决了多次更新的问题——最新的优先。

我已经看到这是作为一个 Windows 服务实现的,它有一个内部队列(可以持久化到数据库异步以实现弹性),它管理队列并简单地一项一项地获取项目,验证项目,记录更改/内容,最后将其推送到通过 WebService 调用每个 Web 服务器的本地列表(服务器维护内存中列表,该列表只需根据需要进行更新/添加/删除)。

Does each server have it's own version of List locally cached or do you plan to use a centralized caching layer?

As suggested, you can have a centralized "push" process which works off a centralized queue. Any changes submitted by any server are en-queued, and the "push" process can push updates to all the servers via some remoting / WebService mechanism.

This offers the advantage of any changes/updates/deletes being applied at once (or close in time) to all the servers, centralized validation or logging if needed. This also solves the problem of multiple updates - the latest one takes precedence.

I've seen this implemented as a windows service which has an internal queue (can be persisted to DB async for resiliency) which manages the queue and simply takes items one by one, validates the item, loggs change/content and finally pushes it to local Lists via WebService calls to each web server (servers maintain in-memory list which simply gets updated/added/deleted as needed).

橘和柠 2024-12-29 18:08:52

有一些算法可用于同步分布式系统。

在你的情况下,你需要一种算法,给定系统上的两个事件,告诉你其中一个事件首先发生。如果您可以决定任意两个事件(即第一个事件),那么所有冲突都可以得到解决。

我建议您使用 Lamport 时钟

There are algorithms that can be used to syncronize Distributed systems.

In your case you need an algorithms that given two events on the system tells you wich one of them happened firts. If you can decide for any two events wich is the first one then all the conflicts could be resolved.

I recommend you to use Lamport Clocks.

别挽留 2024-12-29 18:08:52

如果您使用的是 Windows 平台,我建议您查看“Windows Server AppFabric< /a>”,尤其是缓存功能。这个名字很时髦,但我认为这正是你正在寻找的,我引用:

分布式内存缓存,为 .NET 应用程序提供
应用程序数据的高速访问、规模和高可用性。

If you're on a Windows platform, I suggest you take a look at "Windows Server AppFabric", and especially the Caching feature. The name is funky, but I think it's exactly what you're looking for, I quote:

A distributed in-memory cache that provides .NET applications with
high-speed access, scale, and high availability to application data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文