并发难 | 池里究竟该放多少线程？

blog 并发 思考

最近在项目里做了一个数据同步的功能。需要把两个数据库里的数据做同步，在业务不繁忙的时候跑一次，核对库里每一条数据，主要是为了保证数据最终一致，做的一个保底工作。之前项目里同步的代码是单线程的，我改成了基于线程池的，但是在上线前的一些问题却引起了我的思考。

现象

程序的代码还是比较简单的，大概类似下面：

// 两个参数分别为线程数量和总任务数
p := pool.NewPool(goroutineCount, len(userIds))
for _, userId := range userIds {
    p.Queue(func(job *pool.Job) {
        userId := job.Params()[0].(int64)
        tx, err := sess.Begin()
        if err != nil {
            panic(err)
        }
        defer tx.RollbackUnlessCommitted()
        if err := dao.SyncSingleUser(tx, userId); err != nil {
            panic(err)
        }
        if err := tx.Commit(); err != nil {
            panic(err)
        }
    }, userId)
}
errOccurs := false
for result := range p.Results() {
    if err, ok := result.(*pool.ErrRecovery); ok {
        glog.Errorln(err)
        errOccurs = true
    }
}
if errOccurs {
    return
}

为了确定线程的数量，我逐步增加线程数记录系统各项数值。下面是在一台 RMBP 上做的测试。

可以发现随着线程数增加，性能会逐步提高，但是当线程数提高到一定程度之后，性能不增反降（这部分数据没放）。如果继续增加线程数进行测试，会发现系统的某些性能指标会被耗尽，程序开始报错。

recovering from panic: dial tcp 127.0.0.1:3306: getsockopt: operation timed out

为什么会出现这种情况呢？在讨论这些问题之前，先回顾一下 goroutine 的设计与实现。

goroutine 设计

事实上，在 golang 中的 goroutine 已经不是传统意义上的线程了。传统的操作系统提供的线程在使用时有一些限制，超过一定数量之后会对性能造成影响。而 golang 提供的 goroutine 是一种 green thread。

Green thread 和 NodeJS 的异步回调方案有类似的地方，都在底层调用的系统的异步 IO 系统调用。

• 异步回调方案：所有 IO 操作的 API 都设计成异步回调形式，底层调用异步的系统调用（如epool、kqueue等）。同时，也可能提供同步版本的 IO 操作（如fs.readFileSync）
• Green thread 方案：所有 IO 操作底层实际上事异步调用，但是在语言中却表现的像一个同步调用。当 IO 操作需要等待时，语言的 runtime 自动调度系统级线程到另一个 Green thread 中。写代码的时候感觉好像是同步的，仿佛在同一个线程完成的，但实际上系统可能切换了线程，但程序对此无感。

由此可见，Green thread 在语言设计上比异步回调方案要略胜一筹，不会出现“冲击波”的现象（具体在 NodeJS 中如何避免“冲击波”代码可以看我这篇文章await & async 深度剖析），但在性能上实际是差不多的，都避免了大量使用操作系统级的线程带来的性能问题，同时又能充分的利用 CPU。

但是，今天我想谈的问题并不是 CPU 利用率／线程数量的问题，这个问题已经被上述两种设计方案比较完美的解决了。

CPU 以外的资源瓶颈

在实际中，更多遇到的是 cpu ／线程数量之外的资源瓶颈。比如锁、数据库链接、tcp链接。举个例子，假如做个爬虫应用，每个 goroutine 爬一个网页，golang 虽然号称百万级别的 goroutine ，但是你每个 goroutine 里面创建一个 tcp 链接，不到 5 万个 goroutine 就会把系统的 tcp 资源耗尽。

回到文章最上面的情况，在 goroutine 里调用了 dao.SyncSingleUser 函数，这个是一个数据库操作，不可避免的会有 socket 操作、硬盘操作。如果将所有数据库操作都无脑的放到 goroutine 中执行，当资源出现瓶颈之后，大量 goroutine 会阻塞或报错。

因此，我在项目里使用了一个 goroutine 池，来确保不会过多使用系统资源导致崩溃。那么问题来了，池里究竟该放多少线程？

又回到了最初使用系统线程时遇到的问题，不过这次导致问题的不再是线程资源，而是其他资源瓶颈（如 tcp、数据库链接 等）。这些资源比线程资源更加复杂，更加难以把控。更加难做 benchmark，也就更难找出一个通用的方法来解决实际场景的问题。

没有银弹

思考过后，我在网上开始搜索解决方案。发现这篇文章的作者和我做了类似的思考：《并发之痛 Thread，Goroutine，Actor》。作者最后得出 Actor 模型能解决一些问题（不过我才疏学浅至今不怎么理解 Actor 模型），但并发带来的问题还远远没到解决的程度。

革命尚未成功 同志任需努力

所以说，软件工程没有银弹，路漫漫其修远兮，吾将上下而求索。