Bean复制的几种框架对比
但是在做订单系统的时候,遇到这样一个业务场景,由于业务原因允许用户通过线下支付宝还款,即我们提供一个公司官方的支付宝二维码,用户扫码还款,然后财务不定期的去拉取该支付宝账户下的还款清单并生成规范化的Excel表格录入到支付系统。
支付系统将这些支付信息生成对应的支付订单并落库,同时针对每笔还款记录生产一个消息信息到消息系统,消息的消费者就是订单系统。订单系统接受到消息后去结算当前用户的金额清算:先还本金,本金还清再还滞纳金,都还清则该笔订单结清并提升可借贷额度,……,整个流程大致如下: 当遇到这种问题的时候,虽然TCP连接建立耗时只增加了2ms左右,整体TCP连接耗时看起来还可接受。但是这里的问题在于这2ms多都是在消耗CPU的周期,所以问题不小。 解决起来也非常简单,办法很多:修改内核参数net.ipv4.ip_local_port_range多预留一些端口号、改用长连接都可以。 2. 半/全连接队列满
如果连接建立的过程中,任意一个队列满了,那么客户端发送过来的syn或者ack就会被丢弃。客户端等待很长一段时间无果后,然后会发出TCP Retransmission重传。拿半连接队列举例: 在这个连接过程中,我们来简单分析一下每一步的耗时:
以上几步操作,可以简单划分为两类:
1ms就等于1000us,因此网络传输耗时比双端的CPU开销要高1000倍左右,甚至更高可能还到100000倍。所以,在正常的TCP连接的建立过程中,一般可以考虑网络延时即可。一个RTT指的是包从一台服务器到另外一台服务器的一个来回的延迟时间。所以从全局来看,TCP连接建立的网络耗时大约需要三次传输,再加上少许的双方CPU开销,总共大约比1.5倍RTT大一点点。不过从客户端视角来看,只要ACK包发出了,内核就认为连接是建立成功了。所以如果在客户端打点统计TCP连接建立耗时的话,只需要两次传输耗时-既1个RTT多一点的时间。(对于服务器端视角来看同理,从SYN包收到开始算,到收到ACK,中间也是一次RTT耗时) 二、TCP连接建立时的异常情况 上一节可以看到在客户端视角,在正常情况下一次TCP连接总的耗时也就就大约是一次网络RTT的耗时。如果所有的事情都这么简单,我想我的这次分享也就没有必要了。事情不一定总是这么美好,总会有意外发生。在某些情况下,可能会导致连接时的网络传输耗时上涨、CPU处理开销增加、甚至是连接失败。现在我们说一下我在线上遇到过的各种沟沟坎坎。 1. 客户端connect系统调用耗时失控
正常一个系统调用的耗时也就是几个us(微秒)左右。但是在《追踪将服务器CPU耗光的凶手!》一文中笔者的一台服务器当时遇到一个状况,某次运维同学转达过来说该服务CPU不够用了,需要扩容。当时的服务器监控如下图: (编辑:济宁站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |