20200210

@ShiKaiWi

Plan

  • 60min: UNP
  • 20min: RocksDB Write Procedure

Notes

UNP

TCP 的 "三次握手建立 connection、四次挥手关闭 connection" 中的 "次" 实际上是指过程中交换的 数据报（segment）。

TCP 的状态转换图新发现

  1. 虚线表示 server 端（被动打开、关闭），实线代表 client 端（主动打开、关闭）（这个 server/client 只是经验上的，毕竟 TCP 是全双工的）。
  2. Closed、Established 状态是两端同时可以达到的状态。
  3. 存在同时建立连接+关闭连接的情况
  4. 被动关闭进入 CLOSED_WAIT 状态后，会发送 FIN 包，发送完会进入 LAST_ACK 状态，等待 ACK 包，但是大部分时间情况是还是处于 CLOSED_WAIT 状态，这一点不清楚。

TCP 的 TIME_WAIT 状态目的

  1. 实现全双工的连接终止: 主动关闭之后，并且接收到对端的 FIN 包，发送 ACK 包，就进入 TIME_WAIT 状态了，然而并不能保证 ACK 包一定被对方接收到，因此 TIME_WAIT 状态可以在对端因为没有接收到 ACK 包的情况下重发 FIN 包的时候再次发送 ACK 包。
  2. 处理老的重复数据报(wandering duplicate segments): 至少维持 2MSL(maximium segment lifetime)，保证网络中游荡的数据报不会污染使用相同 ip 和 port 的 socket，至于为什么 CLOSE_WAIT 不需要等待的原因是 TCP 是全双工的，如果一端保证了 2MSL 不可用的话，那么就不会有相同 ip 和 port 的 socket 再次被建立。

TCP MSS 选项

MSS = maximum segment size，计算方法是 <= MTU(maximum transmission unit，通常为 1500B) - IP_HEADER(v4=20B，v6=40B) - TCP_HEADER(20B)

RocksDB Write Procedure

相关文件：

  • db_impl_write.cc:WriterImpl
  • write_thread.h
  • write_batch.h

目前的进展：

  1. 过了一遍 WriteImpl 流程，分支比较多，看到写入的实际触发动作是在写入流程触发的（无论是 leader 还是 follower），leader 需要触发 follower 的写入，这个和我一开始设想的单独维护线程池不同，不过确实是很好的设计，本来就是上层控制写入线程的数量的，单独维护线程池本身就是一个简单、低效的做法。
  2. 发现含有 merge 操作的 batch 写入是不支持 concurrent update memtable 的。

明天的安排： 仔细研究几个分支

More

  • 被动关闭进入 CLOSED_WAIT 状态后，会发送 FIN 包，发送完会进入 LAST_ACK 状态，等待 ACK 包，但是大部分时间情况是还是处于 CLOSED_WAIT 状态，这一点不清楚。
  • std::aligned_storage
  • TEST_SYNC_POINT