1、Milvus 时钟机制
Milvus 通过时间戳水印来保障读链路的一致性，如下图所示，在往消息队列插入数据时， Milvus 不光会为这些插入记录打上时间戳，还会不间断地插入同步时间戳，以图中同步时间戳 syncTs1 为例，当下游消费者（比如QueryNodes）看到 syncTs1，那么意味着 syncTs1 以前的 数据已经全部被消费了，换句话说，比 syncTs1 时间戳还小的插入记录不会再出现在消息队列中。
2、Guarantee Timestamp
Milvus 通过引入 Guarantee timestamp （GuaranteeTs） 来实现不同的一致性级别。GuaranteeTs 用于通知查询节点，在查询节点可以看到 GuaranteeT 之前的所有数据之前，不会执行搜索或查询请求。指定一致性级别时，一致性级别将映射到特定的 GuaranteeTs 值。
QueryNodes 会不断从消息队列里面拿到插入记录以及同步时间戳，每消费到一个同步时间 戳，QueryNodes 会把这个时间戳称为可服务时间——“ServiceTime”，QueryNodes 只能够看到 ServiceTime 以前所有的数据。有了这个 ServiceTime，Milvus 根据不同用户对一致性以及可用性的需求，提供了 GuaranteeTs， 用户可以指定 GuaranteeTs 告知 QueryNodes 我这次 Search 请求必须看到 GuaranteeTs 以前 的所有数据。
如下图所示，如果 GuaranteeTs 小于 ServiceTime，QueryNodes 可以立刻执行 Search 查询。
如果 GuaranteeTs 大于 ServiceTime，QueryNodes 必须从消息队列里持续消费同步时间戳， 直到 ServiceTime 大于 GuaranteeTs 才能执行 Search 查询。
如果用户希望得到足够高的查询精度，对一致性有较高的要求，对查询时延不敏感，那么 GuaranteeTs 应该尽可能大；反之，如果用户希望尽快得到搜索结果，对可用性有较高的要求，对查询精度有较高的 容忍程度，那么 GuaranteeTs 可以不必特别大。
3、一致性等级
- 强一致性（Strong）：GuaranteeTs 设为系统最新时间戳，QueryNodes 需要等待 ServiceTime 推进到当前最新时间戳才能执行该 Search 请求；
- 最终一致性（Eventually）：GuaranteeTs 设为一个特别小的值（比如说设为 1），跳过一致性检查，立刻在当前已有数据上执行 Search 查询；
- 有界一致性（Bounded staleness）：GuaranteeTs 是一个比系统最新时间稍旧的时间，在可容忍范围内可以立刻执行查询；
- 客户端一致性（Session）：客户端使用上一次写入的时间戳作为 GuaranteeTs，那么每个客户端至少能看到 自己插入的全部数据。
Milvus 默认提供有界一致性，如果用户不传入 GuaranteeTs，那么会将 GuaranteeTs 设为系统 当前的最新时间戳。
4、不同一致性适用场景
Strong：根据PACELC定理，如果一致性级别设置为强，则延迟会增加。因此，建议在功能测试时选择一致性强的，以保证测试结果的准确性。强一致性也最适合以牺牲搜索速度为代价对数据一致性有严格要求的应用程序。处理订单支付和账单的在线金融系统就是一个例子。
Bounded staleness：有界过期适用于需要控制搜索延迟并可以接受零星数据不可见的场景。例如，在像视频推荐引擎这样的推荐系统中，数据不可见性有时对整体召回率的影响很小，但可以显著提高推荐系统的性能。
Session：对于那些对同一会话中的数据一致性要求很高的场景，建议选择会话作为一致性级别。例如，从图书馆系统中删除图书条目的数据，在确认删除并刷新页面(不同的会话)之后，图书应该不再在搜索结果中可见。
Eventually：根据PACELC定理，在牺牲一致性的情况下，搜索延迟可以大大缩短。因此，最终一致性最适合对数据一致性要求不高但需要快速搜索性能的场景。例如，检索Amazon产品的评论和评级，其级别为“最终一致”。
