写了很多字，没想到我能写这么多字。看完上面的结构，肯定有人会想，“不对，你第一篇就写了11种服务器，你根据上面的结构图算出来有多少种？老兄，你别点了就糊弄我们了。”对于持有这种观点的观众，我只能说一句“你太详细了！”上面的架构图确实和我第一篇写的11种服务器的架构不一样，因为上图是当前的架构图，11种服务器是最新版本的产品架构。可以看看最新版本和当前版本架构图的区别。后来网关服务器与逻辑处理服务器合并；账号服务器与认证服务器合并；统计服务器、公告服务器、在线服务器被切断；计费服务器被分成报告服务器和同步服务器。于是大家看到了上一篇的架构图。看到上面的架构图，不知道大家会有什么感受。反正我听领导用Perfect来形容好几次了。当时，我也沾沾自喜了很久。但是随着项目的完成以及性能测试和压力测试的开展，发现了一个非常大的问题——性能低下。另外，网吧结账业务发送到上报服务器时，上报服务器需要2-3秒的处理时间。这几乎是灾难性的。要知道我们对每个网吧的考核是每天要上报2000条数据。这样一来，一组服务器所能支撑的网吧数量少得可怜。同时，如果处理速度太慢，业务也会出现很大的漏洞。例如，以连锁网吧为例。用户1在连锁网吧A消费100元后，赶在连锁网吧数据同步之前在连锁网吧B消费（因为处理速度太慢，造成延迟）。这样就相当于用户1重复消费，容易造成网吧账户出现大量负数（用户1消费后没有继续消费），这无疑是对网吧的巨大打击目前的微利网吧行业。究其原因，我想，主要是因为我们在处理所有业务的时候，都是先从SQLServer数据库中查询数据，然后进行计算，修改SQLServer数据库中的相关数据。请注意，对于复杂的业务，此查询是多次的。修改的内容也会涉及到几个不同的表格。以网吧用户表为例。将近3000万条数据存储在一张表中。即使数据可以通过分库分表来缓解，也只能是索引而不能查根。第二个问题是因为网吧数据存储在网吧服务器上，所以网吧每班的班次量是根据网吧本地数据计算的。并且网吧的每笔业务都会上报给中央服务器，中央服务器会重新计算数据；当网吧服务器重启时，会强制更新网吧服务器和中心服务器上不一致的数据。这个过程有两次计算，在不同的业务中（网吧换班和中心服务器强制更新数据）以不同的计算结果作为依据。这样一来，难免会出现数据不正确的问题（其实产品刚上线的时候，我们的DBA都在纠错数据，也就是把中心服务器的数据修改成网吧的数据）。以上两个问题困扰了我很久，因为如果产品做成这样，几乎不可能在市场上推广。直到离开公司后，我才想到用NOSQL来实现。博客地址：http://fxh7622.blog.51cto.com/63841/1544726
