嵌入式JanusGraph查询缓存归属及多节点数据更新获取疑问

问题1：未显式开启事务的只读查询缓存归属 #

JanusGraph 默认所有 Gremlin 操作都会隐式绑定独立事务，通过 Gremlin HTTP 端点发起的单次请求也对应一个完整的隐式事务生命周期，请求结束后事务会自动提交销毁。
你执行的 g.V().has("name","ABC") 查询的结果流向如下：

• 查询首先会尝试命中数据库层级缓存（即全局 DB 缓存，由 janusgraph.cache.db-cache 配置控制是否开启，默认开启），如果缓存未命中才会从底层存储拉取数据
• 拉取到的结果会同时写入两个缓存区域：
  • 当前隐式事务的事务缓存：仅在当前事务存活期间可用，请求结束事务销毁后会被同步清理，不会留存到其他事务
  • 全局 DB 缓存：跨事务生效，会在当前节点长期留存直到过期或被手动清理

也就是说，请求结束后只有 DB 缓存会留存查询结果，事务缓存会随事务销毁直接释放。 #

问题2：多节点部署场景下获取顶点更新值的方案 #

首先明确：事务缓存是单节点、单事务独有的资源，不会跨事务、跨节点共享，所以多节点场景下不存在跨节点读取其他节点事务缓存旧值的问题，通常读到旧值的场景来源于各节点本地独立存储的全局 DB 缓存，可通过以下方案解决：

• 强一致读场景：需要读取最新值的请求，在查询前显式开启事务并设置跳过缓存：graph.buildTransaction().skipCache(true).start()，该配置会让当前请求直接绕过本地事务缓存和全局 DB 缓存，直接从底层存储拉取最新数据
• 调整缓存过期策略：如果允许短时间的一致性延迟，可以调整 janusgraph.cache.db-cache-time 配置，缩小 DB 缓存的有效时长，降低读到旧值的时间窗口
• 替换统一缓存：如果对一致性要求较高且集群规模大，可以关闭 JanusGraph 自带的全局 DB 缓存，改用 Redis 等独立的分布式缓存组件，自行控制缓存的更新、失效逻辑，保证所有节点读到的缓存数据一致

内容的提问来源于stack exchange，提问作者Harshit Sharma