修改
我把问题提到了最顶层。我会留下搜索帮助的问题描述以及有人可能需要的任何背景信息。
如果您使用带有kestrel的memcached库，如果您在群集中使用2+服务器并利用可靠的读取功能（或任何其他功能），memcached哈希算法是否可能总是在错误的位置？您是否必须更改memcached库中的散列算法？我错过了什么吗？有没有人有任何见解？
背景信息
Kestrel用户吹嘘您可以使用任何memcached库连接到您的kestrel群集，以弹出并推送队列中的项目。考虑到这一点后，它似乎有缺陷。 Memcached在没有服务器间通信的集群中工作，因为客户端根据组合的散列算法确定密钥的存储位置或存储位置。
红隼文档讨论了红隼是如何“大多数公平”的，因为客户端连接到随机的kestrel节点以读取或写入队列。如果使用memcached客户端，则客户端将始终查找队列的相同位置，因为memcached的客户端使用一致哈希算法。显然，如果你只使用单个红隼服务器我的集群，那没关系，只有一个地方可以看。即使您使用多个节点，也可能没问题，因为您正在访问静态队列名称，因此散列算法始终位于同一位置。
但是，通过修改您从客户端访问的队列名称来交换与红锥交互的额外功能（通过添加/打开可靠读取，并以/ close结束）。理论上，这应该导致客户端始终查找队列的错误位置，并且永远不会检索队列对象，因为它们一致地写入单个节点，并且从一个节点读取 不同的节点，始终如一。
谢谢！
答案 0 :(得分：1)
免责声明：我没有使用红隼，但听起来不错，我为你的问题做了一些挖掘。 引自红隼文档：
客户端具有群集中所有服务器的列表 并为每个操作随机选择一个
看起来你是对的，你应该只是创建自己的服务器选择算法（这可以在一个自定义类中轻松完成），只需连接到一个服务器并将其用于一个操作（set / get / open） +关闭/监控+确认）然后根据需要切换到另一个。 如果memcached客户端将服务器切换为/ open和/ close，那么这实际上会搞砸你的事务，因此它不是很安全，你必须确保在一个桶形操作中使用相同的服务器而不是memcached操作。 如果你想使用监视器并确认你必须编写自己的客户端类，那么memcached客户端库的剂量并不重要。