V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 7 页 / 共 66 页
回复总数  1308
1 ... 3  4  5  6  7  8  9  10  11  12 ... 66  
103 天前
回复了 IIInsomnia 创建的主题 Go 编程语言 从 0 到 1 手撸一个协程池
按照协程是否常驻,目前主要分两大类:

### 一、idle 协程常驻
1. ants ,好象是常驻协程 cond_t 方式实现
2. 常驻协程+chan 的多种方式

goroutine 比较轻量,runtime 自己就有协程复用相关的,所以每次 go 创建新协程其实成本不大,所以常驻协程未必就是好事情,反倒是常驻协程额外的 chan 或者 cond_t 会有相对一点性能损失以及常驻的内存开销
我和一些小伙伴对各种协程池做压测,想比喻非常驻协程的方案,ants 并不具有性能优势

### 二、idle 协程不常驻
1. 字节的 gopool 这种:协程数量控制+任务队列的方式。当前协程数量没有达到最大则新任务直接创建协程执行,每个协程执行完当前也都会检查队列里是否有新的任务、如果有继续取出任务执行、否则协程退出。如果当前协程数量达到最大值就加入队列等待被执行。字节 gopool 的队列用的 list ,其他实现也有复用 slice 的

goppol 避免了常驻协程的内存开销,协程用完就归还给 runtime ,清爽轻量,没有额外的 chan 、cond_t 之类的操作的损失、性能好,但缺点是 gopool 这种实现的队列,再并发任务数量巨大、任务执行较慢时,会导致队列 size 爆炸性增长,没办法像 chan 那样自然限流去实现系统平衡

2. nbio 的协程池,协类似 gopool 但队列替换成了一个常驻协程+chan 。任务协程数量没达到最大值时新任务直接创建新协程执行、否则加到 chan 队列里,只有一个常驻协程+chan 做队列可以实现自然限流( chan 满了阻塞、自动反馈给调用方)。任务协程用完就还给 runtime ,1 个常驻协程成本也很低,也弥补了 gopool 那种限流缺陷,比较平衡。
105 天前
回复了 FanyFull 创建的主题 生活 三万六千块人民币的房子能住吗?
@Hookery 评论符合 ID, sixsixsix
108 天前
回复了 eachann 创建的主题 Apple m4 mini 连夜装完后索然无味
贤者时间是这样的
学学怎么"扣"吧
先把价格打下来
116 天前
回复了 sbldehanhan 创建的主题 MacBook Pro M4 mbp 硬盘选 512G 还是 1T?
64G 1T 起步, 可以战 5 年
16G/512G 明年又想换 ( 明年是指 2 个月后, 甚至更短时间后 )
@lasuar Can't agree more!
如果不用 orm, 可以试试我这个 github.com/lesismal/sqlw
拉满更香
118 天前
回复了 brader 创建的主题 程序员 现在有部分前端真的水到家了
OP 可以好好修行下技术跳槽到好点的公司, 然后就可以较大程度避免这种队友了
这个度数不高, 如果年纪不是过大晶状体弹性太差, 可以趁早上欧欧眼保仪, 七八成的机会能把近视治好, 但一定要坚持使用它锻炼睫状肌, 坚持用, 效果挺好的.
个体差异, 不一定对每个人都有效, 价格小贵, 好像也有租的服务, ,如果不放心, 可以先看看他们介绍的原理再做决定. 用机器的好处是相比于自己看训练的视频或者自己锻炼那些能屏蔽不少干扰, 效果更好更专业, 但如果你有足够的耐心坚持自己自然训练法之类的, 不用机器也可以的
付费的课程多数都还可以, 免费的那些省钱费时间效果没多好
这么多人说行, 听得我都心动了
128 天前
回复了 momowei 创建的主题 Go 编程语言 go 的内存优势在部分场景比想象中多
@james122333 如果有兴趣, #109 里的链接 "2022 Go 生态圈 rpc 框架 Benchmark" 这个帖子的性能对比可以看下, 性能强的基础上, 功能也比其他的 rpc 更丰富, 场景支撑能力更强, 扩展性也极强, codec, 中间件, 协议编解码都可以扩展. star 不如他们多不代表库没有他们好, 写得晚, 而且我个人没有大厂团队那么大的能量去推广罢了
128 天前
回复了 momowei 创建的主题 Go 编程语言 go 的内存优势在部分场景比想象中多
@james122333 #144

> 看了看它就不只是个 rpc... 是长连线 也可以做完断线 呼叫满满的 http style 拿来当 http server 也无不可 不应该以 rpc 为名

大多数人对网络交互都局限在 web 相关那一套了, web 的人最多, 命名 arpc 一是为了讨好社区, 因为其他领域的受众太少了, 二是, rpc 也确实是一个大的功能项, rpc 也是 arpc 的主力功能之一而且把 arpc 用作 rpc 只比其他的 rpc 强(单说 golang, 其他语言我没那么多精力去实现和维护)

按 rpc 的定义, http 本身也是一种 rpc, 所以 http style 这种说法不准确, 至于拿来当 http server, http 做静态资源服务的话肯定是不适合用 rpc 来做, 至于 api, 确实可以用 rpc 替代, arpc 支持这么做的

最重要的是, 更广阔的场景, 其他 rpc 很难支持, 比如做 IM, 游戏, 推送服务, 用其他的 rpc 就不那么适合了, grpc 的 stream 一定程度上可以做一些, 但是 grpc 使用起来太麻烦了而且也局限, 远不如 arpc 灵活

网络交互, 就像我在 arpc readme 里写的, 主要就是 req-res(请求+响应), notify/push 不需要相应, 两个方向 client -> server 和 server -> client, arpc 都支持, 更多的业务场景, 一套全搞定. 不需要很多项目需要 server 推送那样再单开一个 ws 来做, arpc 当 rpc+server push 随便弄
泡茶, 即热饮水机出的所谓 100, 跟烧开的水对比下就知道了. 烧开的那才是真的 100
@cskeleton #39 监管, 合规, 就可以了, 否则即使有多套系统, 人家不告诉你, 你也没办法. 重要的是合法合规, 他们是国家队, 先不论过往股市如何, 单说正常流程上, 这些事应该由监管和合规这些来把控, 而不是你我在这猜测别人怎么搞就会被告不公平. 还是那个观点, 你先想想清楚为什么节前卡单那么多没被告再讨论吧
128 天前
回复了 momowei 创建的主题 Go 编程语言 go 的内存优势在部分场景比想象中多
@james122333 #140

标准库 rpc 对于多数人可能足够用了, 性能上虽然没有什么额外的优化例如 pool 或网络的优化, 但也比很多垃圾框架要强了

另外, 你可能把 arpc 想简单了, arpc 是通用网络框架, rpc 只是一个功能罢了, 比标准库 rpc 丰富多了, 性能也更强

而且, 标准库 rpc 可能还是需要有一些额外的坑需要处理的, 我没做测试只是基于简单扫了下标准库 rpc 代码的猜测, 不一定准确: 比如最基本的例如 timeout/context 好像是不支持, 如果只用普通默认参数没有设置 TCP Keepalive, 赶上 server 设备意外掉电或者维护重启没有 TCP EOF 则 client 的 Call 就可能死等着阻塞了, 自己做一些额外的封装也不麻烦, 只是如果这样子, 还不如别人都支持了的方便
当然, 只要满足你们的需求足够用就可以了
1 ... 3  4  5  6  7  8  9  10  11  12 ... 66  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1352 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 94ms · UTC 23:52 · PVG 07:52 · LAX 15:52 · JFK 18:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.