首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >根据文档,动物园管理员读取的内容并不完全一致,但是创建znode是否完全一致呢?

问根据文档,动物园管理员读取的内容并不完全一致,但是创建znode是否完全一致呢?
EN

Stack Overflow用户
提问于 2018-12-31 07:37:41
回答 1查看 349关注 0票数 1

以下是我的假设/疑问。如果我的理解有什么问题,请说明。

通过阅读文档,我了解到

  1. 动物园管理员写信给领袖,他们被复制到跟随者。可以从跟随者(从)本身提供读取请求。因此,阅读可能是过时的。
  2. 为什么我们不能用动物园管理员作为缓存系统呢?
  3. 由于写入请求总是被发出/重定向给领导人,这意味着节点创建是一致的。当两个客户端发送相同节点名称的写请求时,其中一个总是会收到一个错误(NodeExistsException)。
  4. 如果上面的内容是正确的,那么我们是否可以通过使用requestId创建一个znode来跟踪重复的请求。
  5. 为了在分布式系统中生成序列号,我们可以使用顺序节点创建。
EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2019-01-02 11:09:59

根据问题和评论中提供的信息,基本问题似乎是:无状态多服务器体系结构中的,如何最好地防止数据复制--,这里的数据是“是否已处理了退款?”

这可以说是“主要以意见为基础”。有多种方法可以做到这一点,没有哪一种方式是最好的。你可以用MySQL做这件事,也可以和动物园管理员一起做。

现在出现了纯粹的观点和猜测:

要处理退款,一定有什么数据库?为什么不直接检查一下呢?您正在准备的重复请求场景似乎是罕见的--这种情况不会以每秒100次的速度发生。如果是这样的话,那么这个场景就不需要高性能的实现。只要查一查数据库就行了。

您的工作负载似乎是1:1与read:write的比率。每次处理退款时,您都会检查是否已经处理,如果没有处理,则进行处理并为其输入条目。现在,动物园管理员本身,他说,它最好的工作,如10:1比率的read:write。虽然MySQL没有这样的度量,但它不需要确定*管理员为写活动所做的保证。因此,我希望,它应该是更好的纯写密集型负载。(*顺序、广播、协商一致等保证)

只是吹毛求疵,但你的数据却是数百(数千)个线性列表?数百万?)交易ids。这正是,,MySQL (或任何数据库)及其主键是为什么构建的。动物园管理员是为更复杂/更强大的分层数据而设计的。你不需要的。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/53984837

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档