zhaozhao.zz 78bef6e1fe
optimize(remove) usage of client's pending_querybuf (#10413)
To remove `pending_querybuf`, the key point is reusing `querybuf`, it means master client's `querybuf` is not only used to parse command, but also proxy to sub-replicas.

1. add a new variable `repl_applied` for master client to record how many data applied (propagated via `replicationFeedStreamFromMasterStream()`) but not trimmed in `querybuf`.

2. don't sdsrange `querybuf` in `commandProcessed()`, we trim it to `repl_applied` after the whole replication pipeline processed to avoid fragmented `sdsrange`. And here are some scenarios we cannot trim to `qb_pos`:
    * we don't receive complete command from master
    * master client blocked because of client pause
    * IO threads operate read, master client flagged with CLIENT_PENDING_COMMAND

    In these scenarios, `qb_pos` points to the part of the current command or the beginning of next command, and the current command is not applied yet, so the `repl_applied` is not equal to `qb_pos`.

Some other notes:
* Do not do big arg optimization on master client, since we can only sdsrange `querybuf` after data sent to replicas.
* Set `qb_pos` and `repl_applied` to 0 when `freeClient` in `replicationCacheMaster`.
* Rewrite `processPendingCommandsAndResetClient` to `processPendingCommandAndInputBuffer`, let `processInputBuffer` to be called successively after `processCommandAndResetClient`.
2022-03-25 10:45:40 +08:00
..
2022-03-09 13:55:17 +02:00
2020-04-24 17:11:21 -07:00
2022-03-09 13:58:23 +02:00
2021-12-19 17:52:23 +02:00
2022-02-28 10:59:16 +02:00
2020-10-27 15:04:18 +02:00
2022-01-06 13:39:38 +02:00
2022-03-09 13:58:23 +02:00
2022-03-09 13:58:23 +02:00
2020-05-05 23:35:08 -04:00
2022-01-06 17:59:37 +02:00
2019-11-19 17:23:47 +08:00
2022-01-02 16:54:47 -08:00
2022-03-09 13:58:23 +02:00
2019-10-02 11:30:20 +02:00
2021-07-10 10:04:54 -05:00
2020-07-21 08:13:05 +03:00
2022-03-09 13:58:23 +02:00