一直用着新立得的软件包管理器，很不错，现在想试试Ubuntu的memcache,当然，有很多用法我都不会，我只是测试一上，先搭建环境，再慢慢熟悉 需要 memcahced,php5-memcache在新立德搜索memcache这两个文件都有，还会附带把所需要的libevent也安好， 设置 Memcached： memcached -d -m 64 -u root -l 127.0.0.1 -p 11211 // 缓存64M，执行用户root，端口11211 重起apache,在命令窗口输入 /usr/bin/memcached -d start 当然你得把memcached安在哪儿要清楚，OK，写上测试文件测试一下. $mem = new Memcache; $mem->connect(“127.0.0.1″, 11211); $mem->set(‘key’, ‘This is a memcached test!’, 0, 60); $val = $mem->get(‘key’); echo $val; 有几点很重要 1、对于大块的数据，存储时即使不设定压缩标志，memcache客户端也会自动压缩后上传。 2、数组类型的数据先序列化成字符串再送往memcache服务器。 3、对象类型的数据先用get_class_vars函数将其转化成数组，再序列化成字符串上传给服务器。 4、服务器端只保存字符串。 启动memcached服务器并检查memcached是否启动，关闭memcached： # service memcached start # ps aux|grep memcached [...]
集群架构方面的问题 o memcached是怎么工作的？ o memcached最大的优势是什么？ o memcached和MySQL的query cache相比，有什么优缺点？ o memcached和服务器的local cache（比如PHP的APC、mmap文件等）相比，有什么优缺点？ o memcached的cache机制是怎样的？ o memcached如何实现冗余机制？ o memcached如何处理容错的？ o 如何将memcached中item批量导入导出？ o 但是我确实需要把memcached中的item都dump出来，确实需要把数据load到memcached中，怎么办？ o memcached是如何做身份验证的？ o 如何使用memcached的多线程是什么？如何使用它们？ o memcached能接受的key的最大长度是多少？（250bytes） o memcached对item的过期时间有什么限制？（为什么有30天的限制？） o memcached最大能存储多大的单个item？（1M byte） o 为什么单个item的大小被限制在1M byte之内？ o 为了让memcached更有效地使用服务器的内存，可以在各个服务器上配置大小不等的缓存空间吗？ o 什么是binary协议？它值得关注吗？ o memcached是如何分配内存的？为什么不用malloc/free！？究竟为什么使用slab呢？ o memcached能保证数据存储的原子性吗？ 集群架构方面的问题 memcached是怎么工作的？ Memcached的神奇来自两阶段哈希（two-stage hash）。Memcached就像一个巨大的、存储了很多对的哈希表。通过key，可以存储或查询任意的数据。 客户端可以把数据存储在多台memcached上。当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点； 客户端将请求发送给选中的节点，然后memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。 举个列子，假设有3个客户端1, 2, 3，3台memcached A, B, C： [...]
动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件，比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。 大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。 大型动态应用系统又可分为几个子系统： 1）Web前端系统 2）负载均衡系统 3）数据库集群系统 4）缓存系统 5）分布式存储系统 6）分布式服务器管理系统 7）代码分发系统 Web前端系统 结构图： 为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。该Web前端系统基于 Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理 负载均衡系统 负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs, nginx。大多数网站都是硬件、软件负载均衡系统并用。 数据库集群系统 结构图： 由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的，才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？ 我们可以采用如上图所示的方案： 1) 使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。 2) 使用 MySQL Replication 机制实现快速将主库（写库）的数据库复制到从库（读库）。一个主库对应多个从库，主库数据实时同步到从库。 3) 写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。 4) 读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。 5) 数据库服务器和应用服务器分离。 6) 从数据库使用BigIP做负载均衡。 缓存系统 缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcached。使用正确的缓存系统可以达到实现以下目标： 1、使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。 2、减轻对数据库及存储集服务器的访问压力。 3、Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。 分布式存储系统 结构图： Web系统平台中的存储需求有下面两个特点： 1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。 2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。 因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。（这个地方需要加入对某个分布式存储系统的简单介绍。） 分布式服务器管理系统 结构图： 随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。 在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。它是基于C/S [...]
到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。 如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。 拥抱熟知的技术 动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。 架构层次清晰化 起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。 Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB 层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。 数据冗余? 有必要 很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。 前端优化很重要 因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。 功能增加要谨慎 不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。 有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。 从开始考虑性能 [...]
本人作为一位web工程师，着眼最多之处莫过于性能与架构，本次幸得参与sd2.0大会，得以与同行广泛交流,于此二方面，有些架构设计的心得，不敢独享，与众友分享，本文是这次参会与众同撩交流的心得. 架构设计的几个心得： 一，不要过设计：never over design 这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。 ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构 web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的 二，web架构生命周期：web architecture‘s life cycle 既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你 所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长 google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的 三，缓存：Cache 空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快速为好。。 缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定 老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具 链接:钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢? 我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存 四，核心模块一定要自己开发：DIY your core module 这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其代码是非常可怕的 五，合理选择数据存储方式：reasonable data storage 我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？ 首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了) select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and [...]
1、传统缓存之一（404） 这个办法是把nginx的404错误定向到后端，然后用proxy_store把后端返回的页面保存。 配置： location / { root /home/html/;#主目录 expires 1d;#网页的过期时间 error_page 404 =200 /fetch$request_uri;#404定向到/fetch目录下 } location /fetch/ {#404定向到这里 internal;#指明这个目录不能在外部直接访问到 expires 1d;#网页的过期时间 alias /home/html/;#虚拟目录文件系统地址要和locaion /一致，proxy_store会将文件保存到这目录下 proxy_pass http://www.sudone.com/;#后端upstream地址，/fetch同时是一个代理 proxy_set_header Accept-Encoding ”;#让后端不要返回压缩（gzip或deflate）的内容，保存压缩后的内容会引发乱子。 proxy_store on;#指定nginx将代理返回的文件保存 proxy_temp_path /home/tmp;#临时目录，这个目录要和/home/html在同一个硬盘分区内 } 使用的时候还有要注意是nginx要有权限往/home/tmp和/home/html下有写入文件的权限，在linux下nginx一般会配置成nobody用户运行，这样这两个目录就要chown nobody，设成nobody用户专用，当然也可以chmod 777，不过所有有经验的系统管理员都会建议不要随便使用777。 2、传统缓存之二（!-e） 原理和404跳转基本一致，但更简洁一些： location / { root /home/html/; proxy_store on; proxy_set_header Accept-Encoding ”; proxy_temp_path /home/tmp; if ( !-f $request_filename [...]
我一直是使用mysql这个数据库软件，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能： 1、索引没有建好； 2、sql写法过于复杂； 3、配置错误； 4、机器实在负荷不了； 1、索引没有建好 如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。 看看当前的运行情况 show full processlist 可以多运行几次 这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息 在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题 如果出现了性能问题，则可以进行分析： 1、是不是有sql语句卡住了？ 这是出现比较多的情况，如果数据库是采用myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。 查看processlist里的time这一项，看看有没有执行时间很长的语句，要留意这些语句。 2、大量相同的sql语句正在执行 如果出现这种情况，则有可能是该sql语句执行的效率低下，同样要留意这些语句。 然后把你所怀疑的语句统统集合一下，用desc（explain）来检查这些语句。 首先看看一个正常的desc输出： mysql> desc select * from imgs where imgid=1651768337; +—-+————-+——-+——-+—————+———+———+——-+——+——-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | [...]
使用合适的会话管理 第一个想到的扩展系统的方法就是添加更多硬件。例如，使用两台服务器而不是一台。这听着合理，但会产生潜在问题：会话管理。这对Java程序来说是很严重的问题，在PHP中也会产生可延展性问题， 对于数据库的负载尤其如此。 会话被定义为单独的最终用户登录或者连接一 段时间，其中通常会包含多个TCP/IP的HTTP连接、几个Web页面，通常还包括几十个甚至上百个页面元素，如框架、菜单、Ajax更新等。所有这些 HTTP请求都需要知道用户是谁，才能满足安全的要求，并向用户传送适当的内容，因为这些都是会话的组成部分。通常每个会话都会包括相互关联的会话数据， 如用户名、用户ID、历史、购物车、统计资料等等信息。 问题在于，在有两台Web服务器和多个 HTTP连接的情况下，用户流量会在两台服务器之间分配和移动，服务器很难知道用户是谁，并对所有数据进行跟踪，因为每个页面或者页面的组成部分都可能来 自不同的服务器。在PHP中，通常是这样解决的，在第一次连接或登录的时候就创建一个会话ID并将其放在Cookie中，然后这个Cookie会和每个 HTTP请求一起发送。 这样做带来一个问题，接下来每段PHP脚本 都需要基于ID来查找会话数据。由于PHP无法在执行过程之间保持状态（这与Java不同），这个会话数据需要存储在某个地方，通常是在数据库中。但是， 如果复杂的页面需要在每个页面载入过程中对其进行十次查找（这是经常要做的），那就意味着每个页面都要执行10次SQL查询，这会导致数据库上很大的负 载。 在前面所举的中国 Internet用户 0.01%的例子中，可能很容易在每秒内仅仅为了管理会话就生成上百个查询。解决方法是一直使用位于Cookie中的会话ID，并且使用像 Memcached之类的服务来缓存会话数据以获得高性能。 还要注 意其中存在安全性的问题，因为黑客可 以伪造另一个用户的会话ID，这是很容易找到或看到的，特别是在公用的Wi-Fi中。解决方法是对会话ID进行恰当的加密或者签名，并将其与时间区间、 IP地址以及其他关键信息 像浏览器或者其他细节相绑定。在Internet上有很多不错的关于良好的会话管理的例子，你可以根据需要找到最适合的。 总是要考虑安全性 尽管编写像防止SQL注入和登录安全之类的 代码涉及很多安全问题，但不幸的是，几乎没有人考虑过安全性，而那些考虑到的人也没有对其进行很好地理解。而本文要关注的是操作性的系统安全。对于这类安 全，我们的焦点集中在三个安全领域：防火墙、运行的用户以及文件访问权限。 除了配置专门的硬件防火墙（像Cisco的 ASA）之外，所有服务器都还应该运行像Iptables之类的防火墙，它会保护服务器免受其他威胁和攻击。这些威胁和攻击可能来自公共的 Internet、其他服务器或本地服务器，也包括使用VPN或者SSH通道的开发和操作人员。我们仅对指定的IP开放确实需要的端口。Iptables 可能会很复杂，但是有很多不错的模板，我们通常可以使用它们来帮助客户创建Iptables。例如，默认的RedHat或者CentOS防火墙的配置说明 只有10行，显然并不实用。我们最佳实践的Iptables配置大概有5页，这其中包含了Linux所能提供的最高级的安全防范。 所有公用的服务，都应该运行在专门的用户 下，如Apache。切记永远都不要使用Root用户运行，因为这会让任何闯入到Apache的用户接管整个服务器。如果Apache只是运行在 Apache用户下或者运行在Nobody下，那么闯入Apache就不是一件容易的事情了。 Web服务器运行或者服务的文件 （像.php和.html文件）对于Web服务器的用户应该是不可写的。这意味着Apache或者Nginx用户不应该拥有Web目录的写权限。有很多方 法都可以做到这一点，而最简单的就是将这些文件为其他用户所有，然后让Apache/Nginx等用户归属于能够使用640权限读取文件的组中。这会防范 几乎所有的黑客和针对页面的攻击。 此外，永远不要使用Ftp来上传文件，特别 是在公用的Wi-Fi环境中，因为在其中黑客很容易盗取用户名和密码。取而代之的是使用Sftp会更加安全。另外，每个雇员都应该拥有自己的用户ID和随 机密码。 使用标准的路径和安装配置 一个令人讨厌的部署问题是，开发者很少考虑 他们的软件会被部署到生产Web服务器的什么位置，以及如何部署。我们看到过许多大型的系统将它们的PHP代码部署在/home/xiaofeng或者 /web/code路径下。事实上，这两个路径都是非常不标准的，并且会带来操作和安全性的问题。当这些系统从开发环境转移到测试环境再到生产环境中时， 因为每个安装配置都是非标准的，所以经常会出现问题，这时就需要开发者调整才能够正常工作。 你应该总是使用标准的安装包和二进制文件来 安装像Apache之类的服务器。不要从源代码编译或者安装Tarball，因为这会导致长期稳定性和管理上的问题，另外在服务器上安装多个不同的版本也 会造成混淆。 Web 站点应该总是在指定的平台和 Linux发布的标准路径下进行测试和部署 ，像 [...]
1. 如果一个方法可静态化，就对它做静态声明。速率可提升至4倍。 2. echo 比 print 快。 3. 使用echo的多重参数（译注：指用逗号而不是句点）代替字符串连接。 4. 在执行for循环之前确定最大循环数，不要每循环一次都计算最大值。 5. 养成注销那些不用的变量尤其是大数组 ，以便释放内存。 6. 尽量避免使用__get，__set，__autoload。 7. require_once() is expensive require_once()。 8. 在包含文件时使用完整路径，解析操作系统路径所需的时间会更少。 9. 如果你想知道脚本开始执行（译注：即服务器端收到客户端请求）的时刻，使用$_SERVER[‘REQUEST_TIME’]要好于time()。 10. 检查是否能用strncasecmp，strpbrk，stripos函数代替正则表达式完成相同功能。 11.str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。 12. 如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。 13. 使用选择分支语句（译注：即switch case）好于使用多个if，else if语句。 14. 用@屏蔽错误消息的做法非常低效。 15. 打开apache的mod_deflate模块。 16. 数据库连接当使用完毕时应关掉。 17. $row[‘id’]的效率是$row[id]的7倍。 18. 错误消息代价昂贵。 19. 尽量不要在for循环中使用函数，比如for ($x=0; $x < count($array); $x)每循环一次都会调用count()函数。 20. 在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。 21. 递增一个全局变量要比递增一个局部变量慢2倍。 [...]
