Java程序员的知识博客

【笔记】高并发-秒杀架构实战-Redis实现

【笔记】redis-单机-57万QPS-实践

笔记】ReactiveRedisTemplate压测-单机20万QPS-实践

【笔记】单机100万（百万）QPS的ID生成器

【笔记】微信抢红包-3千万的技术架构

【笔记】百万并发-RedisTemplate压测

【笔记】千万并发-单机41万QPS-Redis-lettuce-实践

本文模拟三种宕机场景，分别演示实际测试效果和TCP调优实践。场景1：进程宕机，场景2：局域网操作系统宕机，场景3：广域网操作系统宕机，场景4：广域网操作系统宕机-调优化。

操作系统内核-TCP-高并发-调优实战-演示-三次握手

Redisson-百万并发-单机23万QPS-调优实战

【代码】Dubbo 连接数控制。

它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，可用来控制Linux网络配置，由于/proc/sys/net目录内容的临时性，建议把TCPIP参数的修改添加到/etc/sysctl.conf文件, 然后保存文件，使用命令“/sbin/sysctl –p”使之立即生效。以上是TCP socket的读写缓冲区的设置，每一项里面都有三个值，第一个值是缓冲区最小值，中间值是缓冲区的默认值，最后一个是缓冲区的最大值，虽然缓冲区的值不受core缓冲区的值的限制，但是缓冲区的最大值仍旧受限于core的最大值。

对于JMM的happens-before规则，即对一个volatile修饰的变量的写操作，happens-before随后对这个变量的读操作。而如果我们使用一个基于句柄方式访问对象的编译器（如Symantec JIT），不加volatile关键字可能会导致重排序，返回一个未初始化完成的实例。，其中说到：如果使用Symantec JIT（一个基于句柄方式访问对象的编译器)，它编译出来的代码就会发生上述的重排序。// 给客户端调用的，如果初始化未完成，应该返回false，如果完成，返回true。

与基于NIO的传输相比，这些JNI传输添加了特定于平台的特性，生成的垃圾更少，并且通常提高了性能.

redisnetty服务端IO线程11服务端工作线程11TCP连接数6565客户端IO线程数22请求次数2000020000QPS7490次/秒7513次/秒平均响应时间0.134毫秒0.133毫秒netty的性能的确可以比肩redis。

从TCP报文观测undertow和redis的性能差异。

Netty 是一个异步的、基于事件驱动的网络应用框架，用于快速开发可维护、高性能的网络服务器和客户端他还是另一个著名网络应用框架 Mina 的重要贡献者Netty 在 Java 网络应用框架中的地位就好比：Spring 框架在 JavaEE 开发中的地位以下的框架都使用了 Netty，因为它们有网络通信需求！开发一个简单的服务器端和客户端加入依赖# 2.2 服务器端代码解读1 处，创建 NioEventLoopGroup，可以简单理解为 后面会详细展开2 处，选择服务 Scoket 实现类

总的来说，关闭Nagle算法在某些特定的网络传输场景下是非常有必要的，可以提高数据传输的实时性和效率。比如在一些实时性要求较高的网络传输场景中，延迟会带来很大的影响，此时关闭Nagle算法可以减少延迟，提高数据传输的实时性。另外，在一些大文件传输或者需要高速传输的场景中，关闭Nagle算法也可以提高数据传输的效率，加快传输速度。Nagle算法是一种用于减少网络传输中的数据包数目的算法，它会将小的数据包合并成一个更大的数据包再进行传输，以减少网络传输中的数据包数量，从而提高网络传输的效率。

这个命令的原理就是redis在内部执行了scan命令，遍历实例中所有的key，然后正对key的类型，分别执行strlen，llen，hlen，scard，zcard命令，来获取string类型的长度，容器类型（list，hash，set，zset）的元素个数。，Redis中保存的键值对是保存在一个字典中的（和Java中的HashMap类似，也是通过数组+链表的方式实现的），key的类型都是string，value的类型可以是string，set，list等。我们经常听到Redis是一个单线程程序。

按照TCP/IP详解卷二的说法，如果listen的那个端点的队列满了（已经完成三次握手的队列，其大小由backlog确定），那么就不回复syn。但是，有个问题，如果多个syn同时到达，那么即使这时候队列未满，也可能接受了这些syn的一部分后队列就满了，那么linux系统如何处理——是否会存在有些链接三次握手完成，但是放不进队列里。之所以设置了timeout，是为了拿到hang住的端口号，测试时可以不设置timeout，然后在没有新的输出时，threadDump，可以看到有多个链接hang在read那里。

异步I/o的技术就是使用AIO。如果考虑性能，poll（）也是不合适的，尽管它可以支持较高的tcp并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分TCP连接上的I/O出现“饥饿”现象。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN-WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。

这时候，我们一定要记住，当出现请求事务大量失败的时候，一定要先看以下具体的错误信息，在继续往下面分析，而不是进行盲目的猜测，这里要提一下高楼老师经常强调的证据链，一定要根据详细的错误信息指向进行下一步分析，不能根据猜测进而通过修改一些参数，或者增加系统资源来解决问题。的值也变得很大，但是仍小于 5000，这也说明之前的 50 的确太小，导致全连接队列被占满，最终影响系统性能，出现大量请求失败,到此，由 TCP 连接队列满导致的问题解决。，严重影响系统的处理能力。为了快速的验证是写日志导致的，

skb在ip层这时候NAT刚完成第一次port（修改dport 1112为dport 80），然后进入了early demux机制，此时的4元组是[saddr:12345 -> daddr:80]，所以这时候匹配上了第一条流的sk，但是系统并不知情有问题了，紧接着NAT第二次改变skb的port，变为[saddr:1112 -> daddr:80]，这个也是后续TCP层延续使用的，虽然这个4元组信息是对的，但是已经没有用了，因为early demux阶段已经获取、保存socket了。出现问题的情景如下图。

对于运行在8核16GB内存的CentOS。

在 Red Hat Enterprise Linux 上调优与 TCP 相关的设置以提高吞吐量、缩短延迟或防止诸如数据包丢失等问题。

定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数,默认值为128.限制了每个端口接收新tcp连接侦听队列的大小。对于一个TCP连接，Server与Client需要通过三次握手来建立网络连接.当三次握手成功后, 我们可以看到端口的状态由LISTEN转变为ESTABLISHED,接着这条链路上就可以开始传送数据了.每一个处于监听(Listen)状态的端口,都有自己的监听队列.监听队列的长度,与如下两方面有关: 　　- somaxconn参数. 　　- 使用该端口的程序中listen()函数.

在Spring Boot应用中，选择合适的Web服务器是至关重要的。常见的Web服务器有Jetty、Tomcat和Undertow。它们各自具有不同的特点和优势，下面将进行详细的比较。

Linux作为一个强大的操作系统，提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中，笔者积累了一些在内网环境应该进行调优的参数。在此分享出来，希望对大家有所帮助。

您将在该文件的参数中看到两个数字:第一个数字是服务器上允许TCP和UDP流量的第一个本地端口，第二个是最后一个本地端口。对于高使用率的系统，您可以将其默认参数更改为32768-61000 -first-last。将上述命令添加到/etc/rc.d/rc.文件中本地脚本文件，下次重新启动系统时，您不必再输入它。

后面跟的 protocol 要求就没有那么严格，它可以是任意词，只要 tcpdump 的 IP 报文头部里的 protocol 字段为 就能匹配上。当你在使用多个过滤器进行组合时，有可能需要用到括号，而括号在 shell 中是特殊符号，因为你需要使用引号将其包含。官方文档手册：https://www.tcpdump.org/manpages/tcpdump.1.html。后面跟的 的关键词是固定的，只能是。根据 tcpflags 进行过滤。基于协议进行过滤：proto。基于端口进行过滤：port。

问题就出在“我不接受数据” 上，如果此时客户端还往服务器发送数据，服务器内核接收到数据，但是发现此时Socket已经close了，则会返回“RST”标志给客户端。然后是客户端和服务器统一使用TCP长连接：客户端使用TCP长连接很容易配置（直接设置HttpClient就好），而服务器配置长连接就比较麻烦了，就拿tomcat来说，需要设置tomcat的maxKeepAliveRequests、connectionTimeout等参数。rst 前第一个消息write 是成功的，而第二条写才会告诉你连接被重置，

接下来调用InputStream的in.read(header, 0, 14);如果available()的返回值为0,说明没有响应数据,可能是对方已经断开连接,另外值得注意的是available()返回的值是非堵塞的,可以被多个线程访问。如果客户端在服务端关闭连接后,没有释放连接,继续试图发送请求和接收响应.总结产生原因,在服务端/客户端单方面关闭连接的情况下,另一方依然以为。客户端和服务端建立tcp的短连接,每次客户端发送一次请求,是由于程序编写的问题,而不是网络的问题引起的.

在本文中，我们将讨论一些影响网络性能的sysctl参数。在深入讨论细节之前，我们首先看一下使用sysctl可以修改的一些内容。NFSProcesses可以通过运行下面的命令来找到所有sysctl参数的完整列表。我们将讨论sysctl中与网络相关的交换机，这些交换机的修改可以大大提高网络的速度。大多数Linux用户都知道这样一个事实:无论您在sysctl中修改什么，它最终都会修改/proc目录中的某个文件。在运行的系统上，你可以将所需的值重定向到/proc文件系统中的文件中，它将立即应用。

这个选项应该根据适合的场景进行判断关闭与否，例如实时性要求比较高的场景，类似用户鼠标操作，键盘输入，触摸屏事件输入，状态更新等这种连续的小分组数据，需要在对端立刻呈现，让用户尽可能感受不到延迟。但是如果网络延迟比较高，采用这种方式，那么会导致网路利用率下降。一般类似HTTP协议请求响应的模型的场景不太需要考虑禁用这个算法，因为在一条TCP连接上发送小报文，不管多小都代表了服务端任务执行的指示，完成了这个请求之后才能继续执行下一个请求，即使Sender端提前发送过去也没有作用，所以。

● 由于nginx也设置了nagle算法，如果没有收到ack，它会等着包的到来，所以就会呈现这个样子 （1）192.168.17.171首先发送一个http get请求（677号包）在发出去的数据还未被确认之前，或者说还没有收到对端的ack之前，新生成的小包是不允许被发送的。● 本文中提到了2个名词，nagle算法与延迟确认，它们看上去很相似，但是并不一样。● nagle算法在与延迟确认互相作用的情况下，会产生严重的延时效果，这是需要警惕的。（4）192.168.17.171回应ack（742号包）

TCP一种面向连接的、可靠的、基于字节流的传输层协议。客户端发送服务端连接请求，等待服务端的回复。服务端收到请求，服务端回复客户端，可以建立连接，并等待。客户端收到回复并发送，确认连接。服务端收到回复。连接成功。四次挥手：与三次握手不同，客户端和服务端都可以主动断开连接。服务A向服务B发送FIN报文段，表示没有数据要传输服务B收到报文段，回复一个ACK报文段，表示也没有数据需要传输了。服务B发送FIN报文段，请求关闭连接。

TCP协议是可靠的通信协议，数据发送方发送给数据接收方的每一个包必须需要数据接收方返回对应的ACK，否则数据发送方就需要重传这个包。这个模式就有点像我和你面对面聊天，你一句我一句。但这种方式的缺点是效率比较低的。如果你说完一句话，我在处理其他事情，没有及时回复你，那你不是要干等着我做完其他事情后，我回复你，你才能说下一句话，很显然这不现实。这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。为解决这个问题，TCP 引入了滑动窗口这个概念。

10,000,10010,000,000Hardwareunder 50%根据我们的观察，在没有minor和majorJVM垃圾收集的情况下，上述所有延迟统计信息都应该在18毫秒的中位数附近。例如，上面的最大延迟是由主要JVM垃圾回收引入的。然而，由于大规模的垃圾回收很少发生，在现实生活中，如此高的延迟每天只会发生几次。我们的客户有大规模部署(数百万最终用户)，其中配置的Java虚拟机不会发生major的JVM垃圾收集。但是，在这些情况下，MigratoryData server每天都会重新启动。

传统的基于进程或线程的并发连接处理模型涉及用单独的进程或线程处理每个连接，并阻塞网络或输入/输出操作。根据应用程序的不同，它在内存和CPU消耗方面可能非常低效。派生一个单独的进程或线程需要准备一个新的运行时环境，包括分配堆和堆栈内存，以及创建一个新的执行上下文。创建这些项目也花费了额外的CPU时间，由于过度的上下文切换导致线程抖动，最终可能导致性能低下。所有这些复杂的问题都体现在像Apache这样的旧web服务器架构中。这是在提供丰富的通用特性和优化服务器资源使用之间的一种权衡。

花1200美元左右买一台1000MHz、2g内存和1000Mbit/s以太网卡的机器。让我们看看——20000个客户端，每个客户端就是50KHz、100Kbytes和50Kbits/秒。对于2万个客户端，每秒从磁盘中取出4千字节并将其发送到网络，不应该需要更多的马力。(顺便说一下，算下来每个客户0.08美元。一些操作系统收取的100美元/客户许可费用开始看起来有点重了!)所以硬件不再是瓶颈。1999年，最繁忙的ftp站点之一cdrom.com实际上通过千兆以太网管道同时处理了10000个客户端。