Category Archives: 计算机技术

POPPEN.DE Architechture

来自High Scalability:http://highscalability.com/blog/2010/4/12/poppende-architecture.html 最近看到了一篇介绍一个德国的交友网站架构的文章,网站规模在High Scalability上只能算是个中等的了,不过对于绝大多数普通网站来说,比那些Facebook,Google的案例更有指导意义。这个网站的状况是这样的: 2.000.000 users 20.000 concurrent users 300.000 private messages per day 250.000 logins per day We have a team of eleven developers, two designers and two sysadmins for this project. 在国内除了屈指可数的几个大网站,一般的大网站也就是这样的一个规模了。文章里逐一说明了它用到的各种技术,和具体的应用形式和优劣。有些地方还是有些借鉴的价值的。 Nginx:似乎很多大网站都已经放弃了Apache而转向Nginx或者Lighttpd了,Poppen前端是2台四岁的老服务器用来支撑峰值为150,000/min的页面请求,另外有3台nginx服务器专门处理图片请求。他们的特别之处在于应用了nginx的memcached模块来实现前端的缓存,这样一来多台前端服务器可以共用同一份缓存,相对于squid或varnish的解决方案,由于同一个页面无需重复生成,就能节省Web应用近一半的运算量。图片服务器的文件保存在本地磁盘, 用户上传的图片集中在一台图片服务器上,另外的三台图片服务器接收到请求后,如果本地没有这个图片,就回到那一个上传图片的服务器去取,然后保存在本地。这里我觉得用豆瓣那样的分布式存储,空间利用上可能会更高效一些,但他们这种的方式更加Simple & Reliable。 PHP-FPM:他们的应用服务器是28台运行着PHP5.3的服务器,每台运行着100个PHP-FPM工作进程,安装了APC。网站是用Symfony1.2开发的,一开始开发速度还是比运行速度重要的,在后期再通过Profile找出性能瓶颈,修改框架的底层代码,通过缓存一些重复的计算,降低框架带来的性能损失。性能分析是使用Facebook开源的XHProf模块实现的,由于XHProf的性能损耗很小,完全可以安装在正式环境中,对真实运行的系统进行Profile,对于发现真正的热点会有很大的帮助。不过对于他们这个规模的访问量(峰值2500/s),还是没算上缓存,他们的服务器数量也太多了点儿,不知道是缓存没起啥作用,还是Symfony的性能损失太大。 MySQL:MySQL似乎是个不变的主角,Scale中最棘手的问题都是在数据库上。Poppen根据网站功能对数据库做了大体的划分。用户相关的数据放在一台服务器上,并且正在准备着进行Sharding,很自然的会用userId进行分区;用户论坛的数据放在由三台机器组成的主从数据库上;用户的custom message存放在4台机器组成的主从数据库上;另外用到了一个NDB集群存放一些写密集的记录用户交互活动的数据;数据库引擎主要用了MyISAM,一切为了速度,但是越来越多的Table Lock让他们开始考虑转向XtraDB。我的上一篇博客有关于MySQL各种引擎的介绍,可以作为参考。 Memcached:他们把Memcache用的挺狠,45G的内存用来存储Session,页面缓存,函数缓存(保存一些函数的执行结果)等,但由于Memcache的功能有限,他们也正准备用MongoDb或Redis Hash API来替代,这样缓存更新时可以更灵活一些。 RabbitMQ:一个用Erlang实现的AMQP(高级消息队列协议),用来做任务的异步处理,现在正在把越来越多的任务交给队列去处理:写日志、发邮件、发消息、图片上传、等等。另外还用到了PHP-FPM的一个比较酷的功能:fastcgi_finish_request(),这个函数可以在PHP执行过程中,先结束HTTP请求的处理,把结果返回给用户,然后PHP脚步继续执行,处理一些用户不需要看到反馈的善后工作,这样就可以给用户更快的页面响应。队列中任务的处理是由两台服务器上的80个PHP进程完成的,每个进程只处理一个任务,然后重启一个进程, 这样来避免资源的泄露。不过这儿还是个保留的可以改进性能的点。 CouchDB:一个Erlang实现的文档型的数据库,感觉和MongoDB类似,他们用来集中的记录日志,不知道为什么他们不选择MongoDB来做这个事。 Graphite:实时的系统状态监控程序。 RED5:据介绍是个Open Source Flash Server,我还不太了解这个概念,不知道Flash Server都提供什么Service,在Poppen是用来支持在线视频播放和视频聊天的。文章后面的介绍中,他们似乎对这个系统不怎么满意,准备转移到Oneteam Media Server,written in Erlang. TSUNG:Poppen的人似乎对Erlang情有独钟,这个东西也是个Erlang写的,分布式性能测试工具。
Posted in 计算机技术 | 1 Comment

【转】MySQL数据库存储引擎和分支现状

在MySQL经历了2008年Sun的收购和2009年Oracle收购Sun的过程中,基本处于停滞发展的情况,在可以预见的未来,MySQL是肯定会被Oracle搁置并且逐步雪藏消灭掉的。MySQL随着相应的各主创和内部开发人员的离去,缔造了各个不同的引擎和分支,让MySQL有希望继续发扬光大起来。 本文大致讲解一下MySQL目前除了主要的 MyISAM、InnoDB、Heap(Memory)、NDB 等引擎之外的其他引擎的发展和现状,以及MySQL主干以外的分支的状况,为了我们未来更好的使用MySQL或者其他分支建立一个了解基础。 要了解主要存储引擎,请参考手册:http://dev.mysql.com/doc/refman/5.1/zh/index.html 或者相关介绍文章:http://www.javaeye.com/topic/211951 【MySQL存储引擎介绍】 [ Falcon存储引擎 ] Falcon存储引擎是MySQL当时寄以厚望的存储引擎,主要是为了面对当时Oracle收购了InnoBase公司的情况,用来取代InnoDB的一个存储引擎。Falcon引擎的主导人员是数据库大师Jim Starkey,从2006年开始开发,到2008年发布Beta版本,至今为止也没有走入主流。2008年中旬,Falcon的主架构师Jim Starkey宣布从MySQL公司辞职,加入了一家创业公司NimbusDB担任CEO,去设计和开发运行在云计算上面的关系/语义数据库,按照2010年目前NoSQL市场的发展来看,他的选择是正确的,但是带来的结果是Falcon陷入一个没有主导人员的地步,导致了至今都属于性能糟糕,半死不活的状态。 Falcon引擎是MySQL AB公司基于Netfrastrucure公司的产品开发的(Netfrastrucure公司被MySQL AB收购),Falcon 当初的目标是嵌入到MySQL 6.0中用来取代InnoDB引擎,基本很多功能设计都是按照InnoDB的目标去设计的。 Falcon是面向多CPU、拥有大量内存的当代硬件环境和典型Web应用的数据库操作特点而开发的,主要功能包括多版本并发控制、完善的ACID支持、支持前缀压缩的B+树索引、数据页压缩(在磁盘上以压缩形式存储,在内存中以非压缩形式存储)、成组提交等。从功能方面来说没有什么新鲜事,大体也就实现了一个事务型存储引擎必须要有的功能(很多高级的功能如多表空间、分区等都还没有),但其架构上却有很多独特之处。 通过网上的一些测试结果Falcon的性能还是很糟糕的,写入速度是  MyISAM 的 1/10 ~ 1/20,Select 的优化也有问题,添加了索引感觉还会进行全表扫描。所以,我终究感觉 Falcon 是个杯具的引擎。 Falcon特性:http://dev.mysql.com/doc/falcon/en/se-falcon-features.html Falcon测试:http://blog.gslin.org/archives/2008/02/12/1425/ Falcon手册:http://dev.mysql.com/doc/falcon/en/ [ SolidDB存储引擎] solidDB存储引擎是由Solid Information Technology(http://www.soliddb.com)开发的,这是一款利用MVCC来实现的事务型存储引擎。它既同时支持悲观和乐观并发控制,这一点其他的存储引擎目前都不支持。solibDB的MySQL版本包括对外键的完全支持。它在许多方面与InnoDB很相似,比如它使用了簇索引。solidDB还包括一个没有额外开销的在线备份功能。 solidDB公司已经由2008年被IBM收购,主要是用于整合为IBM数据库整合方案的一部分,目前是作为一个前端数据缓存的这么一个角色存在。IBM收购solidDB公司,主要是因为甲骨文在2005年6月收购了Solid Information Technology主要竞争对手TimesTen,为了在内存数据库这块市场上有所依托,所以收购了 solidDB公司。 solidDB产品是一个完整的打包程序,包括solidDB存储引擎、MyISAM存储引擎以及MySQL服务器。solidDB与MySQL之间的结合出现于2006年的晚些时候。但是底层的技术以及代码却是经过了该公司15年的完善。Solid公司保证和支持了整个产品。它是基于GPL协议的,并且提供了一个类似于MySQL服务器形式的商业版本。 性能上来说,SolidDB for MySQL开源数据库再次被证明能够完全满足高吞吐量、关键任务级应用对系统性能和可扩展性的要求。 但是就 solidDB被IBM收购,MySQL对Oracle收购的情况来看,基本上 [...]
Posted in 计算机技术 | 4 Comments

神奇的图片

能看出这个图片里的裸女是往哪个方向旋转的吗?
Posted in 计算机技术 | 1 Comment

Python处理中文的编码问题

对于Python的初学者来说,处理汉字估计是最头疼的一件事了,我也算是个初学者,断断续续接触Python也有一年多了,最近才终于搞明白了Python里对多字节字符的处理是怎么回事。 其实Python里对编码的处理能力还是很强大的,只是需要理解它处理字符的方式。Python里有两种字符串,str和unicode,他们都是字符的序列(相当于字符数组),区别在于字符的不同,str里一个字符就是一个字节,unicode中的一个字符是一个unicode里的字,长度可能是2字节,也可能是4字节。 Unicode是Python对多字节字符使用的一种内部编码,也就是说在Python内部处理多字节字符的官方编码,但它并不是我们常见的utf-8,具体是什么编码我也不清楚。在Python里处理字符串时,都需要先将来自文件、网络、或者str的字符串转换成Unicode格式,这一步是通过unicode工厂函数或者str的decode方法(decode可以理解为是从一种被编码的二进制字节流解码为Python内部通用的格式),但这是Python并不知道这个外部格式到底是什么格式,decode方法可以传入一个参数,表示这个数据是什么编码。 得到Unicode对象后,就可以对字符串进行各种操作了。在完成操作,要把字符串输出到文件、网络、或者数据库的时候,就要根据需要再把Unicode转换成需要的目标编码了,这是就要用到encode方法了,将字符串编码成需要的格式。 http://effbot.org/zone/unicode-objects.htm
Posted in 计算机技术 | 1 Comment

向宁为玉碎的Google致敬!

今晚,在清华科技园Google楼前,人们献给Google的花束,和烛光
Posted in 计算机技术 | Leave a comment

PostgreSQL性能测试(转)

http://www.randombugs.com/linux/mysql-postgresql-benchmarks.html 很迷惑为什么PostgreSQL这样优秀的一个项目总是不被接受,网上搜出的和MySQL的对比都在说PostgreSQL比MySQL慢得多,而证据都是三四年前的某个测试数据。昨晚找到了一个09年6月的帖子,测试方式还算比较严谨,数据在上面的链接里可以看到,作者得出了以下结论: MySQL 5.0.51a-24+lenny1 – Debian stable version is the worst performer (also the MySQL version is a little bit old). MySQL 5.1.30/InnoDB 1.0.3 with Google SMP patch – Compiled by SUN and InnoDB compiled by ORACLE outperform PostgreSQL in some cases. PostgreSQL 8.3.7-0lenny1 – Debian Stable version – It’s a top performer from the Debian standard [...]
Posted in 计算机技术 | Tagged , , , , | 1 Comment