基于Go标准库实现缓存系统：请求阻塞优化方案问询

问题背景 #

我用Go标准库net/http实现一套缓存系统，某个端点会解析请求中的key并通过isOK(key)函数验证：若验证不通过，会启动一个goroutine执行makeSureNowOK(key, endpoint)，确保后续请求的isOK(key)返回true。

当前简化实现代码如下：

func (ep *Endpoint) Handler() func(...) {
        for {           
            ep.mu.Lock()
            // WAITINGROOM //
            //lint:ignore SA2001 empty critical section
            ep.mu.Unlock()
            bytesBody, err := isOK(key)
            if err != nil {
                select {
                case <-ep.pause:
                    go makeSureNowOK(key)
                default:
                }
            } else {
                ...
                return
            }
        }
}


func makeSureNowOK(key string, ep ...) {

    ep.mu.Lock()
    
    ... do validation ..    
    ep.pause <- struct{}{}
    ep.mu.Unlock()

}

目前用“加锁后立即解锁”的方式实现等待逻辑，既不优雅也无意义；尝试过关闭通道放行goroutine，但重建通道繁琐；考虑过sync.WaitGroup，但存在Wait调用先于Add的问题，希望找到更优实现方案。

推荐方案：使用sync.Cond实现等待唤醒机制 #

sync.Cond是Go标准库专门用于协调多goroutine等待/唤醒的工具，语义清晰，完美匹配当前场景。

改造步骤 #

1. 扩展Endpoint结构体，添加sync.Cond字段（Cond需绑定互斥锁）：

type Endpoint struct {
    mu sync.Mutex
    cond *sync.Cond
    processingKeys map[string]bool // 标记key是否正在验证
    // 原有其他字段...
}

// 初始化Endpoint时创建Cond实例
func NewEndpoint() *Endpoint {
    ep := &Endpoint{
        processingKeys: make(map[string]bool),
    }
    ep.cond = sync.NewCond(&ep.mu)
    return ep
}

2. 改写Handler逻辑，用Cond.Wait()替代空锁等待：

func (ep *Endpoint) Handler() func(http.ResponseWriter, *http.Request) {
    return func(w http.ResponseWriter, r *http.Request) {
        key := parseKeyFromRequest(r) // 自定义解析key的逻辑
        
        for {
            ep.mu.Lock()
            bytesBody, err := isOK(key)
            ep.mu.Unlock()
            
            if err == nil {
                // 验证通过，返回响应
                w.Write(bytesBody)
                return
            }
            
            ep.mu.Lock()
            // 避免重复启动验证goroutine
            if !ep.processingKeys[key] {
                ep.processingKeys[key] = true
                go ep.makeSureNowOK(key)
            }
            ep.cond.Wait() // 阻塞等待验证完成的唤醒信号
            ep.mu.Unlock()
        }
    }
}

3. 修改makeSureNowOK，完成验证后唤醒所有等待的goroutine：

func (ep *Endpoint) makeSureNowOK(key string) {
    ep.mu.Lock()
    defer func() {
        delete(ep.processingKeys, key)
        ep.cond.Broadcast() // 唤醒所有等待该key的goroutine
        ep.mu.Unlock()
    }()
    
    // 执行验证逻辑，确保后续isOK(key)返回true
    // ... do validation ...
}

方案优势 #

• 语义直观：Wait()和Broadcast()直接对应“等待验证完成”和“通知所有等待者”的业务逻辑，代码可读性高。
• 避免重复工作：通过processingKeys标记，同一key同一时刻仅会启动一个验证goroutine。
• 性能高效：无需频繁创建/销毁通道，也没有空锁带来的无意义上下文切换。

备选方案：基于映射的专属通道通知机制 #

如果不想使用sync.Cond，可以通过映射管理每个key的专属通知通道，避免通道重复创建的问题。

实现步骤 #

1. 扩展Endpoint结构体：

type Endpoint struct {
    mu sync.Mutex
    keyNotifyChans map[string]chan struct{}
    // 原有其他字段...
}

func NewEndpoint() *Endpoint {
    return &Endpoint{
        keyNotifyChans: make(map[string]chan struct{}),
    }
}

2. 改写Handler逻辑：

func (ep *Endpoint) Handler() func(http.ResponseWriter, *http.Request) {
    return func(w http.ResponseWriter, r *http.Request) {
        key := parseKeyFromRequest(r)
        
        for {
            ep.mu.Lock()
            bytesBody, err := isOK(key)
            ep.mu.Unlock()
            
            if err == nil {
                w.Write(bytesBody)
                return
            }
            
            ep.mu.Lock()
            ch, exists := ep.keyNotifyChans[key]
            if !exists {
                ch = make(chan struct{})
                ep.keyNotifyChans[key] = ch
                go ep.makeSureNowOK(key, ch)
            }
            ep.mu.Unlock()
            
            <-ch // 等待验证完成的信号
        }
    }
}

3. 修改makeSureNowOK：

func (ep *Endpoint) makeSureNowOK(key string, ch chan struct{}) {
    // 执行验证逻辑
    // ... do validation ...
    
    ep.mu.Lock()
    close(ch) // 关闭通道，所有等待的goroutine都会被唤醒
    delete(ep.keyNotifyChans, key)
    ep.mu.Unlock()
}

这个方案通过映射为每个待验证的key分配唯一通道，验证完成后关闭通道实现批量通知，逻辑简洁且无冗余操作。

内容的提问来源于stack exchange，提问作者schlumpel