共计 1569 个字符，预计需要花费 4 分钟才能阅读完成。
本文首发于 Nebula Graph Community 公众号
Nebula Graph v2.6 版本当中比拟重要的个性之一便是 TOSS。通过本文，我将带你全方位理解 TOSS 为何物。
从一条 GO 语句说起
家喻户晓，边分为无向边跟有向边两种。所以当按有向边去摸索时，就能够按正向边 / 反向边做遍历，Nebula Graph 也反对这种语义。比方：
go from "101" over known reversely yield known.kdate, id($$);上述语句从点 101 开始反向的找所有的对应邻边。但，当用户应用 Nebula 插入一条边时，命令都相似于：
insert edge known(degree) VALUES "100" -> "101":(299792458);上述语句看上去只写了正向边，并没有输出反向边：这是因为在 Nebula 设计时，当用户插入一条边时，零碎会默默地在后盾写入一条反向边。
聊聊 Nebula Graph 如何插入一条边
以上文的那条 INSERT 语句为例，后盾的执行流程有：
- Nebula Console 将
INSERT对应的 request 发给连贯的 Nebula Graph Server； - Nebula Graph Server 收到后，依据正向边的信息对应补充出反向边的信息，并将这个 AddEdgeRequest 别离发往正反向边对应的主机；
- Nebula Storage Server 收到这个 AddEdgeRequest 后，在本地（通过 raft）插入对应的边，并将后果返回给 Graph Server；
- Nebula Graph Server 收到两边的后果后，返回给 Nebula Console；
流程图如下：
这里，对网络 / 分布式编程比拟相熟的同学可能当初就看出问题了：因为 Graph 对于两个 Storage 的调用应用 RPC，那么当 INSERT 操作执行的次数足够多，就肯定会遇到一边 RPC 胜利，另一边 RPC 失败（超时）的状况。换句话说，可能呈现一个 INSERT 正向边胜利，反向边失败的状况。
这种后果会反馈给客户端：如果用户有正反向边属性统一的需要，就须要对 failed 的 request 做有限重试。然而 Nebula Graph 做为一个数据库，将数据的原子性交由内部（客户端）来保障还是不适合的。
于是，诞生了一个需要——保障正反向边的原子性，即变更边时，正反边要么同时变更胜利，要么同时变更失败。这便是 TOSS（Transaction on storage side）的由来，用于保障对边进行 INSERT、UPDATE 或 UPSERT 操作的最终一致性。
TOSS 应用办法
随着 Nebula v2.6.0 的公布，TOSS 性能曾经上线。但基于性能和稳定性思考，Nebula Graph 默认将该性能设为 default disable 状态。有正反向边一致性需要的小伙伴们能够在 Nebula Graph Server 的配置中找到 enable_experimental_feature 这个选项，将它设为 true 并重启 graphd。如下：
--enable_experimental_feature=true 那么之后的 INSERT / UPDATE / UPSERT 就会有一致性的保障了。（跟之前一样做 CREATE SPACE / CREATE EDGE / INSERT / UPDATE 即可，不须要额定操作）
注：开启 TOSS 之后，只对增量数据无效，存量数据之前有过正反边不统一时不会失去修改。
Nebula 社区首届征文活动正式开启啦 🔗 奖品丰富，全场景笼罩：撸码机械键盘、手机无线充、衰弱小助手智能手环，更有数据库设计、常识图谱实际书籍等你来领，还有 Nebula 粗劣周边送不停
欢送对 Nebula 有趣味、喜钻研的小伙伴来书写本人和 Nebula 乏味的故事呀～
交换图数据库技术？退出 Nebula 交换群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
