挑战极限，超越不可能 - 小系统里的大名堂(caoz)

前言1：这是一篇技术文章，对技术不了解，不知情，以及不懂装懂者请勿浏览本文，以免耽误您宝贵的时间。

前言2：这是一篇典型的自吹自擂，自卖自夸的文章，是一篇借着donews大树好乘凉的文章，不喜者勿入。
前言1：这是一篇技术文章，对技术不了解，不知情，以及不懂装懂者请勿浏览本文，以免耽误您宝贵的时间。

前言2：这是一篇典型的自吹自擂，自卖自夸的文章，是一篇借着donews大树好乘凉的文章，不喜者勿入。

系统说明：

无论怎么说，网站计数器都是一种最简单的网络程序应用，即便是刚刚开始接触脚本的小朋友，也可以在15分钟内搞定这么一个工作。当然，当计数器被赋予更多功能的时候，它的市场形象，商业包装被建立起来之后，就不再是计数器，而被冠以“统计分析系统”，“营销决策支持系统”之类的名堂及头衔，并通过更多的功能亮点来辅佐，但是不管怎么去定义或包装，caoz今天所提到的这个系统，连同展示界面的html，大约也都不足1万行，毕竟还是一个小系统，一个按照传统软件工程学标准，不值得拿出手的小项目。所以本文的标题也着重说明了这一点“小系统里的大名堂”。

首先，请认识一下这个统计分析系统的功能点，这有助于了解后续所谓“挑战”的基础。

1: 时段分析，包括独立ip分析，基于cookie的独立访客分析，以及pv分析。

2: 地域分析，基于纯真网络提供的ip地址库，手工整理出省级ip地域对应表。

3: 搜索引擎，不但能识别主流搜索引擎，还能对关键词做解码处理，清晰了解搜索来访分布。

4: 客户端分析，了解访问者的操作系统和浏览器使用分布。

5: 来路分析，来路站点和来路页面两种分析途径。

6: 受访分析，被访问的界面分布。

7: 同时在线，15分钟内的独立ip来访和15分钟内的所有pv明细及分布

8: 回头率，用户回访情况分析。

9: 动态数据显示，站点可以在被统计界面动态显示当前统计数据。

除了功能点外，另外值得一提的是本系统具有历史数据的全程保存能力，并可随时查看历史上任何一天，任何一项的统计数据。

但是以上这些，都还不算什么。换言之，你找一个有基本能力的程序员，给他足够的时间，他就可以完成如上的所有功能。是的，这些，只不过就是工作量的累积而言。

但是，如果把如上这些功能，放如到一个高并发的网络访问环境里呢？

面对每一条访问请求，这个统计系统都要依次做如下的事情：

1. 判断该请求的来源站点，并显示当前统计数据（动态实时显示）

2. 通过比对数万条记录的ip地域对应区段表，判别该请求的ip所属地域。

3. 通过比对当日所发生过的所有独立ip信息，判别该请求是否属于新的独立ip。

4. 根据cookie判别是否属于独立访客并做统计相关处理

5. 对该请求的来源界面做统计相关处理

6. 对该请求的受访界面做统计相关处理

7. 对该请求是否属于回访及回访深度做统计相关处理

8. 对该请求所属时段做统计相关处理

9. 对该请求是否来源于搜索引擎做判别，如果来源于搜索引擎，则对该请求的具体搜索引擎来源关键字做解码处理及统计相关处理

10. 对该请求所涉及的操作系统及浏览器做统计相关处理

11. 对该请求进行数据完整记录以便于进行同时在线的查询。

是的，每条记录，系统都要做如上的11步工作。

现在的电脑越来越强悍，处理能力越来越高，似乎这不是什么问题，那么我们看看，1秒种的时间，就是你刚眨一下眼睛的时间，系统能处理多少这样的请求呢？5次？10次？50次？ Caoz给你的答案是，200次！

挑战，日处理一千两百万次统计请求，颠峰每秒200次统计请求！

是的，每秒种要将上述的所有工作，作200遍！

挑战1: apache的承受能力！

每秒处理200次统计请求，对于apache而言，不是200，而是400，因为每个统计请求本身是一个动态php（显示动态数据），又携带一个静态小图片，apache每秒处理400条请求似乎不是什么大麻烦，但是当这里面有200条是动态服务端脚本程序的时候，这又不能说不是一种麻烦。

还好，在这种极端200次统计请求/秒，400次http请求/秒的情况下，任劳任怨的apache最多也就占用了20%的CPU资源。

挑战2: 快速地理查询！

Ip->地址反查不是什么新鲜事情，各种外挂的qq工具都包含这个功能，只要有一个ip-地址库就足够了，但是，请注意这里的问题，每次查询ip地址的地域属性，都需要在几万条到十几万条的地址区段库里去追查，而且追查的定位模式不是直接的字段比照匹配（无法使用数据库索引！），而是用独立ip去对比ip区段所属范围的匹配，技术工程师可以设想，当你面对每秒钟200次这样的解析请求，每次都要做区段匹配，如果是遍历模式，这个查询量简直是…… 而且，系统的资源，也不能全消耗在这一个环节上。

幸好，caoz的树型数据结构，能够实现每秒超过1500次个不同ip的地理反查，这个麻烦总算轻松摆平了。

挑战3: 独立IP分析！

首先，实现了基于cookie的独立访客分析，这个功能对系统负载要求并不高，因为可以根据每个请求的cookie参数判断，但是挑战性的工作在后面，在提供新版本统计的时候，caoz给自己下达了这么一个任务！必须完成独立ip的分析，区别在哪里？

技术上的区别是显而易见的，如果你想知道这个ip是否是独立ip，首先你要保存当天的所有ip数据，并且要对新来访ip进行比对，如果确认在当天的ip数据中没有出现过，那么还要加入这个保存的ip数据队列中，对于千万次的统计系统，每天的独立ip数量会在100-200万之间，而访问高峰往往发生在晚上，也就是说，晚上每个请求要比对上百万的历史ip，并决定该请求是否是一个独立ip请求，每秒钟，实现这样的比对200次！

而且，不能只进行ip的比对，因为同一个ip，如果浏览了多个不同的统计成员站点，对于不同的成员站点而言，都是一次独立ip，所以，这实际上是个双索引的过程，ip和用户id双重比对！

这个工作占用了系统上百兆的内存资源，是最耗费系统资源的应用，不过经过caoz的特别设计，效率还算不错，经受了这样的流量冲击和数据压力的双重考验。

一个专业的技术分析师，面对这样的一种功能需求上的如此苛刻的性能指标，我想他一定会给出类似这样的方案，大型数据库，高性能的服务器集群，健壮的开发环境…..

最后的挑战！ 廉价的运营平台！

1：万元级别的普通机架服务器，双AMD CPU，1G内存，SCSI硬盘，如此而已。

2：最简单的开发环境，mysql, apache, php，是的，只有php！ 不论是 web脚本，还是crond任务，还是纯粹的守护进程，只有php！通常被认为上不了台面的开发工具。

以上的一切不是空谈，不是幻想，而是真真实实的运营数据，

www.tong123.com 在平均日统计请求1000万次左右，颠峰日统计请求连续超过1200万次的情况下，平稳运营已经有月余。

www.bucuotj.com 上线前已经通过了极限测试，上线第二天日处理pv已经接近500万，在当前平均每秒处理100个统计请求的高峰时段里，1G内存空闲600M，CPU空闲率90%。实现设计目标（日处理统计请求1200万次），只是时间早晚问题。

以下知名站长均已使用bucuotj平台，可以作为佐证

http://www.1ting.com Alexa全球排名 433

http://www.tk4479.com Alexa全球排名 596

http://www.zhulang.com Alexa全球排名 737

http://www.imobile.com.cn Alexa全球排名 785

http://www.bucuo.net Alexa全球排名 819

http://www.tiexue.net Alexa全球排名910

http://www.9flash.com Alexa全球排名1079

……

最终结论：

其实N久以前，caoz就提到过，任何简单的应用，放在高并发，大流量的环境下，就不再简单，纯粹强调功能而忽视性能，在网络信息膨胀的年代，是行不通的。

实际上由于信息的几何级递增，硬件的增长速度其实已经远远落后于信息的增长速度，那种奢望通过更多的硬件投入来解决信息处理量的想法，其实是异想天开的天真，网络时代带给了系统开发一些更多的考验，一是更大的数据量处理，二是更高的并发量处理，当然，更有二者兼有的情况，在更高的并发量上处理更大的数据量，比如google，比如baidu。就是这种应用的典型。

事实求实的说，caoz一直不是一个纯粹的技术人才，甚至在传统软件领域去看，连“高级程序员”都算不上，面向一些真正高可靠性，大数据量的应用，从设计者的角度看，也会明显的力不从心，比如，千兆网络交换设备，千兆网络安全设备，海量数据搜索引擎，电信省级结算计费中心等等。但是，caoz也希望，那些致力于成为网络程序高手或自以为已经成为网络应用高手的朋友们，也可以以本文做一点参考，看看你是否有把握和信心，在有限的资源环境里，去解决这么一种听上去不可思议的极限应用。

回答最后一个问题，为什么开发工具是php？不用C的原因很简单，caoz懒惰而且不爱学习，对使用繁冗的变量定义，内存指针感到恐慌，所以选择了最简单直接的开发环境，而且，谁说过php只能做web脚本了？作为后台的守护进程，php同样任劳任冤，忠于职守，至于和C的效率差异，在这样的应用场合里，其实并不是主要障碍。

Caoz继续强调这个观点，好的系统，是用思想搭建起来的，而不是工具。用思想驾驭工具，就好比武侠高手，草木飞花皆可伤人！