语音交友app开发之资源隔离的思路与方法 _线程

语音交友app开发为什么要资源隔离
常见的资源,例如磁盘、网络、CPU等等,都会存在竞争的问题,在语音交友app开发分布式架构时,可以将原本连接在一起的组件、模块、资源拆分开来,以便达到最大的利用效率或性能。资源隔离之后,当某一部分组件出现故障时,可以隔离故障,方便定位的同时,阻止传播,避免出现滚雪球以及雪崩效应。
常见的隔离方式有:
线程隔离
网络上很多帖子,大多是从框架开始聊的,这儿说人话其实就是对语音交友app开发线程进行治理,把核心业务线程与非核心业务线程隔开,不同的业务需要的线程数量不同,可以设置不同的线程池,来举一些框架中应用的例子,例如Netty中的主从多线程、请求隔离、Dubbo线程模型。
Netty主从程模型
语音交友app开发主线程负责认证，连接，成功之后交由从线程负责连接的读写操作，大致如下代码：
【语音交友app开发之资源隔离的思路与方法】EventLoopGroup bossGroup = new NioEventLoopGroup(1);EventLoopGroup workerGroup = new NioEventLoopGroup();ServerBootstrap b = new ServerBootstrap();b.group(bossGroup, workerGroup);
主线程是一个单线程，从线程是一个默认为cpu*2个数的线程池，可以在我们的业务中做一个简单测试：
public void channelRead(ChannelHandlerContext ctx, Object msg) {System.out.println("thread name=" + Thread.currentThread().getName() + " server receive msg=" + msg);}
语音交友app开发服务端在读取数据的时候打印一下当前的线程：
thread name=nioEventLoopGroup-3-1 server receive msg="..."
可以发现这里使用的线程其实和处理io线程是同一个；
Dubbo线程隔离模型
Dubbo的底层通信框架其实使用的就是Netty，但是Dubbo并没有直接使用Netty的io线程来处理语音交友app开发业务，可以简单在生产者端输出当前线程名称：
thread name=DubboServerHandler-192.168.1.115:20880-thread-2,...
可以发现语音交友app开发业务逻辑使用并不是线程，这是因为Dubbo有自己的线程模型，可以看看官网提供的模型图：
由图可以知道,Dubbo服务端接收到请求后,通过调度器()分发到不同的线程池，也简单做一些关于调度器()总结:
调度器可以配置消息的处理线程：
通过看源码可以知道,Dubbo默认使用的线程池是，线程数默认为200；
请求线程隔离
是的具体实现,在请求支持四种请求处理方式分别为:BIO、AIO、NIO、APR
BIO模式：
阻塞式I/O操作，表示使用的是传统Java 。I/O操作(即Java.io包及其子包) 。以下版本默认情况下是以bio模式运行的，由于语音交友app开发每个请求都要创建一个线程来处理，线程开销较大，不能处理高并发的场景，在几种模式中性能也最低。
NIO模式：
同步非阻塞I/O操作，是一个基于缓冲区、并能提供非阻塞I/O操作的API，它拥有比传统I/O操作具有更好的并发性能。
在版本之后,把连接介入和业务处理拆分成两个线程池来处理，即:
可以使用独立的线程池来维护的创建。连接器能介入的请求肯定比业务复杂的处理的个数要多，在中间，加入了队列，来等待线程池空闲。这两步是内核完成的，在一阶段无法区分语音交友app开发具体业务或资源，所以只能在连接介入，初始化完成后我们根据自己的业务线去划分独立的连接池。
这样做,语音交友app开发独立的业务或资源中如果出现崩溃，不会影响其他的业务线程，从而达到资源隔离和服务降级的效果。