用javascript + css来实现表格或li的背景隔行换色. 可以先给table 或者 ul一个id，根据id用js来得到相对应的对象元素，再来获取他下面的元素,循环遍历一下，组合一下元素的background-color属性，给它添上就可以了，具体的实现自己可以动手做咯.
function initUl(){
var ul_obj = document.getElementById('ulEle'); //ulEle 为对象的ID
var lis = ul_obj.getElementsByTagName('li');
for (var i=0; i<lis.length;i++){
if ( i%2==0){
lis[i].style.backgroundColor="#ccc";
}else{
lis[i].style.backgroundColor="#fff";
}
}
}
initUl();
Rsync 是什么?
Rsync是一个远程数据同步和文件传输工具，可通过LAN 或互联网快速同步多台主机间的文件.也提供了一个客户机和远程文件服务器进行文件传输。
Rsync 的特色：
快速：第一次同步时 rsync 会复制全部内容，但在下一次只传输修改过的文件。
安全：rsync 允许通过 ssh 协议来加密传输数据。
更少的带宽：rsync 在传输数据的过程中可以实行压缩及解压缩操作，因此可以使用更少的带宽。
特权：安装和执行 rsync 无需特别的权限。
能更新整个目录树和文件系统。
另外对于大量文件从一台服务器上迁移到另一台服务器上，rsync的确是一个不可不用的传输工具。
Rsync服务器架设比较简单，可能我们安装好rsync后，并没有发现配置文件，以及rsync服务启动程序，因为每个管理员可能对rsync用途不一样，所以一般只是安装好软件就完事了，让管理员来根据自己的用途和方向来架设自己的rsync服务器。
架设rsync服务器过程：
架设rsync服务器比较简单，rsync安装后，写一个配置文件即可。此文件的书写也有规则的，可以参照 rsync.samba.org 上的文档来做。
获取svn安装包：
http://subversion.tigris.org/downloads/subversion-1.6.6.tar.gz
http://subversion.tigris.org/downloads/subversion-deps-1.6.6.tar.gz
编译svn以root用户登录：
# tar xfvz subversion-1.6.6.tar.gz
# tar xfvz subversion-deps-1.6.6.tar.gz
# cd subversion-1.6.6
# ./configure –prefix=/opt/svndata –without-berkeley-db
(注：以svnserve方式运行，不加apache编译参数。以fsfs格式存储版本库，不 编译berkeley-db)
# make && make install
最后加入SVN Path 以方便操作：
PATH=$PATH:/opt/svn/bin
export PATH
测试是否安装成功：
# svnserve –-version
svn配置建立svn版本库目录可建多个：
新建文件夹：
# mkdir -p /opt/svndata/test
建立svn版本库：
# svnadmin create /opt/svndata/test
修改svn版本库配置文件版本库：
# vi /opt/svndata/test/conf/svnserve.conf
内容修改为:
[general]
anon-access = none
auth-access = write
password-db = /opt/svndata/test/conf/passwd
authz-db = /opt/svndata/test/conf/authz
realm = test
passwd文件格式如下：列出要访问svn的用户，每个用户一行，示例：
[users]
username = password
配置svn用户访问权限：
# vi /opt/svndata/test/conf/authz
注意：
* 权限配置文件中出现的用户名必须已在用户配置文件中定义。
* 对权限配置文件的修改立即生效，不必重启svn
版本库目录格式：
[<版本库>:/项目/目录]
@<用户组名> = <权限>
<用户名> = <权限>
[/],表示根目录及以下，根目录是 svnserve启动时指定的，我们指定为/opt/svndata，[/]就是表示对全部版本库设置权限。
[repos:/] 表示对版本库repos设置权限
权限主体可以是用户组、用户或*，用户组在前面加@，*表示全部用户。
权限可以是w、r、wr和空，空表示没有任何权限。
启动svn服务器:
svnserve -d -r /opt/svndata/test
-d:表后台运行
-r:版本库的根目录，如果在根目录下面再建版本库，那么访问的时候就得输入
svn://IP/xxx xxx即为你在版本库下面建立的版本库
linux下解压xdebug包。
1、进入xdebug,在这个目录下先运行php目录下面的bin/phpize；
2、在运行
./configure \
--enable-xdebug\
--with-php-config=/你php的bin路径/php-config；
3、make
好了，结束了。这是时候会在xdebug的目录下生成 目录modules，目录下有xdebug.so文件，把xdebug.so复制到你想放的目录。
4、在php的配置文件后面加上
zend_extension = "/路径/xdebug.so"
也不一定是zend_extension，也可能是zend_extension_ts,或者zend_extension_debug。
5、重启下，看phpinfo();（或者 命令行里 ./php -m |grep debug）
有结果就成了.
在大容量，高负荷的web系统中，对数据库进行一系列拆分，可有效提升数据库容量和性能。在初学程序的早期，程序员通常都喜欢按传统数据库设计模式，设计为单库和单一功能表的结构，这样的结构在数据量和并发量达到一定程度之后，会出现严重性能问题和维护问题。在出现问题的时候才着手进行优化，会非常痛苦，所以应该在系统架设之初就考虑好之后会出现的问题。
目前有些数据库策略是采用单库结构，然后通过同步分发到数台服务器实现读写分离。个人觉得这样的策略非常笨拙，还是想办法将其分隔开来好，否则每台机器的内存都很容易超支。
一般只对数据量比较大的表进行拆分，这应该没有什么异议；还有一种是有可能会进行维护的比较重要的表，比如文章目录表，如果有从其它系统倒数据进来的可能的话，也要拆掉，不然倒数据时一不小心把目录表弄坏了，发现忘了备份，那真是欲哭无泪。
下面来分析一下：
一、时间结构
如果业务系统对时效性较高，比如新闻发布系统的文章表，可以把数据库设计成时间结构，按时间分有几种结构：
1) 平板式:
表类似：
article_200901
article_200902
article_200903
用年来分还是用月可自定，但用日期的话表就太多了，也没这必要。一般建议是按月分就可以。
这种分法，其难处在于，假设我要列20条数据，结果这三张表里都有2条，那么业务上很有可能要求读三次表。如果时间长了，有几十张表，而每张表是0条，那不就是要读完整个系统的表才行么？另外这个结构，要作分页是比较难实现的。
主键：在这个系统中，主键是11位带毫秒的时间戳，不要用自动编号，否则难以通过主键定位到表，也可以在查询时带上时间，但比较烦琐。
2) 归档式:
表类似：
article_old
article_new
为了解决平板式的缺点，可以采用时间归档式设计，可以看到这个系统只有两张表。一张是旧文章表，一张是新文章表，新文章表放2个月的信息，每天定期把2个月中的最早一天的文章归入旧表中。这样一方面可以解决性能问题，因为一般新闻发布系统读取的都是新的内容，旧的内容读取少；第二可以委婉地解决功能问题，比如平板式所说的问题，在归档式中最多也只需要读2张表就完成了。
归档式的缺点在于旧表容量还是相对比较大，如果业务允许，可对旧表中的超旧内容进行再归档或直接清理掉。
二、版块结构
如果按照文章的所属版块进行拆表，比如新闻、体育版块拆表，一方面可以使每个表数据量分离，另一方面是各版块之间相互影响可降到最低。假如新闻版块的数据表损坏或需要维护，并不会影响到体育版块的正常工作，从而降低了风险。版块结构同时常用于bbs这样的系统。
板块结构也有几种分法：
1) 对应式:
对于版块数量不多，而且较为固定的形式，就直接对应就好。比如新闻版块，可以分出新闻的目录表，新闻的文章表等。
news_category
news_article
sports_category
sports_article
可看到每一个版块都对应着一组相同的表结构，好处就是一目了然。在功能上，因为版块之间还是有一些隔阂，所以需要联合查询的需求不多，开发上比时间结构的方式要轻松。
主键：依旧要考虑的，在这个系统中，主键是版块 时间戳，单纯的时间戳或自动编号也能用，查询时要记得带上版块用于定位表。
2) 冷热式:
对应式的缺点是，如果版块数量很大而且不确定，那要分出的表数量就太多了。举个例子：百度贴吧，如果按一个词条一个表设计，那得有多少张表呢？
用这样的方式吧。
tieba_汽车
tieba_飞机
tieba_火箭
tieba__unite
这个表汽车、火箭表是属于热门表，定义为新建的版块放在unite表里面，待到其超过一万张主贴的时候才开对应表结构。因为在贴吧这种系统中，冷门版块肯定比热门版块多得多，这些冷门版块通常只有几张帖子，为它们开表也太浪费了；同时热门版块数量和访问量等，又比冷门版块多得多，非常有特点。
unite表还可以扩展成哈希表，利用词条的md5编码，可以分成n张表，我算了一下，md5前一位可分36张表，两位即是1296张表，足够了。
tieba_unite_ab
tieba_unite_ac
...
三、哈希结构
哈希结构通常用于博客之类的基于用户的场合，在博客这样的系统里有几个特点，1是用户数量非常多，2是每个用户发的文章数量都较少，3是用户发文章不定期，4是每个用户发得不多，但总量仍非常之大。基于这些特点，用以上所说的任何一种分表方式都不合适，一没有固定的时效不宜用时间拆，二用户很多，而且还偏偏都是冷门，所以也不宜用版块（用户）拆。
哈希结构在上面有所提及，既然按每个用户不好直接拆，那就把一群用户归进一个表好了。
blog_aa
blog_ab
blog_ac
...
如上所说，md5取前两位哈希可以达到1296张表，如果觉得不够，那就再加一位，总数可达46656张表，还不够？
表的数量太多，要创建这些表也是挺麻烦的，可以考虑在程序里往数据库insert之前，多执行一句判断表存在与否并创建表的语句，很实用，消耗也并不很大。
主键：依旧要考虑的，在这个系统中，主键是用户ID 时间戳，单纯的时间戳或自动编号也能用，但查询时要记得带上用户名用于定位表。
四、总分结构
以上的这些结构，根据每个业务系统，能想出的估计还有很多。不过现在互联网业务越来越复杂了，有些时候，单一的拆分法还不能实现需求，需要几种拆分方案一起实施，多管齐下，这时候其中的逻辑会让人绕晕。我就开发过一个系统，仅仅是将哈希结构和时间结构混着一用，觉得逻辑就相当复杂。
所以，除了拆表之外，按最原始的单库单表，再建一个总表，是非常有利的架构。在这个架构中，每次往数据库会写入两倍数据，读取主要依赖拆表提升性能，总表用于实现拆表后难以实现的功能并且用于每天的定时备份；另外总表和分表还相互是一个完整的备份，任何一个分表损坏或数据不正常，都可以从总表中读到正确的数据并恢复，反之亦然。
在总分结构中，让人感到质疑的是总表的性能和可维护性。我的方案是总表可采用相对能保证稳定的一些服务软件和架构，例如oracle，或lvs pgpool PostgreSQL，重点保证数据稳定；相对的，分表就用轻量级的mysql，重点在于速度。能够对总分表各采用不同的软件和方案，也是总分结构的一大特点
