Go 的并发模型的一些问题

• 資深大佬 : 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 经验