洋洋洒洒写了好多字啊，我都没想到我能写这么多字来。看了上面的架构一定有人会想“不对吧，你在第一篇中可是写的是11种服务器啊，你数一数上面的架构图上才几个？老兄啊，你别是为了点击率而忽悠我们吧”。对于存有这种看法的看客，我只能说“您看的可真细致啊！”上面的这个架构图的确和我第一篇中写的11种服务器的架构不同，那是因为上面的图是目前的架构图，而11种服务器则是第一版的产品架构。大家可以来看看第一版和目前版本架构图的区别。
后来将网关服务器和逻辑处理服务器合并；帐号服务器和认证服务器合并；统计服务器、公告服务器、在线服务器砍掉；计费服务器拆分成上报服务器和同步服务器。所以大家就看到了上一篇中的架构图。
看到上面的架构图以后不知道大家会有何感想，反正我听到领导好几次用Perfect来形容。当时自己也沾沾自喜了好久。
不过随着项目的完成，以及性能测试和压力测试的开展，却发现了一个非常大的问题—性能低下。更有甚者当网吧的一个结账业务发送到上报服务器以后，上报服务器竟然需要2-3秒钟才能处理完毕。这几乎是灾难性的，要知道每个网吧我们的评估是每天上报2000条数据，这样一来，一组服务器所能支持的网吧数量则少的可怜。同时处理速度过慢，会在业务上出现很大的漏洞。例如以连锁网吧为例，用户1在连锁网吧中的A进行消费100块钱以后，抢在连锁网吧数据同步之前（由于处理速度太慢，而造成了延迟）又在连锁网吧B中进行消费，这样以来相当于用户1进行了重复性消费。容易造成网吧账目出现大量的负帐（用户1消费完后，不再进行消费），这对目前薄利的网吧行业的打击无疑是巨大的。
究其原因，我觉得主要是因为我们在处理所有业务的时候都是采取了先从SQL SERVER数据库中查询数据，然后再进行计算，并将SQL SERVER数据库中的相关数据进行修改的方式。要知道对于一个复杂的业务，这种查询是多次的。修改的内容也会涉及到好几张不同的表。
就拿网吧用户表为例，一张表中会存放将近3000万条的数据，即便是通过分库分表的方式，虽然可以缓解，但也只能指标不能治本。
第二个问题是由于网吧数据是放在网吧服务器上，网吧每次交班时的交班金额是按照网吧本地数据计算出来的。而网吧的每一条业务都上报给中心服务器，中心服务器会重新对数据计算一次；并且当网吧服务器重启的时候，对于网吧服务器和中心服务器上不一致的数据进行强制更新。这个流程中出现了两次计算，并且在不同的业务中以不同的计算结果作为依据（网吧中的交班和中心服务器中的强制数据更新）。这样一来势必会出现数据不正确的问题（事实上，在产品刚上线不久的时候，我们的DBA都是在进行数据的修正，即将中心服务器的数据修改成网吧的数据）。
以上两个问题一直困扰着我很久，因为如果产品做成这样的话，在市场上就几乎无法进行推广的。直到后来我离开这家公司以后，才想到了使用NOSQL来实现。