netty与vert.x的区别和联系

Vertx是一个用于下一代异步、可伸缩、并发应用的框架，旨在为JVM提供一个Nodejs的替代方案。开发者可以通过它使用JavaScript、Ruby、Groovy、Java、甚至是混合语言来编写应用。

在内部，一个vertx实例会管理着一个小的线程集合，每个线程针对服务器上的一个可用内核。基本上每个线程都实现了一个事件循环。当部署一个vertx应用实例（又叫做verticle）时，服务器会选择一个事件循环分配给该实例。接下来针对该实例的任务都会通过该线程进行分配。由于在某一时刻可能会有成千上万个verticle在运行，因此在同一时刻会将单个事件循环指定给多个verticle。

Verticle可与运行在相同或不同vertx实例中的其他verticle进行通信，这是通过消息事件总线实现的，它类似于Erlang的actor模型。消息传递旨在让系统能够在多个可用核心上进行扩展而无需以多线程的方式来执行verticle代码。

事件总线是分布式的，并不只会跨越服务器，还会渗透进客户端的JavaScript以处理“实时”的Web应用。

除了并发与消息传递外，vertx还具有如下特性：

TCP/SSL服务器与客户端

HTTP/HTTPS服务器与客户端

WebSockets/SockJS支持

InfoQ有幸采访到了VMWare的高级工程师Tim Fox以了解vertx：

InfoQ：能否从架构上介绍一下vertx及其构建方式？

Tim：vertx的核心是用Java编写的，接下来我们为每一种支持的JVM语言编写了一个薄薄的API层，这样每种语言都有一个适合于该语言的API了。我们并没有向这些语言直接公开Java API。这意味着Ruby用户会通过Ruby的方式编写代码，JS用户会通过JS的方式编写代码。

InfoQ：能否描述一下在vertx上典型的开发流程么，特别是与开发者使用Nodejs的体验进行一下对比？

我觉得这与nodejs是非常类似的。实际的工作流程取决于你是在本地还是云中运行应用。但这并非vertx所特有的。

InfoQ：就调试、监控与运维来看，在JVM与Nodejs上运行实时应用有何差别？

我想说监控与运维实际上与部署vertx的环境之间的关系更为密切而非vertx本身。比如说，如果将vertx部署到云中，那么云提供商可能就会为你提供监控。顺便说一下，社区成员目前已经在OpenShift与Heroku上运行了Vertx。我们希望不久之后CloudFoundry支持就会到来。

InfoQ：vertx与Nodejs有什么基准比较么？

我们尚未发布任何的官方基准。但我自己已经完成了一些，在我所做的测试中，vertx的性能与可伸缩性都远远超越了nodejs。我希望在不久之后能够发布一些基准。

InfoQ：vertx与Netty相比如何呢？

Netty是个很棒的底层IO库。Vertx实际上使用了Netty。但vertx是个用于编写异步应用的完整。Vertx还提供了一个组件模型、文件IO及各种Netty所没有的东西。我要说的是，在JVM世界中，Vertx是更类似于Akka（也使用了Netty）之类的完整框架。

我的世界手机版服务器进不去

　　请检查以下几点：

　　1、查看WIFI

　　WiFi的话，就是你自己的网络问题了，这里不需要多说。

　　2、你有改名字吗？

　　有很多服务器是禁止未改名的玩家进入的，主要是防止小学生在里面乱来，修改名字后进入就没事了。

　　3、服务器问题（有些是要同一个WIFI）

　　服务器问题的话，可能是服务器暂时关闭，目前是进不去，可能要等一段时间。

Connection reset by peer的常见原因：

1）服务器的并发连接数超过了其承载量，服务器会将其中一些连接关闭；

如果知道实际连接服务器的并发客户数没有超过服务器的承载量，则有可能是中了病毒或者木马，引起网络流量异常。可以使用netstat -an查看网络连接情况。

2）客户关掉了浏览器，而服务器还在给客户端发送数据；

3）浏览器端按了Stop；

这两种情况一般不会影响服务器。但是如果对异常信息没有特别处理，有可能在服务器的日志文件中，重复出现该异常，造成服务器日志文件过大，影响服务器的运行。可以对引起异常的部分，使用try…catch捕获该异常，然后不输出或者只输出一句提示信息，避免使用eprintStackTrace();输出全部异常信息。

4）防火墙的问题；

如果网络连接通过防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个TCP的会话，关闭后在读写，就会导致异常。 如果关闭防火墙，解决了问题，需要重新配置防火墙，或者自己编写程序实现TCP的长连接。实现TCP的长连接，需要自己定义心跳协议，每隔一段时间，发送一次心跳协议，双方维持连接。

5）JSP的buffer问题。

JSP页面缺省缓存为8k，当JSP页面数据比较大的时候，有可能JSP没有完全传递给浏览器。这时可以适当调整buffer的大小。

这个问题有点搞笑！！！

用户多，不代表你服务器访问量大，访问量大不一定你服务器压力大！我们换成专业点的问题，高并发下怎么优化能避免服务器压力过大？

1，整个架构:可采用分布式架构，利用微服务架构拆分服务部署在不同的服务节点，避免单节点宕机引起的服务不可用！

2，数据库:采用主从复制，读写分离，甚至是分库分表，表数据根据查询方式的不同采用不同的索引比如btree，hash，关键字段加索引，sql避免复合函数，避免组合排序等，避免使用非索引字段作为条件分组，排序等！减少交互次数，一定不要用select！

3，加缓存:使用诸如memcache，redis，ehcache等缓存数据库定义表，结果表等等，数据库的中间数据放缓存，避免多次访问修改表数据！登录信息session等放缓存实现共享！诸如商品分类，省市区，年龄分类等不常改变的数据，放缓存，不要放数据库！

同时要避免缓存雪崩和穿透等问题的出现导致缓存崩溃！

4，增量统计:不要实时统计大量的数据，应该采用晚间定时任务统计，增量统计等方式提前进行统计，避免实时统计的内存，CPU压力！

5，加服务器:等大文件，一定要单独经过文件服务器，避免IO速度对动态数据的影响！保证系统不会因为文件而崩溃！

6，HTML文件，枚举，静态的方法返回值等静态化处理，放入缓存！

7，负载均衡:使用nginx等对访问量过大的服务采用负载均衡，实现服务集群，提高服务的最大并发数，防止压力过大导致单个服务的崩溃！

8，加入搜索引擎:对于sql中常出现的like，in等语句，使用lucence或者solr中间件，将必要的，依赖模糊搜索的字段和数据使用搜索引擎进行存储，提升搜索速度！#注意:全量数据和增量数据进行定时任务更新！

9，使用消息中间件:对服务之间的数据传输，使用诸如rabbitmq，kafka等等分布式消息队列异步传输，防止同步传输数据的阻塞和数据丢失！

10，抛弃tomcat:做web开发，接触最早的应用服务器就是tomcat了，但是tomcat的单个最大并发量只能不到1w！采取netty等actor模型的高性能应用服务器！

11，多线程:现在的服务器都是多核心处理模式，如果代码采用单线程，同步方式处理，极大的浪费了CPU使用效率和执行时间！

12，避免阻塞:避免bio，blockingqueue等常常引起长久阻塞的技术，而改为nio等异步处理机制！

13，CDN加速:如果访问量实在过大，可根据请求来源采用CDN分流技术，避免大流量完成系统崩溃！

14，避免低效代码:不要频繁创建对象，引用，少用同步锁，不要创建大量线程，不要多层for循环！

还有更多的细节优化技术，暂时想不起来了！

通常情况下是不可以突破的,端口有限制单独对外提供请求的服务不用考虑端口数量问题,监听某一个端口即可但是向提供代理服务器,就不得不考虑端口数量受限问题了当前的1M并发连接测试,也需要在客户端突破6万可用端口的限制端口为16进制,那么2的16次方值为65536,在linux系统里面,1024以下端口都是超级管理员用户（如root）才可以使用,普通用户只能使用大于1024的端口值

服务器是只监听一个端口，所有的客户端连接，都是连接到服务器的同一个端口上的。也就是说服务器只是用了一个端口。就比如Http服务器。默认只用了80端口。

nio 在linux上使用的是epoll ，epoll支持在一个进程中打开的FD是操作系统最大文件句柄数，而不是你所说的16位short表示的文件句柄。 而 select模型 单进程打开的FD是受限的 select模型默认FD是1024 。操作系统最大文件句柄数跟内存有关，1GB内存的机器上，大概是10万个句柄左右。

上一篇文章我们介绍了如何使用SpringBoot+Netty开发JT808网关，这一篇文章将压力测试JT808网关。

网上看过一些百万级部标网关的文章，没有给出服务器配置，没有给出发送速率，没有给出测试报告，完全就是噱头，我们要保持清醒的头脑，一切以数据说话。

使用模拟终端压测工具，压测工具会发送五种消息：终端注册、终端注销、终端鉴权、心跳、位置汇报。JT808网关接收并解析位置信息后发送到RabbitMQ，gnss-web订阅RabbitMQ的位置消息并统计收到的位置数量。对比压测工具总共发送的位置数量和web收到的位置数量是否一致。

由于交通部的压力检测要求不高，我们不按交通部的要求压测，测试时会将发送速率提高2倍以上，看系统的承压能力达到多少。

服务器：腾讯云和阿里云Linux

配置：CPU:4核 内存:8G 带宽:5M

环境：JDK13，RabbitMQ，Redis，其中RabbitMQ和Redis使用Docker容器创建

测试程序：网关jt808-server、web后台gnss-web

消息序列化：ProtoBuf

模拟压测终端台数：3333、10000、12000

流程：启动docker容器的Redis和RabbitMQ，再启动gnss-web，加载20000台终端的信息到Redis缓存，再启动jt808-server。

RabbitMQ的吞吐量：

服务器负载信息：

web收到的位置数量：2523083

查看JT808网关线程，未发现有BLOCK阻塞线程。

总结：压测时间：40分钟，位置数量：1千万，RabbitMQ吞吐量：5000/s，CPU占用率：75-80%，带宽：35M

CPU比以前下降了不少：

JT808网关线程良好，未发现有BLOCK阻塞线程

执行GC垃圾回收后，内存一下子下降了，绿色代表快照前的状态，如果进度条有红色，则表示有内存泄漏。这里全部为绿色，没有出现内存泄漏：