V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  pastor  ›  全部回复第 4 页 / 共 10 页
回复总数  199
1  2  3  4  5  6  7  8  9  10  
2022-08-05 17:00:58 +08:00
回复了 gowk 创建的主题 Go 编程语言 用 Go 写 Web 后端合适吗?
很多人怕是不知道某些大厂内部的 java 基础设施有多么让人作呕。
没错,我说的就是阿里之流
2022-08-05 16:59:40 +08:00
回复了 gowk 创建的主题 Go 编程语言 用 Go 写 Web 后端合适吗?
在新业务没有历史包袱、并且能够实现人力招聘的前提下,大厂都在拥抱 go ,只剩下半桶水程序员还在吵吵不适合
2022-08-05 16:56:29 +08:00
回复了 hhhhhh123 创建的主题 程序员 如何定义,初 中 高 级开发?
按一线薪资标准,简单:
初级:1w 以内
中级:1-2w
高级:2w 以上
2022-08-05 16:16:37 +08:00
回复了 zuiye111 创建的主题 职场话题 一个大龄大厂搬砖工的叹息
这光景,先狗住再说吧
2022-08-04 13:52:47 +08:00
回复了 AlpacaCode 创建的主题 Go 编程语言 现在的工作内容会影响到以后的就业方向吗
如果润,devops 是好方向,就业容易、薪资可能比纯开发还高一点,坚持目前方向是好事情,国内 devops 待遇一般。

如果不润:
1. 既然 3D 图形不是一开始就在做,以后转通常成就也不会太大、竞争力不如别人专业领域一直从事的,薪资天花板可能相对低些,但如果是因为真爱想做自己喜欢的,那请随意。
2. 区块链,要动就早点动,要么就别动。只是做一些链上的功能开发不难,自学一两周个把月就能熟悉很多基础,然后找个工作就是了。如果是想做区块链本身的核心架构算法之类的开发,需要的基本功就比较多了,不是短期能成的事情
2022-08-01 12:24:25 +08:00
回复了 fstar 创建的主题 程序员 TCP 关闭连接的不同版本,哪个才是对的?
@iosyyy #10 好的
2022-08-01 12:08:59 +08:00
回复了 extiing 创建的主题 生活 你能够接受这样的分手原因吗?
拿得起、放得下,自古两难全,做到一样也可。
2022-07-31 16:41:33 +08:00
回复了 fstar 创建的主题 程序员 TCP 关闭连接的不同版本,哪个才是对的?
另外,有时候 v 站的人戾气太重了,希望少点阴阳怪气,莫欺少年穷。
OP 在这研究这些是很值得鼓励的事情,总比很多人玩半辈子 CURD 要强多了
2022-07-31 16:37:31 +08:00
回复了 fstar 创建的主题 程序员 TCP 关闭连接的不同版本,哪个才是对的?
OP 别看这图,改看状态转换图吧,比这清晰多了
2022-07-29 20:34:47 +08:00
回复了 eryajf 创建的主题 程序员 我的 GitHub stars 汇总归类列表,欢迎大家 star 收藏
有没有一种可能,OP 你对精品的定义有所误解?
2022-07-28 16:56:47 +08:00
回复了 ppolanwind 创建的主题 Go 编程语言 在 golang 中,怎么判断一个 socket 连接是否关闭?
@gam2046 不同的服务类型和框架对优雅的定义、代码的封装都不太一样,分类展开了说有点多。。给个详细点的业务类型?
2022-07-27 16:48:05 +08:00
回复了 left7341 创建的主题 奇思妙想 你有什么收藏爱好吗
一起睡过的妹子照片
2022-07-27 16:10:12 +08:00
回复了 ppolanwind 创建的主题 Go 编程语言 在 golang 中,怎么判断一个 socket 连接是否关闭?
@wangyu17455 这样做是 Read 能得到 err 了,但是 socket 如果本身还是活跃的,这就是误杀了

还是我来做课代表吧!

@ppolanwind 正确的做法:
1. 不要通过调用判断是否断开的方法去判断是否断开(比如 IsClosed )
2. 正常使用 Conn ,根据使用的返回值判断,比如 Read/Write 时返回了 err ,就是断开了

以上两条只是说怎么处理,实际实现 Conn 封装时通常要做的:
1. 单独一个协程处理读
2. 如果需要广播功能,单独一个协程处理写,否则可以不用单独协程、直接写就行

前面已经有人提到 keepalive ,但不够全面,仍需注意:
1. TCP 的 keepalive (传输层,4 层)只是检测连接健康状态,但不能用于判断连接的活跃状态。比如链路通顺、4 层 keepalive 是健康的,但 7 层应用层没有数据交互,这种属于僵尸连接了,对于正常的服务器,是应该踢掉这种长时间不活跃的僵尸连接的。所以 TCP 的 keepalive 选项不能解决僵尸连接的问题
2. 7 层应该自己进行 keepalive 协议包的收发比如 websocket 的 ping/pong ,来相互判断。业务协议活跃时可以节约掉 ping/pong 、一段时间没有业务协议交互再 ping/pong ,但 keepalive 间隔本来也比较大所以即使不节约这点也没关系。
3. 既然 7 层应该有自己的 keepalive ,其实 4 层的 keepalive 就没必要了
2022-07-25 19:48:39 +08:00
回复了 Features 创建的主题 程序员 有点羡慕抽烟的同事们
@DrX 我这没激动啊兄弟
2022-07-25 00:13:49 +08:00
回复了 eason1874 创建的主题 云计算 凉心云又一大坑, COS CDN 回源流量无故暴增至 5 倍
@eason1874 #8
印象里我公司用过的 CDN ,回源流量峰值大于资源总量,比如资源总量 500M ,回源流量峰值可能 1G+,回源时间间隔远大于 1 天。

我是开发,运维相关懂得不多,只是猜测:
可能各个厂商实现策略不同,比如跟在线量有关?如果 CDN 都是单点回源然后 CDN 厂内部同步的话,尤其大厂、用户多,很容易赶上大量用户回源高峰期,这样如果大量节点之间同时迅速同步就也可能会有 CDN 厂内部网络风暴的问题,所以调度策略应该不是这种简单的方式,说不定是默认单节点回源后慢慢同步给其他节点,但是节点越多时间越久,这时候如果某些节点收到了请求、但自己节点还没收到回源节点同步来的数据,可能就直接源站了,然后也作为同步节点给其他节点发散?
2022-07-24 21:41:24 +08:00
回复了 eason1874 创建的主题 云计算 凉心云又一大坑, COS CDN 回源流量无故暴增至 5 倍
如果是良心云增加了很多 CDN 节点导致回源流量暴增,那说明它的服务质量是提升了。。
但是我不太相信是这个原因。
2022-07-24 20:31:35 +08:00
回复了 Features 创建的主题 程序员 有点羡慕抽烟的同事们
@DrX #111
兄弟呀,请你相信我,我绝对尊重你的 yanlunziyou 。
不只是尊重你的 yanlunziyou ,我尊重所有人的 yanlunziyou 。
不只是尊重 yanlunziyou ,我还尊重每一个人,包括去叫 998 、1998 、3998 各种服务的时候,我也都非常尊重别人的呀。
yanlunziyou 包括发言,也包括反对甚至批评,如你所说那是你的 yanlunziyou ,但是反对甚至批评,也是我的 yanlunziyou 呀,总不能都你们觉得好的言论就不让我们其他人反对了呀,那烟酒或者其他糟粕文化岂不永无改良之日了嘛!毕竟如你所说,你自己都不抽烟,虽然你这种方式能获得些许好处,但如果整个社会,比如新加坡那种,整体人群都去掉了这些,你可以不去委屈就轻松搞定事情呢?(我不知道你这样做心里委屈不,但至少不是自己喜欢的事物还得去做也不是件值得开心的事情)

另外我是个尖酸刻薄的人,正派这个词从来不是我追求的人设。我也没敢拿 v 站当自己家,你看,发言稍微有点敏感的词就发不出来得拼音了。但是 v 站是让大家能够相对自由地各抒己见的地方,尤其是那种或美好的或有趣的或其他什么有意义的事物,大家说出来,挺好的平台
2022-07-24 13:57:29 +08:00
回复了 dzdh 创建的主题 Go 编程语言 有日志(stdout or file) qps 4k,没日志 qps 10w. why?
@msg7086
我说的是写日志服务器比写本机更慢,用相同的方式,都同步或者都异步,肯定是本机快。如果不考虑日志安全级别、也即不需要考虑异步的丢日志问题,那当然也能异步写本地了。
另外就是,异步写到日志服务器的硬件、配置耦合更高、还需要考虑短线重连之类的稳定性问题,而且是业务进程内的模块,远不如 ELK 拉日志之类的解耦(当然,也额外增加了运维成本,但是开发和代码相对解脱了一些)

索赔是依赖第三方的正常商业行为,但是在依赖第三方之前,自家的 debug 、故障修复能力也是应该尽量自己提升的。
这个安全级别日志是单节点的稳定性、故障恢复、debug 能力的范畴; LB 是处理扩容问题、分布式范畴。一个是单点内的问题,一个是集群扩容能力的问题,所以 LB 跟这个问题没有直接关系
1  2  3  4  5  6  7  8  9  10  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3164 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 12:22 · PVG 20:22 · LAX 05:22 · JFK 08:22
Developed with CodeLauncher
♥ Do have faith in what you're doing.