Tao Wu

Hi, this PR has passed all the Travis tests. Could anyone please have a look?

Any progress on this issue? Where is currently the async work going? I took a quick glance at https://github.com/flier/tokio-kafka and it has been unmaintained since 2018. I will be glad...

@jon-chuang Thanks! I will take a look and see if I can reuse the code in field_generator.

@jon-chuang Since `field_generator` doesn't cover all the data types, I cannot directly reuse the code. I feel like the refactoring can be a to-do because the implementation in this PR...

> Actually, I don't completely understand the purpose of this framework. What tests specifically do we want to run? Is it more of a fuzz-test? Why is the current testing...

I see, but you don't need to actually start Postgres and a Debezium server in CI, if the data has been pre-generated. You can first run Postgres+Debezium+Kafka ([Redpanda](https://docs.redpanda.com/docs/quickstart/quick-start-linux/) is recommended)...

Yeah, just remove debezium and postgres for now in the docker-compose file. Add them back if really needed. (IDK if they will slow down the CI)

> 服务端处理都在1ms以内返回 请问服务端1ms耗时是如何看出的? > 客户端等请求都返回到回调处理时总共经历了6~8ms 你可以给一下服务端的总吞吐, 并实验看是否吞吐下降后, 延迟也会下降.

"服务端记录" 是指的哪个记录? "客户端请求5000条空数据，数据随机分布所有分区，然后并行请求这100个mget" 刚开始客户端建立TCP连接需要时间, 偶尔的TCP预热也需要时间, 一个比较准确的benchmark还是参照我们在https://pegasus-kv.github.io/overview/benchmark的测试结果. 首先运行时间要足够长, 其次应该有明确一些的延迟数值, 我们后续也会提供更细粒度延迟的统计.

> "一是创建连接的时候阻塞了其他并行的读操作" 你意思是C++客户端内部在连接建立的时候阻塞读? 如果是的话我们可以看一下具体实现. > 二是异步mget从开始调用到最后调用rpc请求都是串行的 没理解这句话的意思. > 这边的预热没有创建连接，只是从meta拿了config配置 是的, 我们C++客户端暂时没支持连接预热, 我们只在java客户端支持了: https://pegasus-kv.github.io/clients/java-client#%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%BF%9E%E6%8E%A5%E9%A2%84%E7%83%ADwarm-up