毕业后加入了一家大型的互联网公司的音视频产品部门做后台开发,其实我本身是学习自动化的,研究生的方向嵌入式系统,对互联网可是一知半解,因此能进入这样一个大公司还是很幸运的。
创新互联建站专注于企业网络营销推广、网站重做改版、普兰店网站定制设计、自适应品牌网站建设、H5开发、商城网站建设、集团公司官网建设、成都外贸网站制作、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为普兰店等各大城市提供网站开发制作服务。
刚开始工作的半年应该是在上份工作最快乐的时光,那时候我们十来个人被抽调出来做好友系统,由Z组长负责。从产品到开发,大部分都是新入职员工,pm给画了一个大饼,大家都满怀憧憬。闲话少说,先介绍一下刚开始接触后台开发用到的服务器框架。
第一个接触的叫udpserver。顾名思义,就是只支持udp的服务框架。因为我们部门是做音视频产品的,音视频数据对实时性要求很高,因此常用udp传输数据。Udp server是同步多进程模型,包含1个Interface进程和多个Worker进程。
Iterface进程负责接收来自外部的请求,做一些合法性校验和格式转换后,转发给后端的Worker进程。Worker进程监听不同的端口收包,并处理业务逻辑。Worker进程的回包直接发给客户端。
此处有几个点值得关注:
首先,Worker进程监听的是不同端口。
监听相同的端口显然是更常见的做法,而监听相同的端口也需要注意一点,即监听的端口socket必须是从父进程中继承得到的,而非Worker自己创建的socket。因为对于前者内核才能保证调度的均匀性,而后者是没有这种效果的,内核只会把请求包扔给同一个Worker。
这里之所以使用监听不同端口的方案,是为了保证调度的可控性,请求包发往哪个Worker是有预期的,可以做更个性化的调度策略,问题定位也方便得多。Udp server默认是使用轮询的调度方式。
第二点是,Worker进程回包是直接返回给客户端的。
另一种常见做法是通过Interface进程回包,缺点是Interface会成为瓶颈。而Worker直接回包的缺点是向外部暴露Worker,不过这个问题并不十分严重。相较之下,我们更希望获得性能的提升。为了给客户端回包,Interface会把客户端的ip和端口封装到请求包发给Worker。
框架虽简单,但是性能非常优异,作为echosvr性能可达30w+ QPS。但是这个框架不支持TCP,因此只能作为内部的服务框架使用。
因为很久没用这个框架了,以上所述可能有不准确或者不充分的地方,望不吝赐教。