亿级流量架构之资源隔离思路与方法.docxVIP

亿级流量架构之资源隔离思路与方法 常见的资源,例如磁盘、网络、CPU等等,都会存在竞争的问题,在构建分布式架构时,可以将本来连接在一起的组件、模块、资源拆分开来,以便达到最大的利用效率或功能。资源隔离之后,当某一部分组件消灭毛病时,可以隔离毛病,便利定位的同时,阻挠传播,避开消灭滚雪球以及雪崩效应。 常见的隔离方式有: 线程隔离 进程隔离 集群隔离 机房隔离 读写隔离 动静隔离 爬虫隔离 等等 线程隔离 网络上很多帖子,大多是从框架开头聊的,这儿说人话其实就是对线程进行管理,把核心业务线程与非核心业务线程隔开,不同的业务需要的线程数量不同,可以设置不同的线程池,来举一些框架中应用的例子,例如Netty中的主从多线程、Tomcat恳求隔离、Dubbo线程模型。 Netty主从程模型 主线程担任认证，连接，成功之后交由从线程担任连接的读写操作，大致如下代码： EventLoopGroup bossGroup = new NioEventLoopGroup(1);EventLoopGroup workerGroup = new NioEventLoopGroup();ServerBootstrap b = new ServerBootstrap();b.group(bossGroup, workerGroup); 主线程是一个单线程，从线程是一个默认为cpu*2个数的线程池，可以在我们的业务handler中做一个简约测试： public void channelRead(ChannelHandlerContext ctx, Object msg) { System.out.println(thread name= + Thread.currentThread().getName() + server receive msg= + msg); } 服务端在读取数据的时候打印一下当前的线程： thread name=nioEventLoopGroup-3-1 server receive msg=... 可以发觉这里使用的线程其实和处理io线程是同一个； Dubbo线程隔离模型 Dubbo的底层通信框架其实使用的就是Netty，但是Dubbo并没有直接使用Netty的io线程来处理业务，可以简约在生产者端输出当前线程名称： thread name=DubboServerHandler-15:20880-thread-2,... 可以发觉业务规律使用并不是nioEventLoopGroup线程，这是由于Dubbo有本人的线程模型，可以看看官网供应的模型图： 由图可以晓得,Dubbo服务端接收到恳求后,通过调度器(Dispatcher)分发到不同的线程池，也简约做一些关于调度器(Dispatcher)总结: Dispatcher调度器可以配置消息的处理线程： all?全部消息都派发到线程池，包括恳求，响应，连接大事，断开大事，心跳等。 direct?全部消息都不派发到线程池，全部在 IO 线程上直接执行。 message?只要恳求响应消息派发到线程池，其它连接断开大事，心跳等消息，直接在 IO 线程上执行。 execution?只要恳求消息派发到线程池，不含响应，响应和其它连接断开大事，心跳等消息，直接在 IO 线程上执行。 connection?在 IO 线程上，将连接断开大事放入队列，有序逐一执行，其它消息派发到线程池。 通过看源码可以晓得,Dubbo默认使用的线程池是FixedThreadPool，线程数默认为200； Tomcat恳求线程隔离 Tomcat是Servelet的具体实现,在Tomcat恳求支持四种恳求处理方式分别为:BIO、AIO、NIO、APR BIO模式：堵塞式I/O操作，表示Tomcat使用的是传统Java。I/O操作(即Java.io包及其子包)。Tomcat7以下版本默认情况下是以bio模式运转的，由于每个恳求都要创建一个线程来处理，线程开销较大，不能处理高并发的场景，在几种模式中功能也最低。 NIO模式：同步非堵塞I/O操作，是一个基于缓冲区、并能供应非堵塞I/O操作的API，它拥有比传统I/O操作具有更好的并发功能。关于NIO,可以参考我这篇博客:NIO非堵塞网络编程原理 在Tomcat7版本之后,Tomcat把连接介入和业务处理拆分成两个线程池来处理，即: 可以使用独立的线程池来维护servlet的创建。连接器connector能介入的恳求确定比业务简单的servlet处理的个数要多，在两头，Tomcat加入了队列，来等待servlet线程池空闲。这两步是Tomcat内核完成的，在一阶段无法区分具体业务或资源，所以只能在连接介入，servlet初始化完成后我们