作为No-sql的强项，MongoDB的数据分发/同步机制相对比MySQL灵活的多，支持传统上的主从同步和趋向于高性能的ShareSet，而且对于程序端来说改动相对较小，代价几乎可以不计。现在就从这两种分发机制方式说起。

Master-slaver机制

不同于MySQL的主从同步，MongoDB的主备同步有3种角色，primary（相当于Master）, secondary（相当于Slave），Arbite（选举机）。正常情况下primary与secondary的配置要相当，因为很有可能主备切换，Arbite则没有被升格的可能（只有选举权，没有被选举权），正常情况下只是相当于一个心跳监控机而已。一旦p出现故障或者整个拓扑结构发生变化，导致P不能联系上大多数M之后，如果存在多台S需要升格成P的时候就需要A来进行选举。

Master-Slaver的部署

假设3台主机,主机名分别是 P S A,请注意Shell提示符

P# mongod –rest –replSet testSet

P# mongo

>cfg = {member:{host: “P:27017″}}
>  rs.initiate(cfg)

S# mongod –rest –replSet testSet
p#mongo

>rs.add(“S”)

{ “ok” : 1 }

A# mongod –rest –replSet testSet –oplogSize 8

p# mongo

>rs.add( { host:”A”, arbiterOnly:true } )

{ “ok” : 1 }

宣告成功！就这么简单！

如果之前一直按照此步骤的话，你就可以直接通过访问http://P:28017/来查看整个系统的状态。

理论上MongoDB可以支持互为主备，但个人觉得没有意义，反而会出现较多的一致性问题，没有在这里测试。

Sharding机制

不知道你会怎么理解”Sharding”这个单词，我的第一反应是罐头装的沙丁鱼。从拓扑结构上看，真的很像！

沙丁鱼有3种角色，shard，参与存储和运算的节点，要求数量多；config ，控制节点，保存有各个数据的哈希映射，及负载信息,相对来说是整个环节中的关键应用；mongos，路由节点，负责前端分发和数据汇总，相对来说是整个环节中的中央应用。客户端向任意一个Mongos发起请求，mongs首先从config上获取哈希映射，再通过哈希映射获取所有的数据后汇总给客户端。config不断的维系全局的数据分片，又有点类似心跳监视的意思。更加夸张的是，这种沙丁鱼结构支持嵌套，同样也支持嵌套上面的主从结构。

sharding的部署

这次还是3台机器，S1 S2 MS，S1 S2在做shard服务器的同时也兼作config，shard是27018口，config是27019口，都是默认的端口。

s1# mongod –shardsvr –replSet s1

s1# mongo

> cfg = { _id : “s1″, members : [ {_id : 0, host : "S1:27018"}, ] }

> rs.initiate(cfg)

s2# mongod –shardsvr –replSet s2

s2# mongo

> cfg = { _id : “s1″, members : [ {_id : 0, host : "S2:27018"}, ] }
> rs.initiate(cfg)

s1# mongod –configsvr

s2# mongod –configsvr

MS# mongos –configdb s1:27019,s2:27019

MS#mongo

> db.adminCommand( { addShard : “s1/s1:27018″ } )

> db.adminCommand( { addShard : “s2/s2:27018″ } )

恭喜完成了这么复杂的系统!需要注意的是整个系统中尽量使用主机名,通过hosts指向还是通过DNS无所谓，这是因为系统一旦启动就很难修改主机信息，IP地址远没有主机名灵活。

客户端的配置

算了,照贴PHP官档！

正常情况下，像Redis这样定期回写磁盘的内存数据库，丢失几个数据也是在情理之中，可超过80%数据丢失率实在太离谱。排除了误操作的可能性之后，开始寻找原因。

重启动时的日志：

[26641] 21 Dec 09:46:34 * Slave ask for synchronization

[26641] 21 Dec 09:46:34 * Starting BGSAVE for SYNC

[26641] 21 Dec 09:46:34 # Can’t save in background: fork: Cannot allocate memory

[26641] 21 Dec 09:46:34 * Replication failed, can’t BGSAVE

[26641] 21 Dec 09:46:34 # Received SIGTERM, scheduling shutdown…

[26641] 21 Dec 09:46:34 # User requested shutdown…

很明显的一个问题，系统不能在后台保存，fork进程失败。

翻查了几个月的日志，发觉系统在频繁报错：

[26641] 18 Dec 04:02:14 * 1 changes in 900 seconds. Saving…

[26641] 18 Dec 04:02:14 # Can’t save in background: fork: Cannot allocate memory

系统不能在后台保存，fork进程时无法指定内存。

对源码进行跟踪，在src/rdb.c中定位了这个报错：

int rdbSaveBackground(char *filename) {
    pid_t childpid;
    long long start;

    if (server.bgsavechildpid != -1) return REDIS_ERR;
    if (server.vm_enabled) waitEmptyIOJobsQueue();
    server.dirty_before_bgsave = server.dirty;
    start = ustime();
    if ((childpid = fork()) == 0) {
        /* Child */
        if (server.vm_enabled) vmReopenSwapFile();
        if (server.ipfd > 0) close(server.ipfd);
        if (server.sofd > 0) close(server.sofd);
        if (rdbSave(filename) == REDIS_OK) {
            _exit(0);
        } else {
            _exit(1);
        }
    } else {
        /* Parent */
        server.stat_fork_time = ustime()-start;
        if (childpid == -1) {
            redisLog(REDIS_WARNING,"Can't save in background: fork: %s",
                strerror(errno));
            return REDIS_ERR;
        }
        redisLog(REDIS_NOTICE,"Background saving started by pid %d",childpid);
        server.bgsavechildpid = childpid;
        updateDictResizePolicy();
        return REDIS_OK;
    }
    return REDIS_OK; /* unreached */
}

数据丢失的问题总算搞清楚了！

Redis的数据回写机制分同步和异步两种，

1. 同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。
2. 异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。

个人感觉方法２采用fork主进程的方式很拙劣，但似乎是唯一的方法。内存中的热数据随时可能修改，要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像，这样主进程上就不需要冻结，只要子进程上操作就可以了。

在小内存的进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。

找到原因之后，直接修改内核参数vm.overcommit_memory = 1

Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

1.  如果 vm.overcommit_memory = 1，直接放行
2. vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。
3. vm.overcommit_memory = 2：则会比较 进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap，决定是否放行。

首先，准备2套Redis主机，本例192.168.0.1为主，192.168.0.2为从。为了保障不会出现稀奇古怪的毛病，要求2台主机配置文件中

• databases ，dbs数量，决定了select命令的最大数（分块数量）
• maxmemory，最大内存使用，决定了整个系统的容量

两个参数的配置要一致，系统版本尽量保证一致（我测试过不一致的版本也可以同步，但不保证所有的情况下都可以同步）其余的数据不强制要求一致。

用客户端连接slaver主机的redis并操作

redis-cli -h 192.168.0.2

redis 192.168.0.2:6379> slaveof 192.168.0.1 6379
OK

就这么方便！

这时，可以在输入info命令，查看master_host的配置：

redis 192.168.0.2:6379>info
…
master_host:192.168.0.1
…

为保证主机每次启动都保持slave的状态，则可以在redis.conf中增加一行slaveof 192.168.0.1 6379 即可，也非常简单。

作为redis这类nosql来说，并发的压力并不像MySQL那样迫切，何况数据没有关联，一旦出现并发的瓶颈，可以很方便的将数据拆分成多个主机。那对于标准的web应用，主从的意义是什么？

个人理解：

1. 解决Redis内存回写磁盘一瞬间的阻塞问题。
   Redis 是内存数据库，数据都在内存中，仅在改变时才会回写。但在磁盘回写的时候，由于需要拷贝内存镜像，整个处于阻塞状态，服务器不会做任何相应，在数据少的情况下阻塞时间也很少，可以忽略。但数据达到G这个级别之后的阻塞绝对是致命的。而且这个阻塞由Redis特性决定，无法彻底解决。
   通过主从这种方式对任务进行分工，主机负责写入，通过配置文件中的save选项，减少回写甚至直接取消数据回写，将数据持久化的任务交由slaver主机进行。一旦宕机，由slaver主机上的数据恢复出master。
2. 数据热迁移。
   这个很好理解了，数据迁移示意图

共享表空间方式

由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。

但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增加”，仅仅是一个文件的拆分而已，不能从根本上分离数据和索引。

之前曾经遭遇到700G以上的表空间文件，而且更加让人郁闷的是对于如此大的文件还在以每天数G的数量增加。由于无法停机，即便是拷贝一下也要花费差不多一夜，只能眼睁睁看着它继续增大而毫无保守可行的办法。

独立表空间方式

相对而言对立表空间每个表都有独立的多个数据文件，而且做到了索引和数据的分离。多个小文件之间很方便的完成跨数据库甚至跨硬件的数据拷贝和迁移。相对来说灵活性很好。

这样做同样带来另一个方面的问题。当数据库中的表数量达到一定级别时，每次操作所涉及的文件过多，如果按照默认Centos的ulimit -n = 1024的话，仅仅只能保证同时打开256个表以内，这在习惯上“拆库拆表”的MySQL数据结构上很难达到要求。尚且这种数据文件的利用率不算很高，当大量“不高”的文件集中起来，浪费的空间也很惊人，更何况最后可能出现的状况不是“一堆K级别的小文件”而是“一堆G级别的大文件”，有点适得其反的意思。你自然可以联想到分区表，又是一个“仅仅做文件拆分而已”，多个分区文件缺一不可。

之前同样遇到过这个问题，MySQL连接大的状况下大量的timeout，但主机负载还算可以，查了一圈才知道是open files限制的问题，限制一修改，负载变得惊人，但连接数却又提升的不多。

总之，两种方法各有所长，部分互补，但都不是解决问题的终极方案。期待MySQL能够出现真正意义上表空间的概念，更加自由的规划数据文件。

既然仅仅只是当作一个容器，从性能上考虑那为什么要用MySQL呢？

最近在研究一些NoSQL的东西，memcache类这类的纯Key-value；redis这类key-list；以及更加接近于关系型的MongoDB。这类的数据容器相较MySQL这类SQL数据库而言，更多的都是在性能上做大幅提升。从搜索能力上讲，MySQL的搜索能力又远不及Sphinx或者Solr这类单纯的索引服务器。如果说关系型数据库的优势在于一致性。那事物操作本身也不是MySQL所擅长的，“拆库拆表”的设计理念更是打破了一致性的优势。MySQL剩下的优势恐怕只剩下了“便于维护”这一条了吧。

mysql mongodb 写入对比

mysql mongodb 查询对比

mysql mongodb 资源对比

相比MySQL这些年做的改进，几乎都是在完善事物处理这类高级的SQL逻辑。之前人们选择MySQL的原因，其实很少是由于MySQL的事务处理，而是性能方面的优势。当MySQL不再将性能的提升作为首要任务时，加上近一段时间风声水起的SNS热潮，MySQL的王者地位已经逐渐被NoSQL数据库挑战——甚至出现了完全排除MySQL的SNS框架。

据说MySQL5.6中启用了对于Memcache的支持，看来连MySQL自己也顿悟了……

要说最近最热的云计算，不得不提Hadoop。这个项目就是为集群运算而生的。依赖于它的项目n多，个人感觉hadoop已经逐渐成为一个“基于Java的分布式运算中间件”。

这里安装的hadoop为ver 0.21.0版本，包含了HDFS分布式文件系统。平台为老一套的Ubuntu 1104 server for amd64。

既然是Java Base的，首先要准备jdk环境。默认1104已经把java从apt中剔除了——跟oracle收购sun不无关系，尽管openjdk还在，我还是建议安装sun-jdk。具体实现如下：

echo “deb http://archive.canonical.com/ natty partner” >> /etc/apt/sources.list #添加源
apt-get update
apt-get install sun-java-jdk

文件多而大，耐心等待。

基础环境

默认apt方式安装的jdk目录为/usr/lib/jvm/java-6-sun ，等待jdk完成之后，

echo "/usr/lib/jvm/java-6-sun"  > /etc/jvm

官方建议关闭ipv6，尽管我不清楚有什么影响

echo "blacklist ipv6" >> /etc/modprobe.d/blacklist

建立用户/组，没什么要解释的

addgroup hadoop
adduser --ingroup hadoop hadoop

修改环境变量，vi /etc/bash.bashrc，在末尾添加：

export JAVA_HOME=/usr/lib/jvm/java-6-sun
export JDK_HOME=$JAVA_HOME
export PATH=$PATH:$JAVA_HOME/bin

切换用户到hadoop, su – hadoop

调通ssh，具体参见这里之前的东西。

mkdir .ssh
cd .ssh
ssh-keygen -t rsa
cat id_rsa.pub >> authorized_keys
ssh localhost

配置Hadoop

我默认已经使用hadoop用户进行操作，root权限可以不用了。

将下载后的hadoop保存在适当的目录下，我选择了/opt/hadoop目录。

修改/opt/hadoop/conf/hadoop-env.sh文件中，添加 export JAVA_HOME=/usr/lib/jvm/java-6-sun

cd /opt/hadoop/conf 一堆的配置文件要改。

conf/core-site.xml:

<configuration>
     <property>
         <name>fs.default.name</name><!--文件系统名称-->
        <!--<value>hdfs://localhost:9000</value>单机，不使用集群文件系统 --><value>/date/hadoop</value>
     </property>
</configuration>

conf/hdfs-site.xml:

<configuration>
     <property>
         <name>dfs.replication</name>
         <value>1</value>
     </property>
</configuration>

conf/mapred-site.xml:

<configuration>
     <property>
         <name>mapred.job.tracker</name>
         <value>localhost:9001</value>
     </property>
</configuration>

需要注意的是，不同的版本号之间，配置方式有细微的不同。

配置OK!

首先，下载安装包，我选择的是最新的stable版， 不过不客气的说，即便是coreseek的stable版本，不论是从稳定性、兼容性还是灵活性上都不能算是完善，至少无法跟apache这类经典应用相提并论。

安装ubuntu开发包：
apt-get install make gcc g++ automake libtool mysql-client libmysqlclient15-dev libxml2-dev libexpat1-dev

 
解压：
tar xzvf coreseek-3.2.14.tar.gz
cd coreseek-3.2.14

应该看到有mmseg csft testpack 至少3个目录

安装mmseg中文分词模块

cd mmseg-3.2.14
./bootstrap
./configure –prefix=/usr/local/mmseg3 #不喜欢这个官方目录配置，更换目录后配置无法生效郁闷了很久，稍后再说
make
make install
cd ../testpack
/usr/local/mmseg3/bin/mmseg -d /usr/local/mmseg3/etc var/test/test.xml #测试结果，请确保终端可以看到utf8中文，应该可以看到分词后的结果

安装Python包

虽然coreseek支持直接的mysql连接，但考虑到分词、分表的情况，这种设置不是很灵活。我的方案是通过python脚本的预处理，将mysql的数据整理后传输到coreseek建立索引。这样还有一个优势就是“万能数据源”——memcache、redis这类几乎不指望coreseek官方支持的妖异存储方案，只要有python的api，均可以索引。

官方的安装手册中介绍的python接口是基于ActivePython 替代系统python语言的方式进行的。ActivePython属于第三方封包，远没有系统自带python来的方便，刚开始用系统python测试了数次，均不成功，后来根据出错信息，找到了原因。

apt-get install python-dev python-sqlite python-mysqldb python-memcache

安装coreseek

cd ../csft-3.2.14
./buildconf.sh
./configure –prefix=/usr/local/coreseek –without-unixodbc –with-mmseg –with-mmseg-includes=/usr/local/mmseg3/include/mmseg/ –with-mmseg-libs=/usr/local/mmseg3/lib/ –with-mysql –with-python
make
make install

cd ../testpack
/usr/local/coreseek/bin/indexer -c etc/csft.conf –all
/usr/local/coreseek/bin/search -c etc/csft.conf 网络搜索 #没什么问题了

安装libsphinxclient

coreseek官方教程中建议php使用直接include一个php文件进行操作，事实上php有独立的sphinx模块可以直接操作coreseek (coreseek就是sphinx！)已经进入了php的官方函数库，而且效率的提升不是一点点！但php模块依赖于libsphinxclient包。

cd ../csft-3.2.14/api/libsphinxclient
./configure
make
make install
ldconfig

安装php-sphinx支持

apt-get install php5-dev
wget http://pecl.php.net/get/sphinx-1.1.0.tgz
tar vzxf  sphinx-1.1.0.tgz
cd  sphinx-1.1.0
phpize
./configure
make
make install

确信成功后修改php.ini，还是遵从ubuntu的配置规则
echo “extension=sphinx.so”  > /etc/php5/conf.d/sphinx.ini

如果使用apache或者fast-cgi的话，请重起。察看phpinfo() 如下则安装成功。

sphinx

配置coreseek

说容易也容易，说麻烦也麻烦的工作，照贴一份吧前面说过，我用的是python数据源

/usr/local/coreseek/etc/coreseek.conf

python
{
           path = /usr/local/coreseek/DBSource #python 数据源脚本的存放路径
}
source Blog #索引库1 “Blog”
{
          type = python #类型为python
          name = Blog.MainSource #调用python的class
}
index Blog
{
    source          = Blog #数据源名称
    path            = /data/sphinx/Blog #数据文件存放路径
    docinfo         = extern
    mlock           = 0
    morphology      = none
    min_word_len    = 1
    html_strip      = 0
   charset_dictpath = /usr/local/mmseg3/etc/ #mmseg中文分词库的位置，本文开头时我说不能修改mmseg的安装路径就错在这里
   charset_type        = zh_cn.utf-8
}
source UserInfo #索引库2 “UserInfo” 其余同上
{
    type = python
    name = UserInfo.MainSource
}
index UserInfo
{
     source          = UserInfo
     path            = /data/sphinx/UserInfo
     docinfo         = extern
     mlock           = 0
    morphology      = none
    min_word_len    = 1
    html_strip      = 0
    charset_dictpath = /usr/local/mmseg3/etc/
    charset_type        = zh_cn.utf-8
}

searchd #服务器配置
{
    listen          =   9312  #显而易见，默认的监听端口
    listen          =   172.18.196.90:3306:mysql41 #兼容mysql方式的监听，我们配置了php-sphinx，故除了命令行方式外意义不大，可以关闭
    pid_file        =   /var/run/coreseek.pid
}

曾经跟几个同行聊起了数据库这边的容错方案，有朋友发过类似的牢骚：“网站（或者数据库）做了负载均衡，可用性提高了，单点故障也不怕了，但数据的同步总是慢半拍，无法适用某些应用。如果要求完全解决一一致性的麻烦，就只能到回去。”

程序开发上始终念念不忘的有个“摩尔定律”，归根结底的就是说不要放太多精力去隄防运算速度达不到的问题。在运维以及底层架构涉及上有着同样重要的定律“CAP”，最早由加州大学伯克利分校（又是他）的Eric A. Brewer教授提出的。所有的分布式系统的好坏主要有3个重要的指标来衡量：

• 一致性（Consistency）
• 可用性（Availibility）
• 容错性、鲁棒性原文翻译是“分区容错”（Partition tolerance）

任何一个分布式系统只能同时满足3个条件中的两个，无法同时达到3者兼备。

就拿磁盘RAID来说：

RAID0的情况是数据分散在多块硬盘之上，只存一份。由于只有一份数据，不存在数据不同步的情况，一致性得到保障。多磁盘分散IO，性能提升，可用性提升。多块磁盘拼凑一份数据，磁盘损坏的概率正比上升，同时增加磁盘的难度提升，容错性下降。即为了C和A，放弃了P。

RAID1的情况是数据在每个磁盘上做一个备份。由于有多个备份，可能出现多个磁盘上数据不统一的情况，一致性下降。多磁盘分散IO，性能提升，可用性上升。很容易增加备份磁盘，多个备份，磁盘损坏概率反比下降，鲁棒性上升。即为了A和P，放弃了C。

RAID5的情况是一份数据分散在多块硬盘上，另外保存一份校验数据以方便恢复。数据只有一份，不存在一致性的问题。数据读写的同时可能会需要生成校验数据，影响速度，可用性下降。任何一块磁盘的损坏都可以通过剩余的磁盘中的数据和校验数据恢复，鲁棒性上升。即为了C和P，放弃了A。

对于传统的关系数据库的要求又不得不提ACID：

• 原子性 （Atomicity）数据和操作不可再次分隔
• 一致性（Consistency）操作结束后，仍可进行同样的操作
• 隔离性／无关性（Isolation）操作和操作不得影响
• 不可撤销（Durability）

“不可撤销”，“隔离性”，“原子性”都是限制鲁棒性和容错性的P，一致性本身就是C。剩余的A只能作为牺牲的指标。说得明显点就是目前尚没有什么有效的方法让一条SQL同时在多台主机上同时执行正常。跨表SQL很正常，跨数据库操作已经够变态的了，跨系统进行SQL操作而且保证数据的实时和一致几乎是不可能的。

对于传统的关系型数据库来说难度就是CAP三个之中在你需要任何一个的情况下，即便你愿意花钱去升级硬件，也必须以其他的下降作为代价。要么高可用（负载均衡），要么高安全（热备份），要么高容错（事务回滚），想要正比的升级来获取A是不可能的。

这些年大负载架构的出现带动了nosql型数据库。类似memcache，bigtable和Hbase这类的key-value也是一大亮点。相比关系型的数据库而言，新的数据模型仍然无法摆脱这个魔咒，唯一的优势在于这些架构相对灵活，可以根据需要进行CAP取舍，找出真正适合的C 、A、 P比例。

• FreeBSD + Apache + PHP + Mysql (恶搞版)
• FreeBSD + Apache + PHP + Mysql + Oracle
• Ubuntu + Apache + PHP + Mysql ，比较简单，正常server版安装结束的最后一步可以选择安装LAMP
• Ubuntu + nginx + php
• Ubuntu + php + Oracle

Memcache

说起Memcache，这年头稍微大点的网站几乎是必不可少的。内存Key-value一对一数据库，但数据易失。新浪的团队也有个项目是memcachedb，就是以速度为代价，部分数据回写硬盘。但似乎不是memcache的本意，个人觉得不如直接写sql，仁者见仁吧。

• For Ubuntu
  apt-get install memcached php5-memcache
  /etc/init.d/memcached start
• For FreeBSD
  cd /usr/ports/databases/memcached
  make install clean
  cd /usr/ports/databases/pecl-memcache
  make install clean
  echo”memcached_enable=YES” >> /etc/rc.conf
  /usr/local/etc/rc.d/memcached start

Redis

也是一个Key-value数据库，比起Memcache速度慢一点，但会回写硬盘，数据不丢失。处理Feed之类SQL吃上劲的应用必备。

• For Ubuntu //11.04可行，8.04不行，官方似乎从904以后才加入的。之前的版本不妨用debian包
  apt-get install redis-server php-redis //同样的debian包下载
  /etc/init.d/redis-server start
• For Freebsd
  cd /usr/ports/databases/redis
  make install clean
  echo ‘redis_enable=”YES”‘ >> /etc/rc.conf
  /usr/local/etc/rc.d/redis restart
  cd /usr/ports/databases/php5-redis
  make install clean //敲的条件反射了

说起redis的PHP支持类，由于redis是明文的传输，所以很多人会选择redisend这类基于socket连接方式的php类——说白了就是模拟telnet 6379。根据实际测试的结果，C扩展至少有40%以上的提升，而且内存更少，加包和拆包的过程更迅速。更何况redisend的前一个版本一堆问题，后一个版本又是php5.3 only的天上一脚，地上一脚的维护也是麻烦。不是万不得已还是少用为妙。

PHP-FPM

这个是给Nginx做fastcgi扩展的，相比php-cgi, spawn-cgi不但性能上有提升，配置上也灵活的多，但FreeBSD不支持，Ubuntu也不官方推荐。这里使用了ubuntu的非官方库。

echo “deb http://php53.dotdeb.org stable all” >> /etc/apt/sources.list
apt-get update; apt-get upgrade
apt-get install php5-fpm

会直接覆盖之前官方支持的PHP包，请慎重考虑。

/etc/init.d/php5-fpm start

PHP-GD

最常见的缺失，但很容易。

• For Ubuntu
  apt-get install php5-gd
• For FreeBSD
  cd /usr/ports/graphics/php5-gd
  make install clean

Minify

Minify是一个基于PHP5的CSS/JS优化包，其实这不属于Php的扩展。

1. http://code.google.com/p/minify/ 下载最新的minify，解压后，将min目录拷贝至网站根目录下。
2. 确认是否开启了apache 的mod_rewrite，Ubuntu默认不开启，需要a2enmod,选择rewrite后,/etc/init.d/apache2 restart 重起apache
3. 网站根目录下编辑.htaccess内容如下：

   RewriteEngine On
           RewriteBase /
            RewriteRule ^(.*\.(css|js))\S?$ min/index.php?f=$1 [L]

4. 如果系统已经安装了memcache包，不妨用MC替代文件方式存储优化后的信息，编辑min/config.php，末尾添加

   require 'lib/Minify/Cache/Memcache.php';
   $memcache = new Memcache;
   $memcache->connect('localhost', 11211); //根据本地配置调整
   $min_cachePath = new Minify_Cache_Memcache($memcache);

TokyoTyrant (ttServer)

TykyoTyrant想必web game, social game的公司用的很多，大概是由于某家企鹅公司的框架所限吧。这东西就是一个“支持lua扩展并可持续化”的key-value。个人觉得完全可以通过memcache + redis两者取代。

• for Ubuntu (natty ok, hardy not support)
  apt-get install tokyotyrant
  /etc/init.d/tokyotyrant 52~53行稍作修改：
  52 #SERVERHOST=”$RUNDIR/$NAME.sock”
  53 SERVERPORT=1978
  即可通过/etc/init.d/tokyotyrant start命令启动1978端口的监听

• for Freebsd
  cd /usr/ports/databases/tokyotyrant/
  make install clean

时隔了5年多，不妨回头重新从新的高度上说说LAMP结构的网站如何支撑尽可能大的负载。同样说明，本文代表站长Litrin的个人意见，欢迎共同探讨，但喷子慎入。

首先声明的是，以下一堆相对无趣的文字仅针对一系列负载到了至少10W pv以上级别，对于较小规模的网站大可不必遵守，还是提倡成本优先的原则，到了对应的PV级别想必也会有足够的财力和物力去改版了。

初期规划

这里主要还是指设计模型等前期工作。MVC的设计结构深入人心，不得不承认确实大多架构设计师首选的设计结构必是MVC。事实上，在一个网站上最容易获取，最不缺的资源是CPU和内存，最大的瓶颈都是出现在IO。

作为LAMP架构最大的问题就是MVC的代价太大，层层的封包意味着重复判断；打开大量的程序文件只会严重拖累性能。网上很多免费的、开源的PHP框架，用过的几个诸如ThinkPHP, ZF等应付中小型网站绝对没有问题，但都不适合大负载的网站。甚至包括Smarty这样单纯的模版引擎，大量的IO操作会拖累整体性能。如果不考虑其他因素，我甚至都考虑过All in 1的垃圾结构——这当然不现实。但恰恰是这种all in 1却正是大负载最适合的结构。奇怪的悖论。

受GAE的影响，曾经想过API+XML的方式实现网站架构，但后来打消了这个念头。XML本身的结构冗余度很多，这也就意味着信息承载率低。在内部几台服务器之间的通讯状况想必都没有必要搞XML，如果要搞类似的模式，CSV方式反倒是不错的选择。XML是为了开放给第三方用户的。

数据库设计

读写分离这个是众所周知的秘密了。Mysql 的Master + Slaver的设计真的很方便！最多就是多搞几重的读写分离。

拆表、拆库、分机器，大表做纵拆，宽表做横拆，不关联的分机器；纵拆是为了省时间，横拆是为了省内存，分机器是为了分负载。Mysql在几百万行数据级别以下性能是很不错的，超过这个数量级，就算机器再强悍都会死的很难看，mysql垃圾的锁表机制会展现无疑。没有人愿等到30秒以上的Respone，何况我曾经遭遇一个45分钟以上的Select操作（一重操作，没有用到Like，使用索引）。曾经用过mysql 的分区表，感觉这种方法更像是在打补丁——改变数据库结构去适应程序，很奇怪的流程，更何况即便逃过这次不拆，迟早有一天还会回来拆的。

索引，该有的全都有，但对于写操作频繁的表，索引反倒成了累赘，不要让索引数占到字段数的30%以上这是约定俗成的标准吧。

memcache，没什么可以多说的，这玩意基本上就是铺硬件换时间的。

说道非关系型数据库，好像近期很热门。怎么说呢？越是复杂的网站越是能体现出它的优势，但问题是大多数网站都不会像twitter或者Facebook这么复杂，况且大多数程序员的逻辑还是SQL模式，贸进很可能搞砸。

WWW服务器拓扑设计

F5这类的设备是必须的，之前曾经觉得LVS可以替代F5这样的设备。用过之后才发现，这等于是将整个网站的身价性命都扔到了一台服务器上，一旦宕机或者被侵入呢？

对于Apache还是nginx的争论持续了很久。nginx很快速，可以将单独的PHP负载分离出去，但没有apache来的灵活。要根据需求再做评价。

异步操作和缓存机制

这个貌似也没有什么花头，调整好负载之后可以将一部分操作异步到数据库相对空闲的时段进行，达到移峰填谷的效果。配合memcache或者其他的缓存机制本身也是动转静的手段之一。

自动和手动的问题

属于代码级别了吧。良好的编程规范对系统的优化是很显著的。漫山遍野的select *， 大量的变量不清空是高负载系统的忌讳。纵然php的内存处理机制再出色，它永远也不会理解你设置的变量什么时候失效，减少这看似寥寥无几的空间乘上惊人的pv数也是很可观的。

首当其冲的应该算是云技术，但这个技术总体上属于物理层的技术，况且云已经成为公认的技术趋势。这里主要是谈下网站的架构，云技术相对关系较为偏离，我也就不再探讨了。

BigTable数据库

一开始接触下来的GAE，最感觉不适应的就非它的“数据存储”技术。通常用惯了SQL，用了GAE觉得数据设计上很要有很大的转变。
GAE的“数据库”感觉就是一个巨大的List，每一条记录都是key-value的对应关系。当然起初是无法满足很多传统上的数据结构。不过如果你能够在数据结构设计上打破SQL的限制，通过极端灵活的Key-value, key-value, key-value，你就能发觉这样的框架事实上比传统的SQL更适合网站。
说mysql比oracle在网站实现上的优势并非是因为它功能的强大，而是它速度快，结构简单。尽管有人戏称mysql“裸奔”，但无可否认的就是这种“裸奔”的效果带来的mysql的成功。GAE的数据库比mysql还要“裸奔”，但更快的响应将会是SQL永远无法企及的。FaceBook之前也抛弃了SQL亦证明了这一点。

此外整站之间的数据复制也算是革新之一。

多通道的融合

GAE整合了mail，xmpp，跨域验证等一系列的通道也算是特色之一，想必很多人会认为google这是在捆绑自己的产品。作为之前的门户网站的特色，每家人都会有一个自己的邮箱，一个自己的聊天工具，以及一系列自己的产品捆绑在内。GAE的创新在于用户只需要一个自己的google帐户就可以实现捆绑所有的gae服务。这是一个真正意义上的以用户为本。
Xmpp的捆绑还意味着EDM之后，将来IM营销或者类似的IM推送将会逐步成为一个产业。或者更进一步，IM机器人或者类似的技术将会一定程度上取代现有人人对话模式。当然，这需要一段时间，但至少个人认为目前大量的taobao网店需要这种技术^_^。

精巧的运维界面

相信GAE的后他大家也会印象深刻，能对每一个模块进行精确的监控，已经让运维的工作从翻阅日志的文本化提升到了图形化。粒度也更为精准，如果能配合Analytics之类的数据，完全可以实现智能化的运维。

RSS XML SOAP 网址抓取…

其实这也不算是什么革新，Web2.0时代的开始就是以此为标志的。但事实上单单从开发库中各个库的名称都叫API来看，就可以明白，其实整个GAE就是构建在这些基础之上的。SOAP成为了各个模块之间的粘合剂。
这个带来的优势就是，无需关心这个库那个库——好像本站技术性文档的大部分都是解决的“库问题”。各自统一接口，加速了开发的进程。

这些天，系统在部分时间（不一定是高峰期），会出现大量的堵塞。堵塞每次持续时间最多5分钟，之后要么自己恢复，要么系统IO吃光。已经排除了病毒或者网络的问题。

利用sqlserver自带的“事件探查器”发觉大多数的阻塞都是跟其中的一个表有关。这个表数据有3M行的数据，并建立了聚合索引。
反复优化索引，系统没有起色。狠心删除了主键的聚合索引，问题竟奇迹般的解决了！
将聚合索引索引转为非聚合索引之后，系统再也没有出现故障。

分析下来大致如此：

1. 系统纪录的日志文件是以时间倒序为聚合索引，但由于日志的记入方式决定了数据的纪录方式并非按照顺序。即会出现新纪录比旧纪录先写入的情况。
2. 3百万行的数据大约有500~700M的磁盘空间占用，按照聚合索引占整体数据大小的30%来计，索引大小大约为200M左右。
3. 由于聚合索引是按照固定的顺序纪录，出现乱序的数据写入，sqlserver就必须重建聚合索引，每次都要重新生成这200M。
4. 200M的数据需要相当长的时间，在此期间如果再有数据记入，行锁就上升为表锁，故出现系统阻塞。而之前一直没有出现问题，只不过是由于数据小，而索引生成的很快罢了。

所以建议聚合索引的使用前请确认在大数据的情况下务必保证新加的数据都在文件的末尾，这样系统就不会因为频繁的重建索引而造成数据阻塞或者IO的浪费。

作为网站运行来说，日志分析是一个很重要的工作。当一个网站的日志到了一定程度，或者一个网站同时有多台服务器的时候，传统的文本日志分析总会遇到瓶颈。

这个时候我就会想起强大的sql语句。看了网上很多人的帖子，都是将日志转成sql语句再导入的，搞得有点复杂。本方案不需要任何多余的软件和操作，一切全是实时、自动，供各位参考。

主机至少需要预安装apache(废话！)和mysql的客户端。如果访问量不大且服务器的资源管够的话可以将mysql装在本地，否则建议一台独立的mysql服务器。

在apache配置文件或者虚拟主机配置文件中面添加

LogFormat INSERT INTO apacheLog (ID, dateTime, IP, URL, code, referer, userAgent, size, request) VALUES ( NULL , \"%{%Y-%m-%d %H:%M:%S}t\", \"%a\", \"%U\", \"%>s\", \" %{Referer}i\", \"%{User-Agent}i\", %b, %T);" sqlcomm
CustomLog "| /usr/local/Mysql --host=HOST --user=USER --password=PASSWORD --database=LITRIN_NET" sqlcomm

建立数据库apacheLog。

CREATE TABLE ` apacheLog ` (
  `ID` int(11) NOT NULL auto_increment,
  `dateTime` datetime NOT NULL,
  `IP` varchar(15) NOT NULL,
  `URL` varchar(256) NOT NULL,
  `code` varchar(3) NOT NULL,
  `referer` varchar(256) NOT NULL,
  `userAgent` varchar(256) NOT NULL,
  `size` int(11) NOT NULL,
  `request` float NOT NULL,
  PRIMARY KEY  (`ID`),
  KEY `dateTime` (`dateTime`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

 确认无误后重启apache生效！

其实整个流程很简单：先是利用LogFormat设置将日志转换为接近sql的格式，再通过CustomLog 调用pipe实现mysql写入。你也可以参照http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats的格式设置写入自己关心的数据。
此外，你也可以使用SetEnvIf配合正则表达式过滤掉诸如图片、CSS、JS之类相对不重要的信息。

oracle官方建议的linux仅限于Redhat, Suse, Asianux以及oracle自家的linux。但作为测试的一部分，我选择了ubuntu的新版本910 AMD64 server作为平台。不过理论上使用ubuntu Desktop或者Xubuntu更省力一点。系统内存为8G，根据建议（如下），设置了8G的swap。

之前还有一篇solaris下10up2的安装可以参考

安装完毕后还是个人习惯性的那一套：
#sudo apt-get update
#sudo apt-get upgrade

升级结束后安装必要的库：
#sudo apt-get install gnome-core unzip build-essential libaio-dev(ms libaio 就可以)

设置环境变量：
修改/etc/bash.bashrc，在末尾添加如下内容
ORACLE_HOME=/opt/oracle/product/11.2.0/Db_1
export ORACLE_HOME
ORACLE_BASE=/opt/oracle
export ORACLE_BASE
NLS_LANG=american_america.zhs16gbk
export NLS_LANG
PATH=$PATH:$ORACLE_HOME/bin
ORACLE_SID=orcl
export ORACLE_SID

修改内核参数：（官方文档没有提及，保险起见，还是添加了）

fs.file-max = 6815744
fs.aio-max-nr = 1048576
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576


重起机器。