📚 课程目录第3章合规性检查的概念与重要性

3. 合规性检查的概念与重要性

做了这么多年性能优化，我发现一个挺有意思的现象：很多人一听到“合规性检查”，第一反应就是“哦，又是流程上的破事”。但实际上，合规性检查是卡顿排查的照妖镜。它能快速告诉你——当前的问题，到底是代码写错了，还是系统设计本身就违规了。

3.1 到底什么是合规性检查？

说白了就是一套规则。这套规则定义了“在什么情况下，你的访问行为是允许的”。比如Polling的频率上限、单次采集的数据量、并发连接数阈值、重试策略等等。

举个我实际遇到的例子：有一次线上告警说某服务响应变慢，我抓了堆栈一看，发现客户端的Polling线程每200ms就发一次请求。但服务端的限流规则是“每10秒最多30次”。这么一算，客户端每秒5次，完全踩在红线上了。这就属于典型的合规性违规——不是你写错了代码，是你没遵守接口调用契约。

核心定义：合规性检查是验证系统行为是否满足预定义的规则或服务等级协议（SLA）的过程。在Polling场景下，它主要检查频率、负载、超时、数据一致性这四个维度。

3.2 为什么合规性如此重要？两张表说清楚

我把合规性和非合规的差异做了一张对比表，看完你就明白为什么我每次做卡顿排查，第一件事就是先查合规性。

合规 vs 非合规行为对比
维度	合规行为	非合规行为
Polling频率	按服务端要求间隔（如 ≥1s）	无限制密集请求（如 10ms）
并发控制	单线程或限制并发连接数	开启数十个线程同时Poll
数据量	每次只拉取必要字段	一次拉取全量数据（几千条）
错误处理	指数退避 + 有限重试	失败后立即重试，无限重试
连接复用	使用HTTP连接池	每次新建TCP连接

看到了吧？非合规的行为几乎条条都会导致卡顿——资源耗尽、连接堆积、请求排队，哪一个都够你查半天。

3.3 合规性检查在卡顿排查中的定位

我习惯把卡顿原因分成三层：代码层、架构层、合规层。其中合规层是最容易被忽略的一层，但往往也是最容易定位的一层。你想想看，如果连规则都不符合，那代码调得再优雅也没用。

我曾经踩过的坑：有次排查Nginx大量499超时，折腾了一周，重写了业务代码、优化了SQL，还是没解决。最后发现是客户端的Polling请求没有带，网关直接把请求丢掉并返回401。客户端的异常处理又把401当作正常响应继续轮询，导致无限重试。这根本不是性能问题，是合规性断裂——请求连准入层都过不去。

3.4 合规性检查的清单（我平时用的）

下面这个清单是我在项目里积累下来的，每次接入新的Polling场景我都会过一遍。建议你可以直接拿去用。

频率合规：服务端是否有明确的间隔要求？如果没有，我自己定一个安全值（一般最低1秒）。
数据量合规：单次返回的数据是不是分页的？如果接口没有分页，那一定要问清楚最大返回条数。
连接数合规：同一时刻最多允许多少个连接？多线程Polling时尤其要注意。
错误码合规：哪些HTTP状态码需要重试？哪些应该停止？比如429（限流）和503（服务不可用）的处理策略完全不同。
认证合规：每次请求是否携带了正确的/？有没有有效期检查？

小窍门：把上述检查点写成单元测试，部署到CI/CD流水线中。我团队现在就是这么干的——每次代码变更，第一轮跑的就是合规性检查，跑不过直接阻塞发布。这比上线后再根因分析快得多。

3.5 知识体系一览

为了让你更直观的理解整个章节的脉络，我画了一张结构图。它把合规性检查拆成了规则定义、检查执行、结果分析、修复闭环四个环节，并标注了与卡顿的直接关联。

3.6 落到代码：一个简单的合规性检查器

理论说完了，我写个Python片段，演示怎么在Polling请求前做一次合规检查。这段代码可以直接集成到你的SDK中。

class PollingComplianceChecker:
    """
    简单的合规性检查器，用于拦截不合规的Polling请求。
    """
    def __init__(self, min_interval=1.0, max_concurrent=1):
        self.min_interval = min_interval  # 秒
        self.max_concurrent = max_concurrent
        self._last_request_time = 0
        self._active_requests = 0
        self._lock = threading.Lock()

    def check(self) -> bool:
        with self._lock:
            now = time.time()
            if now - self._last_request_time < self.min_interval:
                return False  # 频率违规
            if self._active_requests >= self.max_concurrent:
                return False  # 并发违规
            return True

    def enter(self):
        with self._lock:
            self._active_requests += 1
            self._last_request_time = time.time()

    def exit(self):
        with self._lock:
            self._active_requests -= 1

# 使用示例
checker = PollingComplianceChecker(min_interval=0.5, max_concurrent=2)
if not checker.check():
    logger.warning("合规性检查未通过，本次Polling请求被跳过")
    # 可以在此处添加降级策略，比如改用长轮询
else:
    checker.enter()
    try:
        response = requests.get(url)
    finally:
        checker.exit()

经验之谈：上面这个类我用了好几年，但后来发现一个bug——多进程场景下锁不生效。所以在分布式系统中，建议把last_request_time存到Redis里做原子检查。另外，max_concurrent最好也通过服务端动态下发，别写死。

3.7 总结一下

合规性检查不是什么玄学，它就是一套预先约定的游戏规则。你做卡顿排查的时候，先从规则入手，比瞎看代码快十倍。记住：卡顿不一定是你代码写得差，有时候只是因为你的请求“不守规矩”。