CockroachDB-读和写

本文知识点来源于官网地址https://www.cockroachlabs.com/docs/stable/architecture/reads-and-writes-overview.html

查询执行

当CRDB执行查询时，集群将请求路由到包含相关数据的范围的Leaseholder。如果查询涉及多个范围，则请求将发送给多个Leaseholder。对于读请求，只有相关范围的Leaseholder检索数据。对于写请求，Raft共识协议规定，在提交写请求之前，相关范围的大部分副本必须一致。

读场景

假设场景：

• 集群中有3个节点
• 有3个小表，每一个都对应一个range
• ranges默认有3个副本
• 在节点2上执行查询，从表3读取数据
  
  在这个例子中：
• 节点2(网关节点)接收从表3读取的请求。
• 表3的Leaseholder位于节点3上，因此请求被路由到节点3。
• 节点3将数据返回给节点2。
• 节点2响应客户端。

如果查询被具有相关range的Leaseholder的节点接收，则网络跳数会减少:

写场景

假设一个简单的写场景，对节点3执行一个查询，写入表1:

在这个例子中：

• 节点3(网关节点)接收到写入表1的请求。
• 表1的Leaseholder位于节点1上，因此请求被路由到节点1。
• Leaseholder是与Raft leader相同的副本，因此它同时将写操作追加到自己的Raft日志中，并通知节点2和3上的follower副本。
• 一旦一个follower将写操作追加到它的Raft日志中(因此，基于相同的Raft日志，大多数副本都同意)，它就通知leader，写操作被提交到同意的副本上的键值。在此关系图中，节点2上的follower确认了写入，但它也可能是节点3上的follower。还要注意，没有参与共识协议的追随者通常会在其他人之后很快提交写。
• 节点1返回向节点3提交的确认。
• 节点3响应客户端。

就像在读场景中一样，如果写请求是由拥有相关range的Leaseholder和Raft leader的节点接收的，那么网络跳数就会更少:

网络和I/O瓶颈

记住上面的例子，将网络延迟和磁盘I/O视为潜在的性能瓶颈总是很重要的。总而言之:
对于读取，网关节点和Leaseholder之间的跳转增加了延迟。
对于写，在网关节点和Leaseholder/Raft leader之间跳跃，以及在Leaseholder/Raft leader和Raft follower之间跳跃，增加延迟。此外，由于在提交写操作之前，Raft日志条目被持久化到磁盘，因此磁盘I/O非常重要。