PS:不是搞设计开发大佬,也不是某高校毕业的高材生,只是分享一些自己开发中的方法.实现的是低并发IM系统,千发级,只做于个人研究使用.
1.TCP or UDP 的选择也是让人头疼的问题
①TCP :它的优势也就不用说了,是一种安全可靠的数据传输方式,但是 考虑到 (长连接->用户在线,消息推送,短连接->登录获取数据等.)
②UDP:轻便,快捷,相对于TCP对服务器的负担小了不少,但是其不可靠的传输方式就需要我们来考虑消息的完整性.
UDP和TCP的区别
1.UDP无需连接,对于建立的连接,只需要定时进行心跳包等技术手段维持该应用的状态
2.TCP有连接,不需要关心客户主动或被动断开连接的问题.
1.UDP不需要占用服务器大量的临时资源
2.TCP在建立连接后对服务器的系统资源的占用相对于UDP是较大的.
1.UDP在不稳定的网络环境中传输数据尤为致命,会有较高的丢包率
2.TCP由于其拥有复杂的拥塞控制算法,使得其具有更高的安全性和可靠性,可以在不稳定的网络环境中传输数据,达到,不丢包,无差错,不重复
对于其中的选择也是颇让人头疼的,如果需要更稳定的,可靠的传输毋庸置疑的使用TCP,如果需要更低的服务器负载达到更快更高的并发,则UDP是不二之选.
设计之中,如果考虑加入P2P通讯技术,在登录服务端处理完必要数据之后让用户与用户之间来处理各自的消息,服务器只做记录处理,那么可以降低绝大部分的流量和系统资源(TCP and UDP p2p技术).其主要难点在于数据是否可靠的到达目的地,和容错的处理.
2.数据通讯数据格式
是使用二进制还是纯文本格式 是个可讨论的问题,
1.数据的冗余:尽量的减少数据对带宽的要求是开发中必须要注意的问题
2.数据的复杂程度:过于复杂的编码算法会对服务器造成无形的压力,尤其是用户量大的时候,该问题会尤为的凸显出来.也会对前期的调试造成
3.数据的安全性:对于某些带有敏感信息和必要的隐私数据要做专门的安全加密.
但小生使用的是 序列化数据+JSON文本 然后进行算法压缩进行传输 ,因为技术有限,对于其他技术真的也是心有余而力不足.
例如:
首先服务器获取到数据首先对数据进行初步解析,然后分清类型,分发给不同的业务层,再由各业务层进行解析处理.
那么对于数据包的类型和子类型要有一个明确的规定,方便服务器分发业务.
咱们首先考虑到的就是 该数据包归属的标识和标识的封装.
假设:
服务器业务层分为 主和子 两层业务,对于子业务的再细化不做讨论.
那么数据包的业务类型就要进行封装, 我使用的方法是 在数据包 的前面增加两个字节,因为每1字节表示整数为0-255那么主业务层的极限就是256个单位,子业务层单位也是256. 最大单位为256*256=65535 完全可以包括所有所需要的的业务单元
在初步的解析过程中可以直接获取数据包前两字节然后对数据包进行有关的转发和处理.
这种方式,我认为可以对数据进行最简的优化和节省对带宽的使用,但是拓展性极低,如果需要修改业务层结构则需要对数据的处理和打包进行修改随后引起的就是对所有处理单元的消息接收模块的修改.也是有利有弊
3.服务器框架
由于技术不到位不考虑高性能的NIO和redis,直接使用WinSocket+多线程
1.Socket可以使用网上较为流行且可靠的Hp-Socket高性能通讯框架,但据爆出有内存泄漏问题,笔者还没发现.
也可以自己编写协议.
2.服务器框架包括具体编写和服务分布,考虑到在高并发下的数据是否可以可靠的到达服务器,并有条不紊的处理还考虑到其处理数据的速度.
对于一些静态数据,比如更新文件,推送消息(图片,网站)可以经过CDN加速 减少一部分对服务器的带宽压力
大致服务器结构如上图↑
服务端的运行详情:
Socket(接收数据)->进入消息处理队列等待采集->多线程顺序采集完毕开始分发业务->业务单元处理数据(保存,修改临时数据或提交到数据库服务器进行数据的保存或进行下一步的处理转发)
技术瓶颈:多线程中对于数据库的操作(读写中对数据库锁表等或提交数据库前的逻辑),服务器奔溃对数据的恢复以免最大程度上的避免损失,Socket的稳定性(粘包,丢包,重复,出错)等问题.设计中好友关系的逻辑问题,与同步问题.
4.其他:
1.前端: 使用H5技术还是仅使用Windows窗口编程.是否后期还需要拓展到WebSocket技术
2.用户间的数据: 频繁的即时消息,是否都需要经过服务器转发还是使用p2p点对点技术,如果使用p2p点对点技术,如果一方掉线是否可以完整的保存离线消息,供登录后查收.与 p2p点对点技术消息是否可以可靠的到达传输.是完全的依靠TCP或UDP服务器中转还是 点对点传输与服务器中转相结合.
PS:仅为分享自己的一些经验和观点,有个人见解请评论,笔者虚心学习.