fishermen

对于mc，group是all，不同业务可能存在冲突覆盖，导致端口无法监听，改为full group存储。

灰度存在读堆积问题，原因跟当前策略有关： 1. 单个ip灰度，单ip写对某个size的msg，会盯住某个mcq持续写； 2. 读会轮询读。 从而导致读写不匹配，进而产生堆积问题。 解决对策： 1. 打开整个服务池，读不堆积，则本策略暂不上线（预期原因：写入机器数量大于后端mcq数量，则会写均衡）； 2. 打开整个服务池，如果读仍然堆积，则上该策略（预期原因：写入机器数量小于后端mcq数量，导致写仍然不均衡）。 遗留： 在写入机器远小于后端后端mcq时，仍然需要调整写策略（低优先级？）。

将重试策略收归到协议context中，目前涉及两个变量： 1. retry_on_rsp_notok； 2. max_tries。

后端连接断开后，req无响应，kv返回除了设置status，还需构建一个默认响应body

根据kvector读写策略，读aggregation，写aggregation or 单库单表

breeze 解析redis响应时，没有处理 “*-1\r\n”，可能出现不可预知的问题： 1. 在 debug 模式下，Rust 会直接触发 panic（运行时错误），提示整数溢出，导致连接断开。 2. 在 release 模式下（默认关闭溢出检查），会按照无符号整数的环绕规则处理，结果为 usize::MAX - 2（例如 64 位系统上是 18446744073709551613），pipeline下会吞噬并读取到非法位置。

rang & modrange，对于 nocheck 的特殊场景，存在最大 index 等于 shards 的情况，对这种场景进行纠正，避免异常。