oltp应用开发方面的高手

技术测试：你是oltp应用开发方面的高手吗？

这里是一篇技术测试的文章，希望所有那些自称的和被人吹捧的技术高手来看一看，做做我们的几个测试，看看你属于那种层次的高手？

以下测试是针对oltp开发而言的，对于做算法和桌面程序的，不是我这里要讨论的对象。

好了，第一个考题：你能否做一个统计系统，功能上和易数差不多，能够通过页面嵌入方式记录一个网站的显示次数，来访分析，时段分析，日期分析等等。怎么，这就被难住了，那你算哪门子高手？啊哈，这位说了，这些都easy，手到擒来，很好，很好，看来在实现功能上，你具有了高手的基本能力，不过且慢，如果你认为可以实现这些功能就能自称做个易数统计出来，未免也太小瞧了技术这碗饭的分量，实现这些功能，就中国而言，至少有6位数的程序员可以作到，而设计这么一套系统（仅从功能考虑），也至少有5位数的程序员可以作到，明白吗？你不过是这里面平平常常的一个而已了，要高兴还早呢。

第二个考题：呵呵，其实还是做这些功能，不过加个条件，我只给你一台PC Server（单/双PIII 733+512M Ecc内存+18G SCSI硬盘），你要支撑300万/天的请求调用。琢磨琢磨吧。
简简单单的一个cgi+数据库，那是肯定死翘翘了，怎么办？
第一，你要建立三层体系模型，后台数据库必须通过中间应用层和前台CGI分开。
第二，合理分配使用共享内存空间，并合理通过IPC信号量防止内存区的读写冲突和死锁。
第三，必要时改写web server原代码以获得效率最优化，比如改写apache server的http_log.c程序并重新编译。
如果你对建立这么一套系统的整体架构非常清楚，那么恭喜，你可以在一个比较不错的网络公司做一个CTO了，中国能够清晰搭建这样系统的人，不过4位数而已（当然，能够在这样系统里进行编码工作的，肯定还是有5位数以上的，毕竟左右都是c语言而已）。
知道为什么层出不穷那么多统计系统，虽然功能花哨，但是最后都撑不过易数，基本功不扎实，光靠功能花哨，那是没前途的。

在这个领域做的比较好的，好耶，网易，adsunion，腾讯，太极链等几家而已。
那些所谓广告交换没什么技术瓶颈的人，自己做一套大并访系统出来再说话。

第三个考题，还是这些功能，（我够贫的是吧）我要你一天能记录下3000万次浏览日志，不但要统计，还要完整记录，以供随时查验，当然主机环境提升一下，处理数据的主机用集群，但是核心数据库还是用一台电脑的，这次用sun的小型机，比如RS6000什么的；还有这次再加个条件，数据损失不能超过0.01%。
这个已经不再象建立一个网站了，到象是大型电信的计费中心。你能胜任吗？
这时候要求对整体操作系统，对C语言，对数据库核心都必须有深入骨髓的理解，甚至于，对于数据的导入导出和一些日志的数据库记录，你已经不能再用sql去写了！要利用数据库产品的核心接口按照其数据存储格式直接进行文件或设备块的读写操作！对于一些负载非常大而性能要求又非常高的系统，甚至你需要建立一套独立的数据库体系和数据结构体系。这不是玩笑，因为我领教过这样的系统。
在中国，能搭建这样平台的高手，最多3位数而已。主要集中在电信计费领域，如亚信这样的企业。

第四个考题，这次每天的请求不是3000万了，而是3万万，我没说胡话，3万万！不过你的工作变了，我不要你再做后面的数据处理，我只让你做一个前端报文转发处理，这次我很苛刻，给你一台PII的PC服务器，256M Ecc内存，而数据损失要求则绝对不能超过0.0001%，你的工作很简单，对来往的请求进行简单识别并转发到合适的应用服务器处理。
你用web server转发？别开玩笑了！这时候，你已经别无选择，用汇编自己写一套报文处理程序，作为看守进程驻入内存并挂在接收报文的端口上，你对效率的理解，应当已经超出了对操作系统的认识，对编程语言的认识，而直接达到对CPU指令集的认识程度上，是的，你必须清楚自己的每一条汇编指令是不是已经达到最小的CPU指令占用。必须能计算出分解和处理一条报文的流程需要多少CPU指令循环，是不是已经针对CPU的指令集达到了最大优化，当然，你还必须很熟悉TCP/IP协议对每一种报文的格式定义和规范，不过这和汇编指令的效率优化而言，到不显得有多高深了。
我们经常说CISCO是硬件产品服务商，错了！他们的利润主要就来自于这样的算法！！中国联想、华为等等都想强占这块肥肉的市场，但是在高端领域（其实并不是硬件高端，而是算法高端！），我们还是彻底的空白。
庆幸的是，我知道国内有人在做这样的事情了，当宽带不可避免的成为主流的时候，这种算法的强度和要求，会成为攫取利润的最好途径。
中国在这方面能达到标准的，又有几个人呢？

出了这四个考题，没别的意思，我刚大学毕业的时候，也是自视甚高，因为当时的感觉是，和专业课的计算机作业相比（我是力学专业的，动不动要求编程解一个偏微分方程的收敛解，来分析什么旋流场的速度、温度等的分布），做wewebb开发简直毫无算法可言。再加上当时国内做web数据库的也少，动辄以为自己已经是满高手了，结果幸好跑到给电信做计费的企业混了一年，接触了国内最大的电信集中计费中心的解决方案（一直在运营，还不错），才知道敢情OLTP应用里面学问大的很，自己这点皮毛拿出来吹嘘简直是不知天高地厚。现在看看外面一堆和我当初一样的小毛孩子整天做两个烂程序就自诩高手，只好出来说几句。

其实对于OLTP应用而言，功能的实现一般都非常容易，和那些从事力学、数学、物理等行业的数值计算相比简直毫无算法可言，而OLTP的技术难点主要在于性能，也就是你做一个桌面程序或算法程序，都不会面临并访过高的处理问题，但是做一个OLTP应用，无论如何你都必须直视一下子很多访问冲上来的情况，如果这个问题解决不了，无论多好的创意，多好的功能，都不会得到持续和长远的发展。

由于很多创业者和投资者对技术不通或半通，他们往往拿一个性能指标有很大缺陷的东东当个宝贝，因为一般而言，开发出新东东大家都只是忙着测试功能，很少有对性能进行完整测评的，只有持续运营到一定阶段，并访达到一定程度，性能缺陷开始暴露，才临急抱佛脚，这时候造成的损失就很不核算，甚至是压根解决不了，只好放弃某种功能，从而使品牌信誉整体下降。

加强算法基础，加强技术基础，少卖弄一些花里胡哨的东西，是走向技术高手的真正路线，那些今天学会了什么语言，明天又学会了什么语言的主儿，别吹嘘了，从70年代到现在，最值钱的程序员一直是写汇编和写标准C的，不为什么，因为这是真功夫。
相关文章：
《数据仓库》-[转] - 09月10日 21:31
技术专题：大型应用系统的一些讨论 -- by 曹政 - 07月22日 01:07
MySQL 大企业级应用可行性分析(之四) - 09月14日 12:56
MySQL 大企业级应用可行性分析(之三) - 09月14日 12:54
转贴-招聘老婆一名 满足以下30个条件即可 - 04月29日 17:14
小规模低性能低流量网站设计原则 - 04月17日 15:16
eBay 的Scalability最佳实践 - 04月14日 09:01
再谈 eBay 的扩展性最佳实践 - 04月14日 08:59
定期定额和它的7个好朋友 - 04月01日 20:24
手机之家网站架构--对话高春辉 - 03月30日 11:24
2条评论(Comments)
老板  [10月29日 09:20]
幸好我只是个什么都不知道的老板
9遍  [07月22日 03:50]
赫赫，有数据损失的OLTP不算OLTP，
严格说起来，报文转发也不算OLTP。
RS6000不是SUN的小型机，是IBM的。
核心数据库机器很少有用1台计算机的，
集群工作是常有的，按照数据进行
partition也是常用的。

算法是一方面，架构很关键，
尽量分布式处理，集群处理，
容错是关键。

说实话，计费系统的oltp难度不算艰辛，
况且还允许数据损失。

高端路由器还是比较难的。