当前在线人数14218
首页 - 分类讨论区 - 电脑网络 - 葵花宝典版 - 同主题阅读文章
未名交友
[更多]
[更多]
[bssd] Go 的大并发处理网络碰到两个个问题
[版面:葵花宝典][首篇作者:SSA] , 2017年12月05日20:55:40 ,1201次阅读,47次回复
来APP回复,赚取更多伪币 关注本站公众号:
[首页] [上页][下页][末页] [分页:1 2 3 ]
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 1 ]

发信人: SSA (草虫), 信区: Programming
标  题: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Tue Dec  5 20:55:40 2017, 美东)

理论上用 goroutine 来替代 thread,
用 channel 协助调度是比较干净的一个模型。

但是实际中发现,如果每个 tcp 连接都是一个
goroutine 来处理,如果同时很多个 tcp 连接
同时并发发送数据,很容易就出现 tcp connection
reset。

google 了一下,发现有其他人抱怨类似的问题。
解决办法是用什么work pool 之类的限制并发
同时发送的数量。如果这么搞反而就比较麻烦了,
因为 goroutine 本来就是隔离了和 thread
这些打交道,用 work pool 这些其实就是变相
用 thread 来调度。隔靴挠痒的感觉。

求指点。

另外一个发现的问题是,go 貌似不能直接用 raw
data。从网络来到数据包需要经过 decode 过程
才能包裹到 go 的 struct。这个过程需要一个一个
byte shift 到其他类型的type 里面去。不知道
有没有其他好点办法.反正用 native go 貌似没
有好办法的,因为要 box go 的类型。低带宽的数据
可以这么搞,高带宽的数据这么过一下手会浪费一些
CPU。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
silverhawk
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 2 ]

发信人: silverhawk (silverhawk), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 02:52:02 2017, 美东)

raw data应该有很成熟的JSON unmarshall包了啊,不是太大问题,TCP connection
reset确定是跟连接数有关吗?还是timeout,还是其他原因?理论上TCP连接和go
channel完全是独立事件,除非你哪里channel block了?
【 在 SSA (草虫) 的大作中提到: 】
: 理论上用 goroutine 来替代 thread,
: 用 channel 协助调度是比较干净的一个模型。
: 但是实际中发现,如果每个 tcp 连接都是一个
: goroutine 来处理,如果同时很多个 tcp 连接
: 同时并发发送数据,很容易就出现 tcp connection
: reset。
: google 了一下,发现有其他人抱怨类似的问题。
: 解决办法是用什么work pool 之类的限制并发
: 同时发送的数量。如果这么搞反而就比较麻烦了,
: 因为 goroutine 本来就是隔离了和 thread
: ...................



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 3 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 03:37:01 2017, 美东)

我没有解释清楚,raw data 经过打包是可以用的,但是打包
过程需要 copy 一次数据。这个看看https://golang.org/src/encoding/binary/
binary.go
这个貌似是最接近的了,里面要根据接受方的类型一个 byte 一个
byte 来拼凑数据。

tcp reset 这个这个问题直观上是并发的网络数目相关的。
这里用到的网络比较类似群讨论,server 上面挂一大堆 client。
server收到一个 message 就直接 forward 给一大堆 client。
不是 time out,直接 tcp reset 那个 connection 断了。

Anyway,google 看了一下,很多其他地方有提到,对于高并发这
些直接用 goroutine 来处理每个 tcp 连接是不合适的。
例如这里他们的解决办法是抛弃 goroutine 用 work pool:

http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

goroutine 这个愿望是美好的,可惜现实是残酷的。

【 在 silverhawk (silverhawk) 的大作中提到: 】
: raw data应该有很成熟的JSON unmarshall包了啊,不是太大问题,TCP connection
: reset确定是跟连接数有关吗?还是timeout,还是其他原因?理论上TCP连接和go
: channel完全是独立事件,除非你哪里channel block了?


--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
walkrandom
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 4 ]

发信人: walkrandom (walkrandom), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 07:37:04 2017, 美东)


不知道你怎么实现的,不好说。
每个client对应的是server上的一个channel。
如果reset太快,把channel改成buffered的channel可能好点。
有时候是资源耗尽了,disk IO,network IO,memory,etc
这时候要加semaphore控制并发。
你可以把The Go Programming Language 里面的chatroom编译一遍,看看能有多少并发。


【 在 SSA (草虫) 的大作中提到: 】
: 我没有解释清楚,raw data 经过打包是可以用的,但是打包
: 过程需要 copy 一次数据。这个看看https://golang.org/src/encoding/binary/
: binary.go
: 这个貌似是最接近的了,里面要根据接受方的类型一个 byte 一个
: byte 来拼凑数据。
: tcp reset 这个这个问题直观上是并发的网络数目相关的。
: 这里用到的网络比较类似群讨论,server 上面挂一大堆 client。
: server收到一个 message 就直接 forward 给一大堆 client。
: 不是 time out,直接 tcp reset 那个 connection 断了。
: Anyway,google 看了一下,很多其他地方有提到,对于高并发这
: ...................



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 74.]

 
wdong
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 5 ]

发信人: wdong (万事休), 信区: Programming
标  题:  Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 07:39:17 2017, 美东)

是bug吧。如果是go的bug, 修好了可是大credit。不过我觉得是楼主参数没设好,资源
用光了。

【在  SSA(草虫)的大作中提到:】
:理论上用 goroutine 来替代 thread,
:用 channel 协助调度是比较干净的一个模型。


--
※ 修改:·wdong 於 Dec  6 07:42:25 2017 修改本文·[FROM: 2602:306:cd3c:8a]
※ 来源:·Android 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 108.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 6 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 08:22:58 2017, 美东)

channel 不是问题,每个 tcp socket 要对应一个 goroutine。
因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
来 block。感觉这个 goroutine 对应一个 socket 是不能上
大并发的。

network IO 是不可能耗尽的,就是 blocking 慢而以。
内存应该还好。

【 在 walkrandom (walkrandom) 的大作中提到: 】
: 不知道你怎么实现的,不好说。
: 每个client对应的是server上的一个channel。
: 如果reset太快,把channel改成buffered的channel可能好点。
: 有时候是资源耗尽了,disk IO,network IO,memory,etc
: 这时候要加semaphore控制并发。
: 你可以把The Go Programming Language 里面的chatroom编译一遍,看看能有多少并
发。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 7 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re:  Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 08:29:48 2017, 美东)

内存还是大大的有。其他还能有什么资源。
感觉是 go 的编程模式的问题。
比较正规的解法是用 epoll 这种 call back 的方式来处理的。
go 用那个 non blocking mode IO 和goroutine 在即将要
block 的时候才去换goroutine。这种方式上不了比较大规模。

anyway。 网上看来有不少分享都是要上大并发要去掉 goroutine。
这个我感觉应该是 go 本身编程模式的问题。go 自己的 scheduler
并不适合干大并发。你想想每个 goroutine 都有自己的context
内存。连接多了这个很费的。

【 在 wdong (万事休) 的大作中提到: 】
: 是bug吧。如果是go的bug, 修好了可是大credit。不过我觉得是楼主参数没设好,资源
: 用光了。
: :理论上用 goroutine 来替代 thread,
: :用 channel 协助调度是比较干净的一个模型。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
walkrandom
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 8 ]

发信人: walkrandom (walkrandom), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 09:36:11 2017, 美东)

哦,我大概知道原因了。
你可能把server对client的读和写放到一个goroutine了,造成blocking。
每个client应该对应server上面两个goroutine,一个读,一个写。
这样server上minimal goroutine number应该是2*N + 2
N是client的数目。
还要有个main goroutine和一个scheduler。
goroutine很便宜,一个只要2KB内存,多开几个无妨。


【 在 SSA (草虫) 的大作中提到: 】
: channel 不是问题,每个 tcp socket 要对应一个 goroutine。
: 因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
: 来 block。感觉这个 goroutine 对应一个 socket 是不能上
: 大并发的。
: network IO 是不可能耗尽的,就是 blocking 慢而以。
: 内存应该还好。
: 发。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 140.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 9 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 10:29:21 2017, 美东)


【 在 walkrandom (walkrandom) 的大作中提到: 】
: 哦,我大概知道原因了。
: 你可能把server对client的读和写放到一个goroutine了,造成blocking。
: 每个client应该对应server上面两个goroutine,一个读,一个写。

我 double check 了一下,已经是读和写分别一个 goroutine 了。
所以不是这个问题。

: 这样server上minimal goroutine number应该是2*N + 2
: N是client的数目。
: 还要有个main goroutine和一个scheduler。
: goroutine很便宜,一个只要2KB内存,多开几个无妨。

多开几个无妨,我也是这么想的。但是实际情况不是这样。
我感觉上是多开了 goroutine 会影响schedule 到那个
tcp socket 的相应时间。或者有什么其他的bug。

在了解到一些 goroutine 的内部实现细节以后,例如是
基于 non blocking io 这些。 我越来越觉得这个 goroutine
对付简单情况可以,很多 goroutine 不太能 scale 的。

--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
wdong
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 10 ]

发信人: wdong (万事休), 信区: Programming
标  题:  Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 10:52:49 2017, 美东)

你这个情况,大并发,是go的核心竞争力。如果这都搞不定,还要go干嘛。如果只是几
千个thread, pthread就够了啊。

【在  SSA(草虫)的大作中提到:】

:【 在 walkrandom (walkrandom) 的大作中提到: 】


--
※ 修改:·wdong 於 Dec  6 10:53:13 2017 修改本文·[FROM: 198.]
※ 来源:·Android 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 198.]

 
walkrandom
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 11 ]

发信人: walkrandom (walkrandom), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 10:57:56 2017, 美东)

那server上面,有多少个channel?
如果少于client的数目,也可能造成堵塞。

【 在 SSA (草虫) 的大作中提到: 】
: 我 double check 了一下,已经是读和写分别一个 goroutine 了。
: 所以不是这个问题。
: 多开几个无妨,我也是这么想的。但是实际情况不是这样。
: 我感觉上是多开了 goroutine 会影响schedule 到那个
: tcp socket 的相应时间。或者有什么其他的bug。
: 在了解到一些 goroutine 的内部实现细节以后,例如是
: 基于 non blocking io 这些。 我越来越觉得这个 goroutine
: 对付简单情况可以,很多 goroutine 不太能 scale 的。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 140.]

 
LeftShark
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 12 ]

发信人: LeftShark (Left Shark), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 13:16:26 2017, 美东)

题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔?
就算是你
们看不上的java+thread,拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
个K的qps?几十个K?又换句话说你都几十个K的在线业务量级了,公司起码也是若干B
的市值了吧,你拿go折腾来折腾去一年能省多少几块钱下来。

说白了就是钻技术不要太深,还是要最终outcome/impact为主导。

话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server,结果问题一大堆,
跟公司其他Java为主的后端工程开发格格不入,怨声载道。



--
※ 修改:·LeftShark 於 Dec  6 13:17:26 2017 修改本文·[FROM: 2620:0:1000:fd86]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2620:0:1000:fd8]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 13 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 13:46:53 2017, 美东)

你们公司写go rpc替代java的不是为了装逼。
是为了取代java的人,自己往上走。竞争是血腥残酷的。不出问题是不可能的。
不怨声载道也是不可能的。

后端新人要上位,靠java是不可能的。这不是技术问题。技术业务政治一起卡
位的老师傅多的是。

【 在 LeftShark (Left Shark) 的大作中提到: 】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔?
: 就算是你
: 们看不上的java+thread,拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps?几十个K?又换句话说你都几十个K的在线业务量级了,公司起码也是若干
B
: 的市值了吧,你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深,还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server,结果问题一大堆,
: 跟公司其他Java为主的后端工程开发格格不入,怨声载道。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 192.]

 
walkrandom
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 14 ]

发信人: walkrandom (walkrandom), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 14:20:07 2017, 美东)


一台server上,如果用docker container,java大概比go多两百兆。十个container,
就是2G。
看公司规模,大概几千台server就可以省出一个程序员的工资了。

【 在 LeftShark (Left Shark) 的大作中提到: 】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔?
: 就算是你
: 们看不上的java+thread,拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps?几十个K?又换句话说你都几十个K的在线业务量级了,公司起码也是若干
B
: 的市值了吧,你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深,还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server,结果问题一大堆,
: 跟公司其他Java为主的后端工程开发格格不入,怨声载道。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 140.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 15 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 14:25:41 2017, 美东)

You can always assume and explain some application scenarios to defend any
opinions and that was the art of business.

Overall, I think Golang would be unstoppable because Rob Pike
and google had already built these fake/true application user cases for you.
Who was still doing same things for Java? Oracle?

【 在 walkrandom (walkrandom) 的大作中提到: 】
: 一台server上,如果用docker container,java大概比go多两百兆。十个container,
: 就是2G。
: 看公司规模,大概几千台server就可以省出一个程序员的工资了。
: B




--
※ 修改:·guvest 於 Dec  6 14:26:34 2017 修改本文·[FROM: 192.]
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 192.]

 
LeftShark
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 16 ]

发信人: LeftShark (Left Shark), 信区: Programming
标  题: Re:  Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 15:54:55 2017, 美东)

几千的container你这是Million/sec级别的业务吞吐吧,公司得有成百上千程序员吧,
省下来那点点远不能成为你justify language层面的决策

【在  walkrandom(walkrandom)的大作中提到:】

:一台server上,如果用docker container,java大概比go多两百兆。十个container,

--
※ 来源:·Android 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2607:fb90:4a4:6]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 17 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re:  Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 21:26:55 2017, 美东)



【 在 wdong (万事休) 的大作中提到: 】
: 你这个情况,大并发,是go的核心竞争力。如果这都搞不定,还要go干嘛。如果只是几
: 千个thread, pthread就够了啊。

你去看看我前面引用的文章讨论了这个问题而且给出了
解决办法。

http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

简单的说,就是不能用简单的goroutine 对应一个 tcp
socket 的方法。需要搞 server pool 这些。避免
太多 goroutine 来处理并发。

不是说 go 不能搞,是不能简单粗暴用 goroutine 和
tcp connection 对应的阻塞方式指望 go 的 scheduler
能解决大并发问题。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 18 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 21:28:58 2017, 美东)

channel 绝对没有少于 client 数目,可能是几倍,
至少两倍以上,一个读一个写,还有其他的我没有仔细数。
最开始写这个的哥们完全是按照 go 的精神来写的。

【 在 walkrandom (walkrandom) 的大作中提到: 】
: 那server上面,有多少个channel?
: 如果少于client的数目,也可能造成堵塞。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 19 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 21:36:20 2017, 美东)

这个我们的确有这个需求,至少要 demo 能够处理这样的流量。
如果是我一个人写和维护就直接 C + epoll 橹了,而且保证是最优化的。

这个 go 的头不是我开的,但是也不是完全没有解就是了。
其实说白了就是放弃 goroutine N:1 tcp 的对应关系。
然后把 go 当 C 写,自己处理 server pool,epoll 这些。
网上有人讨论这个基本上是这个结果。

java 就算了吧。我这个不是典型的 web 后段应用,
有其他考虑,java 基本上不考虑了。

【 在 LeftShark (Left Shark) 的大作中提到: 】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔?
: 就算是你
: 们看不上的java+thread,拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps?几十个K?又换句话说你都几十个K的在线业务量级了,公司起码也是若干
B
: 的市值了吧,你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深,还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server,结果问题一大堆,
: 跟公司其他Java为主的后端工程开发格格不入,怨声载道。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

 
SSA
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 20 ]

发信人: SSA (草虫), 信区: Programming
标  题: Re: [bssd] Go 的大并发处理网络碰到两个个问题
发信站: BBS 未名空间站 (Wed Dec  6 21:41:52 2017, 美东)

这个项目 java 是不太能用的,有其他的考虑。
如果是我自己写最爱是 C,这个我很精通。
但是如果不能用 C 的话,go 大概是最接近的一个了。
其他相关的人和项目有用 go 的话,对我来说
是可以接受的选择。

Anyway, 讨论 go vs java 这个非技术层面的
东西大概不会有什么结果。

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: You can always assume and explain some application scenarios to defend any
: opinions and that was the art of business.
: Overall, I think Golang would be unstoppable because Rob Pike
: and google had already built these fake/true application user cases for
you.
:  Who was still doing same things for Java? Oracle?



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 24.]

[首页] [上页][下页][末页] [分页:1 2 3 ]
[快速返回] [ 进入葵花宝典讨论区] [返回顶部]
回复文章
标题:
内 容:

未名交友
将您的链接放在这儿

友情链接


 

Site Map - Contact Us - Terms and Conditions - Privacy Policy

版权所有,未名空间(mitbbs.com),since 1996