在access中如何在报表中统计满足条件的记录个数
在access中如何在报表中统计满足条件的记录个数
09-10-31 &匿名提问
报表精灵没有用过,如果是用Access的话本身分组报表每个页脚添加一个sum(合计字段),字段强制分页即可
请登录后再发表评论!
书 名: 中文版Access2007循序渐进教程　　作　者：龙腾科技　　出版社： 科学出版社　　出版时间： 2008　　ISBN: 2　　开本： 16　　定价: 26.00 元[编辑本段]内容简介　　《中文版Access2007循序渐进教程》共分9章，通过众多实例全面介绍了Access2007的各项功能，主要包括Access2007的基本构成、表的创建方法、查询的概念和创建方法、可视化窗体的创建方法、报表的创建方法、宏的使用方法、使用VBA开发Access数据库的方法，并在第9章中给出2个综合实例，详细讲解企业中“客户管理系统”和”进销存管理系统”的创建。[编辑本段]目录　　第1章Access2007和数据库　　1．1Access2007的主要用途　　1．2Access2007的主体构成　　1．2．1表　　1．2．2查询　　1．2．3窗体　　1．2．4报表　　1．2．5宏　　1．2．6VBA　　1-3数据库基础知识　　1．3．1数据库的概念　　1．3．2关系型数据库　　1．4Access2007空白数据库的创建　　1．5Access2007的操作界面和设置　　1．6Access2007和编程　　1．7Access2007、VB、ASP和SQL　　1．8典型实例：利用模板创建“学生”　　管理数据库　　本章小结　　思考与练习　　第2章表--Access的“仓库”　　2．1“货架”--认识表的结构　　2．2存储数据的架构--创建表　　2．2．1输入数据直接创建表　　2．2．2使用“表模板”创建表　　2．2．3通过“表设计器”创建表　　2．2．4边学边练：创建“计件工资管理系统”的表　　2．3规划“容器”--表中字段的设置　　2．3．1Access2007的“字段”类型　　2．3．2Access2007的字段属性　　2．3．3设置字段的显示和打印格式　　2．3：4设置字段的输入格式　　2．3．5设置字段的默认值　　2．3．6设置“字段”输入的有效性规则　　2．3．7使用“查阅向导”创建“下拉列表”　　2．3．8边学边练：为“计件工资管理系统”添加下拉菜单　　2.4“归类”引用--设置表的关系　　2．5“容器”包装--设计表的外观　　2．5．1隐藏列和冻结列　　2．5．2改变字体　　2．5．3改变列宽和行高　　2．6典型实例：创建“考勤管理　　系统”的表　　本章小结　　思考与练习　　第3章查询一Access的“检索系统”　　3．1“查询”初体验　　3．1．1查询的概念和种类　　3．1．2查询和数据表的关系　　3．2找出符合条件的数据--创建“选择查询”　　3．2．1使用向导创建选择查询　　3．2．2使用设计视图创建选择查询　　3．2．3设置查询条件　　3．2．4．边学边练：在“计件工资管理系统”中创建查询　　3．3同时查询多个表中的数据--创建“高级查询”　　3．3．1交叉表查询　　3_3．2参数查询　　3．3．3操作查询　　3．3．4SQL查询　　3．3．5边学边练：在“计件工资管理系统”数据库中创建SOL查询　　3．4典型实例：创建“考勤管理系统”的查询　　本章小结　　思考与练习　　第4章窗体---Access的“查询界面”　　4．1数据的操作窗口--了解窗体　　4．1．1窗体简介　　4．1-2窗体的视图方法　　4．2规划操作界面--创建窗体　　4．2．1自动创建窗体　　4．2．2使用向导创建基于单表的窗体　　4．2．3使用向导创建基于多表的窗体　　4．2．4创建数据透视图及数据透视表　　4．2．5使用设计视图创建窗体　　4．2．6边学边练：“计件工资管理系统”中窗体的创建　　4-3安装“设备”--使用窗体控件　　4．3．1控件组中各按钮的功能　　4．3．2文本框控件的使用　　4．3．3标签控件的使用　　4．3．4组合框及列表框控件的使用　　4．3．5命令按钮控件的使用　　4．3．6选项组、切换按钮、选项按钮和复选框控件的使用　　4．3．7Office控件的使用　　4．3．8’边学边练：“计件工资管理系统”中窗体控件的添加　　4．4典型实例：创建“考勤管理系统”的窗体　　本章小结　　思考与练习　　第5章报表--Access的“统计系统”　　5．1领导要看的材料--什么是“报表”　　5．2简易输出--创建报表的方法　　5．2．1自动创建报表　　5．2．2利用向导创建报表　　5．2．3利用设计视图创建报表　　5．2．4使用空白报表工具创建报表　　5．2．5边学边练：创建“计件工资管理系统”的报表　　5．3美容增色--报表的附加设置　　5-3．1节的操作　　5．3．2插入时间和页码　　5．3．3排序和分组操作　　5．3,4-在报表中使用汇总字段　　5-3．5插入图片　　5．3．6边学边练：优化工资报表　　5．4高级技巧--创建多列报表和子报表　　5.4．1创建多列报表　　5．4-2创建子报表　　5.5功成名就--打印报表　　5．5．1报表的页面设置　　5．5．2报表的打印　　5．5．3边学边练：打印“计件工资管理系统”的工资报表　　5.6报表快照　　5．7典型实例：创建“考勤管理系统”的报表　　本章小结　　思考与练习　　第6章宏--完善数据库的工具　　6．1“全自动洗衣机”--什么是宏　　6．1．1新建宏　　6．1．2宏的基本结构　　6．2“插上电源”--使用宏　　6．2．1宏的调用　　6．2．2执行条件宏操作　　6．2．3宏组操作　　6-3“开机运行”--宏的常用操作　　6．3．1启动和关闭Access对象　　6．3．2查找记录　　6．3．3窗体菜单操作　　6_4“故障检修”--宏的错误与调试　　6．4．1宏的语法错误与调试　　6．4．2宏的运行错误与调试　　6．4．3宏的逻辑错误与调试　　6．5典型实例：在“考勤管理系统”中　　使用宏添加快捷键　　本章小结　　思考与练习　　第7章VBA--Access的编程语言　　7．1“超级货架”--什么是VBA　　7．2“内部结构”--VBA程序的基本语法与书写格式　　7．2．1变量和常量　　7．2．2流程控制语句　　7．2．3过程与函数　　7．2．4注释语句　　7．2．5语句的连写和换行　　7.3“增加内涵”--功能模块的创建　　7．3．1模块简介　　7．3．2创建具有密码验证的主窗体模块　　7.3．3创建查询窗体模块　　7．3．4边学边练l使用VBA增加“计件工资管理系统”的功能　　7．4“兢兢业业”--VBA程序的调试　　7．5典型实例：给“考勤管理系统”　　添加功能代码　　本章小结　　思考与练习　　第8章保密、数据共享和界面定制　　8．1检测隐患--数据分析　　8．2“保密”--数据库安全　　8．2．1设置数据库密码　　8．2．2边学边练；给“计件工资管理系统”数据库设置密码　　8．3“节省时间”--导入数据、链接数据及导出数据　　8．3．1导入数据和链接数据　　8．3．2导出数据　　8．3．3边学边练：导出本月工资表　　8．4“高级境界”--数据库实用工具　　本章小结　　思考与练习　　第9章创建实用Access数据库　　9．1公司客户管理系统　　9．1．1创建“公司客户管理系统”的数据表　　9．1．2创建“公司客户管理系统”的供货查询　　9．1．3创建窗体　　9．1．4创建客户报表　　9．1．5使用宏创建主窗体　　9．1．6完善“公司客户管理系统”　　9．2进销存管理系统　　9．2．1系统数据库和表的设计　　9．2．2创建查询　　9．2．3创建主窗体　　9．2．4给主窗体添加代码　　9．2．5建立“盈利查询”报表并　　添加代码　　本章小结　　思考与练习　　……
请登录后再发表评论!
英文bug既指臭虫，也泛指所有虫类。意指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。来源嘛，参考这个什么是bug?臭虫的故事有人曾这样比喻过摩尔定律造成的电脑技术的飞速发展：如果汽车工业像电脑工业那样高速发展的话，现在的汽车每小时可以跑一千公里，售价只有一元钱。作者有一个反面的回应：幸好汽车工业没有像电脑那样发展。如果汽车像微机一样的不安全不可靠的话，地球上活着的驾驶员和乘客大概就不多了。试想一下，如果你在高速公路上行驶，突然方向盘、油门、刹车全部失灵，仪表上显示一条信息：“你执行了非法操作，系统关机。”这种可怕的景象，正是日常发生在我们每一个微机用户身边的事。这种情形的出现是如此频繁，我们已经习以为常了。我们对“死机”这个名词已毫不陌生，并且知道要随时“存”一下自己的工作，比如正在编写的一个文件，正在计算的一个报表，正在输入的一个客户名录，正在创建的一个网页等等但是，当一个新用户第一次用电脑时，恐怕会被这个情形吓一大跳。作者曾亲身经历过一件事。有一天晚上，作者去看一个朋友，他正在试用新买回来的一台个人电脑。他按了一个键，系统突然死机，隔壁的楼房也在同时停电。朋友吓出了一身冷汗。他以为是他搞死了电脑，拖累得隔壁楼房也掉了电其实，这些现象根本不是用户的错，是系统的“臭虫”发作。如果要怪谁的话，应该怪电脑的硬件或软件厂商。所谓“臭虫（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执行了非法操作的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操作，比如本来是做加法但按了减法键。这样用户会得到一个不正确的结果，但不会引起臭虫发作。软件厂商在设计产品时的一个基本要求，就是不允许用户做非法的操作。只要允许用户做的，都是合法的。用户根本就没有办法知道厂家心里是怎么想的，哪些操作序列是非法的。从电脑诞生之日起，就有了电脑臭虫。第一个有记载的臭虫是美国海军的编程员，编译器的发明者格蕾斯·哈珀（Grace Hopper）发现的。哈珀后来成了美国海军的一个将军，领导了著名计算机语言Cobol的开发。日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”[从此以后，人们将计算机错误戏称为虫子（bug）或臭虫，而把找寻错误的工作称为“找臭虫”（debug）。哈珀的事件记录本，连同那个飞蛾，现在陈列在美国历史博物馆中。今天的电脑臭虫之多，是难以令人置信的。据电脑业界媒体报道，微软视窗98操作系统改正了视窗95里面5000多个臭虫。也就是说，当几年前视窗95软件推向市场时，每套里都含有5000个臭虫！全世界有数千亿个臭虫在我们的微机中飞来爬去，这就难怪我们的微机应用老会出问题了。电脑含有这么多臭虫有一个技术原因，就是软件越来越庞大复杂。在任何复杂的大系统中，错误是难以避免的。大型软件尤其难以按时按预算完成。1995年，国外的一个大规模的研究调查了17万个软件开发项目（总投资达2500亿美元）。结果发现，只有6%按时按预算完成，31%的项目被中途取消。其余53%的项目最终完成，但都超出了预算和进度。这些项目中，一大半项目的实际花费超出预算达189%电脑程序是由语句组成的。据报道，视窗95含有1500万行代码。假设每行代码包含一个语句，那么视窗95的潜在臭虫就会有200多万个（见下页规则4）。在出厂之前，微软做了大量测试。根据琼斯规则5，需要做18次测试才能把臭虫数降低到5000个。假设测试一次耗时一个月（实际上常常不止一个月），那也需要一年半的时间。如果要把臭虫个数降到1，总共需要做42次测试，或三年半还多的时间。当然，微软的视窗95建筑在视窗3.1版多年的开发和使用基础上，并不是完全从头做起，用不了这么多时间。但不论怎么算，测试和纠正臭虫的成本都是很大的。琼斯先生（Capers Jones）评价软件项目的简单规则发表在《IEEE　Computer》杂志上（1996年第3期）。琼斯先生申明这些简单的规则难以精确地评估现实的软件开发项目，仅供参考。函数点=语句数/100规则1　文档页数 ＝ 函数点1.15 规则2　需求规范的改变不宜超过每月1%的速度规则3　测试用例数 = 函数点1.2 规则4　潜在臭虫数＝函数点1.25 规则5　每次查错工作（检查或测试）能发现并修正30%的现有臭虫。规则6　开发所需月数 ＝  函数点0.4规则7　开发所需人数 ＝ 函数点 / 150 规则8　维护所需人数 ＝ 函数点 / 500N`规则9　预计软件使用年数 ＝ 函数点0.25规则10　一个人月的实际工作小时数＝每月22天×每天6小时，即一个人月实际工作时间＝每月132小时其实，人们并不是不可以更好地对付臭虫。斯坦福大学的唐纳德·克鲁思教授（Donald Knuth，他自己取的中文名字是“高纳德”）就是创造高质量软件产品的典范人物。他在80年代初开发的计算机排版软件TeX在世界范围内广泛使用，而且非常稳定。作者曾多年使用TeX，从来没有遇到过臭虫。高纳德教授的TeX软件还有一个创举：他在发布这个自由软件时明确宣布，他将对软件负责。对每一个臭虫，他将奖励第一个发现者1美元.我们可以说，世界上像高纳德教授这样的人不多。他毕竟是一个超级程序员，一个图灵奖获得者，一个天才，又有非常优秀的科学训练和素养。而且，他的程序是开放源码的自由软件，全世界都在帮他找错。但是，我们能不能学习他那种科技人员的敬业精神，学习他那种敢于为自己的产品负责的气魄呢?就是高纳德教授这样的人也是会犯错误的。&1999年12月，《美国科学家》杂志评选出“塑造20世纪科学的100本书”，高纳德教授的著作也榜上有名。他在1968年出版的《计算机程序设计的艺术》一书，与爱因斯坦的《相对论》、维纳的《控制论》、狄拉克的《量子力学》等被列为20世纪最有影响的12部科学专著。高纳德教授对这部600多页的专著采取了同样的奖励方法。每一个错误的第一个发现者将获得2.56美元的奖励。不断有人给他写信报告错误。到了1981年，高纳德教授忙于开发TeX, 实在没有时间回信。于是他向所有报告者发了一封标准信，称以后会给他们联系。高纳德教授说，“我可能很慢，但我信守我的承诺。”到了1999年，高纳德教授终于腾出时间回了所有信件，并汇出125张支票。由于时过境迁，有几封信被退回来了，其中有一封是从中国上海发出的。如果你的名字是Du Xiao Wei，在日向高纳德教授发信指正过他书中的错误，高纳德教授还有一张支票等着寄给你！高纳德教授的网址是： 下面是作者与高纳德教授的一次通信克鲁思教授，我是中科院计算所的一名研究员，正在写一本有关电脑的科普书。我知道您在推出TeX软件时，曾悬赏1美元给第一个发现任何臭虫的人士。不知二十年下来，人们发现了多少TeX的臭虫？ 谢谢。 徐志伟徐先生，事实上，我的悬赏是每个错误2.56美元，每年翻一番，直到327.68美元，然后就保持在这个水平。这个悬赏今天还存在。但是，这么多人已经检查过我的程序了，它可能是同等规模软件中错误检查做得最彻底的程序。我的记忆是大概有四、五个人在327.68美元的水平找到了错误。TeX软件的全部错误记录已经发表在《软件实践与经验》杂志中。在20多年的时间内，我记录了总共1276个臭虫的纠正和功能改进。我总共开出了大约4000美元的支票，但是很多人都没有把寄给他们的支票兑现。我实际付出的赏金大约是2000元左右。我也悬赏在我出版的任何书中发现错误的人，奖金为每个错误2.56美元。这样可以帮助我在每一次印刷时改进质量。 如果软件公司愿意奖赏为它们的软件找到臭虫的人，那该多好啊。尤其是如果软件是开放源码的…… 诚挚的， 唐·克鲁思
一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。 所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。 我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。 详见《软件可靠性工程》
英文bug既指臭虫，也泛指所有虫类。意指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。来源嘛，参考这个什么是bug?臭虫的故事有人曾这样比喻过摩尔定律造成的电脑技术的飞速发展：如果汽车工业像电脑工业那样高速发展的话，现在的汽车每小时可以跑一千公里，售价只有一元钱。作者有一个反面的回应：幸好汽车工业没有像电脑那样发展。如果汽车像微机一样的不安全不可靠的话，地球上活着的驾驶员和乘客大概就不多了。试想一下，如果你在高速公路上行驶，突然方向盘、油门、刹车全部失灵，仪表上显示一条信息：“你执行了非法操作，系统关机。”这种可怕的景象，正是日常发生在我们每一个微机用户身边的事。这种情形的出现是如此频繁，我们已经习以为常了。我们对“死机”这个名词已毫不陌生，并且知道要随时“存”一下自己的工作，比如正在编写的一个文件，正在计算的一个报表，正在输入的一个客户名录，正在创建的一个网页等等但是，当一个新用户第一次用电脑时，恐怕会被这个情形吓一大跳。作者曾亲身经历过一件事。有一天晚上，作者去看一个朋友，他正在试用新买回来的一台个人电脑。他按了一个键，系统突然死机，隔壁的楼房也在同时停电。朋友吓出了一身冷汗。他以为是他搞死了电脑，拖累得隔壁楼房也掉了电其实，这些现象根本不是用户的错，是系统的“臭虫”发作。如果要怪谁的话，应该怪电脑的硬件或软件厂商。所谓“臭虫（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执行了非法操作的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操作，比如本来是做加法但按了减法键。这样用户会得到一个不正确的结果，但不会引起臭虫发作。软件厂商在设计产品时的一个基本要求，就是不允许用户做非法的操作。只要允许用户做的，都是合法的。用户根本就没有办法知道厂家心里是怎么想的，哪些操作序列是非法的。从电脑诞生之日起，就有了电脑臭虫。第一个有记载的臭虫是美国海军的编程员，编译器的发明者格蕾斯·哈珀（Grace Hopper）发现的。哈珀后来成了美国海军的一个将军，领导了著名计算机语言Cobol的开发。日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”[从此以后，人们将计算机错误戏称为虫子（bug）或臭虫，而把找寻错误的工作称为“找臭虫”（debug）。哈珀的事件记录本，连同那个飞蛾，现在陈列在美国历史博物馆中。今天的电脑臭虫之多，是难以令人置信的。据电脑业界媒体报道，微软视窗98操作系统改正了视窗95里面5000多个臭虫。也就是说，当几年前视窗95软件推向市场时，每套里都含有5000个臭虫！全世界有数千亿个臭虫在我们的微机中飞来爬去，这就难怪我们的微机应用老会出问题了。电脑含有这么多臭虫有一个技术原因，就是软件越来越庞大复杂。在任何复杂的大系统中，错误是难以避免的。大型软件尤其难以按时按预算完成。1995年，国外的一个大规模的研究调查了17万个软件开发项目（总投资达2500亿美元）。结果发现，只有6%按时按预算完成，31%的项目被中途取消。其余53%的项目最终完成，但都超出了预算和进度。这些项目中，一大半项目的实际花费超出预算达189%电脑程序是由语句组成的。据报道，视窗95含有1500万行代码。假设每行代码包含一个语句，那么视窗95的潜在臭虫就会有200多万个（见下页规则4）。在出厂之前，微软做了大量测试。根据琼斯规则5，需要做18次测试才能把臭虫数降低到5000个。假设测试一次耗时一个月（实际上常常不止一个月），那也需要一年半的时间。如果要把臭虫个数降到1，总共需要做42次测试，或三年半还多的时间。当然，微软的视窗95建筑在视窗3.1版多年的开发和使用基础上，并不是完全从头做起，用不了这么多时间。但不论怎么算，测试和纠正臭虫的成本都是很大的。琼斯先生（Capers Jones）评价软件项目的简单规则发表在《IEEE　Computer》杂志上（1996年第3期）。琼斯先生申明这些简单的规则难以精确地评估现实的软件开发项目，仅供参考。函数点=语句数/100规则1　文档页数 ＝ 函数点1.15 规则2　需求规范的改变不宜超过每月1%的速度规则3　测试用例数 = 函数点1.2 规则4　潜在臭虫数＝函数点1.25 规则5　每次查错工作（检查或测试）能发现并修正30%的现有臭虫。规则6　开发所需月数 ＝ 函数点0.4规则7　开发所需人数 ＝ 函数点 / 150 规则8　维护所需人数 ＝ 函数点 / 500N`规则9　预计软件使用年数 ＝ 函数点0.25规则10　一个人月的实际工作小时数＝每月22天×每天6小时，即一个人月实际工作时间＝每月132小时其实，人们并不是不可以更好地对付臭虫。斯坦福大学的唐纳德·克鲁思教授（Donald Knuth，他自己取的中文名字是“高纳德”）就是创造高质量软件产品的典范人物。他在80年代初开发的计算机排版软件TeX在世界范围内广泛使用，而且非常稳定。作者曾多年使用TeX，从来没有遇到过臭虫。高纳德教授的TeX软件还有一个创举：他在发布这个自由软件时明确宣布，他将对软件负责。对每一个臭虫，他将奖励第一个发现者1美元.我们可以说，世界上像高纳德教授这样的人不多。他毕竟是一个超级程序员，一个图灵奖获得者，一个天才，又有非常优秀的科学训练和素养。而且，他的程序是开放源码的自由软件，全世界都在帮他找错。但是，我们能不能学习他那种科技人员的敬业精神，学习他那种敢于为自己的产品负责的气魄呢?就是高纳德教授这样的人也是会犯错误的。&1999年12月，《美国科学家》杂志评选出“塑造20世纪科学的100本书”，高纳德教授的著作也榜上有名。他在1968年出版的《计算机程序设计的艺术》一书，与爱因斯坦的《相对论》、维纳的《控制论》、狄拉克的《量子力学》等被列为20世纪最有影响的12部科学专著。高纳德教授对这部600多页的专著采取了同样的奖励方法。每一个错误的第一个发现者将获得2.56美元的奖励。不断有人给他写信报告错误。到了1981年，高纳德教授忙于开发TeX, 实在没有时间回信。于是他向所有报告者发了一封标准信，称以后会给他们联系。高纳德教授说，“我可能很慢，但我信守我的承诺。”到了1999年，高纳德教授终于腾出时间回了所有信件，并汇出125张支票。由于时过境迁，有几封信被退回来了，其中有一封是从中国上海发出的。如果你的名字是Du Xiao Wei，在日向高纳德教授发信指正过他书中的错误，高纳德教授还有一张支票等着寄给你！高纳德教授的网址是： 下面是作者与高纳德教授的一次通信克鲁思教授，我是中科院计算所的一名研究员，正在写一本有关电脑的科普书。我知道您在推出TeX软件时，曾悬赏1美元给第一个发现任何臭虫的人士。不知二十年下来，人们发现了多少TeX的臭虫？ 谢谢。 徐志伟徐先生，事实上，我的悬赏是每个错误2.56美元，每年翻一番，直到327.68美元，然后就保持在这个水平。这个悬赏今天还存在。但是，这么多人已经检查过我的程序了，它可能是同等规模软件中错误检查做得最彻底的程序。我的记忆是大概有四、五个人在327.68美元的水平找到了错误。TeX软件的全部错误记录已经发表在《软件实践与经验》杂志中。在20多年的时间内，我记录了总共1276个臭虫的纠正和功能改进。我总共开出了大约4000美元的支票，但是很多人都没有把寄给他们的支票兑现。我实际付出的赏金大约是2000元左右。我也悬赏在我出版的任何书中发现错误的人，奖金为每个错误2.56美元。这样可以帮助我在每一次印刷时改进质量。 如果软件公司愿意奖赏为它们的软件找到臭虫的人，那该多好啊。尤其是如果软件是开放源码的…… 诚挚的， 唐·克鲁思
请登录后再发表评论!以58帮帮为例看58同城典型技术架构演变
发表于 22:16|
来源《程序员》杂志|
摘要：58同城作为中国最大的生活服务平台，涵盖了房产、招聘、二手、二手车、黄页等业务。本文详细讲述了58帮帮自上线以来，随着用户量、数据量以及产品方向的发展，58帮帮在技术架构上持续的演变。
58同城作为中国最大的生活服务平台，涵盖了房产、招聘、二手、二手车、黄页等业务，在每一个业务类别里都能看到方便用户交流沟通的58帮帮。本文选取了58帮帮作为58同城典型技术架构的代表，详细讲述了58帮帮自上线以来，随着用户量、数据量以及产品方向的发展，58帮帮在技术架构上持续的演变。58帮帮由即时通讯（IM）部分和非IM的业务处理部分构成，目前，整个帮帮系统每天要处理10亿次+的发消息、加好友等传统IM请求，以及30亿+的非IM业务请求操作，总请求到达40亿次+。帮帮同时在线也突破了100万，如此多的请求量和在线用户量对我们带来的挑战非常之大。
本文详细讲述58帮帮技术架构演变的四个阶段：阶段一：传统的IM架构我们如何设计？如何满足千万在线的性能需求？阶段二：从传统IM到商家管理平台，58帮帮的架构如何演变？阶段三：从商家管理平台到移动营销工具，58帮帮的架构又如何演变？阶段四：如何打造满足58帮帮的移动推送系统
阶段一：传统IM
最早58帮帮只是一个传统的IM，主要满足58用户与58商户沟通以及传递信息，核心功能包括添加好友、用户关系、收发消息等。在客户端产品形态分为PC桌面客户端、WEB网页客户端，其中PC桌面客户端主要服务于58商户，58用户使用WEB网页客户端和58商户沟通。针对阶段一的传统IM使用业务场景，我们设计了如图1所示的技术架构。
图1 58帮帮技术架构一
传统IM服务端的整个技术架构分为五层：
接入层（ENTRY）
作为客户端和服务端的接口子系统，此层直接面对PC桌面客户端、WEB网页客户端、移动APPS客户端的海量长连接请求，负责建立与客户端通信的加密通道，整合成内部少量有限的长连接，对通信数据进行压缩与解压，并将相应请求转发至逻辑层（LOGIC）。除此之外，接入层实施初步的攻防策略，用来抵御非逻辑层面的攻击，监控某些数据（连接频率、发包频率、发包速率等），对IP/UID等指标实施封禁，IM在某些紧急情况下，必须能够迅速实施封禁，所以需要实时授权IP/UID等黑白名单，使得白名单动态生效、黑名单自动解封。
逻辑层（LOGIC）
逻辑子系统主要是负责整个58帮帮业务逻辑的处理，包括用户相关（用户登录登出、用户信息设置查询）、好友相关（添加好友、获取好友、删除好友、修改好友信息等）、消息相关（收发好友消息、收发陌生人消息、消息确认、通用消息处理、离线消息等）等复杂逻辑处理。
路由层（ROUTER）
路由子系统主要处理和用户一次登录session相关的数据（比如：用户在线状态[在线、离开、隐身]，登录IP等），这部分涉及的数据变化非常快，没必要固化，直接存储在内存中。并记录用户登录接入层的路由信息，支持向指定UIDS通信的功能。
数据层（DATA ACCESS）
统一数据访问子系统屏蔽了底层的存储引擎，上层不用关心实际的存储是RDBMS或者NoSQL或者其他的KV存储引擎，对上层提供友好、统一的访问接口，封装原子逻辑。并通过CURD接口的抽象封装，增加新的数据操作只需要增加配置，不用变动数据层代码，较容易完成关键数据的存储。
数据存储层（DATA STORAGE）
数据存储层是58帮帮数据的固化存储系统，根据数据的特点使用了RDBMS（MySQL）、NoSQL（MongoDB）等持久化存储，并通过分布式缓存（Memcached、Redis等）加速查询。
阶段一的传统IM架构是分层低耦合，在每层中我们采用了无状态的设计，每层的子系统可以自由动态扩展，以满足请求量增长需求。在每层中我们通过子系统冗余部署，消除单点，保证了系统的高可用性。每层之间的调用设计成了动态负载均衡方式，当被调用下层某台子系统故障时，上层子系统调用自动动态切换到可用服务节点，继续完成用户请求操作。单机线上支持50W+的同时在线用户，单机线上达到了3w+QPS，以满足千万级用户同时在线的需求。
阶段二：从传统IM到商家管理平台
随着产品的不断发展变化，58帮帮不再局限于传统的IM，而是一个逐步向商家管理平台演进，不断接入房产、招聘等分类信息业务，提供商家管理功能，进行发帖、帖子刷新、置顶帖子等操作。更多的功能，比如招聘简历推荐、房产发布等需要在客户端完成操作和展示。针对这些变化，在传统IM的架构上做了调整，主要变化体现在客户端。技术架构如图2所示。
图表 2 58帮帮技术架构二
第三方业务（招聘、房产、二手车等）接入，和IM业务类型不一样，从技术角度分析，为了满足对应的产品功能，对长连接没有依赖，可以使用更加优雅的实现方式，因此没必须继续使用长连接，我们采用了在客户端通过HTTP的方式调用第三方服务，开发效率非常高，第三方业务可以快速接入，但由于客户端与第三方业务耦合紧密，带来很多兼容性的困难，一旦第三方业务策略发生变化、接口发生变动，客户端就要随之更新以适配变化，客户端升级代价非常大，而且不能做到实时更新，比如需要升级时，用户可以选择不升级，这些都会带来很大的麻烦。
为了解决客户端通过HTTP方式“简单粗暴”调用问题，在阶段一传统技术架构基础继续演变，形成了如下的架构，如图3所示。
图表 3 58帮帮技术架构三
以上演变的技术架构，我们发现客户端调用第三方业务由HTTP直接调用方式演变为通过58帮帮服务端中转调用的方式。客户端不再和第三方业务直接“接触”，所有第三方请求都会通过58帮帮服务端中转，58帮帮服务端继续调用第三方业务接口，即使下游服务策略变动、业务变动，我们只需要58帮帮服务端做相应的调整，对58帮帮客户端完全透明，从而避免了客户端升级代价大的问题。然而此技术架构存在的问题也比较明显：第一、一次用户请求要经过5个子系统（CLIENT→ENTRY→LOGIC→EXTLOGIC→TRANSIT→DESTSERVICE），5次网络交换，交互路径比较长，响应延迟较高。第二、线上出现问题，定位问题需要查看至少5个子系统日志，增加了快速分析和解决问题困难，成本较高。第三、客户端通过58帮帮服务端调用第三方业务，仍然采用的是TCP长连接的方式，随着移动化到来，移动网络相对不够稳定，试想正在使用58帮帮刷新二手帖子，进入电梯后，网络不稳定，刷新功能不再能够使用，提示你用户已经掉线，请重新登录后使用，这样的用户体现一定很糟糕。
阶段三：从商家管理平台到移动营销工具
随着业务发展以及产品的变化，我们从商家管理平台演变成商家随身的移动营销工具，定位为商家移动生意平台，满足招聘、房产、二手车、黄页等分类业务商家。58帮帮技术架构持续演变如图4所示。
图表 4 58帮帮技术架构四
从产品层面看，我们接入了更多的分类业务，这部分业务在技术架构上我们采用了更加轻量化的WebService服务，客户端使用HTTP的方式调用58帮帮WebService服务，WebService服务再调用下游服务，通过这样的架构，第一：我们解决了第三方服务变动对客户端升级的影响；第二：减少了对TCP长连接的依赖，稳定性和用户体验更好；第三；一次用户只需要2次网络交互，响应延迟提高；第四：用户请求调用路径变短，我们定位和分析线上问题，更加快速效率更高效。
通过上述的技术架构可以看到，58帮帮最终架构分为两个部分：IM相关（用户、好友、消息等）我们在技术架构上采用了TCP长连接的方式，保证了消息的及时到达；第三方业务部分我们采用HTTP短连接方式，在技术层面减少对长连接的依赖，在满足产品功能的同时，用户体验更好。
阶段四：如何打造满足58帮帮的移动推送系统
随着58帮帮移动化的深入，我们需要打造自己的移动推送系统，以解决移动环境下网络不稳定、APP应用无法触达的问题，从而把Message、Operation、Alert等类型消息推送给用户。
移动推送主要的三种实现方式：
客户端轮询（pull）：客户端定期发起查询请求，来达到推送的目的。pull的优点和缺点都很明显，架构简单但实时性差，想提高实时性，只能加快查询频率，但这会造成电量、流量消耗过高。
短信推送：通过短信发送推送消息，并在客户端置入短信拦截模块，将接收到的短信拦截，并解析后转发给应用处理。这个方案实时性好、到达率高，但成本很高。
服务端长连接（push)：这是目前的主流实现方式，实时性好，且电量消耗低，技术架构复杂度较高。
目前的移动推送技术都是结合这3个方面展开的，但对于不同的移动终端平台，又有各自不同的实现，这里简单介绍一下iOS和Android上的具体实现方案。
对于iOS来说相对简单，你没有别的选择，iOS中的应用是不允许后台常驻，所以你没有办法通过开发自己的push service来完成推送下发，只能通过苹果APNS渠道来完成推送，推送流程如图5所示。
图表 5 iOS移动推送流程
Android平台
在Android平台上，由于没有iOS那样的限制，可选的方案就多一些。你可以通过Google官方的C2DM完成推送，可以借助开源的推送协议（例如XMPP）实现，也可以借助市面上的各种推送产品完成推送。
Google C2DM]的主要流程如图6所示。
图表 6 C2DM推送流程
C2DM和APNS流程类似，但其最大的问题是服务器在国外，很容易被屏蔽，而且由于Android社区分裂比较严重，很多厂商可能直接就把C2DM模块给去掉了，所以在国内这个方案极不可靠。
对于开源推送协议，常见的有XMPP等,，事实上谷歌的C2DM底层就是基于XMPP实现的，我们通过调用和测试，主要遇到了两个问题：1. 没有ACK机制，消息不可靠；2.
请求量大时会不稳定。
除此之外海域一些市面上的第三方推送产品供选择，使用这些产品需要面对几个问题：
虽然都宣传到达率能到90%及以上，但实际使用起来，发现远远不到。
第三方移动推送产品的推送通道是共用的，会面向多个客户，如果某一个客户推送量特别大，你的推送实时性可能就会受到影响，这些都是你不可控的。
我们曾经考虑实现一套完整的移动推送平台方案，如果从零开始来做，需要解决几个难点：首先是服务端对移动客户端海量长连接的管理、维持；然后是客户端常驻Service稳定性；第三手机在内存不足的时候，系统会杀掉你的Service，甚至有些系统比较强势，它不允许第三方Service常驻；如何在这些复杂场景下处理好，非常麻烦。
图表 7 58帮帮移动推送系统技术架构
综合考虑，58帮帮推送方案没有选择从零开始的自建方案，我们采用了第三方移动推送平台和自主研发高性能Provider的方案（如图7所示），满足每天百亿量级的吞吐量，并通过动态组合和扩展的方式，结合离线的移动推送数据分析，不同手机使用不同的推送策略，针对性的优化，从而提升到达率。
，关注架构和算法领域，）
作者简介：孙玄，58同城系统架构师，技术委员会架构组主任，产品技术学院优秀讲师，58同城即时通讯、C2C技术负责人，负责58核心系统的架构以及优化工作。涉及自主研发分布式存储系统、MongoDB、MySQL、Memcached、Redis等。毕业于浙江大学。前百度高级工程师，参与社区搜索部多个基础系统的设计与实现。
，关注架构和算法领域，寻求报道或者投稿请发邮件，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）
本文来自《程序员》电子刊10月B架构专题文章，，包含：iPad版、Android版、PDF版。
值得一提的是，由CSDN举办的
将于11月19-21日在北京举行，本次大会涵盖：新型数据库、编程语言、工具与平台、产品与设计、前端开发、算法、微信开发、架构实践、安全等九大分
论坛，届时国外知名讲师将分享所在领域的最佳实践。【】
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章