一.项目架构
主要:
前端:MUI+H5PLUS
后端: SpringBoot+netty
计划:
后端架构主要使用:Springboot(2.0)
聊天消息收发:netty(4.X))
数据库:Mysql,MariaDB
文件存储:Nginx+基于fastdfs搭建的图片分布式服务器
持久层:Mybatis
服务器:腾讯云
BIO,NIO,AIO
BIO
生活中的事例:
比如上厕所,所有坑位都满了,那么我们只能一直在外面干等着不做其他事, 并且主动的观察有哪个坑位会空出来
NIO
事例:
(在这里坑位可以理解为channel)
现在上厕所的人如果没有坑位,则不会再在外面干等,而是去做其他事情,然后时不时回来看下是否有坑位,有则占据.
关于NIO:
多个Client在访问server时,会通过一个单线程的Selector(叫做选择器,或者多路复用器),
Selector是一个线程,该线程会主动轮询,当客户端与服务端建立链接的时候,就会产生一个Channel,注意,每一个Client与Selector建立链接后都会有一个Channel,Channel是一个双向通道,他可以建立数据的读写,将数据读写到缓冲区buffer里去.所以Channel的数据读写是一种非阻塞的读写,如果没有数据则会直接跳过,而不会同步的等待数据.Selector是一个单线程,但其可以应付成千上万个client,客户端的增多基本不会影响他的性能.
总之,channel是一个读写工具,每一个cilent通过selector都有一个对应的channel异步读写数据到buffer里.每一个服务端都有一个selector.
值得注意的是,与stream不一样,当buffer里的数据读完后,数据还是会存在与buffer里的,(stream读完后会消失)
AIO
异步阻塞IO事例:
一个人在上厕所的时候,所有坑位都满了,而这时候这个人比较懒,在厕所里光等着什么都不干,让每一个坑位的用户在释放完后通知他.因此只有有人来通知了后,这个人才会去上厕所.
异步非阻塞IO事例:
现在这个人在坑位全满的情况下,不会再在厕所里干等着,而是在做其他事情,只有在占坑的用户释放完后,来通知他,他才会去使用
事例总结:
BIO,NIO,AIO区别
Netty
1.单线程模型
连接的过程是由单线程Reactor处理的,在高负载,高并发的情况下,容易让客户端发起请求时候会超时,而由于客户端的超时机制,容易导致不断请求连接的死循环.
生活事例:
此时的Reactor就好比店里的一个招待员,其又要负责揽客,又要负责对客人的其他服务
因此,当客人多时,总有忙不过来的时候
2.多线程模型
生活事例:
现在,reactor只负责揽客,当客人来了后,他就只是让客人去大堂等待其他人的服务就好了.
而此时,如果客人再更多一点,那么一个接待人也会有忙不过来的时候,因此就需要
主从线程模型
3.主从线程模型(推荐和开发采用)
从Hello Netty服务器开始
助手类可以理解为***,因为每个channel对应的数据和逻辑可能不一样,所以就需要不同的助手去完成(***)请求
1.mavan坐标:
pipeline就好比一个大的***,而handlerA,B,C...都是它的子集
编写自定义助手类
在同包下,创建一个新的类
结果
控制台:
此时没有判断http请求
判断Http请求:
在原先的逻辑外面套上一层判断
回到控制台发现还有两个
原因:多了favicon.ico
通过linux的curl访问(非长链接)
可以发现请求成功了!
而此时控制台也只打印了一次
京公网安备 11010502036488号