作为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官档！

既然仅仅只是当作一个容器，从性能上考虑那为什么要用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
}

• 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数也是很可观的。

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

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

分析下来大致如此：

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

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