feat:codis-proxy bigKey/Request fuse protection

[XiaoLiang2333]

#1691
#2228

[chejinge]

这里还是还原回去吧

[XiaoLiang2333]

ok

[chejinge]

这里是把监控也做了吗

[XiaoLiang2333]

是的，除了一些特定的命令外，每一次请求/响应若被判定为bigRequest/Key、HighRisk则会存入日志，以便于使用命令"XMonitor"查看

[AlexStocks]

关闭一个 Proxy 然后重启，其大 key 信息不存在，但 Pika 大 key 信息还存在，造成 Proxy 与 Pika 大 key 信息不一致。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

When a Proxy is closed and then restarted, its big key information does not exist, but the Pika big key information still exists, causing the Proxy and Pika big key information to be inconsistent.

[luky116]

所有的中文注释，改为英文的

[luky116]

return limiterState.Int64() == SWITCH_CLOSED || limiter.Allow()

[luky116]

本 PR 的功能是做大 key 分析吗？还有必要做 熔断 逻辑吗？可以把你的思路和步骤详细的写一下

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Is the function of this PR to do big key analysis? Is it still necessary to do circuit breaker logic? You can write down your ideas and steps in detail.

[AlexStocks]

@CodiumAI-Agent /review

[CodiumAI-Agent]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	4, because the PR introduces a significant amount of new code (482 lines in a single file) which implements complex logic for monitoring and logging based on various conditions. The complexity of the logic, combined with the use of concurrency and atomic operations, requires careful review to ensure correctness, thread safety, and performance.
🧪 Relevant tests	No
⚡ Possible issues	Possible Bug: The CheckResponseByArrayReturned function may return false negatives in scenarios where the array length is not an even number but should still be considered for monitoring based on content size or other criteria. This is due to the condition that immediately returns false if the array length is not an even number.
	Performance Concern: The extensive use of atomic operations and potential frequent locking in a high-throughput environment (like a proxy server handling many requests) could lead to performance bottlenecks. Review and possibly benchmark sections where atomic variables are heavily used to ensure that performance is not adversely affected.
🔒 Security concerns	No

Code feedback:

---

relevant file	codis/pkg/proxy/monitorBkv.go
suggestion	Consider adding a default case in switch statements where flags are checked (e.g., in CheckBatchsizeOfRequest). This would handle unexpected flags values gracefully, potentially logging a warning or error. This is important to ensure that all possible paths are accounted for, enhancing the robustness of the code. [important]
relevant line	switch flag & (FlagReqKeys | FlagReqKeyFields) {

---

relevant file	codis/pkg/proxy/monitorBkv.go
suggestion	Implement a mechanism to limit the frequency of logging to avoid potential I/O bottlenecks when many records are generated in a short period. This could be achieved by introducing a rate limiter or a buffer that periodically flushes records to the log. [important]
relevant line	collectRecord(record)

---

relevant file	codis/pkg/proxy/monitorBkv.go
suggestion	Refactor the repeated pattern of checking conditions and setting values in functions like XMonitorSetMaxLengthOfValue into a helper function to reduce code duplication. This will make the code cleaner and easier to maintain. [medium]
relevant line	if maxLength < 0 {

---

relevant file	codis/pkg/proxy/monitorBkv.go
suggestion	For better maintainability, consider separating the large monitorBkv.go file into smaller files, each focusing on a specific aspect of functionality (e.g., request monitoring, response monitoring, utility functions). This modular approach can make the codebase easier to navigate and maintain. [medium]
relevant line	package proxy

---

[AlexStocks]

@CodiumAI-Agent /improve

[CodiumAI-Agent]

Failed to generate code suggestions for PR