Milvus核心设计（2）-----TSO机制详解

目录

背景

动机

Timestamp种类及使用场景

Guarantee timestamp

Service timestamp

Graceful time

Timestamp同步机制

主流程

时间戳同步流程

背景

Milvus 在设计上突出了分布式的设计，虽然Chroma 也支持分布式的store 与 query。但是相对Milvus来说，不算非常突出。正因为Milvus 在设计上对分布式store 与 query 非常重视，所以引入了TSO机制。也就是timestamp oracle mechanism。我会以比较形象的方式讲述下这部分机理，并结合Milvus的配置及工作生活中的场景，技术上的设计美感和项目中的管理艺术，最终你会发现大道殊途同归。‘梦里寻他千百度,蓦然回首,那人却在灯火阑珊处‘。

TSO设计动机

Milvus 在设计时为什么要引入 TSO机制？实际上其动机和使用场景挂钩，当你使用 stand-alone 模式启动Milvus时，TSO的作用或许你看不出来，当然在不同 coordinate 与 node 之间这种时间同步机制仍然存在，因为从设计上的角度上来说，如果支持了分布式，那么自然也涵盖了stand-alone的单机模式。只是单机模式可以延用分布式设计的特性。

想象一个场景：

那么最正确的结果应该是：

• user2在 t2 时刻 query c0 collection， 结果是 empty result。

• user2在 t7 时刻 query c0 collection， 结果是 A1。

• user2在 t12 时刻 query c0 collection， 结果是 A1与A2。

• user2在 t71 时刻 query c0 collection， 结果是 A1。

假设没有统一的时间戳作为度量，你没法将不同cilent 的操作，这里包括了 DDL 与 DML，进行统一输出。DDL与 DML 前面都介绍过了，这里就一笔带过。但是客户端子的时间系统有可能基准参差不齐，这例你有可能说使用对时服务可以解决这个问题。确实，使用对时服务可以解决多client时间同步的问题，但是因为timestamp对分布式系统太重要，你不能总想着依靠一个对时服务来解决所有的问题。万一两个对时服务基准不统一，或是一个client根本连不上对时服务怎么办？真正robest的db 不会将自己的 kernel 依附在一个自己认为是核心且必要，但外界可有可无，甚至不准的service 之上。

先看下Milvus 中几种timestamp 的定义与使用场景

Timestamp种类及使用场景

Guarantee timestamp

这种 timestamp 顾名思义，就是保证性质的，就相当于设置之后Milvus保证在这个之前的所有DDL 与DML都执行完成。

需要注意的是，这个 guarantee 时间戳不需要你来设置，因为它对于Milvus 来说太核心了，万一你设置一个不太对的值，整个 system 的 query 结果可能不符合预期或是直接导致Milvus sys崩溃。 

举个例子：