KVM主机是之前一直在说的Ubuntu1204的libvirt，没有桌面系统，也就意味着不能简单的通过virt-manger工具配置。主机在外网，且防火墙限制了它不能直接通过VNC连接。

首先是准备ssh 通道，windows下，我一直用putty

连接成功后，本地将会出现5900端口的监听，直接用VNC的客户端连接localhost的5900事实上就连接到了远程主机的5900。当然，虚拟机还没有启动，两个5900都不存在。

准备配置文件，其实我是直接用模版修改出来的：

 <domain type='kvm'>
  <name>medkaoyan</name>
  <uuid>f5936116-24c7-163f-13ac-7f50604faa5c</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.0'>hvm</type>
    <boot dev='cdrom'/> <!-- 首次用光驱启动 -->
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/data/VM/medkaoyan/freebsd.qcow2'/> <!-- 磁盘文件 -->
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
<!--
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/data/VM/medkaoyan/data.qcow2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='1'/>
    </disk>
-->
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/root/FreeBSD-9.0-RELEASE-i386-disc1.iso'/> <!-- 安装介质 -->
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:ef:8c:06'/>
      <source bridge='br0'/>
      <model type='ne2k_pci'/> <!-- 网络 -->
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <!-- <input type='mouse' bus='ps2'/> -->
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
</domain>

典型的xml，很好通读，里面的问题稍后再说。

制作虚拟磁盘文件，配置文件中，此文件名为 /data/VM/medkaoyan/freebsd.qcow2

kvm-image create -f qcow2 /data/VM/medkaoyan/freebsd.qcow2 20G   , 创建一个20G的虚拟磁盘。

多说一句，KVM支持多种虚拟磁盘格式，除了诸如vmdk等其他几个虚拟主机格式的文件之外，raw和qcow2我用的比较多。raw事实上是硬模拟了一个裸设备，这样做的优势是相对来说数据是平滑的，也就是一旦虚拟机崩溃，用这个文件可以硬恢复数据的。但磁盘空间是预分配的，而且不支持snap，从某种程度上说是增加了崩溃几率。qcow2的空间分配是按照使用率来的，效率比较高，而且支持数据压缩、数据缓存等高级功能，但问题是一旦崩溃，数据恢复比较复杂。大家各取所需吧。

下载安装镜像，没什么难度：

wget http://mirrors.163.com/FreeBSD/releases/ISO-IMAGES/9.0/FreeBSD-9.0-RELEASE-i386-disc1.iso

对于网络，系统原本推荐的是virtio，但FreeBSD不支持virtio，第一次安装的时候我在全部完成之后进入系统，手工配置内核后才OK，其间没有网络cvsup都是问题，费时费力。为了方便，索性这次直接修改默认配置到ne2k_pci，很方便！

确认无误后启动virsh，create你的xml配置文件，start 虚拟主机。此时5900开始监听，VNC上！

安装过程是图形化的，直接跳过。

完成后destroy 主机， 将启动介质从cdrom切换为hd。

首次进入系统后，准备之前说的virtio模块，优化性能（需要安装src源并保持更新）。

cd /usr/src/sys/dev
svn co http://svn.freebsd.org/base/projects/virtio/sys/dev/virtio
cd /usr/src/sys/modules
svn co http://svn.freebsd.org/base/projects/virtio/sys/modules/virtio
cd /usr/src/sys/modules/virtio

make install

漫长的编译过程。。。。完成后编辑 /boot/loader.conf，增加：

virtio_load="YES"
virtio_pci_load="YES"
virtio_blk_load="YES"
if_vtnet_load="YES"
virtio_balloon_load="YES"

重起之后确认模块是否挂装：

# dmesg | grep -i  virtio
vtnet0:  on virtio_pci0
virtio_pci1:  port 0xc060-0xc07f irq 11 at device 4.0 on pci0
vtballoon0:  on virtio_pci1
virtio_pci2:  port 0xc080-0xc0bf mem 0xf2040000-0xf2040fff irq 10 at device 5.0 on pci0
vtblk0:  on virtio_pci2

写在最后的是通过virt-install的安装方法，有没有觉得之前看这么多是上当了？   请先apt-get install virtinst

sudo virt-install \
--name medkaoyan\
--ram 512 --vcpus=2 \
--os-type unix --hvm --vnc \
--cdrom=/root/FreeBSD-9.0-RELEASE-i386-disc1.iso \
--network=bridge:br0,model=ne2k_pci \
--disk path=/data/VM/medkaoyan/freebsd.qcow2,size=20

首当其冲的是$_SERVER["HTTP_REFERER"] 环境变量，这个问题经常出现在需要跳转的页面上，表现为跳转到白板。
很多代码习惯上用$_SERVER["HTTP_REFERER"] 获取上次访问的页面URL，这对于mod_php来说，由于采用直接嵌入http服务器的方法，PHP可以很容易的获得HTTP_REFERER变量。但对于CGI方式的php-fpm来说，此环境变量无法获取，我个人的解决方法是通过不断刷新一个cookie获取。显得很笨拙，但代码改动的量很少。你也许会说这样做容易被篡改，但事实上即便mod_php获取的环境变量也是很容易被篡改的。

接下来是$_SERVER["HTTPS"]，这个问题经常出现在跳转上，如果发现所有的跳转url出现异常多半是这个问题。
mod_php中$_SERVER["HTTPS"]变量只有在启用了https之后才会出现，否则empty($_SERVER["HTTPS"]) === true，而作为php-fpm这个值是始终存在的，只是在http时$_SERVER["HTTPS"] === null而已。尽管$_SERVER["HTTPS"] == null 等价于empty($_SERVER["HTTPS"]) == true，但在“三等”条件下并不成立。

对应的$_SERVER变量问题还有x-forward*之类，这里不再累述。

然后是rewrite规则，这个规则事实上是apache和nginx之间的兼容问题，跟php无关。
个人觉得很apache和nginx的跳转规则基本上是通用的甚至于只要用记事本做个全文替换就好。例如：

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

转换为nginx

rewrite "^(.*\.(css|js))$"              /min/index.php?f=$1     last;

当然，nginx是不支持.htaccess的，需要写入配置文件中去。

执行时间问题，对应的大多为502报错。这个问题说实话我没有很好的方法解决，只能提前规划。
不同于mod_php的方式，在执行一个较长时间的脚本时，一旦超出阀值（默认10秒）php-fpm会自动关闭执行，向前端返回502。个人觉得这相对于mod_php来说是一个保护性的设置，是优势所在，不应该关闭。

进程控制类函数，相对用的应该不多。
php-fpm用的是非阻塞性质的线程池，不应该有这类函数出现，应当慎用。

一个窍门：$_ENV变量
相比mod_php来说，$_ENV变量是一个优势，对于企业开发，特别是开发和运维分开的企业，这很容易开发出环境无关的代码——运维修改$_ENV变量，开发读取此变量，相互直接不需要太多交流。对应5.3 fpm配置文件中 env[TEMP] = /tmp 或者5.2 <value name=”environment”>  <value name=”TMP”>/tmp</value>标签。

1204 新特性：

• The Head-Up Display (HUD) 顶部部显示空间
• The Video Lens 新的视频展现方式
• Ubuntu Software Centre 新的软件中心

全文http://www.ubuntu.com/ubuntu/whats-new

看到这里，就捎带着说说Unix的Socket协议吧。

Socket接口或者叫博克利套接字接口，最初在Unix系统中实现的目的是为了进行进程间的通讯，习惯上被define成AF_UNIX或者PF_UNIX。目前大部分的socket套接的通讯方式已经完全兼容TCP/IP，对于本地的访问进程可以通过raw socket的方式访问socket文件就可以方便的进行通讯。相对于TCP/IP这种IP地址+端口号的方式Unix socket的描述符更像是一个文件路径。

例如在php中 mysql_connect(‘localhost’, ‘mysql_user’, ‘mysql_password’); 可以替换为 mysql_connect(‘UNIX:/var/run/mysqld/mysqld.sock’, ‘mysql_user’, ‘mysql_password’); (Ubuntu的默认MysqlSocket的保存路径和Redhat的是不同的，需要注意！)

由于socket的通讯方式相比TCP/IP来说不需要占用带宽，所以在某些情况下可以达到提升性能的目的。而且由于上文所说大部分Socket有意设计的跟TCP/IP协议兼容，故很多情况下可以善用它。

举个例子吧，就说php5.3-fpm + nginx的修改。

默认情况下，php-fpm绑定了本地的9000端口，nginx将请求转发到本地9000号从而实现对php的解析。

我们修改php-fpm.ini文件，如果是apt安装，可以直接修改/etc/php5/fpm/pool.d/www.conf

listen = 127.0.0.1:9000 改为 listen = /var/lib/php5/php-fpm.sock

php5.3以前的php-fpm是一个xml，

<value name=”listen_address”>127.0.0.1:9000</value> 改为 <value name=”listen_address”>/tmp/php-fpm.sock</value>

重起php-fpm之后，netstat -an应该没有了对于9000端口的监听，取而代之的是多了这么一行

unix 2 [ ACC ] STREAM LISTENING 124099 /var/lib/php5/php-fpm.sock

修改nginx配置：

location ~ \.php$ {
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/var/lib/php5/php-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}

重起Nginx，成功！

相关文章：

• Cython快速实现Python的C重构
• Cython快速实现Python的C重构

老一套的python源码：

def sheepBorn(i):
    if i < 1:
        return 0
    elif i < 2:
        return 1
    return sheepBorn(i-1) + sheepBorn(i-2) - sheepBorn(i-5)

和计时测试借口：

import time
from sheepBorn import sheepBorn

startTime = time.time()
print sheepBorn(32)
print time.time() - startTime

直接Python的测试结果耗时15.7993621826秒。

在不修改任何代码的情况下把它通过Cython编译为.so文件再测试一遍，

9.83871483803，有差距了！

修改为面向Cython优化过的pyx文件

def sheepBorn(int i):
    cdef int a
    if i < 1:
        a = 0
    elif i < 2:
        a = 1
    else:
        a = sheepBorn(i-1) + sheepBorn(i-2) - sheepBorn(i-5)

    return a

说实话，由于算法已经足够精简了，代码上几乎没有变化。
测试结果是7.72257995605，也就是一行的变动，导致了不错的提升！

Continue!

察看转换过程中的C中间文件，找到了 static PyObject *__pyx_pf_9sheepBorn_sheepBorn(PyObject *__pyx_self, PyObject *__pyx_arg_i)函数，很臃肿，简单的优化了一下：

static int py_sheepBorn(int i)
{
     if (i &lt 1) return 0;
     if (i &lt 2) return 1;
     return py_sheepBorn(i -1) + py_sheepBorn(i-2) - py_sheepBorn(i-5);
}
//修改部分略过

重新编译为python 的 so扩展
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c sheepBorn.c -o build/temp.linux-x86_64-2.7/sheepBorn.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/sheepBorn.o -o /root/ctype/cython/sheepBorn.so
测试结果0.174817800522，这是极限吗？

工作的频繁变动不排除一方面有公司的因素或者说项目的因素存在，但另一方面，我还是觉得目前个人的职业发展出现了瓶颈，很难找到一个突破口，翻来覆去都是一些重复，重复，再重复。当收入水平上可以满足一定的生活现状的条件下，时间一长在惰性的干预下，就会到达到所谓职业的稳定期。加上由于年龄和家庭的影响，我很害怕今后将难有大的突破。由于IT行业本身的特性，“稳定”事实上是“后退”“下滑”之类词语的婉转用法。“Keep huger, Keep thinking! (－Steven Jobs)” ，这两者之间的关系确实是紧密的。

总之，我深怕自己陷入由来已久的“工程师30岁现象”中去。

之前相对来说公司都是以创业型或者发展型企业为主，对于我们这样的技术人员来说，这样的公司能够提供一个成长中的平台。随着公司的发展，只要你愿意接触，很容易在各个方面上有所提升，进步也是很明显的。但缺点在于，如果一个技术人员始终处于这种状态下，久而久之技术上是够全面的了，由于平台的容量所限，往往在一段时间内，很难在某一方面有所精通，达到所谓的专家级别。所谓“小公司出全才，大公司出专才。”是有道理的。

举个例子，就拿做网站架构来说，在创业型公司里，由于一切都是新的，加之有前车之鉴，而且在可预见的时间内得到“摩尔定律”的眷顾没有什么技术上的难题，团队合作上也没有什么顾及，可以肆无忌惮的用一些很花哨的东西，甚至可以肆无忌惮的修改需求以适应这些东西。一旦成品出现，这些花哨的东西，足够成为你取笑老牌网站的资本。但当一个创业型企业实现蜕变，成为一个成熟型企业时，网站的访问量达到了一定规模，团队规模也足够庞大，这个时候，起作用的更多的是“物种起源”而不是“摩尔定律”。不管是技术架构还是管理架构都会出现不适应的问题，那些花哨的东西成为华而不实的鸡肋，既不能拿掉，也无法推翻重来。况且这个时候团队内部的配合、团队间的配合也远远不是当初时那么的顺畅和简单。说1＋1<2尚且是乐观主义者，事实上1＋1<1的情况也不在少数。后来的人不明就里，处于各种目的，无一例外的痛斥前人留下的烂摊子，如果整个公司的所有部门都是如此面貌的话，不客气的说，这样的公司无法实现蜕变，要么几十年如一日始终处于创业期（貌似没有这样的公司），要么干脆关门大吉。

我这里说的“发展型公司”和“成熟的公司”并非指的是公司大小和规模，而是指一个公司从职位设置到规章制度都有章可循。对于一个相对成熟的公司来说，各方面的资源相对完善，各个岗位都是专注于某一特定内容。关注一个问题更多并不是“如何实现”，而是“如何控制”。在“可控”的前提下，他们更多的愿意以专业的人去处理专业的事情，“顶岗”是绝对失控的表现，不会被轻易的允许。这也就意味着在其中的人特别是技术出身的人的工作范围被压缩到了一个狭长的位置，只能定向去发展，最终的目标是“悟净”，而不是“悟空”——相对大师兄的呼风唤雨，却又状况百出，沙师弟只要把那么几句经典台词说好就可以了。沙僧易找，悟空难寻，这么做本身就是为了防止失控。但由于过度的追求“可控”，“悟空”被加上了过多的紧箍咒，畏首畏脚，很难发挥，久而久之也将成为“悟净”！

对于身处其中的技术人员来说，在经过了创业型公司不断发展的洗礼之后，兴许已经积累的足够的资本，而且工作方式上也形成了足够强烈的惯性。或许已经很难再去适应一个成熟企业的方方面面。如果没有足够的准备，他也很难再去适应一个企业的蜕变。从另一方面来说，对于成熟公司的员工一旦成了习惯，如果不是创业公司的核心团队，他将很难适应创业初期的失控局面，同样也要需要不断的适应。我有幸的是能将自己的爱好、性格和职业做到了比较好的统一，对于这种适应已经逐步的感到了力不从心，对于很多没有如此幸运的人来说，这个适应本身就更加成为了一种累赘。

目前的国内互联网公司的创业很容易，门槛足够低，但这些也导致了成功转型的不够多，大多数的互联网公司最终都没能够成功。即便所谓成功的互联网企业，说句老实话，大多都是成为某些国外巨头或者国内更大型企业的模仿抄袭或／和附庸而已。很难说是开创了新思路、新市场、新平台什么的。这对于一个30岁左右，已经有了足够职业沉淀的技术人员来说， 年少轻狂时代的冲劲已经荡然无存 ，单从项目上很难说有吸引力，或者从工作内容上讲他已经有所厌倦；接近10年的工作经验可能已经让他们看透了这个行业的起起落落，某些“奶酪”已经被动过了，失去了原先的激励效果；来自生活的压力要求他更多的想要更稳定的收入或者是更多的收入，而这个时候的等待他们可能并非是单纯技术层面的转变，甚至来自职业上的转型都迫在眉睫。兴许这就是前面说到的 “工程师30岁现象”的由来。

我一直尽可能的想要避免这个问题，然而它却不可避免的悄悄来临了⋯⋯

说起Python，首先想到的他是一种“胶水语言”。作为一种合格的胶水语言，比起开发的难易程度或者开发效率来讲，语言的适应性和可扩充性同样很重要。python的一大特色是有许多方便灵活的扩展模块。

对于上次我们曾经说过ctypes的方式可能对于已经存在的lib库，这对于已经存在的C libs或者有C程序员参与的情况下是很方便的，但对于很多团队来说，合格的C程序员始终是个缺口。这次我们就说说针对单独的一个模块通过Python的一个扩展Cython进行C重构，从而达到尽可能减少工作量，从而达到最便捷的C重构。

在此之前，安装cython和python-dev（需要Python.h文件参与）

apt-get install python python-dev

python原文件，这次选择的是“费波拉契数列”的计算：

fib.py

def fib(i):
    a = 0
    b = 1
    while i > 0:
        i -= 1
        a, b = b, a+b

    return True

startTest.py

import time
from fib import fib

startTime = time.time()
for i in xrange(1,10):
    fib(10**6)

print time.time() - startTime

执行 python startTest.py得到的运行时间是130.857528925，两分多钟。

准备编译脚本，虽然违背了没有coding，但请相信,代码真的很少

build.py

from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext

setup(

cmdclass = {'build_ext': build_ext},

ext_modules = [Extension("fib", ["fib.py"])]

)

开始编译：

root@Vhost2:~/testCython# python build.py build_ext --inplace

running build_ext

cythoning fib.py to fib.c

building 'fib' extension

creating build

creating build/temp.linux-x86_64-2.7

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c fib.c -o build/temp.linux-x86_64-2.7/fib.o

gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/fib.o -o /root/testCython/fib.so

当前目录下应该多出来一个fib.c和fib.so，不要怀疑，.c的那个就是C的源码，而.so则是基于c 的python 扩展。如果你有实力可以在.c文件上进行人肉优化，我想效率也远高于从0开始。其中比较好的一点是，C源码中，python的源码会作为注释添加其中，看起来也很方便。

本文主要介绍的是cython，对于生成出来C代码的优劣不在讨论中，有兴趣欢迎私下交流。

开始新的测试：

删除原来的py库，mv fib.py fib.py.bak && rm -f *.pyc

python startTest.py

得出结果105.579359305，汗！没有想象中的那么突飞猛进。通过cProfile的导出，没有看出什么名堂。

事实上查看了C源码，发觉事实上大量的代码实现的仍旧是Python的逻辑，而Python的效率跟C绝对不是一个等级。这当然存在更加有优势的优化方式，但已经脱离了“快速实现”的本质，本文不再介绍。

考虑到“费波拉契数列”是python实现的经典例子，我重新改动了代码。（方便测试，连函数名都没动，容易误导）

fib.py

def fib(i):
    a = 0

    while i > 0:
        a += i
        i -= 1

return a

6.1317088604 : 4.3963329792算是比较显著了吧。

对于编译后的脚本来说，个人觉得性能的提升只是一方面的优势。特别是一些对安全性有要求的应用中，编译后的代码隐蔽性较好，在生产环境中即便别人获得了你的服务器权限，也很难反拆你的算法，避免了很多麻烦。

需要注意的是，对于yield方式实现的迭代器，cython无法完成编译，只能重新修改代码，但对于大多数的代码来说，cython几乎是平滑的。而且你甚至可以写一个全自动的部署脚本，上线后自动完成编译。

照旧，先放上例子：

def test(i):
    x = 0
    while i > 0:
        i -= 1
        x += i
    return x

想必各位都能看懂段代码吧，不懂得话，请直接跳过。

由于C对于类型的判断强于Python，为了方便起见，建议整理一篇文档，以保证出入参数时不会报错。大致如下：

• 方法名：test
• 方法简介：计算从0到i的总数
• 入参：int  i
• 返回：int x

为了更清晰，我习惯上画一个流程图：

把上面的文档整理一下，找一个会C的朋友。一般来说，可以遵循以下流程：

需要注意的是。为了保证成本最低，一定要从-1元开始出价，这样在流程第二步加价1元之后，你仍然不需要出钱，当然你也可以从-10000开始。考虑到程序要适应大多数情况，而不是个别情况，个人强力推荐从-1开始！

之后需要一定转换时间，视具体需求而定，如果你的项目像我的一样简单，这个过程应该不会太久。

转换出来的代码大致如下：

int test(int i)
{
    int x = 0;
    while(i < 0) x += --i;
    return x;
}

完全可以部署的代码！

祝大家节日愉快！

PS：如果您来访问的日期不是某年的4月1日的话，请去这里查看。

这个基类的优势在于特别是对于“分库分表”的MySQL来说，支持直接多进程并发读库，性能超强。而且对于Python2.6以下不具有多进程特性的用户来说，这个基类支持通过线程来模拟进程，完全透明！

该库已经在生产环境中使用。

需要MySQLdb类包

#!/usr/bin/env python
# -*- coding:utf-8 -*-
# abs class for CoreSeek indexer data source
#
#   By Litrin J. 2011-07
#

from DBConfig import DBConfig
import MySQLdb
import datetime, time, types
try:
    from multiprocessing import Process, Queue
except:
    from threading import Thread as Process
    from Queue import Queue

class CoreSeek(object):
    '''
    Abs class for CoreSeek data source.
    '''

    DBName = ""
    #field list, you can use "as" method, just like 'id as uid' to rename the `id` field to uid
    Field = []
    WhereCause = "TRUE"
    #the uniq id in the row for 1 table
    UniqId = None
    Scheme = []
    FieldOrder = []

    SQLGroupBy = ""
    #if the table to long, use it!
    SQLLimit = 0
    #Debug switch
    Debug = False

    MaxProcess = 2

    #private var
    __data = []
    __curItem = []
    __uniqNumber = 0
    __tableList = []
    
    __processPool = []   

    def __init__(self, conf):
        if self.__class__ == CoreSeek:
            raise NotImplementedError, "Cannot create object of class CoreSeek!"

        self.conf = conf
    
    def __del__(self):
        pass

    def __getattr__(self, key):
        if self.UniqId is None and 'id' == key:
            return self.__uniqNumber
        else:
            return self.__curItem[key]
    
    def __iter__(self):
        while self.NextDocument() :
            yield self.__curItem   
 
    def __str__(self):
        return str(self.__curItem)

    def GetScheme(self):  
        return self.Scheme

    def GetFieldOrder(self):
        return self.FieldOrder

    def Connected(self):
        tableList = DBConfig().getDBTableConfig(self.DBName)
        self.__tableList = Queue(len(tableList))
        for dConfig in tableList:
            self.__tableList.put(dConfig)

        self.__data = Queue()
        if (len(tableList) < self.MaxProcess):
            self.MaxProcess = len(tableList)

        for i in range (0, self.MaxProcess):
            process = Process(target=self.getTableData).run()
            self.__processPool.append(process)

    def NextDocument(self, err=None):
        if (  self.__data.empty() == False ):
            self.__curItem = self.__data.get()
            self.__uniqNumber += 1

            if (self.Debug):
                print self
            return True

        iProcessRuning = 0
        for process in self.__processPool:
            if process is not None and process.is_alive():
                iProcessRuning += 1 

        if (iProcessRuning > 0):
            return self.NextDocument()

        else:
            del self.__tableList
            del self.__data
            time.sleep(0.01)
            return False
    
    def getTableData(self):
        if (self.__tableList.empty() ):
            return False

        dConfig = self.__tableList.get()
        
        sSQL = self.getSQL(dConfig["tableName"])
        iCountPreLoad = self.SQLLimit
        iRecordLoaded = 0

        if (iCountPreLoad == 0):
            iRecordLoaded = self.doLoadData(dConfig, sSQL)

        else:
            iStep         = 0
            iRecordCount  = iCountPreLoad
               
            while (iCountPreLoad == iRecordCount):
                sLimit = " LIMIT " + str(iStep * iCountPreLoad ) + ", " + str(iCountPreLoad)
                sLimitSQL = sSQL + sLimit
                
                iRecordCount = self.doLoadData(dConfig, sLimitSQL)

                if (iRecordCount < iCountPreLoad):
                    break
                iRecordLoaded += iRecordCount
                
                iStep += 1

        self.getTableData()

        return True
   
    def doLoadData(self, dConfig, sSQL):

        tableNumber = int(dConfig["tableName"][-2:], 16)

        mysqlHandle = MySQLdb.connect(host=dConfig["host"], user=dConfig["user"],passwd=dConfig["passwd"], db=dConfig["dbName"], charset="UTF8")
        mysqlCursor = mysqlHandle.cursor()

        if (self.Debug):
            print "SQL: " + sSQL

        try:
            mysqlCursor.execute(sSQL)

            lResultList = mysqlCursor.fetchall()
            iRecordCount = len(lResultList)
        
        except:
            return 0
    
        for lRow in lResultList:
            dRow = self.getNamedDict(lRow)
            if self.UniqId is not None:
                dRow["tablerecord"] = [tableNumber, dRow[self.UniqId.lower()]]
                dRow["id"] = int (dRow[self.UniqId.lower()]) * 1000 + tableNumber

            dRow = self.buildIndex(dRow)

            self.__data.put(dRow)                   

        mysqlHandle.close()
        
        return iRecordCount
    
    def getSQL(self, sTableName):
        SQL = "SELECT %s FROM %s WHERE %s " % (", ".join(self.Field), sTableName, self.WhereCause)

        if(self.SQLGroupBy != ""):
            SQL += "GROUP BY %s " % self.SQLGroupBy
        return SQL

    def getNamedDict(self, lRow):
        i = 0
        result = {}
        for sFieldName in self.Field:
            sDictKey = sFieldName.lower()
            if (sDictKey.find(" as ") > 0):
                sDictKey = sDictKey[sDictKey.find(' as ')+4: ]

            if (isinstance(lRow[i], types.StringTypes)):
                result[sDictKey] = lRow[i].encode("utf-8")
            elif (type(lRow[i]) == type(datetime.datetime.today())):
                result[sDictKey] = int(time.mktime(lRow[i].timetuple()))
            else:
                result[sDictKey] = lRow[i]
            i+=1
        
        return result

    def buildIndex(self, *dRow):
        if(self.Debug):
            print dRow

        return dRow

class CoreSeekUtility:

    @staticmethod
    def literallyCut(string, sChar=" ", CharSet="utf-8"):

        uString = string.decode(CharSet)
        iLength = len(uString)
        if (iLength <= 1):
            return string

        lString = [uString[i:i+1] for i in range(0, iLength)]
        sCut = sChar.join(lString)

        return sCut.encode(CharSet)

    @staticmethod
    def dictIndex(dRecord):
        result = ""
        for key in dRecord:
            key = key.upper()
            value = dRecord[key]

            result += key + "=" + str(value) + " "

        return result

数据源示例：

from CoreSeek import CoreSeek, CoreSeekUtility
import time

class Topic(CoreSeek):
    Scheme = [
              ('id' , {'docid' : True ,} ),
              ('index', { 'type' : 'text',} ),
              ('index_uid', { 'type' : 'text',} ),

              ('topicid', { 'type' : 'integer'} ),
              ('type', { 'type' : 'integer'} ),
              ('privacy', { 'type' : 'integer'} ),
              ('body', { 'type' : 'string'} ),
              ('title', { 'type' : 'string'} ),
              ('uid', { 'type' : 'string'} ),
              ('description', { 'type' : 'string'} )
          ]

    FieldOrder = [('index', 'index_uid')]
    Field = ["topicId", "uid", "title", 'body', 'privacy', 'description', 'type']

    DBName = "Topic"

    def buildIndex(self, dRow):
        dRow['index_uid'] = dRow['uid']
        dRow['index'] = "%s %s" % (dRow['title'], dRow['description'])

        return dRow

class TopicDelta(Topic):
    WhereCause = "createTime > %s " % (time.time() - 3600)

if __name__ == "__main__":
    conf = {}
    source = Topic(conf)
    source.Connected()

    while source.NextDocument():
        print source

这些日子，IT界最为盛大的公关秀莫过于IBM的新一代超级计算机“华生（Watson）”对阵2位智力问答高手，最终计算机胜出。这不免让我想到了“深蓝”对阵卡斯帕罗的象棋赛。两场比赛有着诸多相似：同样的人机对战；同样是号称当时代最强的计算机；同样的“险胜”。当然也不排除IBM方面可能会让对决更加精彩或者更加戏剧化让人印象深刻有意进行了台下交易之类的黑幕。

我个人一直比较推崇IBM，IBM更接近于一个技术研发者，而Google也好Apple也好，更接近一个技术或者产品的推广者。IBM的研发动向可以说是行业的风向标。

15年前的那场象棋赛，尽管至今IBM也没有公布源代码，但根据当初官方宣称的说法是基于“穷举概率”。可以这样理解：“深蓝”在下第一步棋之前就会把棋盘上的所有可能都进行了一次例遍，统计出每一步棋导致最终的胜出概率，然后选择概率最高的那一步。如果这是真的，可以预见的是这绝对是海量的运算。按照当时的标准，台式机刚刚跨入100MHz，这种计算是不可想象的。
直到今天，如果换了我去考虑实现的话（尽管我根本一窍不通），我第一反应将会是分布式计算框架和Map Reduce，而且我相信如果今天有人需要重新实现这一课题时，首选的就是是分布式Map Reduce。选择这个框架的原因主要是考虑到并发的问题，IBM在15年前已经关注了这个方向的问题，尽管Map Reduce的概念是近几年才由Google提出的。可见IBM的先知先觉。

正如15年前一样，今天IBM到底要向我们展示什么技术上的革新呢？我的理解是“语义分析”，“自然语句合成”，“海量数据检索”这3个方面。如何让计算机“听懂”自然语音是这一个阶段有待突破的问题（注：当初还没有ip4s和Siri）。之前还看到过报道，亚马逊为了节约成本，将呼叫中心部署在菲律宾，通过当地廉价的劳动成本为欧美国家服务。从这个侧面可以反应出大型服务企业在应对人工语音服务的一种无奈。不去说远的，抛开识别语音不谈，哪怕是对自然语句的理，也是目前计算机行业的难题之一。解假设目前有这么一种机器人程序能够实现大部分淘宝店家的“阿里旺旺”的职守功能，只要出得起这个价钱的话，相信很快就会成为网店必备。此外还有对于同声传译的突破……种种的难题解答的可能性都能在这次智力问答中得到展示。

之前的比赛更多的是展现了IBM强悍的机能，今天的比赛展示更多的则是在此强悍机能之上强大的软件能力。与其说是2场比赛，不如说是一场比赛，只是中场休息了太长时间，在此期间，我们经历了M到G级别的硬件更新，经历了互联网的崛起，经历了Window3到windows7……但终究还是面临了这样一个问题：“我们有了如此强悍的硬件之后，到底该如何驾驭？难道只是为了测评软件的得分去买硬件吗？”IBM已经用下半场的比赛回答了我们：“No！还有更多的难题需要我们去升级硬件。”

我很期待下一个15年的比赛！

之前从事的行业以企业管理和电子商务系统为主，这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项，特别是企业信息化管理系统和电子商务中的帐务结算子系统，这类系统对于数据的原子性和一致性的要求近乎苛刻，根据CAP原则，只能放弃性能作为代价。后来辗转到互联网行业，特别是SNS的开发和运维中，很多思维模式必须要打破。SNS，特别是Feed部分的数据结构，绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付，即便实现成功，也始终无法摆脱“硬撑”的嫌疑。

之前使用过Memcache，并曾经很长一段时间把Key-Value和Memcache等价起来，认为K-V数据库就是一个缓存工具而已。只不过是把DB中的热数据临时保存的解决方案。当出现了更为强大的Redis之后，No-SQL也从Key-value，演化到了Key-list, Key-Hash，Key-set，并支持数据的持久化，其实直道现在我仍然认为它还是中规中矩的Key-Value，只不过对应了json数据结构中的三种括号而已。

在以前用DB的时候，经常会出现很多慢查询，到头来只是因为没有及时更新索引而已。对于很多企业而言，开发和运维是两个团队，尽管Facebook提出了DevOps这种“快速运维”的管理模式，但真正实施上，往往由于侧重点的不同，加上“快速迭代”的产品策略，运维团队，特别是DBA很难第一时间跟进开发团队的步伐调整索引或者数据结构；开发团队也很难在开发中发觉DB瓶颈，从而进行设计变动。这样势必需要在DB操作上进行限制，这样一方面有利于性能上进行优化，同时也会减低数据结构的复杂性。

我的想法是通过底层封装，限制数据库的直接访问，通过类似Key-value的访问数据获取模式进行数据操作，直接忽略底层的数据结构。开发人员无须关注数据的物理存贮位置和存储结构，这样整个系统将成为K-V主导。配合Json化的数据结构可以直接实现很多DB Like的操作。

对于文本匹配的问题，由于MySQL之类的DB本身也支持的很弱，直接通过CoreSeek之类的全文搜索引擎实现。目的是“合适的工具做合适的事情”。让DB去做更加擅长的事物关系处理。

通过这样的改造，整个系统将成为一个No-SQL的数据结构，这样带来的性能提升绝对不是一点点，或者说这样的数据规划本身就是“并发优化”的。 带来的问题最主要的就是一致性问题，但仅过实际经验来说，只要处置得当，一致性问题绝对是“可接受的”。当然，中间可以用Mongo这类的骑墙产品过渡，但我个人的观点是：Mongo的存在是为了替代简单逻辑中MySQL的地位，而不是仅仅用来作为适应性过渡，因为这玩艺是No-SQL的，对大多数人来说用起来却比SQL还复杂。

记得在PHP开发过程中，经常会用到实例级别或者线程级别的变量缓存，带来的性能提升是巨大的。但对于tornado来说，由于每次访问都会实例化tornado.web.RequestHandler，不能满足要求，只能考虑在主线程上进行变量缓存。一旦成功将有可能直接抛弃redis。

种种原因，不公开最终实现的代码，这里只用一个页面计数器来模拟。通过一个页面http://localhost/get获得主页http://localhost/的Page View。

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.httpclient
import tornado.web
import sys, os
from tornado.options import define, options

#####
class PageCounter(object):
    count = 0
####

#PageCounter = 0 这种采用全局变量的方法被证实无法实现。

class MainPage(tornado.web.RequestHandler):

    def get(self):
        PageCounter.count += 1
        self.finish('Hello World!')

class GetPageView(tornado.web.RequestHandler):
    def get(self):
        sPageView = str(PageCounter.count)
        self.write(sPageView)

def main(port):
    if os.fork() != 0:
        exit()
    define("port", default=port, help="run on the given port", type=int)
    application = tornado.web.Application([
        ("/", MainPage),
        ("/get", GetPageView),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":

    if len (sys.argv) > 1:
        port = sys.argv[1]
    else:
        port = 80
    main(port)

这里要说的是object基类的PageCounter方法，可以定义一种数据结构以及对应的操作方法。当然这段代码只是Demo，写得不规范。由于PageCount是全局的，跟随进程实例化，所以可以很灵活在各个实例之间传递数据。

类似这种方法，我们的项目性能提升了至少5倍。但这样实现的结果也非常明显，首先不能持久化，一旦进程终止，数据就被清空；其次是进程隔离，这种方法共享数据只能工作在tornado的一个进程中，对于习惯于多进程并行的Tornado部署会有问题，我们最终的做法是做唯一哈希；最后要注意的是内存释放的问题，数据保存在内存中，如果是大量的数据通过dict/list做映射的话需要进行定期清理，当然通过这种方法可以变态的做一个基于HTTP协议的Key-value数据库。

# ab -n10000 -c1000 http://localhost/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: TornadoServer/2.1.1
Server Hostname: localhost
Server Port: 80

Document Path: /
Document Length: 12 bytes

Concurrency Level: 1000
Time taken for tests: 8.921 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1700000 bytes
HTML transferred: 120000 bytes
Requests per second: 1120.89 [#/sec] (mean)
Time per request: 892.148 [ms] (mean)
Time per request: 0.892 [ms] (mean, across all concurrent requests)
Transfer rate: 186.09 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 230 792.8 0 3012
Processing: 14 134 73.9 114 1878
Waiting: 14 134 73.9 114 1878
Total: 86 364 815.1 114 3818

Percentage of the requests served within a certain time (ms)
50% 114
66% 115
75% 121
80% 141
90% 378
95% 3135
98% 3176
99% 3223
100% 3818 (longest request)

从小站一开始就在思索如何与用户互动，评论自然是一个好的方式。但访问本站的朋友大多数是在处理问题时通过搜索引擎进来的，看一眼就走人，可谓是“来也匆匆，去也匆匆”自然不会有评论。即便是文章中的错误，除了背后骂娘之外也不会有其他的动作。当然也有很多的评论，几乎占了90%以上，无非还停留在某某论坛的抢积分逻辑上。“顶”，“路过”等等没什么营养的回复我会直接归结为垃圾评论。

作为ITer，我本身非常热衷于新事物，微博这类的新媒体我也用了一段时间。当然09年前以Twitter为主，众所周知的原因，不能成为主流。后来用了Google buzz，最大的优点在于可以直接与Google Reader中的feed订阅同步。可惜google自己终止了它。最终只能回归到GFW内的本地克隆。抵制腾讯的我选择了新浪微博。

@开源微站 敬请关注！

再此之前，还是先确认系统的CPU是否支持虚拟化：
#egrep ‘(vmx|svm)’ /proc/cpuinfo

应该有返回，如果没有返回，且确认您的CPU支持虚拟化的话，建议去看看BIOS设置，大多数的主板都支持关闭此技术的。

还是以最常用的Ubuntu Server 做例子，desktop的可以直接apt-get install ubuntu-server之后，用server的核心启动。如果你全程参考本文，个人建议还是通过后一种方式来做，因为本文的过程需要X环境。

首先，设置好桥接，由于我使用的机器在远程，操作全部通过ssh，桥接的过程断开过网络。让机房重起数次之后，找到了最稳妥的方法，虽然也要断网，但好在会自己恢复。

#sudo apt-get install bridge-utils uml-utilities

#vi /etc/network/intefaces

auto lo
iface lo inet loopback

auto tap0
iface tap0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user root

auto br0
iface br0 inet static
bridge_ports eth0 tap0
address 192.168.1.3
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254

注意这个br0，我通过前端防火墙做的DMZ通道，所以设置了内网地址。主机通过这个ip访问。所有的虚拟主机也直接设置到192.168.1.0/24网段。

#/etc/init.d/network restart

断网了，等待几分钟后网络恢复，直接ifconfig

br0       Link encap:Ethernet  HWaddr 02:0b:b1:f7:79:01
inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::b:b1ff:fef7:7901/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:506941 errors:0 dropped:0 overruns:0 frame:0
TX packets:733910 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45469237 (45.4 MB)  TX bytes:654152049 (654.1 MB)

eth0      Link encap:Ethernet  HWaddr e4:1f:13:95:82:cf
inet6 addr: fe80::e61f:13ff:fe95:82cf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:1367878 errors:0 dropped:0 overruns:0 frame:0
TX packets:1541493 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:689206805 (689.2 MB)  TX bytes:1062795975 (1.0 GB)
Memory:81a80000-81aa0000

eth0:0    Link encap:Ethernet  HWaddr e4:1f:13:95:82:cf
inet addr:192.168.1.2  Bcast:0.0.0.0  Mask:0.0.0.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Memory:81a80000-81aa0000

桥接成功！

相对来说，我还是比较喜欢图形化的管理工具，命令行实在太痛苦

#apt-get install virt-manager libvirtd kvm libvirt-bin

看看是否安装成功

# ls /dev | grep kvm

直接用ssh通道执行gnome-session就可以连到远程桌面，执行系统工具里的“虚拟系统管理器”。添加连接中选择本地，QEMU/KVM。

然后建立新的虚拟主机，个人觉得这块跟用VM之类的工具没有什么区别了，直接跳过了。不过在第五步的时候，请将网卡设置为桥接设备，除非仅仅用于NAT方式联网。

需要注意的是，如果你跟我一样通过远程连接，直接打开主机的控制台的时候，键盘会不听使唤。这不是切换键盘设置可以搞定的问题，我尝试过不同的X客户端和操作系统，涵盖了windows mac linux，全都如此。只能认为是一个bug。我的最终解决方法是通过ssh通道，将远程主机的5900 VNC端口转接回本地，然后再通过vnc客户端连接本地才得以通过，键盘的问题得以解决。很傻，如果你有更好的方式，敬请赐教了！

照旧建立一个虚拟主机，我还是选择了Ubuntu Server 1110 64bit，也没有什么好说的。安装好之后，配置好了ssh。从此就可以直接抛弃vnc和宿主主机的X访问了。

在虚拟主机上安装定制的内核:

#apt-get install kernel-virtual

重起的速度那是嗖嗖的！直接lsmod发觉真的是定制内核，和标准的server内核比起来一点多余的没有：

root@www:~# lsmod
Module                  Size  Used by
psmouse                73882  0
serio_raw              13166  0
lp                     17799  0
parport                46562  1 lp
8139too                32177  0
8139cp                 27412  0

对比一下性能吧，还是那道题目的python原版，稍作优化：

虚拟机：

root@www:/home/litrin# python TimeCost.py
10240
Cost: 0.508388996124
root@www:/home/litrin# python TimeCost.py
10240
Cost: 0.507208108902
root@www:/home/litrin#

宿主机：

root@vserver:~# python TimeCost.py
10240
Cost: 4.35039806366
root@vserver:~# python TimeCost.py
10240
Cost: 4.35194683075

我开始真的不知道该如何解释。虚拟机的性能竟然强于宿主机。后来检查了python的版本才明白，宿主是py2.6而客户机是2.7，版本不同，性能有差距，但可以肯定的是，从这一点上来说虚拟化的性能损失不大。

最后一步，去掉虚拟机上不需要的东西，精简主义者！

这次就直接用宿主的命令行操作吧：

#virsh

virsh # list
Id Name                 State
———————————-
30 www.litrin.net       running //我的虚拟主机名为www.litrin.net，请注意！

virsh # edit www.litrin.net

删掉vnc, pty, mouse, graphic

virsh # destroy www.litrin.net

virsh # start www.litrin.net

这里有一个问题也凸现，就是无法使用宿主机的reboot和halt命令，只能强行的destroy。

你同时还可以配合DHCP和主机克隆，大规模快速甚至自动化的架设多个虚拟机，本文不再探讨。

尽管现在“云”已经被用滥了，搞个虚拟机就敢号称云托管的大有人在。个人觉得其实对于少数几台主机的虚拟化来说，更多的是节约机房的托管费用和主机成本，这对于稍微大一点的项目并没有什么太多的优势。如果配合上open stack之类的故障平滑迁移技术才是虚拟化方案的终极利器。

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

一直把Python当成胶水语言来用，这次就接着这个话题，说个Python C重构的例子：

首先是python原码：(很眼熟吗？)

#!/usr/bin/env python

import time

lGoal = {}

def main(i):
#    if lGoal.has_key(i):
#        return lGoal[i]

    if i < 1:
        return long (0)
    elif i < 2:
        return long(1)
    return main(i-1) + main(i-2) - main(i-5)

def getList(iMax):
    for i in range(1, iMax+1):
        iGoal = main(i)
        lGoal[i] = iGoal

    return lGoal

#i = int(raw_input())
i = 30
timeStart = time.time()
getList(i)

print "Cost: %s" % (time.time() - timeStart)

看看它的耗时：
Cost: 21.9739699364

首先对于这种多重循环和调用，绝对是C的强项，理论上Python 2 C 之后会有很大的提升空间。重构的思路是用Python的ctypes模块调用基于C的lib库，这样可以在保留大部分Python代码的基础上完成重构，而且重构之后的程序仍然还是Python的。
开始C重构vi LoadTest.c：

#include <stdio.h>
/*
int main()
{
    int i, goal;
    for (i=1; i <= 30; i++)
    {
        goal = C_Time_Cost(i);
        printf ("%d, %d \n", i, goal);

    }

   return 0;
}
*/
int C_Time_Cost(int a)
{
    if (a < 1)
    {
        return 0;
    }
    if (a < 2 )
    {
        return 1;
    }

    return C_Time_Cost( a - 1 ) + C_Time_Cost( a - 2 ) - C_Time_Cost( a - 5 ) ;
}

编译到.o文件：
gcc -c LoadTest.c -fPIC

编译成为Lib
gcc –shared -o libLoadTest.so LoadTest.o
cp libLoadTest.so /lib64 && ldconfig //这一点很重要，否则会报找不到lib文件。

修改python:

#!/usr/bin/env python

import time
from ctypes import *
lGoal = {}

def main(i):
    cdll.LoadLibrary("libLoadTest.so")
    libc = CDLL("libLoadTest.so")
    goal = libc.C_Time_Cost(c_int(i))
    return goal

def getList(iMax):
    for i in range(1, iMax+1):
        iGoal = main(i)
        lGoal[i] = iGoal

    return lGoal

#i = int(raw_input())
i = 30
timeStart = time.time()
getList(i)

print "Cost: %s" % (time.time() - timeStart)

执行时间：
Cost: 0.280420064926

对比之前的21.9739699364 性能提升78倍！不过需要注意，ctypes模块的加载本身很耗资源，使用不当会起到反效果，例如将i=30改为i=10的情况下，python: 0.000591039657593，而Ctypes则需要0.00165605545044，反而落后3倍的时间。

正常情况下，像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能够出现真正意义上表空间的概念，更加自由的规划数据文件。