当前位置: 首页 > 知识库问答 >
问题:

使用编年史地图作为微服务间数据共享的手段

丁勇
2023-03-14

在学习了教程之后,我们了解到数据复制只在Chronicle Map企业版中可用,我们使用的是开源版本。有人能提出上述方法是否现实可行吗?

另外,如果共享持久化文件的方法不能达到预期的效果,那么我们是否可以使用chronicle map结合chronicle engine来实现微服务间的数据共享呢?

共有1个答案

白禄
2023-03-14

编年史映射通过将整个文件映射到内存中来工作。我不确定网络存储完全支持mmap,但即使支持,我怀疑这种设计在性能和复制一致性方面会非常好。

另外,如果共享持久化文件的方法不能达到预期的效果,那么我们是否可以使用chronicle map结合chronicle engine来实现微服务间的数据共享呢?

除非您愿意自己编写和支持复制代码,否则实际上我认为您必须为Chronicle Enterprise支付费用。如果您需要一个经过战斗测试的、开源的、社区支持的复制键值存储,像Redis集群这样的存储可能是一个更好的选择,尽管它可能比编年史地图效率低。

 类似资料:
  • 当前体系结构: 问题: 我们在前端和后端层之间有一个两步流程。 null 微服务2(MS2)需要验证I1的完整性,因为它来自前端。如何避免对MS1进行新的查询?最好的办法是什么? 我试图优化的流删除了步骤1.3和2.3 流程1: null 流程2: 2.1用户X已在本地/会话存储中存储了数据(MS2_Data) 2.2用户X在MS1上保留数据(MS2_Data+MS1_Data) 2.3 MS1使

  • 我正在设计一个微服务架构中的评审分析平台。 应用程序如下所示; null null 问题在于,验证服务需要获取site-a的所有评论,应用验证规则并生成错误(如果有的话)。我知道共享数据库模式和实体打破了微服务体系结构。 一个可能的解决方案是 每当验证服务需要对站点进行审查时,它就会请求网关,网关会将请求重定向到审查服务并采取响应。 这种方法的两个可能缺点是 验证服务是否知道网关?是否会带来依赖?

  • 在描述中说: 编年史映射提供内存访问速度,并支持超低垃圾收集。编年史地图可以支持最苛刻的应用程序。

  • 我有以下映射定义,其中map.containsKey()显然不起作用: 我使用的是编年史地图2.4.17,在我的项目中迁移到版本3太难了。

  • 在所有情况下,重要的是,如果允许用户Y访问该公司,微服务本身仍然必须检查是否允许用户Y对该公司进行某种操作。因此,此用户到公司的匹配仅用于确保用户对公司有访问权限。 我并不是真的很喜欢这些方法,因为将消息放入队列(1)意味着每个服务都必须被告知一个更改。使用Zuul验证(2)也不是真正实用的,因为它应该只是一个网关。