Go 的并发模型的一些问题

[bushenx]

最近在优化业务上的一块功能，现阶段这个功能会对用户的每个请求新建一个协程处理，但是个人感觉这样无节制的使用协程有些不妥。想在这上面优化一下，比如限制用户新建协程的数量。有这个想法但是具体实现应该如何做？有什么书籍或者文章介绍类似这样协程并发模型的，可以推荐学习一下吗？

[pythonnoob]

直接用消息队列削谷平峰，或者用令牌桶限制数量

[bushenx]

@pythonnoob 令牌桶有使用，但是想在协程创建的地方也控制一下协程的并发数量，可以给支个招或者有什么别的渠道学习一下吗？

[matrix67]

用户的每个请求当一个任务，丢到队列里面去，然后 go 开 worker 去解决任务。

[bushenx]

@matrix67 当时是想到这个方法，但是如果用户接入量很多，队列是不是需要一个全局锁去保护，这样感觉有失性能。

[bushenx]

我想能不能有什么并发模型能限制每个用户起协程的数量，但是又不会因为同步而损失太多性能。

[rrfeng]

千万级 goroutine 没什么问题。
延时敏感的也不会用 go 吧。

[namaketa]

一切性能问题都要问问自己为什么不能提配置 /加机器解决呢。
协程调度开销已经很低了，特别对于重 io 任务。
建议跑跑 benchmark 自己看调度耗时占比，再去判断要不要优化。
golang 管道性能确实比较一般，可以多开几个管道。
如果你真的有千万级别 /低时延 /重计算的任务，放过 go 吧。

[faker1]

1 楼的感觉可以， 实在想做感觉 可以参考 go 自己的任务调度， 锁的粒度放细， （全局，局部）类似分 group , 感觉这个是过度搞的，好像

[ginjedoad]

使用协程池就好了。

[ginjedoad]

比如这位同学写的稍微复杂了点。但是对于协程的限制数量级限制的同时，整体性能不升反降。https://github.com/panjf2000/ants

“单机上百万上千万的同步批量任务处理现实意义不大，但是在异步批量任务处理方面有很大的应用价值，所以我个人觉得，Goroutine Pool 真正的价值还是在：

限制并发的 goroutine 数量；
复用 goroutine，减轻 runtime 调度压力，提升程序性能；
规避过多的 goroutine 侵占系统资源（ CPU&内存）。”

[sujin190]

在线程外设计协程本来就是为了干这个的啊，每个请求一个协程，你们倒好，居然还怕协程创建太多，真是服了

[sujin190]

之前做锁服务的时候测试过，每个请求一个协程，十万级 rps 并没有啥问题，想要更高确实需要协程复用，但这个过程必须是无锁的，无锁协程池并不是每个场景都能有的，web 这种真没啥必要

[bushenx]

或许是我的表述不够明确，业务背景是服务会处理所有用户的请求，假设某个用户在某时间段请求数量剧增，这就导致会创建很多协程，而很多的协程会影响其他用户创建的协程。我是想减轻单个用户对所有用户的影响，所以限制协程数量。

[scnace]

你自己做个 benchmark 就知道了啊， 反正楼上的人说了你也不敢直接就这么干吧。。实在不行就上 goroutine pool 呗。。

[zxCoder]

歪个楼问一句，要看懂楼上大佬们所讨论的东西，大概要几年的工作 /golang 经验

[pythonnoob]

@bushenx 加机器。除非到了加机器也解决不了的情况否则别做这种优化。

[pythonnoob]

协程的调度器是无数大牛做出来的，一般人做所谓的优化很多时候会适得其反。请求激增的情况应该首先考虑加机器、前端或反代限流这些极其轻松的手段。

[pythonnoob]

除非是 bat 、12306 这种体量，否则通过优化架构已经可以解决 99%的问题了

[bushenx]

@pythonnoob 我的问题楼上的老哥已经给出答案了，就是实现一个协程池。因为我的逻辑是根据用户的请求创建协程，这很可能会导致协程被无休止创建。但是协程池就可以很好解决这个问题。在同步任务下协程池确实是没有必要的，go 运行时会有逻辑复用 g，但是这异步任务下协程池就可以很好的控制协程数量。我这个需求应该不算是性能优化，是极端情况下的一种保护措施。