80s team blog

CSDN（SD俱乐部第4期）下一代用户体验设计

温飞飞 ai829 — Wed, 25 Jun 2008 14:28:05 +0800

前几天在CSDN的一个活动上的演讲，主要是介绍Silverlight以及IE8的，我是负责最后面的一部分。大家如果人没去又对这些技术感兴趣的，可以直接观看视频以及下载PDF的演讲稿

下面是CSDN网站的活动回顾页面

http://211.100.26.82/CSDN_Live/200/silverlight.htm

Python的小工具,使用PHP的序列化数据

瞄的技术 — Tue, 24 Jun 2008 11:11:34 +0800

PHP可以使用serialize将对象数组等任何值转化为序列化格式字符串存储到文本，内存，数据库中，unserialize可以将序列化数据还原为对象和变量。
Python的这个开源库可以帮助Python将Python的dict,list等转化为PHP的序列化格式，或将PHP的序列化格式还原为Python对应的数据格式。
http://hurring.com/scott/code/python/serialize/

Silverlight 2.0 Developer Reference

温飞飞 ai829 — Mon, 16 Jun 2008 11:37:22 +0800

here is the from Brad Abrams
It is very useful for Silverlight Developers. Enjoy!~~

you can download the image file in three file formats

[JPG format 5.8MB] download here

[PNG format 6.5MB] download here

[TIF format 19.9 MB] download here

感谢蓝色寄来的书

温飞飞 ai829 — Mon, 16 Jun 2008 11:31:14 +0800

中文版的Flex高级编程，原来看到过电子书，不过还是母语看着比较舒服

感谢蓝色寄过来的书，一定好好观摩一下。

模拟用户登录脚本,手工输入验证码

瞄的技术 — Thu, 12 Jun 2008 15:36:00 +0800

今天某友人有个需求，希望能够登录到某网站，然后抓取一些资料回来。登录这里最麻烦的就是验证码，虽然这个网站验证码不复杂，但是看了下网上对于破解验证码的介绍，感觉还是挺麻烦的-_-!~。
我这个需求不需要每天定时跑，只要进去抓一次就好，于是乎采用人工输入验证码的方式。
先将验证码下载到本机，然后程序保持会话的情况下等待用户手工输入验证码，用户看完下载的验证码数字后，输入使脚本执行登录。

脚本代码如下，有兴趣的可以试试:
#!/usr/bin/env python
# encoding: utf-8
import urllib,urllib2,httplib,cookielib,os
IMGPATH = “”

#存验证码函数
def saveValidateCode(bin,path):
print path
f = open(path,”wb”)
f.write(bin)
f.close()

def main(codeurl,loginurl):
cookie=cookielib.CookieJar()
cj=urllib2.HTTPCookieProcessor(cookie)
request=urllib2.Request(codeurl)
opener=urllib2.build_opener(cj)
c = opener.open(request)
bincontent= c.read()
#存验证码为1.bmp
saveValidateCode(bincontent,IMGPATH.join([”1.bmp”]))
print “请输入验证码”
imgcode=raw_input()

usedata = {’user_name’:'用户名’,'password’:'密码’,'validatecode’:imgcode}#输入登录表单字段
loginrequest=urllib2.Request(loginurl)
c = opener.open(loginrequest,urllib.urlencode(usedata))#登录
bincontent = c.read()

if __name__ == ‘__main__’:
main(’验证码的url’,'登录提交地址’)

Adobe Flex/Air中国行调查

温飞飞 ai829 — Wed, 11 Jun 2008 10:33:58 +0800

随着Adobe 对中国市场的重视，Adobe今年9月-11月将会在中国做一个关于Flex/AIR的活动。美国总部的一些重量级的人物以及Flex/AIR的布道者都会到中国来。作为一个Flex/AIR开发者，你希望Adobe的活动走访以下哪个城市?

投票请点这里

这是个类似美国的AIRBus的活动，会走访几个城市，会来一些大家都熟知的Evangelist或者开发者关系的人，希望和国内的开发者近距离接触，了解大家对技术的应用场景等的东西，希望大家踊跃投票，你的投票会影响他们的行程！

一个目录下放多少文件合适？

瞄的技术 — Tue, 10 Jun 2008 17:14:45 +0800

在linux各种文件系统上，一个目录放多少文件合适？这个问题貌似没有准确的答案，至少我没查到。
我以前的同事说是文件超过3000后，查找文件的性能会下降。这个问题决定例如：图片这种文件是按照什么样的存放规则放在存储上，如果同一目录存放文件数量过多会降低文件的查找时间，如果过于分散又影响维护。

我今天做了个测试，我个人觉得不太正确，没有获得直接的结果。
由于我们WEB开发使用PHP，读写也使用PHP，所以用PHP做读写文件的测试。
一个脚本向一个目录下写固定文件大小，文件名不同的文件，文件名规则是从1开始一直到我指定的数量。
例如：1.TXT……40000.TXT
脚本写完文件后，会根据我指定的文件名用fopen打开,读取一下指定的文件,从fopen开始到fclose结束用Php计时获得PHP找到文件并读取出内容消耗的时间。
测试环境：DELL服务器，型号忘记了，配置:Intel(R) Xeon(TM) CPU 3.06GHz,内存4g,ext3,CentOS release 4.6

我测试结果在1W以内时读取大概在3-4微妙，过万后，5W以后会在4微妙，没有反复测试但是测试5W,20W,40W,60w没有超过4微妙。
我觉得这个测试肯定是有问题的，应该加上并发读取和不固定的文件大小来模拟互联网服务的情况，或许可以获得真正的速度。
但是在文件超过2000后，rm删除文件时已经提示Argument list too long。
我觉得如果以方便系统维护的角度讲，也许不应该超过这个数字，虽然也有其他方式维护，但是这个问题还是应该注意的，HASH目录是解决办法。
下面有一篇我从其他BLOG转载的文章，是对于文件系统测试的,算是参考:

Linux日志文件系统及性能分析

张文江 , 硕士研究生
吴庆波 , 副研究员
2005 年 9 月

日志文件系统可以在系统发生断电或者其它系统故障时保证整体数据的完整性， Linux是目前支持日志文件系统最多的操作系统之一，本文重点研究了Linux常用的日志文件系统：EXT3、ReiserFS、XFS和JFS日志技术，并采用标准的测试工具PostMark和 Bonnie++对它们进行了测试，给出了详细的性能分析，对Linux服务器应用具有重要的参考价值。

一、概述

所谓日志文件系统是在传统文件系统的基础上，加入文件系统更改的日志记录，它的设计思想是：跟踪记录文件系统的变化，并将变化内容记录入日志。日志文件系统在磁盘分区中保存有日志记录，写操作首先是对记录文件进行操作，若整个写操作由于某种原因(如系统掉电)而中断，系统重启时，会根据日志记录来恢复中断前的写操作。在日志文件系统中，所有的文件系统的变化都被记录到日志，每隔一定时间，文件系统会将更新后的元数据及文件内容写入磁盘。在对元数据做任何改变以前，文件系统驱动程序会向日志中写入一个条目，这个条目描述了它将要做些什么，然后它修改元数据。目前Linux的日志文件系统主要有：在 Ext2基础上开发的Ext3，根据面向对象思想设计的ReiserFS，由SGI IRIX系统移植过来的XFS，由IBM AIX系统移植过来的JFS，其中EXT3完全兼容EXT2，其磁盘结构和EXT2完全一样，只是加入日志技术；而后三种文件系统广泛使用了B树以提高文件系统的效率。

二、Ext3

Ext3文件系统是直接从Ext2文件系统发展而来，目前Ext3文件系统已经非常稳定可靠，它完全兼容Ext2文件系统，用户可以平滑地过渡到一个日志功能健全的文件系统。Ext3日志文件系统的思想就是对文件系统进行的任何高级修改都分两步进行。首先，把待写块的一个副本存放在日志中；其次，当发往日志的I/O 数据传送完成时（即数据提交到日志），块就写入文件系统。当发往文件系统的I/O 数据传送终止时（即数据提交给文件系统），日志中的块副本就被丢弃。

2.1 Ext3日志模式

Ext3既可以只对元数据做日志，也可以同时对文件数据块做日志。具体来说，Ext3提供以下三种日志模式：

日志（Journal ）
文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会，但是它需要很多额外的磁盘访问。例如，当一个新文件被创建时，它的所有数据块都必须复制一份作为日志记录。这是最安全和最慢的Ext3日志模式。
预定（Ordered ）
只有对文件系统元数据的改变才记入日志。然而，Ext3文件系统把元数据和相关的数据块进行分组，以便把元数据写入磁盘之前写入数据块。这样，就可以减少文件内数据损坏的机会；例如，确保增大文件的任何写访问都完全受日志的保护。这是缺省的Ext3 日志模式。
写回（Writeback ）
只有对文件系统元数据的改变才记入日志；这是在其他日志文件系统发现的方法，也是最快的模式。

2.2 日志块设备（JBD）

Ext3 文件系统本身不处理日志，而是利用日志块设备（Journaling Block Device）或叫JBD 的通用内核层。Ext3文件系统调用JDB例程以确保在系统万一出现故障时它的后续操作不会损坏磁盘数据结构。Ext3 与JDB 之间的交互本质上基于三个基本单元：日志记录，原子操作和事务。

日志记录本质上是文件系统将要发出的低级操作的描述。在某些日志文件系统中，日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而，JDB 层使用的日志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间（例如，当低级操作仅仅改变位图的一个位时），但是，它还是相当快的，因为JBD 层直接对缓冲区和缓冲区首部进行操作。

修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机，就会损坏磁盘数据。为了防止数据损坏，Ext3文件系统必须确保每个系统调用以原子的方式进行处理。原子操作是对磁盘数据结构的一组低级操作，这组低级操作对应一个单独的高级操作。

出于效率的原因，JBD 层对日志的处理采用分组的方法，即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。此外，与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如，只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块。

三、ReiserFS

ReiserFS是一个非常优秀的文件系统，其开发者非常有魄力，整个文件系统完全是从头设计的。目前，ReiserFS可轻松管理上百G的文件系统，这在企业级应用中非常重要。ReiserFS 是根据面向对象的思想设计的，由语义层（semantic layer)和存储层（storage layer)组成。语义层主要是对对象命名空间的管理及对象接口的定义，以确定对象的功能。存储层主要是对磁盘空间的管理。语义层与存储层是通过键（key）联系的。语义层通过对对象名进行解析生成键，存储层通过键找到对象在磁盘上存储空间，键值是全局唯一的。

3.1 语义层主要接口

1) 文件接口每个文件拥有一个接口ID，此ID标识一个方法集，此方法集包含访问ReiserFS 文件的所有接口。

2) 属性接口 ReiserFS实现了一种新接口，把文件的每一种属性当做一个文件，属性的值就是此文件的内容，以实现对文件属性的目录式访问。

3) hash接口目录是文件名到文件的映射表，ReiserFS是通过B＋树来实现这张映射表。由于文件名是变长的，而且有时文件名会很长，所以文件名不适合作为键值，故引入了Hash函数来产生键值。

4) 安全接口安全接口处理所有的安全性检查，通常是由文件接口触发的。下面以读文件为例：文件接口的read 方法在读入文件数据之前会调用安全接口的read chech 方法来来进行安全性检查,而后者又会调用属性文件的read方法把文件属性读入以便检查。

5) 项（Item）接口项接口主要是一些对项进行平衡处理的方法，包括：项的拆分，项的评估，项的覆写，项的追加，项的删除，插入及查找。

6) 键分配（key Assignment）接口当把一个键分配给一个项时，键分配接口就会被触发。每一种项都有一个与其对应的键分配方法。

3.2 存储层

ReiserFS是以B+树来存储数据的,其结构如图：

图1：ReiserFS B+ 树

在B+树中的各个结点中有一个称为项（Item）的数据结构。项是一个数据容器，一个项只属于一个结点，是结点管理空间的基本单位。如图所示，一个项包括以下内容：

1) Item_body：项的数据域

2) Item_key：项的键值

3) Item_offset：数据域的起点在结点中的偏移量

4) Item_length：数据域的长度

5) Item_Plugin_id：项接口ID。

图2： ReiserFS 项结构

ReiserFS设计了多种不同的项以存储不同的数据，主要有以下几种：

1) static_stat_data：静态统计数据，包括文件的所有者，访问权限，创建时间，最近修改时间，链接数等

2) cmpnd_dir_item：包含各个目录项

3) extend_pointers：指向一个盘区（extend）

4) node_pointers：指向一个结点

5) bodies：包含的是文件的小部分数据

3.3 ReiserFS日志

与ext3一样，ReiserFS也有三种日志模式，即journal,ordered, writeback。同时，ReiserFS引入了两种日志优化方法：copy-on-capture和steal-on-capture。copy-on-capture:当一个事务要修改的块在另一个未提交的事务中时，就把这个块复制一份，这样这两个事务就可以并发进行了。steal-on-capture：当一个块被多个事务修改时，只有最晚提交的那个事务才把这个块实际写入文件系统，其他事务都不写这个块。

四、XFS

XFS 是一种高性能的64 位文件系统，由SGI 公司为了替代原有的EFS 文件系统而开发的。XFS 通过保持cache 的一致性、定位数据和分布处理磁盘请求来提供对文件系统数据的低延迟、高带宽的访问。目前SGI已经将XFS文件系统从IRIX移植到Linux。

4.1 分配组（allocation groups）

当创建 XFS 文件系统时，底层块设备被分割成八个或更多个大小相等的线性区域（region），用户可以将它们想象成”块”（chunk）或者”线性范围（range）”，在 XFS 中，每个区域称为一个”分配组”。分配组是唯一的，因为每个分配组管理自己的索引节点（inode）和空闲空间，实际上是将这些分配组转化为一种文件子系统，这些子系统透明地存在于 XFS 文件系统内。有了分配组，XFS 代码将允许多个线程和进程持续以并行方式运行，即使它们中的许多线程和进程正在同一文件系统上执行大规模 IO 操作。因此，将 XFS 与某些高端硬件相结合，将获得高性能而不会使文件系统成为瓶颈。分配组在内部使用高效的 B+树来跟踪主要数据，具有优越性能和极大的可扩展性。

4.2 日志记录

XFS 也是一种日志记录文件系统，它允许意外重新引导后的快速恢复。象 ReiserFS 一样，XFS 使用逻辑日志；它不象 ext3 那样将文字文件系统块记录到日志，而是使用一种高效的磁盘格式来记录元数据的变动。就 XFS 而言，逻辑日志记录是很适合的；在高端硬件上，日志经常是整个文件系统中争用最多的资源。通过使用节省空间的逻辑日志记录，可以将对日志的争用降至最小。另外，XFS 允许将日志存储在另一个块设备上，例如，另一个磁盘上的一个分区。这个特性很有用，它进一步改进了 XFS 文件系统的性能。

4.3 延迟分配

延迟分配是 XFS 独有的特性，它是查找空闲空间区域并用于存储新数据的过程。通过延迟分配，XFS 赢得了许多机会来优化写性能。到了要将数据写到磁盘的时候，XFS 能够以这种优化文件系统性能的方式，智能地分配空闲空间。尤其是，如果要将一批新数据添加到单一文件，XFS 可以在磁盘上分配一个单一、相邻区域来储存这些数据。如果 XFS 没有延迟它的分配决定，那么，它也许已经不知不觉地将数据写到了多个非相邻块中，从而显著地降低了写性能。但是，因为 XFS 延迟了它的分配决定，所以，它能够一下子写完数据，从而提高了写性能，并减少了整个文件系统的碎片。在性能上，延迟分配还有另一个优点。在要创建许多”短命的”临时文件的情况下，XFS 可能根本不需要将这些文件全部写到磁盘。因为从未给这些文件分配任何块，所以，也就不必释放任何块，甚至根本没有触及底层文件系统元数据。

五、JFS

JFS 由IBM 公司开发，最初出现在AIX 操作系统之上，它提供了基于日志的字节级、面向事务的高性能文件系统。它具有可伸缩性和健壮性，与非日志文件系统相比，它的优点是其快速重启能力：JFS 能够在几秒或几分钟内就把文件系统恢复到一致状态。JFS 是完全 64 位的文件系统。所有 JFS 文件系统结构化字段都是 64 位大小。这允许 JFS 同时支持大文件和大分区。

为了支持 DCE DFS（分布式计算环境分布式文件系统），JFS 将磁盘空间分配池（称为聚集）的概念, 与可安装的文件系统子树（称为文件集）的概念分开。每个分区只有一个聚集；每个聚集可能有多个文件集。在第一个发行版中，JFS 仅支持每个聚集一个文件集；但是，所有元数据都已设计成适用于所有情况。

如图3所示，聚集开始部分是32K的保留区，紧随其后的是聚集主超级块。超级块包含聚集的信息，例如：聚集的大小、分配组的大小、聚集块的尺寸等等。超级块位于固定位置，这使得 JFS 不依赖任何其它信息，就能够找到它们。在聚集中还有一个重要的结构是聚集索引结点表（Aggregate Inode Table）以及用于其映射的聚集索引结点分配映射表（Aggregate Inode Allocation Map）。AIT表中的inode 0 保留，inode 1 描述聚集本身，inode 2 描述聚集块映射表（block map）， inode 3 描述安装时的内嵌日志，inode 4 描述在聚集格式化期间发现的坏块，保留inode 5 到 15 以备将来扩展。从inode 16 开始，每个inode代表一个文件集。文件集中也有索引结点表以及用于其映射的索引结点分配映射表，文件集中的inode 描述文件集中的每一个文件。

图3 JFS磁盘结构

JFS 使用基于盘区的寻址结构，连同主动的块分配策略，产生紧凑、高效、可伸缩的结构，以将文件中的逻辑偏移量映射成磁盘上的物理地址。盘区是象一个单元那样分配给文件的相连块序列，可用一个由 <逻辑偏移量，长度，物理地址> 组成的三元组来描述。寻址结构是一棵 B+ 树，该树由盘区描述符（上面提到的三元组）填充，根在 inode 中，键为文件中的逻辑偏移量。

JFS 按需为磁盘 inode 动态地分配空间，同时释放不再需要的空间。这一支持避开了在文件系统创建期间，为磁盘 inode 保留固定数量空间的传统方法，因此用户不再需要估计文件系统包含的文件和目录最大数目。另外，这一支持使磁盘 inode 与固定磁盘位置分离。

JFS 提供两种不同的目录组织。第一种组织用于小目录，并且在目录的 inode 内存储目录内容。这就不再需要不同的目录块 I/O，同时也不再需要分配不同的存储器。最多可有 8 个项可直接存储在 inode 中，这些项不包括自己(.)和父(..)目录项，这两个项存储在 inode 中不同的区域内。第二种组织用于较大的目录，用按名字键控的 B+ 树表示每个目录。与传统无序的目录组织比较，它提供更快的目录查找、插入和删除能力。

六、性能测试

6.1 测试环境

6.2测试工具

所用的测试工具是Postmark和Bonnie++。Postmark主要用于测试文件系统在邮件系统或电子商务系统中性能，这类应用的特点是：需要频繁、大量地存取小文件。而Bonnie++主要测试大文件的IO性能。

6.3 测试结果分析

下面将详细分析用上述两种测试工具在各种测试参数配置下的结果。

图4 PostMark 小文件

图 4是PostMark测试小文件的结果，其参数是文件大小50B增至1K, 同一目录下的文件数从5k至20k，事务总数为25k。从图中我们可以看出：

1. 不论是Ext3 还是ReiserFS,在三种日志模式中，写回（writeback）最快，预定（ordered）次之，日志（journal）最慢。

2. 在各种文件系统中，ReiserFS 的写回和预定模式是最快的，且随着文件数的增加事务处理速度下降的也很慢。

3. Ext3在文件数较少时，事务处理速度也比较快，但当文件数超过10k后，速度就比较慢了。

4. XFS和JFS的速度较慢，但随着文件数的增加，速度下降的比较缓慢。

图5 PostMark 大文件

图5是PostMark测试大文件的结果，其参数是文件大小1k至16K,同一目录下的文件数从5k增至20k，事务总数为25k时的测试结果。从图中我们可以看出：

1. 在处理大文件时，当文件数达到15k时，各种文件系统处理能力都较差。

2. 当文件数在小于10k时，ReiserFS的写回、预定模式和EXT3的写回模式性能是比较好的。但这两种文件系统的全日志模式都比较差。

3. XFS文件系统的性能居中，JFS文件系统的性能最差。

图6：Bonnie++顺序写的速率

图7：Bonnie++顺序写时CPU利用率

图6是Bonnie++对文件大小分别为1G，2G，4G顺序写的性能比较，图7是其CPU的利用率比较。从上述两图中我们可以看出：

1. 除了Ext3和ReiserFS的Journal模式的性能较差外，其他几种模式和XFS、JFS写磁盘的速率相当。

2. 从CPU利用率来看，各种文件系统的CPU利用率都比较低，而且随着数据量的增大CPU的利用率降低。

3. Journal模式的CPU利用率比其他两种模式要低。

图8：Bonnie++ 顺序创建文件

图9：Bonnie++ 随机创建文件

图10：Bonnie++ 随机删除文件

图11：Bonnie++ 随机删除文件时的CPU利用率

图8至图11是Bonnie++对创建和删除文件的性能比较，文件数由50k增至400k。从中可以看出：

1. 不管是创建文件，还是删除文件，Ext3和ReiserFS的三种日志模式之间的性能差别可以忽略不计。这主要是由于创建、删除文件都是对元数据的操作，而对元数据的操作三种模式之间本身就没有什么区别。

2. 不管是创建文件，还是删除文件，Ext3的性能都比较差；ReiserFS的性能是最好的，特别是文件数少于100k时。这主要是由于Ext3是基于Ext2的，其目录项是线性组织的，而其他文件系统都是树形结构。

3. 从CPU的利用率来看，除Ext3的利用率交给外，其他几种文件系统的利用率都很低。

综上所述，我们可以得出以下结论：

1. 在小型系统，如：邮件系统或小规模的电子商务系统应用时，ReiserFS和Ext3 的性能是比较好的。但由于Ext3的目录项是线型的，而ReiserFS的目录项是树型的，故当目录下文件较多时，ReiserFS的性能更优。

2. 在对于上G的这种大文件做I/O时，各种文件系统间的性能差距很小，性能瓶颈往往在磁盘上。

3. 虽然XFS和JFS在设计结构上都比较好，但它们主要是针对大中型系统的，在小型系统中由于硬件的原因性能发挥不明显。

4. 全日志模式和预定、写回这两种模式相比，性能差距是比较大的；而预定和写回之间的性能差距不大。所以性能和安全兼顾时，文件系统的缺省安全模式，即预定模式是比较好的选择。

做个关于Silverlight的小调查

温飞飞 ai829 — Sat, 31 May 2008 22:16:51 +0800

做一个调查，有多少人知道Silverlight，如果从成熟的1.0和beta的2.0中选，现在你会选择用那个，另外在另外半年内你选择用那个版本。
PS: Silverlight各个版本在国内的下载量已达5000W（官方消息）

配置Heartbeat

瞄的技术 — Fri, 30 May 2008 18:06:41 +0800

Heartbeat是linux的HA插件，它可以通过主备的互相检测来到达主服务器倒了，自动切换备服务器。不仅可以用于lvs，其他服务也可以使用。
Ldirectord是lvs的启动工具,可以根据配置来启动对应LVS的服务。

由于资源的问题只在2台服务器上配置Heartbeat可以自动切换，没有测试Ldirectord。这部分介绍网上有很多。实际就是在两个配置了一样的LVS Director机器上实现主备的自动切换。

主 eth0:202.106.184.251外网IP,eth1:10.55.37.220内网IP
备 eth0:202.106.184.145外网IP,eth1:10.55.37.145内网IP。
2台服务器都要安装Heartbeat，并配置节点，Heartbeat可以通过串口或网络来检查主节点服务器是否存在，因此2个机器内网IP提供给Heartbeat使用。
在主备两个机器上都要在配置一个VIP，VIP提供用户访问。
VIP:202.106.184.132

Heartbeat的配置
在两个主备D机器上：
安装
yum install heartbeat-ldirectord.i386

yum install heartbeat.i386

配置VIP
vi /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
IPADDR=202.106.184.132
broadcast=202.106.184.255
NETMASK=255.255.255.255
ONBOOT=yes#开机就启动

/etc/rc.d/init.d/network restart #重启网卡

route add -host 202.106.184.132 dev eth0:0

在两台机器的hosts上把两个主机名对应的IP地址增加上。
XD_Blog_Web_184_251 202.106.184.251
XD_Blog_Web_184_145 202.106.184.145

配置Heartbeat：

在/usr/share/doc/heartbeat-2.1.3下有配置文件的模板
authkeys 是主备服务器验证配置文件,需要上传到/etc/ha.d/ 权限600
格式
auth 2 #选择哪种认证
#1 crc #crc方式
2 sha1 HI! #sha1加密后面的”HI!”是密码
#3 md5 Hello! #md5方式

haresources 是Heartbeat主节点和监控服务的配置文件
格式:
XD_Blog_Web_184_251 IPaddr::202.106.184.251/24/202.106.184.255 ipvsadm ldirectord::www
#XD_Blog_Web_184_251主节点的主机名，需要在/etc/hosts下增加主机名对应的ip地址;
#IPaddr::vip/24/网关;
#ipvsadm ldirectord::www 要切换的服务及ldirectord读取www这个配置文件

我测试的是httpd服务
XD_Blog_Web_184_251 IPaddr::202.106.184.132/24/202.106.184.255 httpd

ha.cf是Heartbeat的配置文件，主要是在主机down的时候备机如何处理。
bcast eth1 # 其他参数基本用默认的，这个参数是两台服务器的Heartbeat用什么形式连接，用内网端口eth1连接

node XD_Blog_Web_184_251#一共有多少个节点就写多少个
node XD_Blog_Web_184_145
其他参数解释:
serial /dev/ttyS0

使用串口heartbeat - 如果你不使用串口heartbeat, 你必须选择其它的介质，比如以太网bcast (ethernet) heartbeat。如果你使用其它串口heartbeat，修改/dev/ttyS0 为其它的串口设备。

watchdog /dev/watchdog

可选项：watchdog功能提供了一种方法能让系统在出现故障无法提供”heartbeat”时，仍然具有最小的功能，能在出现故障1分钟后重启该机器。这个功能可以帮助服务器在确实停止心跳后能够重新恢复心跳。如果你想使用该特性，你必须在内核中装入”softdog” 内核模块用来生成实际的设备文件。想要达到这个目的, 首先输入 “insmod softdog” 加载模块。然后，输入”grep misc /proc/devices” 注意显示的数字 (should be 10).然后, 输入”cat /proc/misc | grep watchdog” 注意输出显示出的数字(should be 130)。现在你可以生成设备文件使用如下命令：”mknod /dev/watchdog c 10 130″ 。

bcast eth1

指定使用的广播heartbeat 的网络接口eth1(修改为eth0, eth2, 或你所使用的接口)

keepalive 2

设置心跳间隔时间为2两秒。

warntime 10

在日志中发出最后心跳”late heartbeat” 前的警告时间设定。

deadtime 30

在30秒后明确该节点的死亡。

initdead 120

在一些配置中，节点重启后需要花一些时间启动网络。这个时间与”deadtime”不同，要单独对待。至少是标准死亡时间的两倍。

hopfudge 1

可选项：用于环状拓扑结构,在集群中总共跳跃节点的数量。

baud 19200

串口波特率的设定(bps).

udpport 694

bcast和ucast通讯使用的端口号694 。这是缺省值，官方IANA 使用标准端口号。

nice_failback on

可选项：对那些熟悉Tru64 Unix, 心跳活动就像是”favored member”模式。主节点获取所有资源直到它宕机,同时备份节点启用。一旦主节点重新开始工作, 它将从备份节点重新获取所有资源。这个选项用来防止主节点失效后重新又获得集群资源。

node linuxha1.linux-ha.org

强制选项：通过`uname -n`命令显示出的集群中的机器名。

node linuxha2.linux-ha.org

强制选项：通过`uname -n`命令显示出的集群中的机器名。

respawnuseridcmd

可选项：列出可以被spawned 和监控的命令。例如：To spawn ccm 后台进程，可以增加如下内容：
respawn hacluster /usr/lib/heartbeat/ccm
通知heartbeat 重新以可信任userid身份运行(在我们的例子中是hacluster) 同时监视该进程的”健康”状况，如果进程死掉，重启它。例如ipfail, 内容如下：
respawn hacluster /usr/lib/heartbeat/ipfail
NOTE: 如果进程以退出代码100死掉, 这个进程将不会respawned。

pingping1.linux-ha.orgping2.linux-ha.org ….

可选项：指定ping 的节点。这些节点不是集群中的节点。它们用来检测网络的连接性，以便运行一些像ipfail的模块。

两个服务器启动Heartbeat
/etc/init.d/heartbeat start

当主服务器关闭时，服务会自动切换到备服务器。
备服务器检查到主服务器没有相应的Log:
heartbeat[9836]: 2008/05/30_15:07:47 WARN: node xd_blog_web_184_251: is dead
heartbeat[9836]: 2008/05/30_15:07:47 WARN: No STONITH device configured.
heartbeat[9836]: 2008/05/30_15:07:47 WARN: Shared disks are not protected.
heartbeat[9836]: 2008/05/30_15:07:47 info: Resources being acquired from xd_blog_web_184_251.
heartbeat[9836]: 2008/05/30_15:07:47 info: Link xd_blog_web_184_251:eth1 dead.
harc[10882]:    2008/05/30_15:07:47 info: Running /etc/ha.d/rc.d/status status
heartbeat[10883]: 2008/05/30_15:07:47 info: No local resources [/usr/share/heartbeat/ResourceManager listkeys xd_blog_web_184_145] to acquire.
mach_down[10911]:       2008/05/30_15:07:47 info: Taking over resource group IPaddr::202.106.184.132/24/202.106.184.255
ResourceManager[10937]: 2008/05/30_15:07:47 info: Acquiring resource group: xd_blog_web_184_251 IPaddr::202.106.184.132/24/202.106.184.255 httpd
IPaddr[10964]: 2008/05/30_15:07:47 INFO: Running OK
mach_down[10911]:       2008/05/30_15:07:47 info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[10911]:       2008/05/30_15:07:47 info: mach_down takeover complete for node xd_blog_web_184_251.
heartbeat[9836]: 2008/05/30_15:07:47 info: mach_down takeover complete.

主服务器恢复，备服务器停止服务器的Log
heartbeat[9836]: 2008/05/30_15:17:48 info: Heartbeat restart on node xd_blog_web_184_251
heartbeat[9836]: 2008/05/30_15:17:48 info: Link xd_blog_web_184_251:eth1 up.
heartbeat[9836]: 2008/05/30_15:17:48 info: Status update for node xd_blog_web_184_251: status init
heartbeat[9836]: 2008/05/30_15:17:48 info: Status update for node xd_blog_web_184_251: status up
harc[11426]:    2008/05/30_15:17:48 info: Running /etc/ha.d/rc.d/status status
heartbeat[9836]: 2008/05/30_15:17:48 info: Status update for node xd_blog_web_184_251: status active
heartbeat[9836]: 2008/05/30_15:17:48 info: all clients are now paused
harc[11442]:    2008/05/30_15:17:48 info: Running /etc/ha.d/rc.d/status status
heartbeat[9836]: 2008/05/30_15:17:48 info: remote resource transition completed.
heartbeat[9836]: 2008/05/30_15:17:48 info: xd_blog_web_184_145 wants to go standby [foreign]
harc[11458]:    2008/05/30_15:17:48 info: Running /etc/ha.d/rc.d/status status
heartbeat[9836]: 2008/05/30_15:17:49 info: standby: xd_blog_web_184_251 can take our foreign resources
heartbeat[11474]: 2008/05/30_15:17:49 info: give up foreign HA resources (standby).
ResourceManager[11487]: 2008/05/30_15:17:49 info: Releasing resource group: xd_blog_web_184_251 IPaddr::202.106.184.132/24/202.106.184.255 httpd
ResourceManager[11487]: 2008/05/30_15:17:49 info: Running /etc/init.d/httpd stop
ResourceManager[11487]: 2008/05/30_15:17:49 info: Running /etc/ha.d/resource.d/IPaddr 202.106.184.132/24/202.106.184.255 stop
IPaddr[11577]: 2008/05/30_15:17:49 INFO: ifconfig eth0:0 down
IPaddr[11551]: 2008/05/30_15:17:49 INFO: Success
heartbeat[11474]: 2008/05/30_15:17:49 info: foreign HA resource release completed (standby).
heartbeat[9836]: 2008/05/30_15:17:49 info: Local standby process completed [foreign].
heartbeat[9836]: 2008/05/30_15:17:51 info: all clients are now resumed
Ldirectord的配置，没有经过测试,将Ldirectord.cf存为www.cf，内容如下:

virtual=202.106.184.132:80 #vip
real=202.106.184.250:80 gate #R机
fallback=127.0.0.1:80 gate
service=http
request=”index.php”
receive=”Test Page”
#virtualhost=some.domain.com.au
scheduler=rr
#persistent=600
#netmask=255.255.255.255
protocol=tcp
checktype=negotiate
checkport=80
#request=”index.php”
#receive=”Test Page”
#virtualhost=www.x.y.z

lvs 安装及配置

瞄的技术 — Fri, 30 May 2008 18:05:38 +0800

LVS介绍和各种模式调度算法去LVS官网看就好了。不过这个配置没什么实际意义，Director是单点，OVER了就全完了，这部分还要在学习一下。
另外网络环境是个很灵活的事，需要灵活处理。下面的安装方法也是我参考其他的文档，尝试的。

安装
linux kernel2.6的都不需要打patch。只要安装ipvsadm就好了

实现VS/NAT:
这个模式实际是信息双向流动都通过lvs,内部服务器是不可见的，发包收包都是通过lvs的D机来做的，因此貌似D机器的压力会很大，要处理双向的流量。

Director eth0:202.106.184.251外网IP,eth1:10.55.37.220内网IP。我用的是双网卡，经过和其他同事讨论，单网卡也一样。

RealServer只需要设置网关为D的内网IP即可。
RealServer：10.55.37.132；10.55.37.231内网Ip

Director 配置:
yum install ipvsadm.i386

vi /etc/sysctl.conf
net.ipv4.ip_forward = 1 #打开IP转发

sysctl -p 重新使用配置
ipvsadm -L #显示内核虚拟服务器表
ipvsadm -C 清除内核虚拟服务器表中的所有记录。

ipvsadm -A -t 202.106.184.251:80 -s wlc #-a加记录 -t tcp服务 -s调度模式默认wlc
ipvsadm -a -t 202.106.184.251:80 -r 10.55.37.145:80 -m #-m nat模式 -r 真实的服务器地址:端口
ipvsadm -a -t 202.106.184.251:80 -r 10.55.37.132:80 -m

/etc/rc.d/init.d/ipvsadm save 将配制保存到/etc/sysconfig/ipvsadm 配制文件中

在两台R机器
vi /etc/sysconfig/network
GATEWAY=10.55.37.220 #修改网关为D机IP

在R机器开apache配置虚拟目录，设置域名到D机的HOST,访问域名可以发现在两个R机器轮询。

VS/DR:
这个模式类似单臂路由，指的是用户的请求通过LVS的D机进去，分发给R机器，但是R机回包的时候不原路经过D机返回给客户端，而是经过其他路由或线路范围，这样在D机只处理请求并不向用户返回数据，降低压力。
D机器依然是双网卡，单网卡也可以，有的配置方案上是单网卡+VIP,貌似如果没有HA的话，VIP不需要。

Director eth0:202.106.184.251外网IP,eth1:10.55.37.220内网IP。
ipvsadm -C #清掉以前的配置记录
ipvsadm -A -t 202.106.184.251:80 -s wlc
ipvsadm -a -t 202.106.184.251:80 -r 10.55.37.145:80 -g
ipvsadm -a -t 202.106.184.251:80 -r 10.55.37.231:80 -g

在两台R机器
vi /etc/sysctl.conf #设置arp 这部分我没太搞明白
net.ipv4.ip_forward = 1
net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_announce = 2 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2


vi /etc/sysconfig/network-scripts/ifcfg-lo:0 #增加vip

DEVICE=lo:0

IPADDR=202.106.184.251 #我这里写的就是D机的外网IP,如果D机器对外提供访问的是VIP,这里填对应的VIP

NETMASK=255.255.255.255

ONBOOT=yes
/etc/rc.d/init.d/network restart #重启网卡

在R机器开apache配置虚拟目录，设置域名到D机的HOST,访问域名可以发现在两个R机器轮询。
arp配置的含义:

arp_ignore - 整型
        当对要求解析本地目标IP地址的ARP请求做响应时，定义不同的模式：
        0 - (缺省): 响应配置在任何接口上的任何本地目标地址
        1 - 只有当目标IP地址是配置在进入接口上的本地地址时才响应
        2 - 只有当目标IP地址是配置在进入接口上的本地地址，并且发送者的IP地址处于本接口的同一网段时才响应
        3 - 不响应用scope host配置的本地地址，只有通用地址和链接地址会被响应
        4-7 - 保留
        8 - 不响应所有的本地地址

        conf/{all,interface}/arp_ignore的最大值在{interface}上收到APR请求的时候被使用。

arp_announce - 整型
        在ARP请求被送到接口上，要在IP包中宣布本地源IP地址时，定义不同的限制级别：
        0 - （缺省）使用配置在任何接口上的任何本地地址
        1 - 尝试避免本接口上的本地地址不是目标的子网段。当目标主机请求的源地址是逻辑网段的一部分时候，这种模式有用。
            如果我们生成这个请求，我们将会检查包含目标IP的所有子网，保留来自这些子网的源地址。
            如果没有这样的子网，就用级别2的规则来选择。
        2 - 总是使用这个目标的最好的本地地址。在这种模式下，我们忽略IP包中的源地址，尝试选择我们喜欢的本地地址给目标主机。
            选择的方式是在输出接口上包含目标IP地址的所有子网里寻找主要的IP地址。
            如果没有合适的的目标地址，就选择输出接口或者所有其他接口上的第一个地址。

            conf/{all,interface}/arp_announce的最大值是被使用的。

            提高限制级别会提供更多的机会来接收到解析目标的响应回答，而降低级别会宣布更多有效的发送者信息。

Silverlight 2.0 Developer Reference

温飞飞 ai829 — Sat, 24 May 2008 23:08:31 +0800

here is the Silverlight 2.0 Developer Reference from Brad Abrams
It is very useful for Silverlight Developers. Enjoy!~~

you can download the image file in three file formats

JPG file | PNG file | TIF file

MYSQL数据库设计的一点总结

瞄的技术 — Fri, 23 May 2008 19:26:32 +0800

大大小小也搞过一些数据库设计，见过一些其他人的设计，看过些书，总结总结，经验谈。
选表类型：
大家都知道mysql的myisam表适合读操作大，写操作少;表级锁表
innodb表正好相反；行级锁表
互联网服务，不算支付性的服务外，互动产品，新闻系统等等一般都是读多，写少。用myisam表比较合适。

表的设计
定长表:所有列的字段长度都是定长的。可以去查mysql的手册不定长字段是VARCHAR、BLOB或TEXT。int char都是定长的，定长表占用空间会大。
动态表:就是字段不是都定长的。
定长表要比动态表检索速度快。

软件系统的设计习惯是把每张表都分清很明确的功能，比如用户表都是用户信息，如果需要同时从留言表取数据，又从用户表取用户信息的时候，就会采用联合查询，有的时候一些操作还会用left,join等各种复杂sql语句，没准还要用mysql的函数。如果是针对访问量，读取量很大的互联网服务时，同时并发去读，数据量又大，很可怕。最好是如果数据不会修改，在常用的表上有冗余字段，能够做到一次读，把数据都拿到；可以有冗余的写操作，但减少复杂的查询操作。

在设计表的时候要将这个表的所有字段类型占用的字节数求和，并乘以你的预期（如:存储100W数据量），就是整张表未来会占用容量。

拆表拆库
拆表就是将一张表复制N多张，里面分别存放不用内容的数据，数据的存放是用HASH算法来决定放入哪张表。
例如用户表user,传统情况就是一张表，拆表就是将表复制为user_01,user_02等里面都存放了格式一样的不同用户数据。

拆库和拆表类似，就是库的复制。

拆表或拆库有很多的HASH算法，主要目的就是减少表的数据量，用算法保证每个表的数据量平均，请求，读写操作被分摊降低压力，而且安全，出了问题最多是一部分用户受影响。缺点就是检索不方便，需要另想办法。

很多网站为了前期省事都会采用discuz的产品，如bbs,blog等，网上有不少关于这个产品的介绍和优化方法，没细研究过，听过一些网站介绍他们的优化方法时，对于数据库主要是采用主从的方法，将数据库的读写分离来提高性能，但是个人觉得这种办法在数据量到了规模的时候就OVER了，并发和读写操作没提升，数据也是会逐渐累计超过限制。

互联网服务由于要应对大数据量，大请求量，所以在设计开发的时候就不要太学院派，不要力图达到数据库、程序的设计“优美”，性能是最要紧的。

随机日志

2005年11月01日 -- Windows live–Google和Microsoft的战争前兆 (4)
2005年04月28日 -- 寻找新的浏览方式–picture viewer (0)
2005年07月25日 -- 微软的Virtual earth (1)
2006年06月05日 -- 当当网音乐频道设计项目成功上线 (1)
2005年03月30日 -- Flash支持的系统平台和语言的列表 (0)

[5月]RIAMeeting第六次开发者交流活动

温飞飞 ai829 — Wed, 21 May 2008 10:43:45 +0800

[5月]RIAMeeting第六次开发者交流活动
5月的一场大地震带给我们过多的悲痛，但国家还要兴起，技术还要进步，让广大RIA开发者化悲愤为力量，继续开创中国的RIA事业吧！
本月的25日，RIAMeeting将举办第六次开发者交流活动，本次活动邀请到了Adobe总部的Air Evangelist （老外）为我们讲一个 General AIR Overview，之后会介绍一下Flash10的新特性以及讨论展示一些Flash10的示例代码，以下是本次活动的详情：
会议时间：周日(5月25日) 13:30-17:00
会议日程：
13:30–14:00 签到时间
14:00-15:00 General AIR Overview
15:00–16:00 Flash10新特性
16:00–17:00 分组讨论

会议地点：
Adobe中国研发中心
北京海淀区中关村东路1号院清华科技园科技大厦 A座 21层

请使用这个链接 http://www.riameeting.cn/register/ 报名

网页版HTTPWATCH 网站性能调试好工具

瞄的技术 — Tue, 20 May 2008 17:33:10 +0800

httpwatch现在是开发互联网服务的必用工具(IE下使用)，ff下是firebug,yslow。
http://www.gomez.com/info_center/instant_test.php
这个工具类似网站版的httpwatch,可以列出你所制定URL页面的各个内部元素的下载时间及状态。另外还有一个很不错的功能，就是选择IDC ，有了这个选项你可以测试其他地区的用户对你网站的访问速度。帮助你找到在你网页中制约下载速度是网络问题，还是页面布局，或者是某一个元素的问题。

随机日志

敏捷堂的第一期电子杂志

瞄的技术 — Mon, 28 Apr 2008 10:42:13 +0800

张逸在敏捷中国的邮件列表里发的，我转载上传到工作室的博客上，方便大家传阅。敏捷之道第一期

d945bbe1

随机日志

2008年02月20日 -- on AIR Tour Europe (2)
2008年01月16日 -- Silverlight的一些中文资源 (0)
2005年09月18日 -- 80s noteBar(Beta1.0)桌面版 (7)
2005年04月11日 -- 80s has been added to MXNA (0)
2004年12月30日 -- Flex里DataGird出现的问题 (0)

80s team blog

CSDN（SD俱乐部第4期）下一代用户体验设计

相关日志

Python的小工具,使用PHP的序列化数据

相关日志

Silverlight 2.0 Developer Reference

相关日志

感谢蓝色寄来的书

相关日志

模拟用户登录脚本,手工输入验证码

相关日志

Adobe Flex/Air中国行调查

相关日志

一个目录下放多少文件合适？

相关日志

做个关于Silverlight的小调查

相关日志

配置Heartbeat

相关日志

lvs 安装及配置

相关日志

Silverlight 2.0 Developer Reference

相关日志

MYSQL数据库设计的一点总结

随机日志

[5月]RIAMeeting第六次开发者交流活动

相关日志

网页版HTTPWATCH 网站性能调试好工具

随机日志

敏捷堂的第一期电子杂志

随机日志