当前位置:首页 > 迷失传奇 > 正文内容

新开变态传奇网站65535上线满级_超变态传奇65535级

2周前 (05-10)迷失传奇14

引子

刚才下班回家路上,无意中听到大街上放的歌,歌词有这么一句:“毡房外又有驼铃声声响起,我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望,如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。

在工作上,我们有十年的时间来把思考能力上升一个等级。对于一个问题,需要在很短的时间反复思考,深层次地弄懂。懂得,有三个初级境界,对应三个方法:

1>字面理解-what、why、how

2>前因后果-5why

3>选择最优-SMART

回到主线:为什么是初级境界?我自己也不知道更高级别的境界是有什么,因为自己境界没有达到。但是至少有:刻入骨髓 这一境界。

举个例子:十二年前,有次在大街上走,我走过一个【北京银行】的大门,银行二楼的玻璃哗啦啦掉下来。我知道身后有危险,有很多玻璃落到了距离我身后不到十公分的地方。我当时很镇定的继续向前走。等过了危险区,我很想神经质的大叫。因为走路时再多犹豫2秒,可能脑袋上被扎的全是玻璃。所以走路时时时刻刻都会想着离楼房远一些,并且好像感受到了自己脑袋被玻璃扎。我理解这可以算作把楼房玻璃很危险的理解刻入骨髓。

字面理解

今天举的这个例子纯粹是技术问题,终于不需要用蹩脚的比喻把事情描述的更难理解来达到脱敏的效果。

what

我们采用的是dubbo服务,这是个稳定成熟的RPC框架。但是我们在某些应用中会发现,只要这个应用一发布(或者重启),就会出现请求超时的问题,如下图所示:

新开变态传奇网站65535上线满级

而且都是第一笔请求会报错,之后就再也没有问题了。

(上图来源于网络,下面有参考文章。如果可以,我想把这些字调的再小一些)

why

我当时很快就定位了问题,因为在内网wiki上、技术博客上,很多人都写了这个坑。所以不讲排查思路了,直接讲结论:

在server端连接数过多, linux系统有个连接队列溢出了。溢出的连接被丢弃,但是client端不知道,仍然给此server发送消息。连接没有建立自然发送不成功。client发第一笔消息超时,相当于探活失败,client端于是重新建立连接。连接成功建立后开始正常的通信,所以后面都成功了。

how

怎么来解决这个问题呢?四个思路。

第一个是队列溢出了,那就说明队列太小。可以把队列值改大。dubbo使用的是一个写死的默认值:50。可以修改dubbo源码把值改大或者干脆动态获取队列值。

第二个是队列数不变,实际连接数减少。减少server端的连接方,比如有些client端其实没有实际业务调用这个server端了,就双方聊聊把无用的依赖去掉。

第三个是可以让服务端在丢弃连接的同时给client端通知一下,linux有个系统参数/proc/sys/net/ipv4/tcp_abort_on_overflow,默认为0。不会给client端发通知,但是设置为1时会给server端发一个reset请求,客户端收到会重连。

第四个是让client端定时心跳探测。探测发现超时了马上重连,超时的那笔只是探测请求,不影响业务。

新开变态传奇网站65535上线满级

前因后果

作为软件工程师,重要的一个软素质是批判性思维。多问几个问题,找到答案,理解就能更进一步。

Q1: 提到溢出的队列到底是什么队列?

A: 下图是TCP连接三次握手的示意图。

新开变态传奇网站65535上线满级

一次握手:

一开始client端和server端都处于closed状态(未建立连接状态)。client端主动向server端发起syn请求建立连接请求,server端收到后将与client端的连接设置为listen状态(半连接状态)。问题来了,server端怎么保存与client端的状态呢?总需要有地方存呀,存的地方就是队列。连接队列又叫backlog队列。到这里,server端与client端的半连接建立了。这里的backlog队列也叫半连接队列。

二次握手:

server端返回ack应答+syn请求给client,意思是:ack我收到了你的请求,syn你收到我的了没?client端收到server端响应,将自己的状态设置为established状态(连接状态)。

三次握手:

client向server端发送一个ack响应,告诉server端收到。然后server端收到后将与client端的连接设置为established状态(全连接状态)。同样,全连接状态在server端也需要一个backlog队列存储。这里的backlog队列也叫全连接队列。

Q2: backlog队列到底是全连接队列还是半连接队列?

A: 这个问题让我想起别的事情。我大学是东北大学,有次看到校内论坛上有个帖子:“东北大学和东南大学谁更有资格叫东大?”最终没啥结论,东北大学内网再论证自己该叫东大,东南大学内网肯定不认。

但是backlog的问题还是有达成共识的可能的。backlog其实是一个连接队列,在Linux内核2.2之前,backlog包括半连接状态和全连接状态两种队列。在Linux内核2.2之后,分离为两个backlog来分别限制半连接(SYN_RCVD状态)队列大小和全连接(ESTABLISHED状态)队列大小。

半连接队列:

队列长度由/proc/sys/net/ipv4/tcp_max_syn_backlog指定,默认为2048。

全连接队列:

队列长度由/proc/sys/net/core/somaxconn和使用listen函数时传入的参数,二者取最小值。默认为128。

在Linux内核2.4.25之前,是写死在代码常量 SOMAXCONN ,在Linux内核2.4.25之后,在配置文件/proc/sys/net/core/somaxconn中直接修改,或者在 /etc/sysctl.conf 中配置 net.core.somaxconn = 128 。

想到这里我恍然大悟,东北大学、东方大学、东南大学在自己的地盘都有资格简称东大(这里讲这个插曲是为了澄清一件事情:我昨天下午4点发的文章里标题是一个北大妹子,那篇文章是帮朋友的忙,北大妹子不是我,我是东大妹子)。

Q3: 到底是全连接队列还是半连接队列溢出导致了超时?

A: server端与client端进行二次握手的前提是server端认为自己与client建立连接是没有任何问题的。如果server端半连接队列溢出了,自己这边都没有处于半连接状态,自然不会发送ack+syn给client端。client端做的应该是重新尝试建立连接,不是发送数据。请求会发送到已经建立好连接的server端(server端是多机器多活部署的)不会造成请求超时。

而二次握手一旦完成,进行三次握手时,如果全连接队列已满,服务器收到客户端发来的ACK, 不会将该连接的状态从SYN_RCVD变为ESTABLISHED。但是客户端已经认为连接建立好了开始发送数据了,这时候是有可能造成超时的。

Q4: 全连接队列满了之后server端是怎么处理的呢?

当全连接队列已满时,则根据 tcp_abort_on_overflow 的值来执行相应动作。

tcp_abort_on_overflow = 0 处理:

则服务器建立该连接的定时器,这个定时器是一个服务器的规则是从新发送syn+ack的时间间隔成倍的增加,比如从新了第二次握手,进行了5次,这五次的时间分别是 1s, 2s,4s,8s,16s,这种倍数规则叫“二进制指数退让”(binary exponential backoff)。

给客户端定时从新发回SYN+ACK即重新进行第二次握手,(如果客户端设定的超时时间比较短就很容易出现异常)服务器重新进行第二次握手的次数由/proc/sys/net/ipv4/tcp_synack_retries 这个linux系统参数决定。

tcp_abort_on_overflow = 1处理:

当 tcp_abort_on_overflow 等于1 时,发送一个reset请求重置连接。客户端收到可以尝试再次从第一次握手开始建立连接或者其他处理。

Q5: 怎么验证确实是backlog队列溢出呢?

ss 是 Socket Statistics 的缩写。ss 命令可以用来获取 socket 统计信息 。ss -l 是显示listen状态的数据,如下所示:

[root@localhost ~]# ss -lState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:http *:* LISTEN 0 128 :::ssh :::* LISTEN 0 128 *:ssh *:* LISTEN 0 100 ::1:smtp :::* LISTEN 0 100 127.0.0.1:smtp *:*

在LISTEN状态,其中 Send-Q 即为全连接队列的最大值,Recv-Q 则表示全连接队列中等待被server段处理的数量。数量为0,说明处理能力很够;Send-Q =Recv-Q ,满了,再来就丢弃掉了。

但是这是一个实时的数据,一段时间有拥塞,过一会儿就好了怎么查呢?

可以使用netstat -s 可以查看被全连接队列丢弃的数据。

[root@localhost ~]# netstat -s | grep "times the listen queue of a socket overflowed"35552 times the listen queue of a socket overflowed

补充说明: 半连接队列很多文章叫做 SYN QUEUE队列。 全连接队列很多文章叫做ACCEPT QUEUE队列。 这是一些研究linux源码的同学根据源码的命名来叫的。

新开变态传奇网站65535上线满级

选择最优

马云说:“选择比努力重要” 。懂得三境界,第三境界的重点不是懂,而是得。最终要根据懂了的内容决策出最优方案。

除了字面理解里提到的四种思路,前因后果里还提到了重新进行第二次握手的次数由/proc/sys/net/ipv4/tcp_synack_retries 这个linux系统参数决定。

分别来分析一下各个方案的可行性和优缺点:

方案1:把队列值调大

这个队列值是指 全连接队列 ,调大之后,client端的二次握手就在这个队列里排队等待server端真正建立连接。假设队列值调到上限65535。第65535号请求在排队的过程,client端是established状态,数据可能会发送过来,服务端还没有established状态,还不能处理。

到什么时候能处理呢?65535个请求全部处理完需要13s的样子。对一般的服务来说妥妥的超时。所以nginx和redis都是使用的511,让响应时间在100ms内完成。

方案2:减少连接数

只要能减少的下来,这是理想的法子。现在server端都过载了,可想而知,接入的client端不再少数,推动他们一个个去梳理和改造,就算大家执行力很强,把改下的下了。可想而知,废弃的也一般不会有多少。不展开了啊,现在已经三千多字了,争取五千字内结束。

还有没有别的方法减少连接数呢?最简单的就是使用分治法。

划分子集

跟同事讨论请教的时候,他给我提供了一个划分子集的思路。让client端只和server端一部分服务器建立连接。有两种分配谁跟谁连接的算法,一个是随机算法。但是server端服务器我最多见过几千台组成一个集群的。对随机(虽然连接数是服务器台数的n倍)来说,样本是很少的,会很不均匀;另外一个是确定性算法,思路也很简单。连接的client端及数量是确定的,那就排个序,按照server端数量分配一下。这样连接数是均匀的,但是就没办法做到请求级别的流量均匀。

粘滞连接

尽可能让客户端总是向同一提供者发起调用,除非该提供者挂了,再连另一台。<dubbo:protocol name="dubbo" sticky="true" />。如果每个client端都只和一个server端建立连接。那server端压力就是原来的(1/机器台数)。不够加机器就行了,横向可扩展。

新开变态传奇网站65535上线满级

这种做法最大的问题是高可用和并发请求的问题,对于可用性要求不高、请求量不高的服务(比如后台定时任务定时拉取可重试)其实是可以用的。但是这需要client端的自觉性,而对维护这个client端的人员来讲,他们自身是没有好处的,因为原本也就是只是重启时发生一次超时嘛。所以客户端在可以的情况下愿不愿意这样做就看格局了。

方案3:服务端通知

服务端通知上面 前因后果 中有提到可以设置

/proc/sys/net/ipv4/tcp_synack_retries

重新进行几次进行第二次握手。但是这个阶段,client端可能会发数据包过来造成超时;另外,可以设置

/proc/sys/net/ipv4/tcp_abort_on_overflow=1

整个握手直接断掉,client端是closed状态,它会找其他established状态的连接进行数据包发送,不会造成超时。事实上,调研了一些大厂,

tcp_abort_on_overflow=1是作为默认配置的。

方案4:客户端探测

客户端探测想自己做的话比较麻烦,比如说把,客户端调了n个服务,每个服务建立了n个连接。资源开销大,还必须要复用这些已经建立的连接,复杂度高。

其实provider 和consumer 有双向心跳(探测)的,那为什么没检测出并进行重连?

这个首先面临的问题:client端认为连接成功了,但server端认为没有成功。那么server端 是不会发送心跳给 client端的。

client端是不是应该发心跳给server端呢?是的,原来使用dubbo2.5.3版本时3分钟client端会发送一个探测,之后把问题连接closed掉。只是dubbo 2.6.9使用了netty4。他们强强联手搞出来一个bug,探测机制楞没生效!

新开变态传奇网站65535上线满级

心跳有个条件,就是lastRead 和 lastWrite 不为空。那就需要看哪里设置了这两个参数。通过代码查到client端连接成功和server端连接成功的时候都会设置。这里只考虑client端情况,对比netty3发现netty4里少了

NettyServerHandler的handler链处理。这个handler链处理就是用来初始化那两个值的。

除了改client端源码,有没有别的方法让client端探测生效呢?其实什么都不用TCP就有keepalive(探活)机制。默认是7200秒,也就是2小时。可以修改:

/proc/sys/net/ipv4/tcp_keepalive_time单位是秒

好了,解决问题的方法就讲到这里,完结撒花~~

新开变态传奇网站65535上线满级

咦,说好的SMART原则呢?

S代表具体的(Specific)

M代表可衡量的(Measurable)

A代表可达到的(Attainable)

R代表与最终目标是相关的(Relevant)

T代表有明确的截止期限(Time-bound)

方案这么多,哪种是最好的呢?看场景。方案4提到了问题其实是开源组件有bug导致。但改开源组件,看公司规划、开源社区支持,A可行性上有制约;

方案2涉及很多整改和推动,T时效上有制约。方案虽多,排除法排除一下能剩下一个就不错了。

扫描二维码推送至手机访问。

版权声明:本文由超超乐私服网发布,如需转载请注明出处。

本文链接:https://www.cclsf.com/article/527.html

分享给朋友:

“新开变态传奇网站65535上线满级_超变态传奇65535级” 的相关文章

新版冰雪传奇

新版冰雪传奇

朋友们大家好。今天给大家推荐一款新款游戏冰雪传世, 相信没有玩过的朋友们对这款游戏会不太了解,但是对老玩家们肯定是期待值满满。接下来我给大家简单的介绍一下。这款游戏不同于其他的传世 版本,冰雪传世可以打金的地方很多,而这款冰雪传世借鉴了别的打金游戏的一些游戏玩法,加入了回收武器装备会给元宝和角色经...

180火龙复古传奇手游官网(火龙复古传奇官网)

180火龙复古传奇手游官网(火龙复古传奇官网)

传奇这一个游戏已经诞生二十多个年头了。在这个时间段里传奇也是产生了许多不一样的版本,不断地在更新换代。在其中最受玩家欢迎的应当便是最经典的1复古火龙版本了,根本原因就是这个版本中三职业尤其的平衡,并没有一刀999的氪金。并且官方管理的也是尤其的严苛,游戏乐趣自然也是最好的!下边小编说说我对这版本的一...

现在还有老虎皮卖吗(现在还有老版传奇吗)

现在还有老虎皮卖吗(现在还有老版传奇吗)

大家好,我是你们的老朋友啊木,玩传奇就关注《冰雪火龙三职业》今天我们就来说说老版传奇和现在的传奇区别在哪!首先它俩是同一款游戏,你要问他2有什么区别,那区别确实挺多的,如果有时间的话就听小弟来说道说道!第一它俩的时间就不一样,不要说这是废话。毕竟怀旧版是打着怀旧的旗号,证明它还是希望借助当年的口碑来...

版本超变传奇

版本超变传奇

嗨,各位玩家们大家好啊,欢迎来到【可乐王城英雄】,双职业传奇手游武圣屠龙鉴宝是怎么玩的呢,武圣屠龙鉴宝玩法跟随小编一起来看看吧,希望能够给大家带来帮助哦!武圣屠龙霸气时装外观,随时可以开启pvp战斗。对于手机的负担也小,基本上玩一天也不会没电。终极变态,创造新传奇!海量装备随便爆。大奖和终极大奖从自...

天影沉默传奇攻略,沉默ol传奇

天影沉默传奇攻略,沉默ol传奇

当我们打开2021年TVB的台庆剧目,会发现吸睛系数到达一个新低谷。其中,目前正在播出的新版《十月初五的月光》,真的很难找出一个正面的观后评价。回头看看2000年版本,不仅豆瓣评分高达8.7,更是TVB当年的收视冠军剧集。这边提到的收视,是指从1991年10月开始,香港开始以设置个人收视纪录系统来计...

游戏发布网站(新游戏发布网站)游戏发布网站(新游戏发布网站)游戏发布网站(新游戏发布网站)

游戏发布网站(新游戏发布网站)游戏发布网站(新游戏发布网站)游戏发布网站(新游戏发布网站)

游戏行业一直都是得玩家者得天下,作为内容消费主体的玩家也不再是默默用钱投票,而是走到了台前,开始用自己的声量、二次创作主动对游戏行业产生影响。年底除了各种数据报告以及排行榜等量化的指标外,玩家在游戏外对相关内容的热情程度,同样也是值得关注的重点。海外论坛类网站Reddit于近日发布了自家网站的年度总...