谈谈服务器程序设计

最近在实现服务器业务逻辑过程中碰到了一些问题,引起了一些思考,这里就随便这段时间对服务器实现的一些理解(以下的理解均对应于单进程单线程模型)。

高并发是服务器程序的一个重要衡量指标,因此大部分框架都在说能够达到多少多少并发量。但我觉得这些框架的本质其实都差不多。无非都是使用了如epoll/kevent之类的高性能事件监听器,唯一的区别就是他们在此之上提供给应用层的便宜性。

因此从高并发的层面上来讲,其socket的高并发性能主要还是取决于如epoll/kevent的性能。

假如框架已经有了尽可能高的并发能力,应用层的实现真的就一定会高并发么?

操作系统的多进程是我最早接触到的高并发概念。OS按时间片去调度几十甚至上百个进程,让这些进程看起来像是在同时执行,这叫并发。

再看看socket并发,其实是同样的道理,让某一时间段能处理的socket请求越多,其并发量就越高。

跟OS调度不同的是,OS各进程在物理上是独立的,因此操作系统可以强行让一个进程睡眠,然后唤醒另一个进程而不会引起竞争。而同一台服务器程序上的的所有socket请求都会操作这一个服务器程序的资源,这就要求框架不能强行中断正在处理的socket请求,必须等待次请求处理完成之后才能处理下一个请求,不然整个进程内的资源都会出现竞争,想象一下几万个线程请求同一个资源的情况。这其实就是早期的非抢占式OS。

其实问题捋到这,基本上就有答案了。因为各个请求是非抢占式,因此业务逻辑必须为整个高并发程序作出贡献。努力降低每个请求的时间开销,不能造层成单点性能瓶颈。


当一个进程已经满足不了所有在线用户时,进行服务器进程拆分是势在必行的。拆分之后的分布式应用就需要处理着复杂的逻辑。

如何保证网络中断重连后的正确性,以及如何保证资源处理的一致性都是分布式里面比较经典的问题。甚至还有人总结出了cap定理。就说说我最近碰到的两个问题吧。

考虑一下有服务器进程A和服务器进程B,服务器进程A处理普通的逻辑,服务器B管理着用户的金币。当玩家需要一个烧钱的操作时,A rpc到B去扣钱,当B扣完钱之后准备回ack给A时网络断掉了。于是服务器A重新连接到B,然后重新请求扣钱。

这就会造成一个结果,客户钱被多扣了一次,面临的就可能是无尽的投诉。因此这种问题是必须要解决的。

其实现在的各大网络支付平台已经给出了解决方案,那就是订单系统,当然订单系统肯定还有其他作用。服务器A先请求B创建一个订单,然后A拿着这个订单再去B扣钱,如果中间网络断开,A重连后再次拿着同样的订单去请求B扣钱。B查询到此订单已经完成,直接返回Ok即可。这样既解决了重复扣钱的行为。其实这很像是TCP的三次握手的性质。

既然如此我们其实还可以借鉴TCP的发包机制来解决这个问题。

为每一个请求分配一个seq id, 当服务器B处理完成时就记录下这个seq id. 服务器B每接到一个请求的seq id就会检查是否已经执行过,如果已经执行过,就代表这条命令被重复发送了,直接返回结果。这样就可以解决重复发送命令的问题。使用了这种机制之后,服务器B会有很多已完成的seq id, 如何清理这些已完成的seq id就成为了一个问题。

我想了很久,其中一个解决方案就是服务器A向服务器B定时同步还没有处理完成的seq id,每当B收到这种心跳包之后,就把已经处理处理完的seq id清理掉, 然后把剩余seq id作为Ack同步到A服务器。


此段分析基于silly的coroutine机制。

在使用rpc时,容易掉入一个陷阱。就是把rpc call当作本地调用来使用。但是有一个隐藏陷阱就是,rpc call会让出当前coroutine,以便空出cpu来处理其他socket请求。这时如果先后两条socket同时操作同一个数据并且都调用rpc call,就可能会产生伪并发问题。

举个例子,服务器A接收到client请求后将本地数据d1通过rpc call到服务器B去处理,然后把结果存回服务器A的本地数d1.

如果client连续发出两条这样的请求,就会造成数据不一致的问题。因此当使用rpc时必须要小心思考是否会产生并发问题。

当然其实上面的例子只是用来说明问题。只要明确一下服务器的之间的责任即可解决。比如把数据d1从服务器A挪到服务器B,然后把rpc call的语义变掉就可以解决这个伪并发问题。

事情并不总是这么简单,我最近碰到的数据库cache同步问题,就不是那么好解决。我在数据库上层加了cache层,这样每次读取时直接读取cache,可以提高效率。

但是在更新数据库时,我碰到了一个问题。向数据库更新一个数据的流程是update cache,update db。
在调用update db时会与rpc一样让出当前处理coroutine。这样当在同一个socket请求时,同时更新两条数据进数据库,就是下面的执行顺序。
update cache A
update db A
update cache B
update db B

这样B的数据还没有更新到cache,就可能会处理新的socket请求,这时有可能会拿旧的数据B进行处理,从而产生误操作。

这个问题最终我打算实现一个channel来管理,把更新数据库部分放到一个channel中慢慢执行。待实现后再贴出地址。



发表评论