主程的晋升攻略(7):服务器模型谈

在上一篇《主程的晋升攻略(6):CGI和FastCGI》中,讲到Web服务器和CGI/FastCGI能动态输出内容,从而提供更强大的业务处理能力。Web服务器这种架构,我称之为Web模式,与之相对的是Svr模式。Web模式和Svr模式是互联网项目的后台最常见的两种模式。先介绍几个概念。

 

同步通讯 vs 异步通讯

同步通讯是指在一个连接中,一个请求的应答没回来前,不能发送下一个请求,整个通讯过程是请求1-应答1-请求2-应答2……这种。异步通讯与同步通讯相反,在一个连接中,可以随意发送请求,而且收到应答的顺序可能与发送请求的顺序不一致。

 

从描述上就能理解,同步通讯的通讯性能比异步低,但好处是简单,不用考虑乱序应答的复杂情况。

 

同步逻辑 vs 异步逻辑

同步逻辑是指在代码中遇到需要等待的调用时(例如向数据库查询数据),阻塞着,一直等待调用完成。异步逻辑则是不阻塞,继续执行后续代码。

 

我们常见的文件IO接口read/write,网络IO接口send/recv默认都是同步的,需要执行特别的设置API才能变成非阻塞的。同步逻辑符合人脑的思维模式,写异步逻辑需要处理各种非阻塞和异常情况,极其挑战智力,就算采用有限状态机,也是件很具挑战的工作。

 

无状态 vs 有状态

CGI/FastCGI每次执行时,会从数据层(db或数据cache)获得数据,修改后再写回到数据层,也就是说CGI/FastCGI并不会缓存数据。这就是无状态。

 

无状态的架构中,请求是这台Web服务器处理,还是那台处理,都没有区别,因为数据都是从别处获得的。这种架构的扩容非常方便,但需注意,要防范一个请求同时多并发时,可能出现的数据不一致的漏洞,即要做防并发处理。后续会就防并发单独写个文章来展开说。

 

有状态是与无状态相对的概念,是指服务器中缓存了数据。这种架构中,因为不需要反复的从数据层取数据,性能会高很多,但因为服务器缓存了数据,为了保持数据一致性,只能把该数据的请求都分发到这台服务器来处理。对于游戏来说,每个区的用户数据是独立的,对交互的实时性要求高,采用有状态的架构正好合适。

 

Web模式 vs Svr模式

最早的网页游戏大多是用html+js做的客户端,如果要实现聊天功能,需要浏览器定时请求服务器获取聊天信息。Web服务器无法主动给客户端推送消息,我总结了下,Web模式的后台有这么些特点:

1、通讯是请求-应答式,即先客户端请求,才会有服务器应答,服务器无法主动推送消息到客户端;

2、是同步通讯,一个连接里,只有收到应答后才能发下一个请求;

3、是同步逻辑,Web模式很少很少采用异步逻辑;

4、是无状态架构,CGI/FastCGI每次从数据层获取数据,修改后再写回到数据层。

 

Svr模式就是与之相对的,客户端和服务器之间采用长连接,客户端的请求不一定会有应答,服务器还可以主动推送消息到客户端,通讯也不限定是同步的,客户端可以不断的发送请求,服务器的应答甚至可能与请求的顺序不一致。

 

Svr模式相对Web模式来说,通讯性能更强,因为采用了长连接和异步通讯,还能主动推送消息,这是优势。但也因为采用了长连接和异步通讯,对客户端开发的要求就更高些,需要处理好断线重连和支持响应乱序。

 

Web模式因为模式简单,Web服务器自己实现了HTTP协议处理和FastCGI进程管理等通用操作,FastCGI这些外部程序只需要处理业务逻辑就行,降低了很多门槛。而且因为是无状态的,扩容非常方便,直接加进程、加机器就能搞定,这个平滑扩容的优势在Web时代的作用非常大——搞性能优化、架构优化的时间成本比较大,而且不可控,如果能加硬件就能快速抗住,那么就是个优秀的架构。

你可能感兴趣的:(Web,异步,同步,主程,状态)