用了 channel，异步处理可以完美代替 ConcurrentQueue和信号量了
但channel底层是什么原理呢？也是 基于ConcurrentQueue和信号量的吗？
--
FROM 223.72.109.*

channel使用场景，有的时候可以用tpl dataflow或reactivex替代

【 在 feed 的大作中提到: 】
: 用了 channel，异步处理可以完美代替 ConcurrentQueue和信号量了
: 但channel底层是什么原理呢？也是 基于ConcurrentQueue和信号量的吗？
--
FROM 114.246.171.*

比如写个微服务，很多request 进来，每个都要访问数据库
不能建立这么多链接访问数据库吧？
那就通过 mq 进行异步化
我们是比较重量级的应用会使用专门的 mq
轻量级的应用就用 memory queue，多线程对其读写。这时候就知道 channel省下了多少事情了。
这都是很常见的应用场景呀，你们没遇到过？

【 在 moneybox 的大作中提到: 】
: 楼主能不能举个通俗易懂的，什么时候需要用channel的例子...
:
--
修改:feed FROM 223.72.108.*
FROM 223.72.108.*

你是指数据库的connectionPool吗？
我其实只是举个例子，数据库只是最常见的瓶颈之一
而在我们的微服务架构中，越来越限制对数据库的访问，甚至规划只有一个核心的微服务才能修改数据库
其他的要访问这个微服务

【 在 keygen 的大作中提到: 】
: 直接扔给 connectionPool，让它来管理排队
:
--
FROM 223.72.108.*

这个场景现在用我说的那俩的多，比pub sub模式好处在于，没有数据请求的时候可以节省至少一个线程，如果不使劲用task的话

【 在 feed 的大作中提到: 】
: 比如写个微服务，很多request 进来，每个都要访问数据库
: 不能建立这么多链接访问数据库吧？
: 那就通过 mq 进行异步化
: ...................
--
修改:leadu FROM 114.246.171.*
FROM 114.246.171.*