既然说了大型,首先要考虑的就是高用户并发的情况。这就需要结合你实际用户端应用场景,视频都双向传输和简单的低通量的文本交互一定不是一个概念。做大型的系统,还要考虑平时的情况和突发的高占用率情况。
首先我们先对应用做一个分类:
1高带宽消耗累应用
这个方面的代表就是直播相关或网络教学领域。直播系统的大体原理,主播手机采集音视频、编码,然后推送一个视频流给服务器(实际上是一个做了负载均衡的视频服务器矩阵组)。然后负责实时流媒体数据流接收的服务器,会将流媒体数据流推送给分发服务器(现在有现成的CDN,这样开发难度就小了很多。)然后观众申请观看的时候,分发服务器就会将所申请的时时流媒体推荐给客户。
这么粗糙的应用就可能包换用户端权限管理服务器组,业务调度服务器组,不同区域IDC建立的接入服务器组,不同区域IDC建立的分发服务器组,分等级的数据存储服务器组,ai内容审核服务器组(基于分流实时分析,预设内容审核规则),归档视频存储服务器组,短视频评级推荐服务器组,应用兴趣行为分析服务器组。客户在请求交互的时候可能还会有一些缓冲的队列呀,nosql之类的(redis,memcache)。各组服务器的规格和数量都是根据同时并发的情况定的,在程序开发好的时间可以通过自动化的方式模拟高并发,再通过查看分析瓶颈,而对前期的规划做出合适的调整。
有些时间还要实现不经过分发,交互直通以降低延时。pk的连线的时候,太高延时是接受不了的。这个就不继续展开了。
还有网盘类应用也也很多类似,只是延时要求没那么高。传统的视频网站也是基本相同原理。
传统的微博也是类似的分发机制。
2低延时需求型
这方面一般是以网络游戏为主。对于一些点电子竞技类的应用,做到80ms以下的低延时是必须。服务器的核心响应速度和带宽的低延时是重点。这种服务器最好可以独享一条专线,或者在虚拟网络系统中设置一个更高的优先级,数据线优先同行也会尽可能的降低延时。至于服务器组之间的vpc也应该有一个更高的通过优先级,以保证服务器之间的访问延时极地。这种应用服务器,最好要支持核心运算,不过这个要开发的架构支持。
再就是后期用户量大的时候,做更新包下载的时候会采用分发服务器(CDN)。
3高突发的缓冲
这种都是电商网站,平时就是讲全段应用服务器做彼此依赖,后端选择一个大吞吐,大并发的后端框架(京东使用的go语言对高并发和数据挖掘就有很多优势,我也刚开始学习)。这种系统网元架构就简单很多,传统的负载均衡后挂着不同模块的应用服务器组,然后经过缓冲服务器组,之后到达数据服务器组和APIGateway。
日常的应用都是没啥问题,都是因为一些节日或促销,或爆款等发生临时性数据 *** 作的拥堵。解决这种缓冲都方式有很多,比如临时快速读写缓存,消息队列等。甚至开发总线通信队列等待机制,很多解决方案。
现在系统本身的规划和后期都优化都有许多解决方案,现在的瓶颈往往是系统间的交互通信。
服务器种类各云服务商都称呼也不一致,总体说分为轻量应用服务器,负载均衡服务器,超算服务器(CPU和GPU两个方向,后者也常常被成为图形处理服务器。)数据服务器(常见的版本都有),文件服务器(nas和oss),分发服务器,缓冲服务器,数据分析服务器。我项目中使用大大类就这些了,也许有些我没用过和不知道的,希望大家在讨论区补充纠正。
希望对你认知有所拓展。
服务器所用到的知识:TCP/UDP,最基本的
并发——你可以选择使用select、poll,或者是多线程、多进程
如果你使用多线程,那么就必须使用同步技术——信号量、互斥体、条件变量的一种或几种,并且对于多线程技术,你还需要考虑使用进行线程分离与合并,
如果你使用了多进程,那么同步技术就不是你需要考虑的了,你需要考虑的是进程相关的问题了,你是使用fork还是vfork,你该如何处理客户端的请求,如何处理客户端断开连接后保证能够处理完数据并且没有僵尸进程产生,你还需要考虑高并发的问题
你发送接受数据的时候,采用何种方式,是阻塞的还是非阻塞的,还有连接超时、重传等问题
你是选择TCP还是UDP,如果选择UDP你可得忙了,需要你自己去进行重传验证,模拟TCP的三次握手,保证数据不会丢失,保证数据的有序性
php中>
欢迎分享,转载请注明来源:内存溢出
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)