讨论: v4 性能提升

[Zheaoli]

目前经过元旦的几天测试和 profile，有这样一些想法

1. 目前经过 Profile，发现主要读侧的瓶颈还是在需要将文件写 file buffer 中，在云服务上，默认走 EBS 这样的存储，性能会额外的低下，同时会引发2的问题
2. 因为1导致写入性能成为瓶颈，在模拟 SLAVE 时，容易出现 source instance 中 output buffer for replica 直接炸了，导致链接 RESET 的情况

我自己目前的看法是这样：

1. feat: Support increment sync #744 我觉得会很有用，但是实现可能需要讨论一下
2. 目前 file buffer 我理解是有两个作用，1 可以让人后续使用 aof_reader 进行同步，2 减少内存使用。这里我觉得可以将 file buffer 作为可选项，我们同样可以实现 sized memory buffer。让用户自行选择

不过 reader 最终的改造需要在 Writer 并行写入改造完成后才能体现，这样是我在犹豫的地方

[suxb201]

是这样的，我上次测试也发现云上环境云盘的低带宽会构成瓶颈：

1. 保存 dump.rdb 阶段需要较高的云盘写带宽，这个阶段耗时较长会导致源端 Redis 的 output buffer 一直堆积。
2. 保存 aof 阶段对云盘带宽需求不高，一般 Redis 的写带宽不会很高，当然也有特殊情况。

可以考虑 dump.rdb 保存到内存，数 G 的内存空间可以接受。

[jjz921024]

2. 目前 file buffer 我理解是有两个作用，1 可以让人后续使用 aof_reader 进行同步，2 减少内存使用。这里我觉得可以将 file buffer 作为可选项，我们同样可以实现 sized memory buffer。让用户自行选择

同样考虑过这点，是否可以增加不落盘的方式提供给用户选择。而且通过golang的有缓冲channel，连接reader和writer，可以天然的拥有背压的功能，内存占用是可控的

[Zheaoli]

这里我考虑的是将 buffer 管理这一块抽象出来，做一个 BufferManager，支持两种模式，一种是 Memory Buffer，一种是 File Buffer

[VonAlex]

Does this meet the demand?
https://github.com/CodisLabs/redis-port/tree/redis-4.x-cgo/pkg/libs/pipe