2020届秋招正式批次面试经验2

业务埋点，日志中心、

采用的Flume的相关的数据日志采集工具来实现的业务的埋点。

redis db双写方案

先更新数据库数据，然后在删除缓存，在删除缓存失败的是的采用一个消息队列的来加入一其中并做消费。消费的过程中消费删除缓存中的key的消息。保证数据的最终一致性。b+树联合索引非叶子节点怎么构造的范围查询走不走联合索引，、< 、>=、 限流数) { //拒绝请求 } //处理请求 } finally { atomic.decrementAndGet(); }

分布式限流：

分布式限流最关键的是要将限流服务做成原子化，而解决方案可以使使用redis+lua或者nginx+lua技术进行实现，通过这两种技术可以实现的高并发和高性能。

首先我们来使用redis+lua实现时间窗内某个接口的请求数限流，实现了该功能后可以改造为限流总并发/请求数和限制总资源数。

有人会纠结如果应用并发量非常大那么redis或者nginx是不是能抗得住；不过这个问题要从多方面考虑：你的流量是不是真的有这么大，是不是可以通过一致性哈希将分布式限流进行分片，是不是可以当并发量太大降级为应用级限流；对策非常多，可以根据实际情况调节；像在京东使用Redis+Lua来限流抢购流量，一般流量是没有问题的。

对于分布式限流目前遇到的场景是业务上的限流，而不是流量入口的限流；流量入口限流应该在接入层完成，而接入层笔者一般使用Nginx。

基于Redis功能的实现限流

简陋的设计思路：假设一个用户（用IP判断）每分钟访问某一个服务接口的次数不能超过10次，那么我们可以在Redis中创建一个键，并此时我们就设置键的过期时间为60秒，每一个用户对此服务接口的访问就把键值加1，在60秒内当键值增加到10的时候，就禁止访问服务接口。在某种场景中添加访问时间间隔还是很有必要的。

基于令牌桶算法的实现：

令牌桶算法最初来源于计算机网络。在网络传输数据时，为了防止网络拥塞，需限制流出网络的流量，使流量以比较均匀的速度向外发送。令牌桶算法就实现了这个功能，可控制发送到网络上数据的数目，并允许突发数据的发送。

令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。最后桶中可以保存的最大令牌数永远不会超过桶的大小。

传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。

令牌桶这种控制机制基于令牌桶中是否存在令牌来指示什么时候可以发送流量。令牌桶中的每一个令牌都代表一个字节。如果令牌桶中存在令牌，则允许发送流量；而如果令牌桶中不存在令牌，则不允许发送流量。因此，如果突发门限被合理地配置并且令牌桶中有足够的令牌，那么流量就可以以峰值速率发送。

分库分表根据什么值去拆

undo log快照读

在操作之前,把需要操作的数据备份到undo log中,若查询数据就有undo log +不在undo log的数据(事务未提交之前)

作用：当rollback将数据恢复到原始之前类似于备份表,为了保证事务的原子性，Innodb使用undo log实现mvcc,从undo log读取旧版本的数据

快照读：读取的是快照版本:undo +未修改的表的数据 ，普通的select

当前读：读取的是最新版本,通过锁机制来保证读取的数据无法被其他事务修改，如insert,delete,update, select .... lock in share mode,select .... for update等。

Redo log：在操作完一条语句后,将最新的数据备份到redo log中。作用：为了事务的持久化,当执行完commit,若redo log写完了,则事务提交成功,将redo log写入表中是开启异步的线程执行的,若提交后突然断电,mysql可以用redo log中恢复数据。

redis大key，热key如何排查

如果是key的数据量很小的时候可以使用的key命令 ，但是如果是大量的数据将存在的是的阻塞，导致其他服务出现卡顿的情况。采用的是的scan命令，能够保证的不阻塞Redis数据倾斜造成集群服务不可用

Redis中的数据的采用的一致性hash算法来实现的数据倾斜的时保证数据的均匀的分布其中。服务间通信，同步RPC Or 异步Mq场景选型

知名度较高的有Thrift(FB的)、dubbo(阿里的)。

RPC的一般需要经历4个步骤：

1、建立通信：首先要解决通讯的问题：即A机器想要调用B机器，首先得建立起通信连接，主要是通过在客户端和服务器之间建立TCP连接。

2、服务寻址：要解决寻址的问题，A服务器上如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么。

3、网络传输：

1. 序列化：当A服务器上的应用发起一个RPC调用时，调用方法和参数数据都需要先进行序列化。
2. 反序列化：当B服务器接收到A服务器的请求之后，又需要对接收到的参数等信息进行反序列化操作。

4、服务调用

B服务器进行本地调用（通过代理Proxy）之后得到了返回值，此时还需要再把返回值发送回A服务器，同样也需要经过序列化操作，然后再经过网络传输将二进制数据发送回A服务器。

通常，一次完整的PRC调用需要经历如上4个步骤。

消息队列（MQ）是一种能实现生产者到消费者单向通信的通信模型，一般来说是指实现这个模型的中间件。典型的MQ中间件:

RabbitMQ、ActiveMQ、Kafka等：典型的特点：1、解耦 2、可靠投递 3、广播 4、最终一致性 5、流量削峰 6、消息投递保证 7、异步通信（支持同步）8、提高系统吞吐、健壮性。典型的使用场景：秒杀业务中利用MQ来实现流量削峰，应用解耦使用。

RPC和MQ的区别和关联

1.在架构上，RPC和MQ的差异点是，Message有一个中间结点Message Queue，可以把消息存储。

2.同步调用：对于要立即等待返回处理结果的场景，RPC是首选。

3.MQ 的使用，一方面是基于性能的考虑，比如服务端不能快速的响应客户端（或客户端也不要求实时响应），需要在队列里缓存。另外一方面，它更侧重数据的传输，因此方式更加多样化，除了点对点外，还有订阅发布等功能。

4.而且随着业务增长，有的处理端处理量会成为瓶颈，会进行同步调用改造为异步调用，这个时候可以考虑使用MQ。

项目中怎么使用的redis的？

1缓存 2分布式锁的实现 3 并发 性能 

缓存的雪崩缓存（数据失效 、宕机）：随机失效 、采用的多级缓存（哨兵机制）、采用的resdi集群式 （集群机制）

缓存击穿：（除了一线大公司数据才可能有这样能热点的数据，一般的公司机会没有这样的数据）小公司一般不处理这的问题。

缓存穿透：（非法请求数据）数据库和缓存的都不存在的数据，1查询的数据加载是缓存中，2使用的布隆过滤器的实现。（标志数据库中的数据存在的ID）采用互斥的分布式锁来实现。（让人物排队 ，只有一才能查询数据 然后加载到缓存中，然后在其他的请求不需要请求数据库）。

Redis的一致性算法原理和作用：

在数据扩容的是时候会产生的数据的不均匀。会造成数据倾斜的问题。一致性hash算法避免将数据重新分布在redis中。解决小范围的数据的移动，不至于全盘扩展。可能造成数据的数据的倾斜问题。这样的时候在redis内部维护了一张的虚拟hash和真实机器的一张关系表格。从而保证的数据在访问虚拟节点的时能够访问真实的数据。

为什么redis的命令是scan不会造成阻塞？

Redis使用了Hash表作为底层实现，原因不外乎高效且实现简单。说到Hash表，很多Java程序员第一反应就是HashMap。没错，Redis底层key的存储结构就是类似于HashMap那样数组+链表的结构。其中第一维的数组大小为2n(n>=0)。每次扩容数组长度扩大一倍。

scan命令就是对这个一维数组进行遍历。每次返回的游标值也都是这个数组的索引。limit参数表示遍历多少个数组的元素，将这些元素下挂接的符合条件的结果都返回。因为每个元素下挂接的链表大小不同，所以每次返回的结果数量也就不同。

这是因为需要考虑遍历时发生字典扩容与缩容的情况（不得不佩服开发者考虑问题的全面性）。我们来看一下在SCAN遍历过程中，发生扩容时，遍历会如何进行。加入我们原始的数组有4个元素，也就是索引有两位，这时需要把它扩充成3位，并进行rehash。

原来挂接在xx下的所有元素被分配到0xx和1xx下。在上图中，当我们即将遍历10时，dict进行了rehash，这时，scan命令会从010开始遍历，而000和100（原00下挂接的元素）不会再被重复遍历。再来看看缩容的情况。假设dict从3位缩容到2位，当即将遍历110时，dict发生了缩容，这时scan会遍历10。这时010下挂接的元素会被重复遍历，但010之前的元素都不会被重复遍历了。所以，缩容时还是可能会有些重复元素出现的。

Redis的rehash：rehash是一个比较复杂的过程，为了不阻塞Redis的进程，它采用了一种渐进式的rehash的机制。

/* 字典 */
typedef struct dict {
    // 类型特定函数
    dictType *type;
    // 私有数据
    void *privdata;
    // 哈希表
    dictht ht[2];
    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
    // 目前正在运行的安全迭代器的数量
    int iterators; /* number of iterators currently running */
} dict;

在Redis的字典结构中，有两个hash表，一个新表，一个旧表。在rehash的过程中，redis将旧表中的元素逐步迁移到新表中，
/* Performs N steps of incremental rehashing. Returns 1 if there are still
 * keys to move from the old to the new hash table, otherwise 0 is returned.
 *
 * Note that a rehashing step consists in moving a bucket (that may have more
 * than one key as we use chaining) from the old to the new hash table, however
 * since part of the hash table may be composed of empty spaces, it is not
 * guaranteed that this function will rehash even a single bucket, since it
 * will visit at max N*10 empty buckets in total, otherwise the amount of
 * work it does would be unbound and the function may block for a long time. */
int dictRehash(dict *d, int n) {
    int empty_visits = n*10; /* Max number of empty buckets to visit. */
    if (!dictIsRehashing(d)) return 0;

    while(n-- && d->ht[0].used != 0) {
        dictEntry *de, *nextde;

        /* Note that rehashidx can't overflow as we are sure there are more
         * elements because ht[0].used != 0 */
        assert(d->ht[0].size > (unsigned long)d->rehashidx);
        while(d->ht[0].table[d->rehashidx] == NULL) {
            d->rehashidx++;
            if (--empty_visits == 0) return 1;
        }
        de = d->ht[0].table[d->rehashidx];
        /* Move all the keys in this bucket from the old to the new hash HT */
        while(de) {
            uint64_t h;

            nextde = de->next;
            /* Get the index in the new hash table */
            h = dictHashKey(d, de->key) & d->ht[1].sizemask;
            de->next = d->ht[1].table[h];
            d->ht[1].table[h] = de;
            d->ht[0].used--;
            d->ht[1].used++;
            de = nextde;
        }
        d->ht[0].table[d->rehashidx] = NULL;
        d->rehashidx++;
    }

    /* Check if we already rehashed the whole table... */
    if (d->ht[0].used == 0) {
        zfree(d->ht[0].table);
        d->ht[0] = d->ht[1];
        _dictReset(&d->ht[1]);
        d->rehashidx = -1;
        return 0;
    }

    /* More to rehash... */
    return 1;
}

• 首先判断一下是否在进行rehash，如果是，则继续进行；否则直接返回。
• 接着就是分n步开始进行渐进式rehash。同时还判断是否还有剩余元素，以保证安全性。
• 在进行rehash之前，首先判断要迁移的bucket是否越界。
• 然后跳过空的bucket，这里有一个empty_visits变量，表示最大可访问的空bucket的数量，这一变量主要是为了保证不过多的阻塞Redis。
• 接下来就是元素的迁移，将当前bucket的全部元素进行rehash，并且更新两张表中元素的数量。
• 每次迁移完一个bucket，需要将旧表中的bucket指向NULL。
• 最后判断一下是否全部迁移完成，如果是，则收回空间，重置rehash索引，否则告诉调用方，仍有数据未迁移。

由于Redis使用的是渐进式rehash机制，因此，scan命令在需要同时扫描新表和旧表，将结果返回客户端。

怎么用最大堆最小堆找中位数

TCP 如何保证可靠性

1. 校验和

TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为：在发送方将整个报文段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确（UDP中为0是正确），否则存在错误。

2. 确认应答与序列号

TCP将每个字节的数据都进行了编号，这就是序列号。 序列号的作用： a、保证可靠性（当接收到的数据总少了某个序号的数据时，能马上知道） b、保证数据的按序到达 c、提高效率，可实现多次发送，一次确认 d、去除重复数据 数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现

TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。

3. 超时重传

当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）。一种情况是发送包丢失了，其基本过程如下：

另一种情况是ACK 丢失，过程如下：

当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，前面提到的序列号就起作用了。

重传时间的确定：重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2500ms后再进行重传，如果仍然得不到应答就等待4500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。

4. 连接管理:连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。

5. 流量控制:接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，导致接收端的缓冲区满，而发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫做流量控制。在TCP报文段首部中有一个16位窗口长度，当接收端接收到发送方的数据后，在应答报文ACK中就将自身缓冲区的剩余大小，放入16窗口大小中。这个大小随数据传输情况而变，窗口越大，网络吞吐量越高，而一旦接收方发现自身的缓冲区快满了，就将窗口设置为更小的值通知发送方。如果缓冲区满，就将窗口置为0，发送方收到后就不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

注意：窗口大小不受16位窗口大小限制，在TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。

6. 拥塞控制

流量控制解决了两台主机之间因传送速率而可能引起的丢包问题，在一方面保证了TCP数据传送的可靠性。然而如果网络非常拥堵，此时再发送数据就会加重网络负担，那么发送的数据段很可能超过了最大生存时间也没有到达接收方，就会产生丢包问题。 为此TCP引入慢启动机制，先发出少量数据，就像探路一样，先摸清当前的网络拥堵状态后，再决定按照多大的速度传送数据。 此处引入一个拥塞窗口： 发送开始时定义拥塞窗口大小为1；每次收到一个ACK应答，拥塞窗口加1；而在每次发送数据时，发送窗口取拥塞窗口与接送段接收窗口最小者。 慢启动：在启动初期以指数增长方式增长；设置一个慢启动的阈值，当以指数增长达到阈值时就停止指数增长，按照线性增长方式增加；线性增长达到网络拥塞时立即“乘法减小”，拥塞窗口置回1，进行新一轮的“慢启动”，同时新一轮的阈值变为原来的一半。 “慢启动”机制可用图表示：

6.1. 慢启动

1）连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。

2）每当收到一个ACK，cwnd++; 呈线性上升

3）每当过了一个RTT，cwnd = cwnd*2; 呈指数让升

4）还有一个ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”（后面会说这个算法）

6.2. 拥塞避免

1）收到一个ACK时，cwnd = cwnd + 1/cwnd

2）当每过一个RTT时，cwnd = cwnd + 1

这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。

6.3. 快重传

当出现ack超时的时候，需要重传数据包。

• sshthresh = cwnd /2
• cwnd 重置为 1
• 进入慢启动过程

TCP认为这种情况太糟糕，反应也很强烈。快速重传在收到3个duplicate ACK时就开启重传(三次 ack 就认为丢包的原理见关于TCP乱序和重传的问题、TCP 快速重传为什么是三次冗余 ACK)，而不用等到RTO超时。

TCP Reno的实现是：

• cwnd = cwnd /2
• sshthresh = cwnd
• 进入快速恢复算法——Fast Recovery

6.4. 快恢复

快速恢复

快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，所以没有必要像RTO超时那么强烈。 注意，正如前面所说，进入Fast Recovery之前，cwnd 和 sshthresh已被更新：

如何让不可靠的UDP变得可靠

如何让不可靠的UDP变得可靠思考

第一节我们简单回顾了一下UDP，了解到UDP是无连接、面向数据包的不可靠的简单传输层协议，现在，我们回到主题本身：UDP本身是不可靠，现在需要保证可靠，在不改变UDP协议的情况下能够想到的是在应用层做可靠性设计，但是应用层做可能通用性会差一些，那么在传输层和应用层之间加一层实现UDP的可靠性呢？基于这个想法提出了RUDP（Reliable UDP），实际上，已经有项目在这么做了，比如Google的QUIC和WebRTC。

可靠意味着更高的通信开销、更大的时延，以实时传输这类应用场景为例，我们可能并不需要绝对的可靠，我们寻求在成本、质量、时延上寻找一个平衡，如下图所示。

TCP 属于通过增大延迟和传输成本来保证质量的通信方式，UDP 是通过牺牲质量来保证时延和成本的通信方式，所以在一些特定场景下 RUDP 更容易找到这样的平衡点。RUDP 是怎么去找这个平衡点的，就要先从 RUDP 的可靠概念和使用场景来分析。

实时通讯中的可靠性定义

在实时通信过程中，不同的需求场景对可靠的需求是不一样的，我们在这里总体归纳为三类定义：

• 尽力可靠：通信的接收方要求发送方的数据尽量完整到达，但业务本身的数据是可以允许缺失的。例如：音视频数据、幂等性状态数据。
• 无序可靠：通信的接收方要求发送方的数据必须完整到达，但可以不管到达先后顺序。例如：文件传输、白板书写、图形实时绘制数据、日志型追加数据等。
• 有序可靠：通信接收方要求发送方的数据必须按顺序完整到达。

RUDP 是根据这三类需求和上节图中的三角制约关系来确定自己的通信模型和机制的，也就是找通信的平衡点。

UDP为什么要可靠

确实很多人也都是这样做的，TCP 是个基于公平性的可靠通信协议，但是在一些苛刻的网络条件下 TCP 要么不能提供正常的通信质量保证，要么成本过高。为什么要在 UDP 之上做可靠保证，究其原因就是在保证通信的时延和质量的条件下尽量降低成本。RUDP 主要解决以下相关问题：

• 端对端连通性问题：一般终端直接和终端通信都会涉及到 NAT 穿越，TCP 在 NAT 穿越实现非常困难，相对来说 UDP 穿越 NAT 却简单很多，如果是端到端的可靠通信一般用 RUDP 方式来解决，场景有：端到端的文件传输、实时音视频传输、交互指令传输等等。【UDP NAT穿越简单很多】
• 弱网环境传输问题：在一些 Wi-Fi 或者 3G/4G 移动网下，需要做低延迟可靠通信，如果用 TCP 通信延迟可能会非常大，这会影响用户体验。例如：实时的操作类网游通信、语音对话、多方白板书写等，这些场景可以采用特殊的 RUDP 方式来解决这类问题；【弱网传输UDP延长会低很多】
• 带宽竞争问题：有时候客户端数据上传需要突破本身 TCP 公平性的限制来达到高速低延时和稳定，也就是说要用特殊的流控算法来压榨客户端上传带宽，例如：直播音视频推流，这类场景用 RUDP 来实现不仅能压榨带宽，也能更好地增加通信的稳定性，避免类似 TCP 的频繁断开重连；
• 传输路径优化问题：在一些对延时要求很高的场景下，会用应用层 relay 的方式来做传输路由优化，也就是动态智能选路，这时双方采用 RUDP 方式来传输，中间的延迟进行 relay 选路优化延时。还有一类基于传输吞吐量的场景，例如：服务与服务之间数据分发、数据备份等，这类场景一般会采用多点并联 relay 来提高传输的速度，也是要建立在 RUDP 上的（这两点在后面着重来描述）；
• 资源优化问题：某些场景为了避免 TCP 的三次握手和四次挥手的过程，会采用 RUDP 来优化资源的占用率和响应时间，提高系统的并发能力，例如 QUIC。

不管哪类场景，都是要保证可靠性，也就是质量，那么在 UDP 之上怎么实现可靠呢？答案就是重传。我们在下一节会重点分析在RUDP的可靠性设计

RUDP基本框架：从图中我们可以看到，构建于UDP之上的RUDP，增加了数据窗口、拥塞控制、确认机制、重传机制等可靠性保障机制。

可靠UDP设计 重传

IP 协议在设计的时候就不是为了数据可靠到达而设计的，所以 UDP 要保证可靠，就依赖于重传，这也就是我们通常意义上的 RUDP 行为。

RUDP的重传通过接收端ACK的丢包信息反馈来进行数据重传，发送端会根据场景来设计自己的重传方式，常见有3类：超时重传、请求重传何FEC选择重传。

超时重传

发送端在T1时刻发送数据包，在一个RTO时间到达时未收到这个数据包的ACK应答，那么发送端则认为需要重传。从中我们其实也可以了解到会出现误判，比如：

1. 接收端受到数据包，但是ACK在中途丢失，会导致重传。
2. ACK未丢失在途，但发送端RTO已经到时了。

所以超时重传依赖于RTO的计算，RTO计算可参考我们在《TCP可靠性二探》一文的计算方式。如果应用场景是对延迟非常敏感但对流量成本要求不高的场景，就可以将RTO的计算设计得比较小。这类典型场景有实时操作类网游、教育领域的书写同步都是典型的用成本换低延迟和高质量的场景，适用于小带宽低延迟传输。

如果是大带宽低延迟传输用超时重传可能不太合适，因为如果这样做，对带宽的消耗极大，极端情况可能导致20%的重传率。面对这样情况怎么办呢？

请求重传

请求重传就是接收端在发送 ACK 的时候携带自己丢失报文的信息反馈，发送端接收到 ACK 信息时根据丢包反馈进行报文重传。如下图所示。

这个反馈过程最关键的步骤就是回送 ACK 的时候应该携带哪些丢失报文的信息，因为 UDP 在网络传输过程中会乱序会抖动，接收端在通信的过程中要评估网络的 jitter time（抖动时间），也就是 rtt_var（RTT 方差值），当发现丢包的时候记录一个时刻 t1，当 t1 + rtt_var < curr_t(当前时刻)，我们就认为它丢失了。

这个时候后续的 ACK 就需要携带这个丢包信息并更新丢包时刻 t2，后续持续扫描丢包队列，如果 t2 + RTO cwnd, 继续保证 DRAIN 状态，如果 flight_size