在 Go 中，一个 channel 默认只能被一个 goroutine 接收，无法直接“广播”给多个监听者；要实现事件同时通知多个处理协程，需借助 fan-out 模式——通过中间 goroutine 将消息复制并分发到多个独立 consumer channel。
Go 的 channel 是点对点通信原语，不具备内置广播能力。当你将同一个 incoming chan Event 同时用于 processEmail 和 processPagerDuty 的 <-incoming 操作时，Go 运行时会随机选择一个就绪的接收方（基于调度器状态），因此你观察到“只有第一个 goroutine 收到事件”——这并非 bug，而是 channel 语义的必然行为。
要让多个处理器同时收到同一事件，必须显式实现“消息复制”。推荐采用 fan-out（扇出）模式：由一个中央分发 goroutine 从源 channel 读取事件，并逐个发送副本到多个专用 consumer channel。以下是针对你原始代码的重构方案：
type Event struct {
Host string
Command string
Output string
}
var (
incoming = make(chan Event) // 原始输入通道（生产者写入）
emailCh = make(chan Event, 10) // 邮件处理器专用通道（带缓冲防阻塞）
pdCh = make(chan Event, 10) // PagerDuty 处理器专用通道
)
// 【关键】广播分发器：将每个事件复制并推送到所有 consumer channel
func broadcast() {
for e := range incoming {
// 发送副本到各处理器通道（非阻塞发送，依赖缓冲区）
select {
case emailCh <- e:
default:
// 可选：记录丢弃日志（若邮箱通道满）
}
select {
case pdCh <- e:
default:
// 可选：记录丢弃日志（若 PD 通道满）
}
}
}
func processEmail(ticker *time.Ticker) {
for {
select {
case t := <-ticker.C:
fmt.Println("Email Tick at", t)
case e := <-emailCh: // 改为监听专用通道
fmt.Println("EMAIL GOT AN EVENT!")
fmt.Println(e)
}
}
}
func processPagerDuty(ticker *time.Ticker) {
for {
select {
case t := <-ticker.C:
fmt.Println("Pagerduty Tick at", t)
case e := <-pdCh: // 改为监听专用通道
fmt.Println("PAGERDUTY GOT AN EVENT!")
fmt.Println(e)
}
}
}
func main() {
// 启动广播器（必须在任何处理器前启动）
go broadcast()
ticker1 := time.NewTicker(10 * time.Second)
go processEmail(ticker1)
ticker2 := time.NewTicker(1 * time.Second)
go processPagerDuty(ticker2)
// HTTP 事件入口保持不变（仍写入 incoming）
http.HandleFunc("/event", func(w http.ResponseWriter, r *http.Request) {
e := Event{Host: "web01-east.domain.com", Command: "foo", Output: "bar"}
incoming <- e // 所有监听者将通过广播器间接收到
w.WriteHeader(http.StatusOK)
})
http.ListenAndServe(":8080", nil)
}✅ 关键设计要点说明：
- 解耦生产与消费：incoming 仅作为统一入口，emailCh/pdCh 各自隔离，避免竞争和阻塞传递。
- 缓冲通道防死锁：为 emailCh 和 pdCh 设置合理缓冲（如 make(chan Event, 10)），防止某处理器暂时卡住导致整个系统停滞。
- 广播器健壮性：使用 select { case ch <- e: default: } 实现非阻塞发送，避免因某个 consumer channel 满而阻塞其他分发。
- 生命周期管理：若需优雅关闭，可引入 context.Context 控制 broadcast() 和各处理器的退出。
⚠️ 不推荐的替代方案提醒：
- ❌ 直接用 close(incoming) + for range：无法实现“广播”，仍为单次消费。
- ❌ 使用 sync.Map 或全局 slice + mutex：破坏 channel 的并发安全抽象，增加复杂度且易出错。
- ❌ 无缓冲 channel + select 多 case：本质仍是竞态选择，非真正广播。
总结：Go 中的“一源多收”必须主动实现消息复制。broadcast() goroutine 是轻量、清晰且符合 Go 并发哲学的标准解法——它将复杂的分发逻辑封装起来，让业务处理器专注自身逻辑，是构建可扩展事件驱动系统的基石模式。
