mixi.jp：使用开源软件搭建的可扩展SNS网站
于敦德 2006-6-27 Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。 下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。 首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。 这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache…
FeedBurner:基于MySQL和JAVA的可扩展Web应用
于敦德 2006-6-27 FeedBurner（以下简称FB，呵呵）我想应该是大家耳熟能详的一个名字，在国内我们有一个同样的服务商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600个源，到2005年4月份，流量已经增长到5Mbps，托管了47700个源；到2005年9月份流量增长到20M，托管了109200个源，而到2006年4月份，流量已经到了115Mbps，270000个源，每天点击量一亿次。 FB的服务使用Java实现，使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题，以及解决的方案。 在2004年8月份，FB的硬件设备包括3台Web服务器，3台应用服务器和两台数据库服务器，使用DNS轮循分布服务负载，将前端请求分布到三台Web服务器上。说实话，如果不考虑稳定性，给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题，单点问题将至少影响到1/3的用户。FB采用了监控的办法来解决，当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)来做监控。 FB碰到的第二个问题是访问统计和管理。可以想象，每当我们在RSS阅读器里点击FB发布的内容，都需要做实时的统计，这个工作量是多么的巨大。大量写操作将导致系统的效率急剧下降，如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制，通过创建执行池来缓冲写操作；只对本日的数据进行实时统计，而以前的数据以统计结果形式存储，进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢，这个时候应该是FB在分析整理前一天的数据，而接下来的访问由于只针对当日数据进行分析，数据量小很多，当然也会快很多。FB的Presentation是这样写，但我发现好像我的FB里并没有今天实时的统计，也许是我观察的不够仔细-_-! 现在第三个问题出现了，由于大多数的操作都集中在主数据库上，数据库服务器的读写出现了冲突，前面提到过Myiasm类型的数据库在写入的时候会锁表，这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显，但现在已经到了不能忽视的程度。解决方案是平衡读写的负载，以及扩展HibernateDaoSupport，区分只读与读写操作，以实现针对读写操作的不同处理。 现在是第四个问题：数据库全面负载过高。由于使用数据库做为缓存，同时数据库被所有的应用服务器共享，速度越来越慢，而这时数据库大小也到了Myisam的上限-4GB，FB的同学们自己都觉得自己有点懒。解决方案是使用内存做缓存，而非数据库，他们同样使用了我们前面推荐的memcached，同时他们还使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式缓存工具。 第五个问题：流行rss源带来大量重复请求，导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源，这同样需要服务器去处理，而目前所有的订阅数都在同一时间进行计算，导致对系统资源的大量占用。解决方案，把计算时间错开，同时在晚间处理堆积下来的请求，但这仍然不够。 问题六：状态统计写入数据库又一次出问题了。越来越多的辅助数据（包括广告统计，文章点击统计，订阅统计）需要写入数据库，导致太多的写操作。解决方案：每天晚上处理完堆积下来的请求后对子表进行截断操作： – FLUSH…
使用Red5和FFMpeg搭建在线Flash流媒体分享平台
最近视频的东西比较火，前些天我也稍微了解了一下使用开源软件建在线Flash流媒体播放平台的解决方案，还是有一些收获。 Red5是一款基于java的开源的Flash流媒体Server软件，可以作为取代Macromedia提供的商业版本FMS。Red5使用RSTP作为流媒体传输协议，内置了一些示例，这些示例实现了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本的功能。由于系统本身是开源的，在碰到问题的时候也比较容易解决，大不了直接改代码，在成本方面也可以省下一笔不小的开销，为未来的功能扩展也提供了充分的空间。 如果仅仅是实现在线录制，在线播放，那么Red5也就差不多够了，但可能我们有时候还需要用户上传自己拍摄的视频文件，而要把这些视频文件转成可播放的flv文件就需要视频编码软件了。FFMpeg提供了录制，播放，视频流处理的完整解决方案。它自身也带了一个基于HTTP的流媒体广播程序以及其它几个实用的程序，但我们的重点还是它的视频转换程序，似乎Google Video也是用的它的程序作为视频转换工具。 我用FFMpeg转了几个视频，效果还可以，在声音上碰到了一些问题，在不添加参数的情况下，有一部分视频的声音会有问题，有的视频无论怎么添加参数，都出不来声音，报错提示的是不支持所带的声音采样格式，只支持几种固定的格式，我看了一下代码，确实是这样子，但理论上应该是能够解决的。FFMpeg自带的libavcodec是一套很牛的编码库，为了保证质量和性能，里面的很多codec都是从头开发的。 这两个加起来，实现一些简单的在线视频功能就差不多了。 PS:今天刚看到古永锵也开始做小视频分享网站：优酷。
使用开源软件，设计高性能可扩展网站
2006-6-17 于敦德 上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案，以解决在发展中由于负载增长而引起的性能问题，同时在设计网站架构的时候就从根本上避免或者解决这些问题。 今天我们来看一下在网站的设计上一些通常使用的解决大规模访问，高负载的方法。我们将主要涉及到以下几方面： 1、 前端负载 2、 业务逻辑层 3、 数据层 在LJ性能优化文章中我们提到对服务器分组是解决负载问题，实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决，这在邮件的服务器以及个人网站，博客的应用中都有使用，在Windows下面有类似的Active Directory解决方案。有的应用（例如博客或者个人网页）会要求在二级域名解析的时候就将用户定位到所属的服务器群组，这个时候请求还没到应用上面，我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind…
从LiveJournal后台发展看大规模网站性能优化方法
于敦德 2006-3-16 一、LiveJournal发展历程 LiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能： 博客，论坛社会性网络，找到朋友聚合，把朋友的文章聚合在一起 LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。 在上线后，LiveJournal实现了非常快速的增长： 2004年4月份：280万注册用户。2005年4月份：680万注册用户。2005年8月份：790万注册用户。达到了每秒钟上千次的页面请求及处理。使用了大量MySQL服务器。使用了大量通用组件。 二、LiveJournal架构现状概况 三、从LiveJournal发展中学习 LiveJournal从1台服务器发展到100台服务器，这其中经历了无数的伤痛，但同时也摸索出了解决这些问题的方法，通过对LiveJournal的学习，可以让我们避免LJ曾经犯过的错误，并且从一开始就对系统进行良好的设计，以避免后期的痛苦。 下面我们一步一步看LJ发展的脚步。
imageMagick图片处理工具
ImageMagick是一套Linux下的开源图形处理工具，针对几乎所有的图片格式提供比较全面的图片处理功能。不像windows下的photoshop，先要双击运行，然后打开图片，然后才能对图片进行处理，ImageMagick可以直接在命令行下运行，加上几个参数，就可以得到想要的图片了，而大批量的处理图片也比photoshop简单的多，写个shell多循环几次就可以了。 假如我想给图片加个框，转一下，再加个阴影，输入以下的命令就可以了： convert -size 400x180 hatching.jpg -thumbnail '200x90>' -bordercolor white -border 6…
bind dlz – 分布式系统的请求分发工具
bind dlz全称是bind dynamic loadable zones，是基于bind的提供的一个组件，作用看名字就知道了，支持动态域加载支持。 bind已经有很久的历史，目前是搭建DNS服务器的首选。对于一般网站来说，一个标准的bind已经完全可以完成所有dns解决的工作，但在海量域名数量的情况下，bind也确实存在着一些问题： 1、域名解析信息全部存储在文本文件中，这非常容易导致由于编辑出错导致的域名解析出错。 2、bind运行时将全部的解析信息放在内存里，如果数量巨大将可能出现内存不足的情况，同时解析信息重新加载时所耗费的时间也非常值得考虑，由于加载时间较长，所以基本可以不考虑动态的进行域名的调整。 dlz就是为了解决这个问题而针对bind开发的组件，可以将域名解析信息放在数据库中，从而避免域名信息变动时重新加载的时间，在变动后马上生效。 dlz支持多种数据存储形式，包括文件系统，Berkeley-DB，Postgre-SQL，MySQL，ODBC，LDAP等等。性能的比较在这里。 bind dlz这种提供动态的域名调整，并且仍然可以提供高性能的dns解析服务的特点可以应用于提供二级或三级域名服务的分布式系统的前端，对不同的域名解析到所在服务器组上，从而实现可扩展的系统架构。
使用memcached进行内存缓存
旧文重发 2005.8.9 通常的网页缓存方式有动态缓存和静态缓存等几种，在ASP.NET中已经可以实现对页面局部进行缓存，而使用memcached的缓存比ASP.NET的局部缓存更加灵活，可以缓存任意的对象，不管是否在页面上输出。而memcached最大的优点是可以分布式的部署，这对于大规模应用来说也是必不可少的要求。 LiveJournal.com使用了memcached在前端进行缓存，取得了良好的效果，而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。
