netty 真的有那么高并发吗_百度知道
netty 真的有那么高并发吗
我有更好的答案
个交易处理1个连接吗？如果是这样，否则不会比你原来的性能差那么多，那就不要用长连接啊。如果不是这样，1个连接处理多个交易，那就是你程序的问题了，用线程池跑交易队列试试。我没用过netty，但我用过nio，给你个建议，处理完就关了呗
其他类似问题
为您推荐：
netty的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Netty3并发优化之ExecutionHandler多线程处理方案 - 推酷
Netty3并发优化之ExecutionHandler多线程处理方案
Netty 4 改进了不少,此篇针对Netty 3来讲【项目用的最多的还是3】
（1）客户端发送一个请求A（长连接），在服务器端的业务层需要20秒以上才能接收到。
（2）客户端发送一个请求B（端连接），在服务器端的业务层可以迅速接收到。
从现象大致知道问题出在服务器端的网络接收层，大量通过长连接发送过来的请求都堵塞在网络层得不到处理（在网络层排队，还没到应用层）。
Boss线程（一个服务器端口对于一个）—接收到客户端连接—生成Channel—交给Work线程池（多个Work线程）来处理。
具体的Work线程—读完已接收的数据到ChannelBuffer—触发ChannelPipeline中的ChannelHandler链来处理业务逻辑。
注意：执行ChannelHandler链的整个过程是同步的，如果业务逻辑的耗时较长，会将导致Work线程长时间被占用得不到释放，从而影响了整个服务器的并发处理能力。
所以，为了提高并发数，一般通过ExecutionHandler线程池来异步处理ChannelHandler链（worker线程在经过ExecutionHandler后就结束了，它会被ChannelFactory的worker线程池所回收）。在Netty中，只需要增加一行代码：
public ChannelPipeline getPipeline() {
return Channels.pipeline(
new DatabaseGatewayProtocolEncoder(),
new DatabaseGatewayProtocolDecoder(),
executionHandler, // Must be shared
new DatabaseQueryingHandler());
ExecutionHandler executionHandler = new ExecutionHandler(
new OrderedMemoryAwareThreadPoolExecutor(16, 48576))
当我们引入ExecutionHandler后，原本同步的ChannelHandler链在经过 ExecutionHandler后就结束了，它会被ChannelFactory的worker线程池所回收，而剩下的ChannelHandler链将由ExecutionHandler的线程池接手处理。
对于ExecutionHandler需要的线程池模型，Netty提供了两种可选：
1） MemoryAwareThreadPoolExecutor 通过对线程池内存的使用控制，可控制Executor中待处理任务的上限（超过上限时，后续进来的任务将被阻塞），并可控制单个Channel待处理任务的上限，防止内存溢出错误；
2） OrderedMemoryAwareThreadPoolExecutor 是 MemoryAwareThreadPoolExecutor 的子类。除了MemoryAwareThreadPoolExecutor 的功能之外，它还可以保证同一Channel中处理的事件流的顺序性，这主要是控制事件在异步处理模式下可能出现的错误的事件顺序，但它并不保证同一Channel中的事件都在一个线程中执行（通常也没必要）。
Thread X: --- Channel A (Event A1) --.
.-- Channel B (Event B2) --- Channel B (Event B3) ---&
Thread Y: --- Channel B (Event B1) --'
'-- Channel A (Event A2) --- Channel A (Event A3) ---&
上图表达的意思有几个：
（1）对整个线程池而言，处理同一个Channel的事件，必须是按照顺序来处理的。例如，必须先处理完Channel A (Event A1) ，再处理Channel A (Event A2)、Channel A (Event A3)
（2）同一个Channel的多个事件，会分布到线程池的多个线程中去处理。
（3）不同Channel的事件可以同时处理（分担到多个线程），互不影响。
OrderedMemoryAwareThreadPoolExecutor 的这种事件处理有序性是有意义的，因为通常情况下，请求发送端希望服务器能够按照顺序处理自己的请求，特别是需要多次握手的应用层协议。例如：XMPP协议。
现在回到具体业务上来，我们这里的认证服务也使用了OrderedMemoryAwareThreadPoolExecutor。认证服务的其中一个环节是使用长连接，不断处理来自另外一个服务器的认证请求。通信的数据包都很小，一般都是200个字节以内。一般情况下，处理这个过程很快，所以没有什么问题。但是，由于认证服务需要调用第三方的接口，如果第三方接口出现延迟，将导致这个过程变慢。一旦一个事件处理不完，由于要保持事件处理的有序性，其他事件就全部堵塞了！而短连接之所以没有问题，是因为短连接一个Channel就一个请求数据包，处理完Channel就关闭了，根本不存在顺序的问题，所以在业务层可以迅速收到请求，只是由于同样的原因（第三方接口），处理时间会比较长。
其实，认证过程都是独立的请求数据包（单个帐号），每个请求数据包之间是没有任何关系的，保持这样的顺序没有意义！
1、去掉OrderedMemoryAwareThreadPoolExecutor，改用MemoryAwareThreadPoolExecutor。
2、减少调用第三方接口的超时时间，让处理线程尽早回归线程池。
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
排版有问题
没有分页内容
视频无法显示
图片无法显示让天下没有难学的技术
最近在学习Netty框架，对着教程上写了个简单的netty应用，可是死活调试不成功，对着程序跟教程上看了几遍也找不到原因，后来又重新写了一遍，服务端程序终于调试成功，原因出在了那个@Skip注释上了，代码如下：
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 3.00 out of 5)
Loading...
定义为一个通往网络socket或者一个由I/O读写能力的组件。
通道提供：
1，通道的当前状态，打开？已连接？
2，跟通道关联的配置信息ChannelConfig，包括buffer大小等。
3，通道支持的I/O操作，如读、写、连接、绑定等。
4，跟通道关联的ChannelPipeline，用来处理通道的I/O事件和请求。
原创文章，转载请注明： 转载自
本文链接地址:
(还没有评分)
Loading...
原文地址：
译者:光辉勇士
校对：郭蕾
现如今我们使用通用的应用程序或者类库来实现系统之间地互相访问，比如我们经常使用一个HTTP客户端来从web服务器上获取信息，或者通过web service来执行一个远程的调用。
然而，有时候一个通用的协议和他的实现并没有覆盖一些场景。比如我们无法使用一个通用的HTTP服务器来处理大文件、电子邮件、近实时消息比如财务信息和多人游戏数据。我们需要一个合适的协议来处理一些特殊的场景。例如你可以实现一个优化的Ajax的聊天应用、媒体流传输或者是大文件传输的HTTP服务器，你甚至可以自己设计和实现一个新的协议来准确地实现你的需求。
原创文章，转载请注明： 转载自
本文链接地址:
(21 votes, average: 4.81 out of 5)
Loading...
声明：本文是《》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
在开始本节之前，我先讲一个亲身经历的故事：曾经有两个项目组同时用到了NIO编程技术，一个项目组选择自己开发NIO服务端，直接使用JDK原生的API，结果2个多月过去了，他们的NIO服务端始终无法稳定，问题频出。由于NIO通信是它们的核心组件之一，因此，项目的进度受到了严重的影响，领导对此非常恼火。另一个项目组直接使用Netty作为NIO服务端，业务的定制开发工作量非常小，测试表明，功能和性能都完全达标，项目组几乎没有在NIO服务端上花费额外的时间和精力，项目进展也非常顺利。
这两个项目组的不同遭遇提醒我们：开发出高质量的NIO程序并不是一件简单的事情，除去NIO固有的复杂性和BUG不谈，作为一个NIO服务端需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等等，如果你没有足够的NIO编程经验积累，一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，需要重启服务器，这种非正常停机会带来巨大的损失。
从可维护性角度看，由于NIO采用了异步非阻塞编程模型，而且是一个IO线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法有效调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。
原创文章，转载请注明： 转载自
本文链接地址:
(5 votes, average: 4.20 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
2.5.1.概念澄清
为了防止由于对一些技术概念和术语的理解或者叫法不一致引起歧义，本小节特意对本书中的专业术语或者技术用语做下声明，如果它们与其它的一些技术书籍术语不一致，请以本小节的解释为准。
2.5.1.1. 异步非阻塞IO
很多人喜欢将JDK1.4提供的NIO框架称为异步非阻塞IO，但是，如果严格按照Unix网络编程模型和JDK的实现进行区分，实际上它只能被称为非阻塞IO，不能叫异步非阻塞IO。在早期的JDK1.4和1.5 update10版本之前，JDK的Selector基于select/poll模型实现，它是基于IO复用技术的非阻塞IO，不是异步IO。在JDK1.5 update10和linux core2.6以上版本，sun优化了Selctor的实现，它底层使用epoll替换了select/poll,上层的API并没有变化，我们可以认为是JDK NIO的一次性能优化，但是它仍旧没有改变IO的模型。相关优化的官方说明如下：
原创文章，转载请注明： 转载自
本文链接地址:
(3 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
执行TimeServer，运行结果如下：
原创文章，转载请注明： 转载自
本文链接地址:
(1 votes, average: 1.00 out of 5)
Loading...
感谢支付宝同事[]在本站发布此文。
上文讲了对netty-mina的线程模型以及任务调度粒度的理解，这篇则主要是讲nio编程中的注意事项，netty-mina的对这些注意事项的实现方式的差异，以及业务层会如何处理这些注意事项。
1. 数据是如何write出去的
java nio如果是non-blocking的话，在每次write(bytes[N])的时候，并不会将N字节全部write出去，每次write仅一部分（具体大小和tcp_write_buffer有关）。那么，mina和netty是怎么处理这种情况的呢？
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 3.50 out of 5)
Loading...
感谢支付宝同事[]在本站发布此文。
这博文的系列主要是为了更好的了解一个完整的nio框架的编程细节以及演进过程，我选了同父（Trustin Lee）的两个框架netty与mina做对比。版本涉及了netty3.x、netty4.x、mina1.x、mina2.x、mina3.x。这里并没有写netty5.x的细节，看了，似乎有一些比较有意思的改动，准备单独写一篇netty4.x与netty5.x的不同。
原创文章，转载请注明： 转载自
本文链接地址:
(9 votes, average: 4.11 out of 5)
Loading...
《》是全球第二本、中国第一本Netty教材，它由华为平台中间件资深架构设计师李林锋撰写，作者有6年多的NIO设计和开发实战经验，多次受邀进行Netty和
NIO编程培训。
本书基于最新的Netty5.0 版本撰写，从Netty开发环境的搭建，到第一个基于Netty的NIO服务端和客户端程序的开发，一步步的让读者从入门到精通，熟练的掌握基于Netty
的NIO开发，理解Netty的架构设计原理，可以对Netty进行深度的定制设计和开发。
原创文章，转载请注明： 转载自
本文链接地址:
(3 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
异步非阻塞IO版本的时间服务器服务端已经介绍完毕，下面我们继续看客户端的实现。
首先看下客户端主函数的实现，AIO时间服务器客户端
TimeClient：
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
NIO2.0引入了新的异步通道的概念，并提供了异步文件通道和异步套接字通道的实现。异步通道提供两种方式获取获取操作结果：
通过java.util.concurrent.Future类来表示异步操作的结果；
在执行异步操作的时候传入一个java.nio.channels.
CompletionHandler接口的实现类作为操作完成的回调。
NIO2.0的异步套接字通道是真正的异步非阻塞IO,它对应Unix网络编程中的事件驱动IO（AIO），它不需要通过多路复用器（Selector）对注册的通道进行轮询操作即可实现异步读写，简化了NIO的编程模型。
下面还是通过代码来熟悉NIO2.0 AIO的相关类库，我们仍旧以时间服务器为例程进行讲解。
原创文章，转载请注明： 转载自
本文链接地址:
(2 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
我们首先还是看下如何对TimeClient进行改造:
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 3.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
步骤一：打开SocketChannel，绑定客户端本地地址（可选，默认系统会随机分配一个可用的本地地址），示例代码如下：
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
我们将在TimeServer例程中给出完整的NIO创建的时间服务器源码：
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 4.75 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
下面，我们对NIO服务端的主要创建过程进行讲解和说明，作为NIO的基础入门，我们将忽略掉一些在生产环境中部署所需要的一些特性和功能。
步骤一：打开ServerSocketChannel，用于监听客户端的连接，它是所有客户端连接的父管道，代码示例如下：
原创文章，转载请注明： 转载自
本文链接地址:
(5 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
在介绍NIO编程之前，我们首先需要澄清一个概念，NIO到底是什么的简称？有人称之为New IO，因为它相对于之前的IO类库是新增的，所以被称为New IO，这是它的官方叫法。但是，由于之前老的IO类库是阻塞IO，New IO类库的目标就是要让JAVA支持非阻塞IO，所以，更多的人喜欢称之为非阻塞IO（Non-block IO），由于非阻塞IO更能够体现NIO的特点，所以本书使用的NIO都指的是非阻塞IO。
与Socket类和ServerSocket类相对应，NIO也提供了SocketChannel和ServerSocketChannel两种不同的套接字通道实现。这两种新增的通道都支持阻塞和非阻塞两种模式。阻塞模式使用非常简单，但是性能和可靠性都不好，非阻塞模式正好相反。开发人员一般可以根据自己的需要来选择合适的模式，一般来说，低负载、低并发的应用程序可以选择同步阻塞IO以降低编程复杂度。但是对于高负载、高并发的网络应用，需要使用NIO的非阻塞模式进行开发。
下面的小节首先介绍NIO编程中的一些基本概念，然后通过NIO服务端的序列图和源码讲解，让大家快速的熟悉NIO编程的关键步骤和API的使用。如果你已经熟悉了NIO编程，可以跳过2.3章节继续学习后面的章节。
原创文章，转载请注明： 转载自
本文链接地址:
(5 votes, average: 4.60 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
为了解决同步阻塞IO面临的一个链路需要一个线程处理的问题，后来有人对它的线程模型进行了优化，后端通过一个线程池来处理多个客户端的请求接入，形成客户端个数M：线程池最大线程数N的比例关系，其中M可以远远大于N，通过线程池可以灵活的调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。 下面，我们结合连接模型图和源码，对伪异步IO进行分析，看它是否能够解决同步阻塞IO面临的问题。
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 4.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章，感谢博文视点授权发布样章，禁止以任何形式转载此文。
网络编程的基本模型是Client/Server模型，也就是两个进程之间进行相互通信，其中服务端提供位置信息（绑定的IP地址和监听端口），客户端通过连接操作向服务端监听的地址发起连接请求，通过三次握手建立连接，如果连接建立成功，双方就可以通过网络套接字（Socket）进行通信。
在基于传统同步阻塞模型开发中，ServerSocket负责绑定IP地址，启动监听端口，Socket负责发起连接操作，连接成功之后，双方通过输入和输出流进行同步阻塞式通信。
原创文章，转载请注明： 转载自
本文链接地址:
(3 votes, average: 5.00 out of 5)
Loading...
声明：本文是《Netty 权威指南》的样章目录，感谢博文视点授权发布样章，禁止以任何形式转载此文。
在本章节，我们分别对JDK的BIO、NIO和JDK1.7最新提供的NIO2.0的使用进行详细说明，通过流程图和代码讲解，让大家体会到随着Java IO类库的不断发展和改进，基于Java的网络编程会变得越来越简单，随着异步IO功能的增强，基于Java NIO开发的网络服务器甚至不逊色于采用C++开发的网络程序。
本章主要内容包括：
传统的同步阻塞式IO编程
基于NIO的非阻塞编程
基于NIO2.0 的异步非阻塞（AIO）编程
为什么要使用NIO编程
为什么选择Netty
原创文章，转载请注明： 转载自
本文链接地址:
(5 votes, average: 4.20 out of 5)
Loading...
一：Netty、NIO、多线程？
时隔很久终于又更新了！之前一直迟迟未动也是因为积累不够，后面比较难下手。过年期间发布了一个，看完也是收获不少。前面的文章我们分析了Netty的结构，这次咱们来分析最错综复杂的一部分-Netty中的多线程以及NIO的应用。
理清NIO与Netty的关系之前，我们必须先要来看看Reactor模式。Netty是一个典型的多线程的Reactor模式的使用，理解了这部分，在宏观上理解Netty的NIO及多线程部分就不会有什么困难了。
本篇文章依然针对Netty 3.7，不过因为也看过一点Netty 5的源码，所以会有一点介绍。
原创文章，转载请注明： 转载自
本文链接地址:
(4 votes, average: 4.50 out of 5)
Loading...让天下没有难学的技术
Netty-Mina深入学习与对比（一）
Netty-Mina深入学习与对比（一）
感谢支付宝同事[]在本站发布此文。
这博文的系列主要是为了更好的了解一个完整的nio框架的编程细节以及演进过程，我选了同父（Trustin Lee）的两个框架netty与mina做对比。版本涉及了netty3.x、netty4.x、mina1.x、mina2.x、mina3.x。这里并没有写netty5.x的细节，看了，似乎有一些比较有意思的改动，准备单独写一篇netty4.x与netty5.x的不同。
netty从twitter发布的这篇《》文章让国内Java界为之一振，也小火了一把，同时netty的社区发展也不错，版本迭代非常快，半年不关注大、小版本就发了好几轮了。但是mina就有点淡了，github上面它最后大多数代码最后的修改日期均在2013年，不过我从个人情感上还是挺喜欢mina3的代码，没有太多的用不上的功能（支持各种协议啥的），跑自带的benchmark性能也比netty4好一些。但是如果是生产用的话，就偏向netty多一些了，毕竟社区活跃，版本迭代也快。
1. mina、netty的线程模型
mina与netty都是Trustin Lee的作品，所以在很多方面都十分相似，他们线程模型也是基本一致，采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。由main reactor处理连接相关的任务：accept、connect等，当连接处理完毕并建立一个socket连接（称之为session）后，给每个session分配一个sub reactor，之后该session的所有IO、业务逻辑处理均交给了该sub reactor。每个reactor均是一个线程，sub reactor中只靠内核调度，没有任何通信且互不打扰。
在我自己的博客里面[]也对netty的线程模型有一定的介绍。现在来讲讲我对线程模型演进的一些理解：
Thread per Connection: 在没有nio之前，这是传统的java网络编程方案所采用的线程模型。即有一个主循环，socket.accept阻塞等待，当建立连接后，创建新的线程/从线程池中取一个，把该socket连接交由新线程全权处理。这种方案优缺点都很明显，优点即实现简单，缺点则是方案的伸缩性受到线程数的限制。
Reactor in Single Thread: 有了nio后，可以采用IO多路复用机制了。我们抽取出一个单线程版的reactor模型，时序图见下文，该方案只有一个线程，所有的socket连接均注册在了该reactor上，由一个线程全权负责所有的任务。它实现简单，且不受线程数的限制。这种方案受限于使用场景，仅适合于IO密集的应用，不太适合CPU密集的应用，且适合于CPU资源紧张的应用上。
Reactor + Thread Pool: 方案2由于受限于使用场景，但为了可以更充分的使用CPU资源，抽取出一个逻辑处理线程池。reactor仅负责IO任务，线程池负责所有其它逻辑的处理。虽然该方案可以充分利用CPU资源，但是这个方案多了进出thread pool的两次上下文切换。
Reactors in threads: 基于方案3缺点的考虑，将reactor分成两个部分。main reactor负责连接任务（accept、connect等），sub reactor负责IO、逻辑任务，即mina与netty的线程模型。该方案适应性十分强，可以调整sub reactor的数量适应CPU资源紧张的应用；同时CPU密集型任务时，又可以在业务处理逻辑中将任务交由线程池处理，如方案5。该方案有一个不太明显的缺点，即session没有分优先级，所有session平等对待均分到所有的线程中，这样可能会导致优先级低耗资源的session堵塞高优先级的session，但似乎netty与mina并没有针对这个做优化。
Reactors in threads + Threads pool: 这也是我所在公司应用框架采用的模型，可以更为灵活的适应所有的应用场景：调整reactor数量、调整thread pool大小等。
以上图片及总结参考：《Linux多线程服务端编程》
2. mina、netty的任务调度粒度
mina、netty在线程模型上并没有太大的差异性，主要的差异还是在任务调度的粒度的不同。任务从逻辑上我给它分为成三种类型：连接相关的任务（bind、connect等）、写任务（write、flush）、调度任务（延迟、定时等），读任务则由selector加循环时间控制了。mina、netty任务调度的趋势是逐渐变小，从session级别的调度 -& 类型级别任务的调度 -& 任务的调度。
mina-1.1.7: SocketIoProcessor$Worker.run
mina-2.0.4: AbstractPollingIoProcessor$Processor.run
mina-3.0.0.M3-SNAPSHOT: AbstractNioSession.processWrite
netty-3.5.8.Final: AbstractNioSelector.run
netty-4.0.6.Final: NioEventLoop.run
mina1、2的任务调度粒度为session。mina会将有IO任务的的session写入队列中，当循环执行任务时，则会轮询所有的session，并依次把session中的所有任务取出来运行。这样粗粒度的调度是不公平调度，会导致某些请求的延迟很高。
mina3的模型改动比较大，代码相对就比较难看了，我仅是随便扫了一下，它仅提炼出了writeQueue。
而netty3的调度粒度则是按照IO操作，分成了registerTaskQueue、writeTaskQueue、eventQueue三个队列，当有IO任务时，依次processRegisterTaskQueue、processEventQueue、processWriteTaskQueue、processSelectedKeys(selector.selectedKeys)。
netty4可能觉得netty3的粒度还是比较粗，将队列细分成了taskQueue和delayedTaskQueue，所有的任务均放在taskQueue中，delayedTaskQueue则是定时调度任务，且netty4可以灵活配置task与selectedKey处理的时间比例。
BTW: netty3.6.0之后，所有的队列均合并成了一个taskQueue
有意思的是，netty4会优先处理selectedKeys，然后再处理任务，netty3则相反。mina1、2则是先处理新建的session，再处理selectedKeys，再处理任务。
难道selectedKeys处理顺序有讲究么？
原创文章，转载请注明： 转载自
本文链接地址:
支付宝中间件研发工程师，现专注于分布式系统、网络编程领域。 (Blog: ，Weibo: ）
Latest posts by 易鸿伟 ()
Related posts:
(9 votes, average: 4.11 out of 5)
Loading...