根据文档，Zookeeper 读取不完全一致，但创建 znode 是否完全一致？
Zookeeper reads is not fully consistent as per documentation, but is creating a znode fully consistent?
下面是我的assumptions/queries。如有理解错误请指出
通过阅读文档我了解到
- Zookeeper 写入 Leader，然后复制到 Follower。可以从跟随者（从属）本身提供读取请求。因此 read 可能会过时。
- 为什么不能使用zookeeper作为缓存系统呢？
- 由于写请求总是made/redirected给Leader，说明节点创建是一致的。当两个客户端发送相同节点名称的写请求时，其中一个总是会收到错误（NodeExistsException）。
- 如果以上是真的，那么我们可以使用 zookeeper 通过使用 requestId 创建一个 znode 来跟踪重复的请求。
- 为了在分布式系统中生成序列号，我们可以使用顺序节点创建。
根据问题和评论中提供的信息，基本问题似乎是：
在无状态的多服务器架构中，如何最好地防止数据重复，这里的数据是"has this refund been processed?"
这符合 "primarily opinion based"。有多种方法可以做到这一点，没有一种方法是最好的。你可以用 MySQL 来做，也可以用 Zookeeper 来做。
现在是纯粹的意见和猜测：
要处理退款，某处必须有一些数据库吗？为什么不检查一下呢？您正在准备的重复请求场景似乎很少发生——这种情况不会每秒发生数百次。如果是这样，那么这种情况不保证高性能实施。只需查询数据库就可以了。
您的工作量似乎是 1:1 与 read:write 的比率。每次处理退款时，您都会检查它是否已处理，如果未处理，则处理它并为其输入。现在 Zookeeper 本身 says 它最适合 10:1 比率 read:write 这样的东西。虽然 MySQL 没有这样的指标，但它不需要确保 zookeeper 为写入活动做出某些*保证。因此我希望，对于纯写入密集型负载应该更好。 (* 顺序性、广播、共识等保证)
只是吹毛求疵，但您的数据是包含数百（数千？数百万？）交易 ID 的线性列表。 正是MySQL（或任何数据库）及其主键的构建目的。 Zookeeper 是为更多 complex/powerful 分层数据而设计的。你不需要。
下面是我的assumptions/queries。如有理解错误请指出
通过阅读文档我了解到
- Zookeeper 写入 Leader，然后复制到 Follower。可以从跟随者（从属）本身提供读取请求。因此 read 可能会过时。
- 为什么不能使用zookeeper作为缓存系统呢？
- 由于写请求总是made/redirected给Leader，说明节点创建是一致的。当两个客户端发送相同节点名称的写请求时，其中一个总是会收到错误（NodeExistsException）。
- 如果以上是真的，那么我们可以使用 zookeeper 通过使用 requestId 创建一个 znode 来跟踪重复的请求。
- 为了在分布式系统中生成序列号，我们可以使用顺序节点创建。
根据问题和评论中提供的信息，基本问题似乎是： 在无状态的多服务器架构中，如何最好地防止数据重复，这里的数据是"has this refund been processed?"
这符合 "primarily opinion based"。有多种方法可以做到这一点，没有一种方法是最好的。你可以用 MySQL 来做，也可以用 Zookeeper 来做。
现在是纯粹的意见和猜测：
要处理退款，某处必须有一些数据库吗？为什么不检查一下呢？您正在准备的重复请求场景似乎很少发生——这种情况不会每秒发生数百次。如果是这样，那么这种情况不保证高性能实施。只需查询数据库就可以了。
您的工作量似乎是 1:1 与 read:write 的比率。每次处理退款时，您都会检查它是否已处理，如果未处理，则处理它并为其输入。现在 Zookeeper 本身 says 它最适合 10:1 比率 read:write 这样的东西。虽然 MySQL 没有这样的指标，但它不需要确保 zookeeper 为写入活动做出某些*保证。因此我希望，对于纯写入密集型负载应该更好。 (* 顺序性、广播、共识等保证)
只是吹毛求疵，但您的数据是包含数百（数千？数百万？）交易 ID 的线性列表。 正是MySQL（或任何数据库）及其主键的构建目的。 Zookeeper 是为更多 complex/powerful 分层数据而设计的。你不需要。