Archive for the ‘默认分类’ Category
Wednesday, December 31st, 2008
去年的这个时候我琢磨是不是要离职，事业单位，福利待遇都很好，离开了什么都要重新再来，思前想后，还是决定出来看看，毕竟在学校呆了18年了（小学5年＋初中3年＋高中3年＋大学4年＋学校出版社3年），在这个不大不小的年纪做这个决定是必要的，估计再过几年就不会动了，也动不了了。2008年2月27日，给出版社的同事写了一封致年轻人的信，然后3月份就到FH网去报到了，刚从学校出来的时候，可能那个经济环境还不错，拿到了些个offer，选择FH网是觉得是门户，公司大一些可能会正规一些，实际怎么样就不说了，一个项目下来，三个技术辞职，剩下的一个是测试，后来陆续在sina看到原来的同事来面试，想想出走还是明智的。6月份到sina报到，直至现在。
2008年成长最快的还是技术方面，PHP还算熟悉了，Javascript也凑合了，抽空做了做Python，已经离不开了，数据挖掘主要方向是推荐系统，也有些收获，过几天把netflix prize的分数晒晒。
与人交往方面还是没什么进步，基本上关系好的是我尊重的人和尊重我的人，所以你要成为我的好朋友，你需要有值得我尊重的东西，尤其是品质，或者尊重我，这样会友好很多。如果你不在二者之列，太对不起了，过去的一年我估计没少得罪你。
我出来之后有人问我出来感觉怎么样或者出来好不好，正好昨天看到一则小故事，人问佛：我不知道我现在的爱是真的还是假的，我该怎么办？佛说：有机会就去爱吧，不要管是劫还是缘，劫也是缘。所以有机会就试试吧，反正我的感觉很好。
2009年主要要做的事情：网络(socket)/桌面(gui)编程；一个精巧的PHP框架(雏形差不多了，和原生的PHP相比性能损耗大概在1.5ms左右)；数据挖掘(推荐系统差不多了，试试其他的领域，有可能在XX预测的方向)；多一些好朋友。
春天快要来了，因为人们都后知后觉，2009，大家都会是好样的。
Posted in 默认分类 | 4 Comments »
Saturday, December 13th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/12/mysql-trap-of-group-concat/
最近在用MySQL做一些数据的预处理，经常会用到group_concat函数，比如类似下面一条语句
mysql>select aid,group_concat(bid) from tbl group by aid limit 1;
sql语句比较简单，按照aid分组，并且把相应的bid用逗号串起来。这样的句子大家可能都用过，也可能不会出问题，但是如果bid非常多的话，你就要小心了，比如下面的提示信息：
Query OK, XXX rows affected, 1 warning (3 min 45.12 sec)
怎么会有警告呢，打出来看看：
mysql> show warnings;
+---------+------+-----------------------------------------+
| Level | Code | Message |
+---------+------+-----------------------------------------+
| Warning | 1260 | 1 line(s) were cut by GROUP_CONCAT() |
+---------+------+-----------------------------------------+
居然被GROUP_CONCAT截断了我的结果，查了一下手册，原来GROUP_CONCAT有个最大长度的限制，超过最大长度就会被截断掉，你可以通过下面的语句获得：
mysql> SELECT @@global.group_concat_max_len;
+-------------------------------+
| @@global.group_concat_max_len |
+-------------------------------+
| 1024 |
+-------------------------------+
1024这就是一般MySQL系统默认的最大长度，如果你的bid串起来大于这个就会出问题，好在有解决的办法：
1.在MySQL配置文件中加上
group_concat_max_len ...
Posted in 默认分类 | 1 Comment »
Wednesday, November 26th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/11/sphinx-on-windows-xp/
前一阵子尝试使用了一下Sphinx，一个能够被各种语言(PHP/Python/Ruby/etc)方便调用的全文检索系统。网上的资料大多是在linux环境下的安装使用，当然，作为生产环境很有必要部署在*nix环境下，作为学习测试，还是windows环境比较方便些。
本文旨在提供一种便捷的方式让Sphinx在windows下安装配置以支持中文全文检索，配置部分在linux下通用。
一、关于Sphinx
Sphinx 是一个在GPLv2 下发布的一个全文检索引擎，商业授权（例如, 嵌入到其他程序中）需要联系作者（Sphinxsearch.com）以获得商业授权。
一般而言，Sphinx是一个独立的搜索引擎，意图为其他应用提供高速、低空间占用、高结果相关度的全文搜索功能。Sphinx可以非常容易的与SQL数据库和脚本语言集成。
当前系统内置MySQL和PostgreSQL 数据库数据源的支持，也支持从标准输入读取特定格式的XML数据。通过修改源代码，用户可以自行增加新的数据源（例如：其他类型的DBMS的原生支持）。
搜索API支持PHP、Python、Perl、Rudy和Java，并且也可以用作MySQL存储引擎。搜索API非常简单，可以在若干个小时之内移植到新的语言上。
Sphinx特性：
高速的建立索引(在当代CPU上，峰值性能可达到10MB/秒);
高性能的搜索(在2–4GB的文本数据上，平均每次检索响应时间小于0.1秒);
可处理海量数据(目前已知可以处理超过100GB的文本数据,在单一CPU的系统上可处理100M文档);
提供了优秀的相关度算法，基于短语相似度和统计（BM25）的复合Ranking方法;
支持分布式搜索;
提供文件的摘录生成;
可作为MySQL的存储引擎提供搜索服务;
支持布尔、短语、词语相似度等多种检索模式;
文档支持多个全文检索字段(最大不超过32个);
文档支持多个额外的属性信息(例如：分组信息，时间戳等);
停止词查询;
支持单一字节编码和UTF-8编码;
原生的MySQL支持(同时支持MyISAM和InnoDB);
原生的PostgreSQL支持.
中文手册可以在这里获得，感谢译者的辛勤工作。
二、Sphinx在windows上的安装
1.直接在http://www.sphinxsearch.com/downloads.html找到最新的windows版本，我这里下的是Win32 release binaries with MySQL support，下载后解压在D:\sphinx目录下；
2.在D:\sphinx\下新建一个data目录用来存放索引文件，一个log目录方日志文件，复制D:\sphinx\sphinx.conf.in到D:\sphinx\bin\sphinx.conf（注意修改文件名）；
3.修改D:\sphinx\bin\sphinx.conf，我这里列出需要修改的几个：
type = mysql # 数据源，我这里是mysql
sql_host = localhost # 数据库服务器
sql_user = root # 数据库用户名
sql_pass = '' # 数据库密码
sql_db = test # 数据库
sql_port = 3306 # 数据库端口
sql_query_pre = SET NAMES utf8 # 去掉此行前面的注释，如果你的数据库是uft8编码的
index test1
{
# 放索引的目录
path = D:/sphinx/data/
# 编码
charset_type = utf-8
# 指定utf-8的编码表
charset_table = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
# 简单分词，只支持0和1，如果要搜索中文，请指定为1
ngram_len = 1
# ...
Posted in Full Text Sarch, Open Source, 默认分类 | 3 Comments »
Wednesday, October 15th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/10/another-way-of-sync-distributed-data-center/
通过Google Reader好友共享看到这篇文章：横向扩展（Facebook），之前看过英文原文，不过仅粗读了一下未求甚解，感谢译者的辛勤劳动。
看完全文，大意是Facebook为了解决跨地域的网络延迟问题，在东海岸新建了一个数据中心，可新的问题随之而来，MySQL数据库复制延迟、memcache缓存不同步，Facebook的工程师通过改进MySQL复制机制，在传递binlog的同时传递memcache更新指令。这样数据库同步了，memcache也更新了。
我将我的名字从"Jason"改为"Monkey"。
我将"Monkey"写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
某个人在弗吉尼亚访问了我信息。在memcache中找到了我的名字，并返回"Jason"。（注意这里，其他用户看到了过时的信息）
同步复制到了之后，将从数据库中我的名字更新为"Monkey"。还需要从弗吉尼亚的memcache中删除我的名字因为缓存对象出现在同步复制流中了。
另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了"Monkey"。
关键的地方就在这里，Facebook有能力对MySQL进行改造，相信一般的公司是不敢的。其实也还有另外一种方式来实现，MySQL引入了一种叫做MySQL UDF(user defined function)的机制，有人也写了个Memcached Functions for MySQL的东东（基于libmemcached，我想应该是稳定高效吧），我们大可以在从服务器上创建触发器，这样一旦有数据更新，调用Memcached Functions for MySQL更新memcached缓存(如果写操作频繁的话，估计触发器也是瓶颈)。
文章的另一个核心是“页面路径选择”，Facebook约定了更新只在主服务器上（西海岸数据中心），东海岸的数据中心数据库服务器全部以slave形式工作，Facebook在最前端有一组负载均衡服务器，更加用户访问的URL来判断是否有写操作，如果有的话直接连接到主服务器上，如果只是页面显示则导向到从服务器上（也许是西海岸服务器），为了解决数据延迟而造成混乱的问题，Facebook在有更新的用户cookie里面加入一个标记，该标记创建后20秒内，都连主服务器（20秒足够对付延迟了吧）。
这是很有意思的一个设计，利用cookie标记用户是否更新过。但问题就是只是自己看到自己最新的数据，其他人有个20秒看到的是过时的数据。
其实是不是可以试试把标记信息放服务器端（如DNS解析部分），比如A用户更新了某些数据，在服务器端做下标记，20秒内请求到这些资源的时候走主服务器。标记大可以用bdb存储，效率就不是问题了。下面是流程：
我将我的名字从"Jason"改为"Monkey"。
我将"Monkey"写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
在服务器端标记我的名字改变了。
某个人访问了我信息，查出我的信息更改过，走主服务器。
同步复制到了之后，将从数据库中我的名字更新为"Monkey"，触发器工作，删除相应memcache缓存。
20秒后，负载均衡端标记失效，另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了"Monkey"。
也是很折腾的一种方案，我这里没有那样的环境，所以也只是理论上的思考，有条件的可以试试看效果如何。
Posted in Arch, 默认分类 | 1 Comment »
Saturday, September 27th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/09/7-stages-scaling-of-web-apps/
几天前看到The 7 Stages of Scaling Web Apps，觉得很是不错，想写点什么，奈何一直很忙，整天忙着那些quick&dirty的项目，让人也堕落了许多。
今天找到报告的原文看了一下，内容丰满了许多。
要构建一个可扩展的网络应用,大多是数据库分表分库、分布式缓存、负载均衡、统一存储，诸如此类，前面我也翻译了一些国外网站架构文章，John Engales的文章高明之处是分7个步骤阐述了一个网络应用从简单到高度可扩展的构建过程。对比这七个步骤，想想我们的应用处在第几步呢？
报告的一开始解释了Performance（性能）和Scalability（扩展性）的区别，里面有两幅图片很好的诠释了，高性能就是买个好车（高配服务器）在高速公路（充足带宽）跑，高扩展性是一堆车跑在立交桥N通道上，不一定跑的很快，至少不会堵车。
第一步：开始阶段
简单的结构：防火墙＋负载均衡、一对服务器、数据库服务器、内部存储，结构简单，没有冗余，维护成本低，很是适合开始阶段。
这样的应用结构应该撑个50W～100W的访问没问题吧，一般的应用话。
很多的应用可能还不到这个水平，一台服务器扔在托管机房里，应用和数据库跑在同一台服务器上，这样的应该是“第零步”吧，如果要扩展这样的应用，升级到第一步吧，应该对程序和数据库不需要怎么修改，效果可能还会不错（如果你的应用不是特别大的话）。
第二步：和第一步一样，只是规模大了些
应用很成功，加更多防火墙、负载均衡，增加更多的应用服务器，找个DBA来优化一下数据库，增加数据库存储备份，把数据库存到SAN或者DAS（这个不太赞同，有几个有这个钱的啊），仍然是个简单的应用。
第二步也很有用，估计能撑到300W左右。如果钱能解决的问题，都不是问题，访问量大了，有钱了，多买点服务器能解决问题何乐而不为？
第三步：痛苦的开始
访问量大了，加个Squid或者Varnish做反向代理吧，或者更高级的负载均衡，以缓存静态内容。加更多的应用服务器，数据库做个Master-Slave，一台Master负责写操作，N台Slave负责读操作，可能会需要做一些代码修改。
到这一步就有点像模像样了，这应该是硬件方面能做到的极限吧，估计撑了500W左右问题不大。
第四步：更加痛苦了
访问量更大了，做个memcache分布式缓存吧，数据库主从复制出现问题了，大量的写堆积到一台服务器上，复制时间过长（数据库从服务器不能即时同步），然后可以做做数据库分区（或者分表），内容统一存储，需要大量重构应用和数据库结构。
终于引入memcache了，可以大大减轻服务器硬盘读取的负载，当数据库（数据库表）变的过大的时候，再多服务器都不管用，想想你的一个数据表有100G，索引有10个G，服务器内存才4个G，光放索引都放不下。这个时候分表会是一个不错的选择，简单的分表可以自定义一个hash函数或者按照ID主键分表，只是这种固定的分表方法将来数据迁移会费事很多，还是推荐Flickr的中心数据库做法，后面会讲到。
到第四步的规模，估计1000W问题不大了
第五步：真正的痛苦开始了
开始恐慌了，开始考虑整个应用模式了，仅仅是通过业务分区还不够，可以通过地理位置啊（比如北方的用户都用北京的服务器），用户ID啊什么的分服务器分区，建立服务器集群，对于每个集群，所有功能都是可用的（这样可以很好的做数据迁移以及冗余），使用一个hash结构或者主服务器来判断用户属于哪个服务器集群（^_^中心数据库）
第五步？估计很多应用都到不了这一步，已经分完善了，估计5000W左右都没问题。
第六步：一点点痛苦
扩展应用和数据库架构，提高性能，增加新功能，优化代码，访问还在增长，但是可控。
比较惬意的阶段了，1个亿的访问量轻松应对吧。
第七步：进入未知的领域
开始找系统的瓶颈了，电源、存储、CDN什么的，更多的数据中心，可能难题是夸地区的数据复制。
呵呵，这个应该是Google考虑的问题了.
想想我们的应用瓶颈在那里，不要一下子什么都想想全了，一步到位的做法是不存在的，知道那里不足，解决它，发现其他的不足，再解决，无休止的循环，直到你失业（什么问题都没有，还要你做什么啊）或者退休（该歇歇了）。
Posted in Arch, 默认分类 | No Comments »
Friday, August 22nd, 2008
一大早上班，看到这则新闻微软照片共享网站上线首日陷入瘫痪 访问量过大，于是问微软的团队，你们怎么不看Flickr的架构啊，微软的团队回答说，我们没有Linux、我们没有Apache、我们没有PHP、我们没有Mysql，我们只有M(any)$。(YY,后面的话绝对是我YY的)。
看来还是有很多事情是钱办不到的。
很多公司在某个领域成功了，已经吃的很饱了，看到别人碗里还有吃的，于是乎就想“动人家的奶酪”，Microsoft看Yahoo火了于是也想做互联网，Yahoo看Google火了于是也想做搜索，中国人在这方面更强，看Youtuble火了，千万个Youtbule站起来了，看Myspace、Facebook火了，好多网站都变成蓝色的了。
恰逢北京奥运会，“伟大”的美国这次估计要“二”了，“伟大”的俄罗斯很多年前就已经是“小三”了，很多国家你别看小，金牌数少，可都有自己的看家绝活，看牙买加的速度，高丽棒子的准度，社会的分工已经由原来的大而全转化成专而精，可惜我们的互联网还在做着一统江湖的美梦。
Microsoft的hotmail，估计很多人只拿hotmail的邮箱做msn登录帐号，Google搜索已经做的很好了，可还是想做Gmail，我是Gmail的忠实用户，几乎每天碰到Gmail错误，难道像microsoft、google这样伟大的公司都做不好一个邮箱吗？
是的，他们不可能做好，他们的成功是由于他们的专注，有钱了就忘记筚路蓝缕的艰辛，记得还在出版社的时候，有次和google的员工在图书订货会上交流google图书馆计划，google的那个员工极其傲慢，oh，my god，google的成功和你一点关系都没有，如此傲慢的企业文化怎么可能把心态放低给用户创造好的产品？
整个世界都遵循着新陈代谢，micorsoft们，你们已经很成功了，为什么啥都要插一杆子呢？做好自己就完成了历史的使命，为什么还要做好别人呢？
我学生物的，但很反对保护大熊猫，既然它都不适应这个世界，为什么不能让它安静的走，还要用氧气一直让它苟延残喘？
没有永恒的美，除了怀念....
Posted in 默认分类 | No Comments »
Tuesday, August 12th, 2008
这是我今年年初从北师大出版社出来的时候写给我同事们的一封信，一晃我已经离开出版社快半年了，那里的很多事情还非常的清晰，毕竟在那里呆了近4年，在出版社工作回答了人生的第一个问题：我能做什么？初出校门，对社会的彷徨以及恐慌，都不知道自己能做什么，到出版社之后发现自己能做很多事情，有些还做的不错，我用近4年时间去回答了这个问题，然后出来了，因为要回答第二个问题：我要做什么？我会用这几年的时间去回答这个问题，希望下一个问题不要是我做了什么，因为做过的事情已经没有多大的意义了，尤其是自己感觉做的不错的事情。
首先向各位亲爱的朋友解释一下离职的原因，离职源于梦想，梦想就是做一个卑微的职业程序员，梦想打中学开始就有，在出版社工作的几年里虽也写了些程序，总觉不太成熟，在现在这个不大不小的年纪做出这个痛苦的决定，也是对职业和人生的一个重新规划。要走了，有些话想和我亲爱的朋友们说说。
生活的意义
生活是有一个支撑点，然后你的思维和活动都围绕它在转动，我亲爱的朋友们，有多久没有问过自己为什么而活着或者认为这个问题根本就是无稽的，我曾经迷失过我的支点，然后感觉整天忙忙碌碌的都不知道自己的忙什么，忙是因为有事情，事情来自两方面：别人要你忙的和自己想忙的，如果仅仅是忙于别人要你忙的，和拉磨的驴又有多大的区别呢？
有时候回过头想想自己所忙于的工作，收获可能比忙更多的工作来的更多。
你懂生活吗？我还不太懂，但我在试着和她沟通。
学习的意义
我们是一群优秀的年轻人，优秀是经过学校和出版社检验的，我们来的时候是优秀的，所以我们工作的时候应该也是优秀的，如果哪一天要走，那应该也是优秀的走。
我曾经困惑过，感觉自己像一块煤在出版社燃烧，担心成为灰烬的一天，我有些惶恐，想想哪天成为了出版社的寄生虫，那是多么可悲而且又可怕的一件事啊，出版社希望员工一直在出版社好好的干，可是她也不希望我们只能在出版社干，她希望我们一直保持我们优秀的品质。优秀不是我们进入出版社的敲门砖，而是我们赖以生存的根本，所以如果有一天出版社抛弃了我们，过错只在我们自己。
不断的学习是我们保持优秀的唯一法宝，我们在忙的同时有多少时间去学习呢？太忙曾经是我的借口，后来才发现安逸是我最大的敌人，鲁迅有句话，大意是这样的：物质生活太过安逸，工作和学习容易被生活所累，我想累及的不仅仅是工作和学习，累及的还有思想。
你学习了吗？
创新的意义
年轻意味着什么？犯错误，犯错误就是创新的开始，大家对我的了解可能仅限于计算机方面，很多人不知道我是学生物技术的，生物的进化只不过是环境对遗传犯的一个又一个错误的选择而已。
我们不是不想创新，我们是害怕犯错误，我们过早的接受了无过便是功的哲学。多么可悲的一件事情。我们进入出版社不仅仅是新陈代谢，而是带来一些不一样的东西，这也是出版社和我们所尊敬的老员工的期望。犯错误不是最可怕的，重要的过错之后的解决方法，我来出版社也犯了无数的错误，直至今日仍蒙几位老师错爱，这也是支撑着我人生信念的一个很重要因素。
创新就是思考的力量。
尊师的意义
我们很幸运的加入到出版社这个大家庭，出版社的今天是我们所尊敬的老同志们创造的，我们创造的是出版社的明天。
新老的交替和磨合难免会有些磕碰，我来也听过不少这方面的传闻。新同志汲汲的想担更重的担子，老同志拽着某些东西不放手，然后矛盾就产生了。
很亲爱的你分享一下我的做法，我来出版社应该也侵犯了不少人的利益，我做事情的原则有两点：我尊重他，发自内心的、我是为出版社利益着想的而不是为了取代他，很多人做好了第二点而没有做好的一点，我们的老员工是富于人情味的，和我们年轻人不同，这是我们缺乏并渴望得到的。
尊重一个人，然后才能把事情做好。
写在最后
我和不只一个人说过，我留出版社是因为舍不得这里的一些人，今天我要走了，唯一舍不得的还是那些人和新进入这个圈子的人。希望你们越来越好，希望出版社越来越好！
你们的朋友：付超群
写于2008年2月27日中午
Posted in 默认分类 | 1 Comment »
Monday, August 4th, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/flickr_architecture_part_i/
Flickr(http://www.flickr.com/)是国外一个领先的图片分享网站，现在应该在yahoo门下，感觉yahoo还是有很多好东西，奈何资本要抛弃他了。这个轮回其实挺有意思的，起先是做实业被microsoft郁闷了，说软件是虚的值不能那么多钱，然后microsoft被yahoo郁闷了，说互联网是虚的不值那么多钱，然后是yahoo被google郁闷了，yahoo比较厚道没说什么，现在microsoft要收购yahoo了（折腾好久了，估计要落听了吧），不知道google将来要被谁郁闷了。成功建立在相同的失败上，反过来失败都是建立在相同的成功上也成立，进入正题吧。
原文地址是http://highscalability.com/flickr-architecture，本文不是原文的严谨翻译，带有我的理解以及补充，由于水平有限，文中的错误请各位斧正。
Flickr处理的数据：
多达40亿次的请求（http request or database query?不知道了，不管是哪个，都够大的吧。）
squid总计约有3500万张图片（硬盘+内存）
squid内存中约有200万张图片
总计有大约4亿7000万张图片，每张图片大概4~5MB
每秒3,8000次请求 (存储了1200万对象在里面)
2 PB 存储(星期天要消费~1.5TB)
每天新增图片超过 400,000
吓死人不偿命....
Flickr用到的技术：
PHP
MySQL
Shards
Memcached 作为中间缓存层，memcached在web2.0网站中可能是引用最广泛的产品之一，开源&强大.
Squid 作反向代理服务器(reverse-proxy for html and images).
Linux (RedHat),如果你想用RedHat企业版又不想付费，试试这个CentOS，基本上100%克隆RedHat企业版（估计传说中1%的RedHat代码没有），我用的就是这个。
Smarty 作为模板解析，很多人在讨论smarty这不好那不好，但是大网站都在用，稳定而且功能强大，系统的瓶颈从来不会再smarty这里，我保证。
Perl 估计用perl做一些系统层面的东西吧，比如日志处理（猜测）
PEAR 做XML和Email解析，和我们一样，Flickr用的也是PHP4，不过新项目还是用PHP5吧
ImageMagick 图像处理的不二选择
Java, for the node service，Java就不太了解了，希望读者补充
Apache 大家都在用，尝鲜的用户nginx或者lighttpd（适合静态文件，youtube用它做媒体文件服务器），出了问题你会抓狂的。
SystemImager 作为服务器部署
Ganglia 分布式系统监控，或者你可以试试nagios，据我所知也很多公司在用
Subcon 用SVN维护服务器配置文件并且可以部署不同的配置文件到服务器集群中去（这个我没用过，系统运维的可能会喜欢）
Cvsup 文件分发，是否类似rsync?
Wackamole前端负载均衡，类似的产品有http://haproxy.1wt.eu/
Flickr架构
常见的Squid反向代理、PHP App Servers、Net App's、Storage Manager我在这里就不讲，我们关注一些让人兴奋的特征:
Mysql的Master-Master结构，mysql的常见的master-slave结构，大家都知道存在"single point of failure"(单点故障的问题)，且只对读操作有好处，对于写频繁的网站却不是一个好的解决方案，Flickr的双master方案据我推测用的就是这个http://code.google.com/p/mysql-master-master/，原理就是master轮询，保证同时只有一个master负责写，解决了单点故障的问题。
Dual Tree Structure，看看下面的图就知道什么是“双树结构”(姑且这么翻译)
示例图中上方的2台机器为master，下方的4台为slave，这种“双树结构”的设计保证一个slave只有一台master，易于扩展也不会形成环路。原文中说这种设计是1＋1＝200％的设计，简单高效。为了防止自增长冲突，数据表中无自增长列。
补充：对于大型应用的分表设计，防止自增长冲突是个问题，有个简单的方案：比如分3张表，可以设第一张表从1开始以3跳跃递增，那么第一张表存储的序列为1，4，7，10……，第二张表从2开始也以3跳跃递增，第二张表存储的序列为2，5，8，11……，第三张表从3开始以3跳跃递增，第三张表存储的序列为3，6，9，12……，保证不会有重复的序号，但这种方案的缺点是如果数据爆炸，3张表不够，你分4张表呢？需要手工迁移数据，如果程序写的不好，底层又要大动了。
Flickr采用的方案是一个中心'users' table（用户表），记录的信息是用户主键以及此用户对以的数据库片区（有点类似Key－>Value的设计，这样的数据结构查询起来是非常迅速的，据说Google的用户登录数据用的就是这样的设计，通过改进版的BDB数据库存储用户名和密码，这样登录起来就不用去查那个大表了），从中心用户表中查出用户数据所在位置，然后直接从目标位置中取出数据。
用专门的服务器存储静态内容，这个容易做到，比如专门的图片服务器。
"Use a share nothing architecture"这个比较费解了，字面上的意思是使用一个无共享的架构，其实就是解除架构上的依赖，类似我们写程序解耦合一样。
除图片外，所有的数据都存在数据库中，这里他们提到了PHP session，我们知道php的session是存储在服务器文件系统的，而且默认没有做hash目录，这就意味着如果你的网站访问量大，比如有10万个人在线，你的session目录下就有10万个文件，如果你的文件格式是NTFS(windows)或者Ext3(Linux)，你要定位到某个文件，系统基本上会假死，有个好的建议是不要在一个文件夹下放超过1000个文件。使用默认的php session还有另外一个问题：服务器session同步，用户在A服务器登录后，session存储在A服务器上，然后应用跳转到B服务器，B服务器上的session没有同步就出问题了，当然解决这个问题的方法很多，比如统一存储session，所有服务器的session都存储在一个vfs设备上，或者通过cookie重新生成一个session在B服务器上
写一篇这样的文章非常的辛苦，第一部分就先写到这里，待续……
Posted in Arch, 默认分类 | 5 Comments »
Friday, August 1st, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/web_log_analytics/
前段时间，一直关注一个开源的统计系统http://www.piwik.org，有两个方面的原因，一是对统计非常有兴趣，二是这个项目构建在Zend Framework上，实在是学习ZF难得的一个样板，程序写的很优美，建议想学ZF的人可以阅读piwik源代码，好的，切入正题。
一般的网站统计系统我知道的有三种类型：
分析网站日子(Apache log)，代表的有
AWStats：http://awstats.sourceforge.net/
analog：http://www.analog.cx/
Webalizer ：http://www.mrunix.net/webalizer/
使用Apache log好处是高速、低开销(apache随着访问写log开销不大)，但是功能一般，比如不能记录客户端的的分辨率、色深、是否支持Java或者Flash等。
通过在网页中嵌入一个探针记录网站日志，piwik就是这样的典型，特点是快速、高开销(piwik是通过php直接往mysql中写记录)、功能强劲(可以记录客户端的详细信息)。
混合使用，代表是Google Analytics、缔元信，这些产品也是在网站中加入一个探针，然后发送一个类似http://www.google-analytics.com/__utm.gif?******的请求，其实是访问服务器上一个空白的图片文件，目的只有一个，记录http日志，这种方式的好处是集上面两种的好处：效率高、功能强。
探针的Javascript代码我们就不分析了，看一下Google Analytics最后发送的请求是什么样子的：
http://www.google-analytics.com/__utm.gif
?utmwv=4.1 //常量
&utmn=1048672819 //随机数，还记得我是怎样处理mootools ajax问题吗？
&utmhn=code.google.com //网站
&utmcs=UTF-8 //编码
&utmsr=1280x800 //分辨率
&utmsc=16-bit //色深
&utmul=zh-cn //语言
&utmje=1 //是否允许Java
&utmfl=9.0%20%20r115 //9.0 r115,Flash播放器版本
&utmdt=Google%20Code //Google Code,标题
&utmhid=594665987
&utmr=- //来源地址
&utmp=/ //目录
&utmac=UA-18071-1 //帐号
&utmcc=__utma%3D247248150.137016230.1209822741.1209822741.1209822741.1%3B%2B__utmz%3D247248150.1209822741.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B // 一些加密字串
有兴趣的可以去读一下ga.js源码，入门的话看一下yahoo的统计源码，写的比较清晰，也没有作混淆。
Posted in 默认分类 | 1 Comment »
Friday, August 1st, 2008
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/kiss-with-you/
看到一个同事邮件里面提到的项目困扰，结合过去一个失败案例，写的一段文字供产品人员和程序员参考以应对项目复杂性。
keep it simple,stupid!
武侠小说里面，招式唯快不破，田伯光的快刀碰见令狐冲郁闷了，独孤九剑以无招胜有招。没有招式敌人再快也无用。
招式唯快就是性能至上主义，以前见过一些天书般的代码（代码足够长、足够复杂、足够你细细品味也看不懂），然后自我得到“极大的满足”，就算有“极好”的性能（好不好谁也不知道），出了bug或者升级的时候就抓狂了，自己都理不清楚了。
招式唯快就是功能至上主义，客户核心的需求就是那20%的功能，然后进入一个天花乱坠的页面，还有“强迫需求”，然后郁闷了，跑了。
简单是世间最美的事情，简单首先保证不会有错误，简单意味着更加易用以及易于维护。
有两条建议与大家分享：
第一条：keep it short，sweety.
过长的代码不容易理解（看了后面忘记前面），很多人说如果一个函数的行数超过70行，一个文件代码超过500行，这个函数，这个文件就太长了，怎么办？看第二条。
第二条：keep it separated,sweety.
过长的代码，把他们分开吧。
什么时候需要分离代码？有重复代码（重复是邪恶的）、一个函数超过70行、一个类有数十个成员函数或方法，把他们拆开吧。
什么地方需要分离代码？martin fowler的建议是如果你在程序里面有需要的注释的时候，就想想能不能拆开，用一个函数去取代。
分离的代码更好理解，想想你要看一个30行的程序，看到最后才知道是获取用户信息的操作，如果把这30行程序拆出来新建一个函数getUserInfo(),噢，整个世界都清净了。
分离的代码更好维护，因为分的足够细，哪个环节需要都可以做局部的修改而不至于影响整个系统。
对于产品，求你了，不要把我用不到东西呈现给我，我想用的时候我可以点开。
Posted in 默认分类 | 1 Comment »