|
============================================
|
项目总结：
|
1、服务端
|
网络通信：
|
tcp协议，长连接
|
粘包问题：tcp协议本身没有报文长度的字段
|
解决的话是在应用层加一个自定义的数据头，在数据头里面增加一个封包长度字段，按封包长度来进行收包解包即可
|
【也可以加一些特殊的标志位来分隔--标志位的风险是内容可能会包含标志位，导致解包出问题】
|
|
针对长连接的半开闭连接，使用心跳检测来去除无用的长连接，并且进行客户端的断线重连的保活
|
|
|
性能优化：由多线程升级为线程池
|
线程池：不会对线程频繁的创建和销毁
|
只是控制线程的使用，配合任务队列完成操作；
|
操作过程：
|
有个总的调度，负责判断任务队列中有没有任务以及线程队列中还有没有空闲线程
|
|
如果有任务来并且有空闲线程，就会将任务分发给空闲线程来执行
|
|
细节：
|
任务队列：
|
满的话，就是达到了任务能排的最大值
|
就需要抛一个满的异常或者使用条件变量来等待放入队列中；
|
|
线程队列：
|
线程数最小值、最大值的设定
|
最小值：保证常规的操作
|
最大值：可能最大的极限，在允许的范围内设定一个合理值
|
【一般从最小到最大之间，可以由并发量的增加来对应开辟更多数量的线程，减少也是一样的道理】
|
用了线程池之后，业务的操作由同步的方式切换到了异步的方式，性能也能得到进一步提升。
|
|
通信模型：
|
select模型：[轮询--按时间间隔每次从头到尾遍历]
|
基于数组存放套接字的轮询模型
|
数组长度有默认大小：windows-64，linux-1024
|
大小可以修改
|
量级：1000个左右[千级]
|
|
poll模型：
|
基于链表存放套接字的轮询模型
|
链表无长度限制
|
量级：10000个左右[万级]
|
|
epoll模型：
|
基于事件触发的一个poll模型，效率更高
|
使用回调的方式处理
|
量级：1000000个左右[百万级]
|
|
数据库封装：MySQL数据库的连接数量默认最大值100个
|
单例模式--多处地方共用同一个对象
|
优点：省内存
|
缺点：效率不够高
|
|
提升性能：连接池[类似线程池的操作]
|
连接池的核心是有一定数量的数据库连接
|
有任务来了，可以给一个空闲连接，来执行任务
|
|
日志封装：
|
单例模式
|
文件滚动--改名算法--用ID或者时间戳的方式改名
|
|
|
|
|
|
|
2、客户端
|
有界面，最容易碰到的问题是界面卡顿的问题
|
解决：将耗时业务放到子线程中去执行，这样就不会阻塞主线程里面的界面响应操作，从而解决卡顿问题
|
|
文件传输：断点续传
|
一般要在服务端专门弄个表来记录一下传输信息
|
当发生传输中断之后，就可以通过查询记录来确定断点处
|
再多比较已传内容断点之前的几个字节内容是否和原始文件的一致，一致则开始从断点处重传。
|
若记录找不到或已传文件丢失都需要从头开始传输。
|
|
超大文件的读取：按行读取，不能一下子全读进来，否则内存不够用
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
