系统

# uname -a               # 查看内核/操作系统/CPU信息
# head -n 1 /etc/issue   # 查看操作系统版本
# cat /proc/cpuinfo      # 查看CPU信息
# hostname               # 查看计算机名
# lspci -tv              # 列出所有PCI设备
# lsusb -tv              # 列出所有USB设备
# lsmod                  # 列出加载的内核模块
# env                    # 查看环境变量

资源

# free -m                # 查看内存使用量和交换区使用量
# df -h                  # 查看各分区使用情况
# du -sh <目录名>        # 查看指定目录的大小
# grep MemTotal /proc/meminfo   # 查看内存总量
# grep MemFree /proc/meminfo    # 查看空闲内存量
# uptime                 # 查看系统运行时间、用户数、负载
# cat /proc/loadavg      # 查看系统负载 (解释详见:

http://blog.haohtml.com/index.php/archives/6860)

磁盘和分区

一、uptime

** ** **** Uptime命令的显示结果包括服务器已经运行了多长时间，有多少登陆用户和对服务器性能的总体评估（load average）。load average值分别记录了上个1分钟，5分钟和15分钟间隔的负载情况，load average不是一个百分比，而是在队列中等待执行的进程的数量。如果进程要求CPU时间被阻塞（意味着CPU没有时间处理它），load average值将增加。另一方面，如果每个进程都可以立刻得到访问CPU的时间，这个值将减少。

UP kernel下的load average的最佳值是1，这说明每个进程都可以立刻被CPU处理，当然，更低不会有问题，只说明浪费了一部分的资源。但在不同的系统间这个值也是不同的，例如一个单CPU的工作站，load average为1或者2都是可以接受的， 而在一个多CPU的系统中这个值应除以物理CPU的个数，假设CPU个数为4，而load average为8或者10，那结果也是在2多点而已。

你可以使用uptime判断一个性能问题是出现在服务器上还是网络上。例如，如果一个网络应用运行性能不理想，运行uptime检查系统负载是否比较高，如果不是这个问题更可能出现在你的网络上。

二、top

Top命令显示了实际CPU使用情况，默认情况下，它显示了服务器上占用CPU的任务信息并且每5秒钟刷新一次。你可以通过多种方式分类它们，包括PID、时间和内存使用情况。

下面是输出值的介绍：

引用

PID：进程标识

USER；进程所有者的用户名

PRI：进程的优先级

NI：nice级别

SIZE：进程占用的内存数量（代码＋数据＋堆栈）

RSS；进程使用的物理内存数量

SHARE；该进程和其他进程共享内存的数量

STAT：进程的状态：S＝休眠状态，R＝运行状态，T＝停止状态，D＝中断休眠状态，Z＝僵尸状态

%CPU：共享的CPU使用

%MEM；共享的物理内存

TIME：进程占用CPU的时间

COMMAND：启动任务的命令行（包括参数）

进程的优先级和nice级别

进程优先级是一个决定进程被CPU执行优先顺序的参数，内核会根据需要调整这个值。Nice值是一个对优先权的限制。进程优先级的值不能低于nice值。（nice值越低优先级越高）

进程优先级是无法去手动改变的，只有通过改变nice值去间接的调整进程优先级。如果一个进程运行的太慢了，你可以通过指定一个较低的nice值去为它分配更多的CPU资源。当然，这意味着其他的一些进程将被分配更少的CPU资源，运行更慢一些。Linux支持nice值的范围是19（低优先级）到-20（高优先级），默认的值是0。如果需要改变一个进程的nice值为负数（高优先级），必须使用su命令登陆到root用户。下面是一些调整nice值的命令示例，

以nice值-5开始程序xyz

#nice –n -5 xyz

改变已经运行的程序的nice值

#renice level pid

将pid为2500的进程的nice值改为10

#renice 10 2500

僵尸进程

当一个进程被结束，在它结束之前通常需要用一些时间去完成所有的任务（比如关闭打开的文件），在一个很短的时间里，这个进程的状态为僵尸状态。在进程完成所有关闭任务之后，会向父进程提交它关闭的信息。有些情况下，一个僵尸进程不能关闭它自己，这时这个进程状态就为z（zombie）。不能使用kill命令杀死僵尸进程，因为它已经标志为“dead”。如果你无法摆脱一个僵尸进程，你可以杀死它的父进程，这个僵尸进程也就消失了。然而，如果父进程是init进程，你不能杀死init进程，因为init是一个重要的系统进程，这种情况下你只能通过一次重新启动服务器来摆脱僵尸进程。也必须分析应用为什么会导致僵死？

三、iostat

iostat是sysstat包的一部分。Iostat显示自系统启动后的平均CPU时间（与uptime类似），它也可以显示磁盘子系统的使用情况，iostat可以用来监测CPU利用率和磁盘利用率。

CPU利用率分四个部分：

引用

%user：user level（应用）的CPU占用率情况

%nice：加入nice优先级的user level的CPU占用率情况

%sys：system level（内核）的CPU占用情况

%idle：空闲的CPU资源情况

磁盘占用率有下面几个部分：

引用

Device：块设备名

Tps：设备每秒进行传输的数量（每秒的I/O请求）。多个单独的I/O请求可以被组成一个传输操作，因为一个传输操作可以是不同的容量。

Blk_read/s, Blk_wrtn/s：该设备每秒读写的块的数量。块可能为不同的容量。

Blk_read, Blk_wrtn：自系统启动以来读写的块设备的总量。

DirectAdmin是一款付费的虚拟主机管理软件，通常简称为DA，DA比Cpanel功能上简单，但是内存占用也更少些，更重要的是价格也更便宜，一般自己用或者搞合租DA算是很合适的。

安装前首先确保已经购买了DirectAdmin的授权，购买授权后会有Client ID，License ID，也需要在DA官网上或者DA销售商那里提交你的VPS或者服务器的IP和系统信息。

1、安装CentOS的相关组件的命令如下：

yum update -y yum install gcc-c++ gcc make automake wget flex -y

2、安装DirectAdmin需要干净的系统，所以在装之前要卸载掉httpd、php、mysql。

yum remove httpd* php* mysql* -y

3、下载DirectAdmin安装脚本文件，执行命令：

wget http://directadmin.com/setup.sh

4、为DirectAdmin安装脚本文件添加执行权限，执行命令：

chmod +x setup.sh

5、执行DirectAdmin安装脚本文件：

./setup.sh

运行DirectAdmin安装文件，然后在下面填入相关的信息。其中hostname最好最好使用如：linode.vpser.net 之类的二级域名不要使用顶级域名。

DirectAdmin’s setup has a few more things you need to fill: Please enter your Client ID :                   //输入你的Client ID Please enter your License ID :                    //输入你的License ID Please enter your hostname (server.domain.com)                         //输入一个主机名，如：linode.vpser.net It must be a Fully Qualified Domain Name Do *not* use a domain you plan on using for the hostname: eg. don’t use domain.com. Use server.domain.com instead. Do not enter http:// or www Enter your hostname (FQDN) : Is this correct? (y,n) :                          //提示上面是否正确，正确请输入y Is eth0 your network adaptor with the license IP? (y,n) :             //输入y Is xx.xx.xx.xx the IP in your license? (y,n) :                           //确认IP是否是License上注册的IP DirectAdmin will now be installed on: Enterprise 5 Is this correct? (must match license) (y,n) :               //输入y You now have 2 options for your apache/php setup. 1: customapache: older, more tested. Includes Apache 1.3, php 4 and frontpage. 2: custombuild 1.1: newer, less tested. Includes any Apache version, php 4, 5, or both in cli and/or suphp. Frontpage not available with Apache 2.x. Post any issues with custombuild to the forum: http://www.directadmin.com/forum/forumdisplay.php?f=61 Enter your choice (1 or 2):        //一般选择2就行，使用php5

最近有个月经问题，老有人问为何开机后，还没有其他服务，mem就被用完了？是不是内存泄露？是否要重启服务？只能说不要看现象，要看本质才能找到问题的根源。 往往给出这样的结果，怀疑内存用了90%： Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

这样怀疑很普遍，因为很多人用惯了Windows。Windows下，可以使用任务管理器查看当前进程对于内存的消耗情况。在我看来，Windows物理内存总是留下一定的空间，就算此时物理内存有空闲时，也会让某些程序去使用虚拟内存，目的是在Windows下启动新程序时，直接分配空闲的物理内存，这样子新程序启动速度就较快，而Linux则不然。

而在Linux下，使用top命令看到内存占用情况：

Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

这里的结果显示使用了3.8G的used，占用率达到90%。看看free的结果你还可以对比一下： $ free -m total used free shared buffers cached Mem: 4049 3784 265 0 208 2939 -/+ buffers/cache: 636 3413 Swap: 2588 0 2588

虽然MEM显示了3.7G左右的used，但是（-/+ buffers/cache）减去buffers和cache的结果可以看到，当前进程实际占用内存是636M，而可用空闲（free）内存为3.4G。

可以这么理解：在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快。

如上面的例子：使用了4G的内存，3.7G被占用，但是buuffer和cached部分作为缓存，可以使用命中率的方式提高使用效率，而且这部分缓存是根据指令随时可以释放的，我们可以认为这部分内存没有实际被使用，也可以认为它是空闲的。

因此查看目前进程正在实际被使用的内存，是used-(buffers+cache)，也可以认为如果swap没有大量使用，mem还是够用的，只有mem被当前进程实际占用完（没有了buffers和cache），才会使用到swap的。

今天在查看 VPS侦探 的 VPS 的SSH登录记录吓了一跳，居然与几个IP连续登录SSH字典猜root密码，我很生气，后果很严重，GFW掉他们，现公布他们的名单：

62.75.214.93  gera125.server4you.de  德国/德国鬼子

203.215.252.189  香港特别行政区/无语。。。。

219.143.200.169  北京市电信 /在党中央还做坏事。。。。

60.12.193.134  浙江省湖州市网通  /

c953dc2c.virtua.com.br  201.83.220.44 巴西 /就你最多。。。。

其中几个还搭建了Nginx的环境，都没做站。

/etc/hosts.allow和/etc/hosts.deny两个文件是控制远程访问设置的，通过他可以允许或者拒绝某个ip或者ip段的客户访问linux的某项服务。

如果请求访问的主机名或IP不包含在/etc/hosts.allow中，那么tcpd进程就检查/etc/hosts.deny。看请求访问的主机名或IP有没有包含在hosts.deny文件中。如果包含，那么访问就被拒绝；如果既不包含在/etc/hosts.allow中，又不包含在/etc/hosts.deny中，那么此访问也被允许。

:[:::…]

daemon list     服务进程名列表，如telnet的服务进程名为in.telnetd client list     访问控制的客户端列表，可以写域名、主机名或网段，如.trubolinux.com.cn或者192.168.1. option          可选选项，这里可以是某些命令，也可以是指定的日志文件

例子：hosts.allow in.telnetd:.vpser.net vsftpd:192.168.0. sshd:192.168.0.0/255.255.255.0

/etc/hosts.allow里第一行vpser.net表示，只有vpser.net这个域里的主机允许访问TELNET服务，注意vpser.net前面的那个点(.)。 /etc/hosts.allow里第二行表示，只有192.168.0这个网段的用户允许访问FTP服务，注意0后面的点(.)。 /etc/hosts.allow里第三行表示，只有192.168.0这个网段的用户允许访问SSH服务，注意这里不能写为192.168.0.0/24。虽然在CISCO路由器种这两中写法是等同的。

在/etc/hosts.deny里加上：

sshd:62.75.214.93 sshd:203.215.252.189 sshd:219.143.200.169 sshd:60.12.193.134 sshd:201.83.220.44 sshd:c953dc2c.virtua.com.br sshd:gera125.server4you.de

把他们访问SSH的全部给拒绝了，Linux的GFW也很强。

本文系： VPS侦探 原创文章，转载请注明出处。

国内转移域名不仅手续繁琐而且需要额外支出，跟国外域名商之间转移域名的快捷方便一比较，你就会觉得国内域名商的落后、不思进取。

刚将一个域名从Godaddy转出到name.com，花费的时间仅为一个小时。我对国内域名商的落后与不思进取的感受更深了。

以下是转移的过程

1. 首先，登录并进入Godaddy的域名管理器（Domain Manager）。
2. 点击你要转移的域名所对应的后面的小锁。 在接下来的页面中去掉“Lock Domain”前的小勾，然后点击“OK”。这时域名将去除锁定。
3. 接下来，是“讨Auth Code” 点选“(Send by Email)”，几分钟后，你就能收到Godaddy发给你一封带Auth Code的邮件。（是的，就几分钟的事）
4. 再来，登录name.com，并进入Transfer Domain Names（在页脚，你可以看到这个链接）。进去后，填入域名和“Auth Code”并确定。如无意外，点击“Checkout”进行付费（com转移是7.99刀，包括一年的续费，也就是说转移是不收费的，都用来续费了。）。付费后，name.com会发给你一封确定转移域名的邮件，点击当中的确定链接，确定转移。
5. 再接下来，就是等候Godaddy的回信了。我等了大概20分钟吧，Godaddy就发信过来说，“他们知道你要进行域名的转移，如果你确信要转移，请到域名管理器中确定转移域名这样”。 再次登录Godaddy的域名管理器，并进入“Pending Tranfers”（鼠标移动到下图中的“Domain”上，可以看到这个选项）当中。 勾选域名，点击上面的“Accept/Decline”，下面选择Accept确定转移即可。
6. 大概二十分钟左右，Godaddy将再次发邮件告诉你转移完成。登录name.com后，就可以看到转移的域名已经在这里出现了。（你可以看到该域名后面的“Private Whois”为“No”，点击激活免费匿名Whois吧。）

我是第一次进行域名的转移，但转移的流程方便快捷，还是能在一个小时左右完成转移的工作。回想到我在E动网中提出要转移域名，他们告诉我，“要快递申请表、身份证复印件……”，我就感觉恶心。 

为什么要从Godaddy转到name.com？ 首先，第二年Godaddy续费域名的价格是10.69刀，来个优惠码可能减到8刀吧（这个是我估计的，大概也是这个价左右吧），而name.com的是8.99刀，价格是差不多的； 第二，name.com的域名都有送匿名whois，这个Godaddy买的话要20多刀？ 第三，godaddy的界面乱，name.com的界面简洁、操作更方便。

综上，于是我转移到name.com

来源:

文件权限除了r、w、x外还有s、t、i、a权限：

s：文件属主和组设置SUID和GUID，文件在被设置了s权限后将以root身份执行。在设置s权限时文件属主、属组必须先设置相应的x权 限，否则s权限并不能正真生效（c h m o d命令不进行必要的完整性检查，即使不设置x权限就设置s权限，chmod也不会报错，当我们ls -l时看到rwS，大写S说明s权限未生效）。Linux修改密码的passwd便是个设置了SUID的程序，普通用户无读写/etc/shadow文件 的权限确可以修改自己的密码。

ls -al /usr/bin/passwd

-rwsr-xr-x 1 root root 32988 2008-12-08 17:17 /usr/bin/passwd

我们可以通过字符模式设置s权限：

chmod a+s filename

也可以使用绝对模式进行设置：

设置s u i d：将相应的权限位之前的那一位设置为4；

设置g u i d：将相应的权限位之前的那一位设置为2；

两者都置位：将相应的权限位之前的那一位设置为4+2=6。

如：chmod 4764 filename   //设置SUID

t ：设置粘着位，一个文件可读写的用户并一定相让他有删除此文件的权限，如果文件设置了t权限则只用属主和root有删除文件的权限，通过chmod +t filename 来设置t权限。

i：不可修改权限   例：chattr u+i filename 则filename文件就不可修改，无论任何人，如果需要修改需要先删除i权限，用chattr -i filename就可以了。查看文件是否设置了i权限用lsattr filename。

a：只追加权限， 对于日志系统很好用，这个权限让目标文件只能追加，不能删除，而且不能通过编辑器追加。可以使用chattr +a设置追加权限。

linux 中某一文件夹的用户是A,想更改成B用户!如何用usermod实现?

su到root

chown B yourdir

chgrp B yourdir

group文件里：

zzg:x:550:litong,liuhong

这都代表什么意思？那个数字代表什么意思？

在passwd里：

liuhong:x:544:550::/usr/local/resin/webapps:/bin/bash

B树

即二叉搜索树：

1.所有非叶子结点至多拥有两个儿子（Left和Right）；

2.所有结点存储一个关键字；

3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；

如：

B树的搜索，从根结点开始，如果查询的关键字与结点的关键字相等，那么就命中；否则，如果查询关键字比结点关键字小，就进入左儿子；如果比结点关键 字大，就进入右儿子；如果左儿子或右儿子的指针为空，则报告找不到相应的关键字；

如果B树的所有非叶子结点的左右子树的结点数目均保持差不多（平衡），那么B树的搜索性能逼近二分查找；但它比连续内存空间的二分查找的优点是，改变B树 结构（插入与删除结点）不需要移动大段的内存数据，甚至通常是常数开销；

如：

但B树在经过多次插入与删除后，有可能导致不同的结构

右边也是一个B树，但它的搜索性能已经是线性的了；同样的关键字集合有可能导致不同的树结构索引；所以，使用B树还要考虑尽可能让B树保持左图的结 构，和避免右图的结构，也就是所谓的“平衡”问题；

实际使用的B树都是在原B树的基础上加上平衡算法，即“平衡二叉树”；如何保持B树结点分布均匀的平衡算法是平衡二叉树的关键；平衡算法是一种在B树中插 入和删除结点的策略；

B-树

是一种多路搜索树（并不是二叉的）：

1.定义任意非叶子结点最多只有M个儿子；且M>2；

2.根结点的儿子数为[2, M]；

3.除根结点以外的非叶子结点的儿子数为[M/2, M]；

4.每个结点存放至少M/2-1（取上整）和至多M-1个关键字；（至少2个关键字）

5.非叶子结点的关键字个数=指向儿子的指针个数-1；

6.非叶子结点的关键字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；

7.非叶子结点的指针：P[1], P[2], …, P[M]；其中P[1]指向关键字小于K[1]的子树，P[M]指向关键字大于K[M-1]的子树，其它P[i]指向关键字属于(K[i-1], K[i])的子树；

8.所有叶子结点位于同一层；

如：（M=3）

B-树的搜索，从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果命中则结束，否则进入查询关键字所属范围的儿子结点；重复，直到所对应的儿 子指针为空，或已经是叶子结点；

B-树的特性：

1.关键字集合分布在整颗树中；

2.任何一个关键字出现且只出现在一个结点中；

3.搜索有可能在非叶子结点结束；

4.其搜索性能等价于在关键字全集内做一次二分查找；

5.自动层次控制；

由于限制了除根结点以外的非叶子结点，至少含有M/2个儿子，确保了结点的至少利用率，其最底搜索性能为：

其中，M为设定的非叶子结点最多子树个数，N为关键字总数；

所以B-树的性能总是等价于二分查找（与M值无关），也就没有B树平衡的问题；

由于M/2的限制，在插入结点时，如果结点已满，需要将结点分裂为两个各占M/2的结点；删除结点时，需将两个不足M/2的兄弟结点合并；

B+树

B+树是B-树的变体，也是一种多路搜索树：

1.其定义基本与B-树同，除了：

2.非叶子结点的子树指针与关键字个数相同；

3.非叶子结点的子树指针P[i]，指向关键字值属于[K[i], K[i+1])的子树（B-树是开区间）；

5.为所有叶子结点增加一个链指针；

6.所有关键字都在叶子结点出现；

如：（M=3）

B+的搜索与B-树也基本相同，区别是B+树只有达到叶子结点才命中（B-树可以在非叶子结点命中），其性能也等价于在关键字全集做一次二分查找；

B+的特性：

1.所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；

2.不可能在非叶子结点命中；

3.非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；

4.更适合文件索引系统；

最近因为项目原因，研究了Cassandra,Hbase等几个NoSQL数据库，最终决定采用HBase。在这里，我就向大家分享一下自己对HBase的理解。

在说HBase之前，我想再唠叨几句。做互联网应用的哥们儿应该都清楚，互联网应用这东西，你没办法预测你的系统什么时候会被多少人访问，你面临的用户到 底有多少，说不定今天你的用户还少，明天系统用户就变多了，结果您的系统应付不过来了了，不干了，这岂不是咱哥几个的悲哀，说时髦点就叫“杯具啊”。

其实说白了，这些就是事先没有认清楚互联网应用什么才是最重要的。从系统架构的角度来说，互联网应用更加看重系统性能以及伸缩性，而传统企业级应用都是比较看重数据完整性和数据安全性。那么我们就来说说互联网应用伸缩性这事儿.对于伸缩性这事儿，哥们儿我也写了几篇博文，想看的兄弟可以参考我以前的博文，对于web server,app server的伸缩性，我在这里先不说了，因为这部分的伸缩性相对来说比较容易一点，我主要来回顾一些一个慢慢变大的互联网应用如何应对数据库这一层的伸缩。

首先刚开始，人不多，压力也不大,搞一台数据库服务器就搞定了，此时所有的东东都塞进一个Server里，包括web server,app server,db server,但是随着人越来越多，系统压力越来越多，这个时候可能你把web server,app server和db server分离了，好歹这样可以应付一阵子，但是随着用户量的不断增加，你会发现，数据库这哥们不行了，速度老慢了，有时候还会宕掉，所以这个时候，你 得给数据库这哥们找几个伴，这个时候Master-Salve就出现了，这个时候有一个Master Server专门负责接收写操作，另外的几个Salve Server专门进行读取，这样Master这哥们终于不抱怨了，总算读写分离了，压力总算轻点了,这个时候其实主要是对读取操作进行了水平扩张，通过增 加多个Salve来克服查询时CPU瓶颈。一般这样下来，你的系统可以应付一定的压力，但是随着用户数量的增多，压力的不断增加，你会发现Master server这哥们的写压力还是变的太大，没办法，这个时候怎么办呢？你就得切分啊，俗话说“只有切分了，才会有伸缩性嘛”， 所以啊，这个时候只能分库了，这也是我们常说的数据库“垂直切分”，比如将一些不关联的数据存放到不同的库中，分开部署，这样终于可以带走一部分的读取和 写入压力了，Master又可以轻松一点了，但是随着数据的不断增多，你的数据库表中的数据又变的非常的大，这样查询效率非常低，这个时候就需要进行“水 平分区”了，比如通过将User表中的数据按照10W来划分，这样每张表不会超过10W了。

综上所述，一般一个流行的web站点都会经历一个从单台DB，到主从复制，到垂直分区再到水平分区的痛苦的过程。其实数据库切分这事儿，看起来原理貌似很 简单，如果真正做起来，我想凡是sharding过数据库的哥们儿都深受其苦啊。对于数据库伸缩的文章，哥们儿可以看看后面的参考资料介绍。

好了，从上面的那一堆废话中，我们也发现数据库存储水平扩张scale out是多么痛苦的一件事情，不过幸好技术在进步，业界的其它弟兄也在努力，09年这一年出现了非常多的NoSQL数据库，更准确的应该说是No relation数据库，这些数据库多数都会对非结构化的数据提供透明的水平扩张能力，大大减轻了哥们儿设计时候的压力。下面我就拿Hbase这分布式列存储系统来说说。

一 Hbase是个啥东东？ 在说Hase是个啥家伙之前，首先我们来看看两个概念，面向行存储和面向列存储。面向行存储，我相信大伙儿应该都清楚，我们熟悉的RDBMS就是此种类型的，面向行存储的数据库主要适合于事务性要求严格场合，或者说面向行存储的存储系统适合OLTP，但是根据CAP理论，传统的RDBMS，为了实现强一致性，通过严格的ACID事务来进行同步，这就造成了系统的可用性和伸缩性方面大大折扣，而目前的很多NoSQL产 品，包括Hbase，它们都是一种最终一致性的系统，它们为了高的可用性牺牲了一部分的一致性。好像，我上面说了面向列存储，那么到底什么是面向列存储 呢？Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。看到这里，如果您不明白Hbase是个啥东东，不要紧，我再总结 一下下：

Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。

二 Hbase数据模型 HBase,Cassandra的数据模型非常类似，他们的思想都是来源于Google的Bigtable，因此这三者的数据模型非常类似，唯一不同的就 是Cassandra具有Super cloumn family的概念，而Hbase目前我没发现。好了，废话少说，我们来看看Hbase的数据模型到底是个啥东东。

在Hbase里面有以下两个主要的概念，Row key,Column Family，我们首先来看看Column family,Column family中文又名“列族”，Column family是在系统启动之前预先定义好的，每一个Column Family都可以根据“限定符”有多个column.下面我们来举个例子就会非常的清晰了。

假如系统中有一个User表，如果按照传统的RDBMS的话，User表中的列是固定的，比如schema 定义了name,age,sex等属性，User的属性是不能动态增加的。但是如果采用列存储系统，比如Hbase，那么我们可以定义User表，然后定 义info 列族，User的数据可以分为：info:name = zhangsan,info:age=30,info:sex=male等，如果后来你又想增加另外的属性，这样很方便只需要 info:newProperty就可以了。

也许前面的这个例子还不够清晰，我们再举个例子来解释一下，熟悉SNS的朋友，应该都知道有好友Feed，一般设计Feed，我们都是按照“某人在某时做 了标题为某某的事情”，但是同时一般我们也会预留一下关键字，比如有时候feed也许需要url，feed需要image属性等，这样来说，feed本身 的属性是不确定的，因此如果采用传统的关系数据库将非常麻烦，况且关系数据库会造成一些为null的单元浪费，而列存储就不会出现这个问题，在Hbase 里，如果每一个column 单元没有值，那么是占用空间的。下面我们通过两张图来形象的表示这种关系：

上图是传统的RDBMS设计的Feed表，我们可以看出feed有多少列是固定的，不能增加，并且为null的列浪费了空间。但是我们再看看下图，下图为 Hbase，Cassandra,Bigtable的数据模型图，从下图可以看出，Feed表的列可以动态的增加，并且为空的列是不存储的，这就大大节约 了空间，关键是Feed这东西随着系统的运行，各种各样的Feed会出现，我们事先没办法预测有多少种Feed，那么我们也就没有办法确定Feed表有多 少列，因此Hbase,Cassandra,Bigtable的基于列存储的数据模型就非常适合此场景。说到这里，采用Hbase的这种方式，还有一个非 常重要的好处就是Feed会自动切分，当Feed表中的数据超过某一个阀值以后，Hbase会自动为我们切分数据，这样的话，查询就具有了伸缩性，而再加上Hbase的弱事务性的特性，对Hbase的写入操作也将变得非常快。

上面说了Column family，那么我之前说的Row key是啥东东，其实你可以理解row key为RDBMS中的某一个行的主键，但是因为Hbase不支持条件查询以及Order by等查询，因此Row key的设计就要根据你系统的查询需求来设计了额。我还拿刚才那个Feed的列子来说，我们一般是查询某个人最新的一些Feed，因此我们Feed的 Row key可以有以下三个部分构成，这样以来当我们要查询某个 人的最进的Feed就可以指定Start Rowkey为<0><0>，End Rowkey为来查询了，同时 因为Hbase中的记录是按照rowkey来排序的，这样就使得查询变得非常快。

原文地址：http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved

HBase vs Cassandra: why we moved

下文中将讨论为何选择Cassandra作为我们的NOSQL方案。

是否Cassandra的血统预言了未来？****

我发现在软件问题上，我们先去考虑上层问题而不是直接深入到细节，可以节约大量时间。在选择HBase还是Cassandra上我也遵循了这一信条。HBase还是Cassandra具有完全不同的血统和基因，这决定了他们在我们应用的可行性。

HBase及其支持系统源自Google的GFS和BigTable设计；而最初由Facebook开源出来的Cassandra采用了BigTable的数据模型，确实是用类似Amozon的Dynamo的存储系统（实际上Cassandra最初的开发工作都是由两个原Dynamo工程师开发的）。

在我看来，他们的根源决定了HBase更适用于数据仓库和大规模数据处理分析（比如对Web建索引），而Cassandra更适用于实时事务处理和处理交互性数据。（HBase的committers被MS Bing收购，Cassandra的committers则为Rackspace工作，后者旨在提供Google，Yahoo和Amazon之外的通用NOSQL方案）

哪个NOSQL数据库势头更好？****

另一个考虑因素是因为Cassandra在社区中目前具有极好的发展势头。软件平台往往是越大就容易更大，人们都喜欢使用有更好支持的系统。

当开始关注HBase，我的感觉是它的背后有很好的社区支持（主要因为StumpleUpon and Streamy的CTO的报告和“HBase vs Cassandra: NoSQL Battle!”），但是我现在相信Cassandra将会比它更加强大。

为了证明这一点，可以参考IRC上开发者的活动：当连接到freenode.org

比较#hbase和#cassandra的开发者频道，你会发现Cassandra的开发者是前者的两倍。

并且，Twitter也打算大规模使用Cassandra。

CAP**：**CA vs AP

根据Eric Brewer教授的CAP理论，在大型分布式系统设计中，C（一致性）A（可用性）P（网络分区容忍性，即让集群被分成多个孤立的分区时系统仍然可用）不能同时满足。普遍认为HBase选择了CP而Cassandra选择了AP。

但是我必须提醒一下这种管理是基于一个不合逻辑的推论。虽然CAP不能同时满足，但是在一个系统中却可以让每个操作去指定它也选择哪两个放弃哪一个，或者对于CAP分别有什么程度的关注、在中间获得一个自己需要的平衡。这就是Cassandra所做的。

我要反复重申Cassandra的这一优点：你可以为每一个操作去选择trade-off。例如，当需要读操作具有高一致性时，就使用“ALL”这个一致性级别（译者注：实际上，因为临时故障的存在，写时可能写到了Hint点，即使使用ALL也不一定能读到期望的）；当我对一致性没有高要求而要求性能，就使用“ONE”这个一致性结果。并且，你还可以选择介于这两者之间的一致性级别，比如“QUORUM”（表决，即多数）。

并且，当一些节点失效时，或者网络抖动时，使用Cassandra仍然能保证除部分要求极高一致性的请求失败外，大部分操作可用。HBase则做不到这样的灵活性。

什么时候monolithic优于****modular

一个重要的差别是每个Cassandra节点是单个Java进程；而完整的HBase方案则由多个部分组成：运行在多个模式的数据库进程，Hadoop HDFS和ZooKeeper系统。

对于小公司来说，HBase的方案的配置过于复杂。如果是个数据库管理员想学习NOSQL系统，HBase则是个不错的选择。

Gossip!

Cassandra是完全的对称系统，系统中没有像HBase那样有管理节点存在，系统中的所有节点承担完全相同的作用。系统中协调的作用完全有集群中节点相互按照纯粹P2P协议Gossip来完成。Cassandra依靠这种协议来检测节点故障,或者路由请求到合适节点处理,所花费的时间相当小。

这种基于Gossip的架构给用户带来如下好处：首先，系统的管理极其简单。例如要添加一个新节点，该节点会自己和seed节点通信完成引导（bootstrapping）过程，做好数据和路由信息的准备。并且，这种P2P架构带来了好的性能和可用性。负载可以很好的在系统内均衡，对于网络出现分区故障或者节点故障可以无缝的解决，这种完全对称性也避免了HBase再加入/移除节点时会出现的那种临时性能不稳定。

第三方报告****

Yahoo对NOSQL系统进行了较为详细的比较，研究结果表明Cassandra更有优势。HBase仅在Range scan上比较有优势。但是我认为实际上应该在Cassandra的基础上再实现你自己的索引，而不是直接用Range scan。如果你对Cassandra的区间查询和存储索引感兴趣，参考我另一篇http://ria101.wordpress.com/2010/02/22/cassandra-randompartitioner-vs-orderpreservingpartitioner/。

下面是相关的报告：

http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king

锁和模块性****

你可能听HBase阵营说过他们的复杂架构可以提供Cassandra的P2P架构所不能提供的好处，比如行锁。但是我要说的是模块性。Cassandra实现了BigTable的数据模型但使用了所有点对称的分布式模型。这是很灵活很高效的一个模型。如果你需要锁、事务或者其他功能，你可以通过添加自己的模块来实现——比如我们就在Cassandra中配合使用Zookeeper来实现scalable locking。

需要锁，自己用Zookeeper；需要索引，自己用Lucandra…Cassandra没有强加可能用不到的复杂性，而是提供了灵活性让你可以自己添加自己需要的模块来完成功能。

MapReduce

Cassandra的一个突出弱点是在于MapReduce。而HBase因为使用的是Hadoop HDFS存储数据，天生就为MapReduce这种分析处理设计。如果你需要这种数据分析，HBase目前确实是最好的选择。

虽然我在这里大肆吹捧Cassandra，我必须指出HBase和Cassandra并不是切地的竞争者，实质上他们又更适合的场景。据我所知，StumbleUpon使用HBase极其Hadoop MapReduce来处理庞大的post。我们的系统更多的是交互应用，因此我们选择Cassandra。

Cassandra从0.6开始支持hadoop，相信其MapReduce支持会越来越好。

丢数据？****

通过CAP的争论，容易产生这样的印象：HBase比Cassandra更安全。实际上在Cassandra中，当你写入新数据他会立即写到commit log并复制到其他节点，这使得及时你的集群系统断电，也只是损失小量数据。并且，Cassandra还利用Merkle树来发现副本间数据不一致问题，进一步提升数据安全

php5-windows默认已经包含了sqlite模块，但没有启用

如果需要支持sqlite，则修改php.ini

启用三个扩展语句

extension=php_pdo.dll

extension=php_pdo_sqlite.dll

extension=php_sqlite.dll （可能不是必须的，但最好一起啦）

我第一次只开了下面两个，因此始终无法启用，测试程序会报错

Fatal error: Call to undefined function sqlite_open()

也就是sqlite没有成功启动

周六的S2 Web 2.0技术沙龙上介绍了memcache中使用mutex场景(文后要演讲稿)，有网友对详情感兴趣，简单介绍如下。

场景

Mutex主要用于有大量并发访问并存在cache过期的场合，如

• 首页top 10, 由数据库加载到memcache缓存n分钟
• 微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
• 需要执行多个IO操作生成的数据存在cache中, 比如查询db多次

问题

在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。

解决方法

方法一 在load db之前先add一个mutex key, mutex key add成功之后再去做加载db, 如果add失败则sleep之后重试读取原cache数据。为了防止死锁，mutex key也需要设置过期时间。伪代码如下 (注：下文伪代码仅供了解思路，可能存在bug，欢迎随时指出。)

if (memcache.get(key) == null) {
    // 3 min timeout to avoid mutex holder crash
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
}

方法二 在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下

v = memcache.get(key);
if (v == null) {
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
} else {
    if (v.timeout <= now()) {
        if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
            // extend the timeout for other threads
            v.timeout += 3 * 60 * 1000;
            memcache.set(key, v, KEY_TIMEOUT * 2);

            // load the latest value from db
            v = db.get(key);
            v.timeout = KEY_TIMEOUT;
            memcache.set(key, value, KEY_TIMEOUT * 2);
            memcache.delete(key_mutex);
        } else {
            sleep(50);
            retry();
        }
    }
}

相对于方案一 优点：避免cache失效时刻大量请求获取不到mutex并进行sleep 缺点：代码复杂性增大，因此一般场合用方案一也已经足够。

最近看到的另外一个介绍Twitter技术的视频[Slides] [Video (GFWed)]，这是Twitter的John Adams在Velocity 2009的一个演讲，主要介绍了Twitter在系统运维方面一些经验。 本文大部分整理的观点都在Twitter(@xmpp)上发过，这里全部整理出来并补充完整。

Twitter没有自己的硬件，都是由NTTA来提供，同时NTTA负责硬件相关的网络、带宽、负载均衡等业务，Twitter operations team只关注核心的业务，包括Performance，Availability，Capacity Planning容量规划，配置管理等，这个可能跟国内一般的互联网公司有所区别。

1. 运维经验

* Metrics

Twitter的监控后台几乎都是图表(critical metrics)，类似驾驶室的转速表，时速表，让操作者可以迅速的了解系统当前的运作状态。联想到我们做的类似监控后台，数据很多，但往往还需要浏览者做二次分析判断，像这样满屏都是图表的方法做得还不够，可以学习下这方面经验。 据John介绍可以从图表上看到系统的瓶颈-系统最弱的环节(web, mq, cache, db?)

根据图表可以科学的制定系统容量规划，而不是事后救火。

* 配置管理

每个系统都需要一个自动配置管理系统，越早越好，这条一整理发到Twitter上去之后引起很多回应。

* Darkmode

配置界面可以enable/disable 高计算消耗或高I/O的功能，也相当于优雅降级，系统压力过大时取消一些非核心但消耗资源大的功能。

* 进程管理

Twitter做了一个”Seppaku” patch, 就是将Daemon在完成了n个requests之后主动kill掉，以保持健康的low memory状态，这种做法据了解国内也有不少公司是这样做。

* 硬件

Twitter将CPU由AMD换成Xeon之后，获得30%性能提升，将CPU由双核/4核换成8核之后，减少了40%的CPU, 不过John也说，这种升级不适合自己购买硬件的公司。

2. 代码协同经验

* Review制度

Twitter有上百个模块，如果没有一个好的制度，容易引起代码修改冲突，并把问题带给最终用户。所以Twitter有一强制的source code review制度, 如果提交的代码的svn comment没有”reviewed by xxx”, 则pre-commit脚本会让提交失败, review过的代码提交后会通过自动配置管理系统应用到上百台服务器上。 有@xiaomics同学在Twitter上马上就问，时间成本能否接受？如果有紧急功能怎么办？个人认为紧急修改时有两人在场，一人修改一人review也不是什么难事。

* 部署管理

从部署图表可以看到每个发布版本的CPU及latency变化，如果某个新版本latency图表有明显的向上跳跃，则说明该发布版本存在问题。另外在监控首页列出各个模块最后deploy版本的时间，可以清楚的看到代码库的现状。

* 团队沟通

Campfire来协同工作，campfire有点像群，但是更适合协同工作。对于Campfire就不做更多介绍，可参考Campfire官方说明。

3. cache

• Memcache key hash, 使用FNV hash 代替 MD5 hash，因为FNV更快。
• 开发了Cache Money plugin(Ruby), 给应用程序提供read-through, write-through cache, 就像一个db访问的钩子，当读写数据库的时候会自动更新cache, 避免了繁琐的cache更新代码。
• “Evictions make the cache unreliable for important configuration data”，Twitter使用memcache的一条经验是，不同类型的数据需放在不同的mc,避免eviction，跟作者前文Memcached数据被踢(evictions>0)现象分析中的一些经验一致。
• Memcached SEGVs, Memcached崩溃(cold cache problem)据称会给这种高度依赖Cache的Web 2.0系统带来灾难，不知道Twitter具体怎么解决。
• 在Web层Twitter使用了Varnish作为反向代理，并对其评价较高。

使用JS实现单击连接保存图片
2种形式都可以

第一种：

<script>
function   SaveAs5(imgURL)
...{
  var   oPop   =   window.open(imgURL,"","width=1,   height=1,   top=5000,   left=5000");
  for(;   oPop.document.readyState   !=   "complete";   )
  ...{
    if   (oPop.document.readyState   ==   "complete")break;
  }
  oPop.document.execCommand("SaveAs");
  oPop.close();
}
</script>

<img   src="t_screenshot_17616.jpg"   id="DemoImg"   border="0"   onclick="SaveAs5(this.src)">

第二种：

<script>
function   SaveAs5(imgURL)
...{
  var   oPop   =   window.open(imgURL,"","width=1,   height=1,   top=5000,   left=5000");
  for(;   oPop.document.readyState   !=   "complete";   )
  ...{
    if   (oPop.document.readyState   ==   "complete")break;
  }
  oPop.document.execCommand("SaveAs");
  oPop.close();
}
</script>

<img   src="../t_screenshot_17616.jpg"   id="DemoImg"   border="0">
<a   href="#"     onclick="SaveAs5(document.getElementById('DemoImg').src)"> 点击这里下载图片 </a>

 New Document

function downLoadImage(imagePathURL){

//如果中间IFRAME不存在，则添加 if(!document.getElementById(“_SAVEASIMAGE_TEMP_FRAME”)) jQuery(‘ width=”0″ height=”0″ src=”about:blank”>’).appendTo(“body”);

if(document.all._SAVEASIMAGE_TEMP_FRAME.src!=imagePathURL){ //图片地址发生变化，加载图片 document.all._SAVEASIMAGE_TEMP_FRAME.src = imagePathURL; }else{ //图片地址没有变化，直接另存为 _doSaveAsImage(); } } function _doSaveAsImage(){ if(document.all._SAVEASIMAGE_TEMP_FRAME.src!=”about:blank”) document.frames(“_SAVEASIMAGE_TEMP_FRAME”).document.execCommand(“SaveAs”); }

//–>