Skip to main content

 路由器网 > 新闻资讯 >

对一个“失败”项目的审视—分析

2014-08-25 20:13 浏览:


洋洋洒洒写了好多字啊,我都没想到我能写这么多字来。看了上面的架构一定有人会想“不对吧,你在第一篇中可是写的是11种服务器啊,你数一数上面的架构图上才几个?老兄啊,你别是为了点击率而忽悠我们吧”。对于存有这种看法的看客,我只能说“您看的可真细致啊!”上面的这个架构图的确和我第一篇中写的11种服务器的架构不同,那是因为上面的图是目前的架构图,而11种服务器则是第一版的产品架构。大家可以来看看第一版和目前版本架构图的区别。

 

wKioL1P66CmDmoruAAFuyZ4zPCc404.jpg

 

后来将网关服务器和逻辑处理服务器合并;帐号服务器和认证服务器合并;统计服务器、公告服务器、在线服务器砍掉;计费服务器拆分成上报服务器和同步服务器。所以大家就看到了上一篇中的架构图。

 

看到上面的架构图以后不知道大家会有何感想,反正我听到领导好几次用Perfect来形容。当时自己也沾沾自喜了好久。

 

不过随着项目的完成,以及性能测试和压力测试的开展,却发现了一个非常大的问题—性能低下。更有甚者当网吧的一个结账业务发送到上报服务器以后,上报服务器竟然需要2-3秒钟才能处理完毕。这几乎是灾难性的,要知道每个网吧我们的评估是每天上报2000条数据,这样一来,一组服务器所能支持的网吧数量则少的可怜。同时处理速度过慢,会在业务上出现很大的漏洞。例如以连锁网吧为例,用户1在连锁网吧中的A进行消费100块钱以后,抢在连锁网吧数据同步之前(由于处理速度太慢,而造成了延迟)又在连锁网吧B中进行消费,这样以来相当于用户1进行了重复性消费。容易造成网吧账目出现大量的负帐(用户1消费完后,不再进行消费),这对目前薄利的网吧行业的打击无疑是巨大的。

 

究其原因,我觉得主要是因为我们在处理所有业务的时候都是采取了先从SQL SERVER数据库中查询数据,然后再进行计算,并将SQL SERVER数据库中的相关数据进行修改的方式。要知道对于一个复杂的业务,这种查询是多次的。修改的内容也会涉及到好几张不同的表。

就拿网吧用户表为例,一张表中会存放将近3000万条的数据,即便是通过分库分表的方式,虽然可以缓解,但也只能指标不能治本。

 

第二个问题是由于网吧数据是放在网吧服务器上,网吧每次交班时的交班金额是按照网吧本地数据计算出来的。而网吧的每一条业务都上报给中心服务器,中心服务器会重新对数据计算一次;并且当网吧服务器重启的时候,对于网吧服务器和中心服务器上不一致的数据进行强制更新。这个流程中出现了两次计算,并且在不同的业务中以不同的计算结果作为依据(网吧中的交班和中心服务器中的强制数据更新)。这样一来势必会出现数据不正确的问题(事实上,在产品刚上线不久的时候,我们的DBA都是在进行数据的修正,即将中心服务器的数据修改成网吧的数据)。

 

以上两个问题一直困扰着我很久,因为如果产品做成这样的话,在市场上就几乎无法进行推广的。直到后来我离开这家公司以后,才想到了使用NOSQL来实现。