年年初以来，随着Redis产品的用户量越来越大、接入服务越来越多，再加上美团点评Memcache和Redis两套缓存融合......
这导致Redis服务端的总体请求量从年初最开始日访问量百亿次级别上涨到高峰时段的万亿次级别，因此给运维和架构团队都带来了极大的挑战。
原本稳定的环境也因为请求量的上涨带来了很多不稳定的因素，其中一直困扰我们的就是网卡丢包问题。
起初线上存在部分Redis节点还在使用千兆网卡的老旧服务器，而缓存服务往往需要承载极高的查询量，并要求毫秒级的响应速度，如此一来千兆网卡很快就出现了瓶颈。
经过整治，我们将千兆网卡服务器替换为了万兆网卡服务器。本以为可以高枕无忧，但是没想到，在业务高峰时段，机器竟然也出现了丢包问题，而此时网卡带宽使用还远远没有达到瓶颈。
定位网络丢包的原因
从异常指标入手
首先，我们在系统监控的net.if.in.dropped指标中，看到有大量数据丢包异常，那么第一步就是要了解这个指标代表什么。
这个指标的数据源，是读取/proc/net/dev中的数据，监控Agent做简单的处理之后上报。
以下为/proc/net/dev的一个示例，可以看到第一行Receive代表in，Transmit代表out，第二行即各个表头字段，再往后每一行代表一个网卡设备具体的值。
其中各个字段意义如下：
/proc/net/dev的数据来源，根据源码文件net/core/net-procfs.c，可以知道上述指标是通过其中的dev_seq_show()函数和dev_seq_printf_stats()函数输出的。
通过上述字段解释，我们可以了解丢包发生在网卡设备驱动层面，但是想要了解真正的原因，需要继续深入源码。
staticintdev_seq_show(structseq_file*seq,void*v){if(v==SEQ_START_TOKEN)/*输出/proc/net/dev表头部分*/seq_puts(seq,"Inter-
Receive""
Transmit\n""face
bytespacketserrsdropfifoframe""