目前的NOSQL主要分为两种，一种是基于内存型的如redis、memcached，一种是基于磁盘型的如Tokyo Tyrant、Tokyo Cabinet、Berkeley DB。
redis、memcached这类内存型NOSQL。虽然读写效率很高，但是有一个大问题，就是数据库持久性。memcached是一重启进程数据就没了。redis支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是Append-only file（缩写aof）的方式。但是这两种效率都不高。 怎样才能做到高效读写，又能保持数据持久性了?
quickdb 是一款基于内存文件系统的 HashTable数据结构的Key-Value数据引擎. . 什么是内存文件系统了？就是操作系统把系统内存划出一部分当作硬盘使用。你可以像操作磁盘那样的操作内存。但效率远远比硬盘来的快多了。通俗叫做内存文件系统，只要服务器不重起数据将一直都在。
通俗的来讲 redis、memcached是自己申请内存管理数据。当进程重启或者挂了就会丢失数据。quickdb是把实体数据储存在内存文件系统里的。当quickdb进程挂了， 实体数据依然还在。 一个进程可能因为各种原因比如修改了配置文件或者要调试数据。要经常重启。但是一个服务器不可能三天两天的重启或者死机。 一般服务器都是半年，或者 好几年都不重起的。 如果你的服务器经常断电或者死机重启那就不叫服务器了。叫家用电脑了。嘿嘿 为了起见,quickdb可以定期的从内存文件系统的数据同步到磁盘中去。这样当服务器重启，也不会丢失数据。 简单的来讲，进程可能会经常因为各种原因要重启或者挂了，但是服务器不可能经常重启或者死机。这样很大程度上保证了数据持久性，也保证了读写效率。做到鱼和熊掌
Non-blocking的中文意思是非堵塞的意思。
现实多数的架构都是blocking的，比如PHP/FastCGI, 即便nginx的前端再好，后端的应用
依然是瓶颈。
所以，如何使用Event/IO实现non-blocking编程，是我们要关注的一个领域。
Ruby的EventMachine, Python的Twisted, Perl的AnyEvent都是不错的开始。
Node.js则是另一个选择。 Javascript似乎是天生的适合作Event/IO的编程语言。 上手轻松，简单。
对于我们来说，最困难的是开始，如何适应新的基于callback的处理模式，这是最大的挑战。
不知不觉又差不多到年底, 闲着无聊简单的总结了下今年的技术。 今年主要工作精力放在公司网站修改和CMS重构。
目前CMS种类大致可分为两种，一种是通用CMS，还有一种是根据自身需求开发的私有CMS。 通用CMS比如dedecms、phpcms等CMS开源项目，适合技术实力不强的中小企业使用。 私有CMS，则结合自身需求，还定制开发的CMS,往往性能比通用型CMS要高。
开源通用型的CMS,虽然功能很强大，但是也有一些致命的缺点
1. 静态页面管理. 当文章数据达到 百万级别的时候，生成静态页面的速度不仅慢，而且加重磁盘IO负载。容易让硬盘坏
2. 不能实现页面片段缓存。 一般页面都会有几个公共片段，比如header和footer。 一般要更新公共片段的数据的时候，都会要全部生成静态页面。才能更新。
3. 支持多站点的CMS，还需要配置FTP，利用FTP把静态页面发布到前端服务器上。这么做麻烦。
一般大型门户网站的CMS，都是靠CDN来加速的。 所以我设计的这款CMS架构是基于CDN模式来设计的，姑且把这款CMS叫做CDN-CMS。
先看一下服务器的架构图
粗看这个服务器架构图很常见，没什么大不了。这个得结合CMS来看，就是另外一种感觉了。
先简单的说一下这个访问流程, 用户首先访问智能DNS SERVER。然后再由DNS把域名解析到相应的单线线路的
1，老鼠嘲笑猫的时候，身旁必有一个洞。
2，站在山顶和站在山脚下的两人，虽然地位不同，但在对方眼里，同样的渺小。
3，路的尽头，仍然是路，只要你愿意走。
4，使我们不快乐的，都是一些芝麻小事，我们可以躲闪一头大象，却躲不开一只苍蝇。
5，最好的与最坏的创造了历史，平庸之辈则繁衍了种族。
6，在这世上惟一件事比别人议论更糟，那就是无人议论你。
7，成功便是站起比倒下多一次。
RedBridge 是一款基于redis 的 HTTP API。 使用LUA 直接跟redis 交互。(类似数据库的存储过程) 高效的实现复杂的业务逻辑。
项目网址：http://code.google.com/p/redbridge/
使用环境：Linux 2.6
软件作者：七夜(李锦星)
RedBridge 具有以下特征：
1. 使用C+epoll 编写的Web Server,支持HTTP GET操作
2. 连接池,连接句柄复用，提高跟redis连接效率
3. 部分类库使用Redis的代码,更加的稳定
4. 使用LUA直接调用Redis命令，实现一次性数据交互实现 复杂的业务逻辑。不需要多次数据交互
5. 服务模型采用单进程，双线程模式
6. 配置文件采用Lua 语法, 容易读取和书写
7. RedBridge发布前，还没有类似的开源项目
cjson for php extension 是修改的PHP自带的JSON ext。php自带的ext只支持UTF-8格式。我在原来的基础修改了一下。增加支持非UTF-8编码的JSON编解码。 包括 GBK、BIG5， 不乱码。
下载地址: 去google code 下载
使用例子:
$str = '{"name":"李锦星","age":25}';
$data = array("name"=>"李锦星", "age"=>25);
echo cjson_encode($data);
print_r(cjson_decode($str, false));
前几个月去了新公司一直忙着公司改版的事宜,抽不出时间更新BLOG内容。为了回报大家的期待。今儿再推出个自己的开源大餐给大家。
话说公司的广告发布系统，效率慢功能又弱。所以打算重构一个广告发布系统。
前台广告投放采用 C + Redis + LUA
后台广告录入采用 PHP + MySQL
架构好了，就开始写了。本来可以写nginx module 和redis 交互来实现广告投放。但是本人爱折腾，还是喜欢自己写server端。 所以直接把 redis 的 event 和 network的代码给剥离出一个独立的高性能服务端。 事件驱动单线程。 文章的后面将提供我剥离出的项目代码。基本是redis 原生代码， 有些我自己加以改进。定时器，我还没加上，下个版本加上。 感觉redis的代码虽然没有nginx 那么的精美，但也够用了。
想深入Redis Event Library 请阅读官方的文章
Redis Event Library http://redis.io/topics/internals-rediseventlib
中文翻译版本 http://blog.ddup.us/?p=114
第一课
一个男人在他妻子洗完澡后准备进浴室洗澡。这时，门铃响了。
妻子迅速用浴巾裹住自己冲到门口。
当她打开门时，邻居鲍勃站在那儿。
在她开口前，鲍勃说，“你如果把浴巾拿掉，我给你800美元。”
想了一会儿，这个女人拿掉浴巾赤裸地站在鲍勃面前。几秒钟后，鲍勃递给她800美元然后离开了。
女人重新裹好浴巾回到屋里。
当她踏进浴室时，丈夫问她，“是谁呀？”
“是邻居鲍勃。”她回答。
“哦，”丈夫说，“他有没有提到还欠我800美元？”
故事寓意：
及时与同舟共济的股东分享重要信息，将会避免不必要的曝光。
第二课
一个销售员、一个办事员和他们的经理步行去午餐时发现了一盏古代油灯。
他们摩擦油灯，一个精灵跳了出来。
精灵说：“我能满足你们每人一个愿望。”
“我先！我先！”办事员说，“我想去巴哈马群岛，开着快艇，与世隔绝。”
倏！她飞走了。
“该我了！该我了！”销售员说，“我想去夏威夷，躺在沙滩上，有私人女按摩师，免费续杯的冰镇果汁朗姆酒，还有一生中的最爱。”
倏！他飞走了。
“OK, 该你了。”精灵对经理说。
经理回答：“我要那两个蠢货午饭后马上回来工作！”
故事寓意：
永远让你的老板开口先。
自从PHP问世以来,以其简单的语法丰富的函数和扩展风靡WEB开发界。但是其简单的功能也是PHP致命点。现在的高访问量高并发量使单机PHP项目无法承受了。所以也出现各种各样的分布式存储。今儿咱讲讲怎么构建一个高效的无单点故障的分布式session服务。 咱可不是标题党，内容和标题绝对吻合。
现在PHP项目分布式session 一般都是 memcached+ client consistent hash。这个解决方案优点是简单。缺点也是N多的。 具体的缺点，可参见 Timyang的 文章
http://timyang.net/architecture/consistent-hashing-practice/
现在咱来说说咱的分布式session 架构,上面这个图这个架构的示意图, 下面是该架构重要的三个部分的说明.
1. 为Web Server集群。 每台机器由Nginx+PHP+eAccelerator组成
nginx 和PHP 是什么我就不多说了。
eAccelerator 是本session架构的点睛之处, eAccelerator不仅是个opcode缓存器.也提供基于共享内存的key-value的存储。共享内存方式的数据存取比socket的 memcached 快多了。 在这里eAccelerator作为 远程session服务的一个本地缓存区。大量减少直接从 session 集群读取数据的压力
2. session proxy
session proxy是基于linux + C + epoll实现的session代理服务器，具有连接池和后端服务器健康监控等功能。 session data 采用我自己研究的session hash法分布数据。 session hash是扩展于传统的 hash() mod n的方式。hash() mod n优点是直接定位快。缺点就是增减服务器的时候，产生的灾难性的数据变动。
session hash 还是采用最快的"hash() mod n"的方式来快速进行数据分布。 但是服务器动态增减或者服务器故障采用新的处理方式。 下面具体讲解一下以上这些情况怎么解决。
服务器故障：比如 有 A、B、C三台session服务器。C 服务器挂了。 就会根据A、B服务器的权重选出一台服务器，充当C服务器。还是组成虚拟的三台服务器(就是无论几台服务器挂了。逻辑上都还有三台服务器的)。 然后由session proxy告知PHP 应用按需重建session数据。 因为前端的eAccelerator已经挡住大多数的session数据请求。所以这个session data 重建并不会带来太大的session集群震荡
服务器的动态增减：这个情景是容易碰到的事情。在这里引用了个动态cursor和timeout的概念。动态游标简单的来说就是我原先有三台服务器,现在加两台服务器。那就是五台服务器了。 我取session数据的时候。先"hash mod 3",取不到数据，我再"hash mod 5"的方式去读取。 看到这里有人就会说了。你这样一次操作得读取两次效率不行啊。所以timeout的概念出现了。因为session 数据是暂时的。比如我登录一个论坛，我看几个帖子觉的没意思。我就把浏览器关了。这样就代表着一个session数据销毁。所以说我们设置个20分钟的timeout。在这20分钟内都是使用两次mod的方式去读取。超过20分钟的session data。就要对该session data进行重建(使用"hash mod 5"的方式服务器定位)。而且只mod 一次读取。
3. session data store
session data store实际上是采用redis来当session 数据存储。
总结
刚才也说过eAccelerator 是本session架构的点睛之处.确实也是,eAccelerator 的session缓存已经承担了相当一部分的session数据访问。所以当后端session挂了话。也能够快速的按需重建session数据。还有一个点睛之处就是优化的hash算法。在传统的"Hash mod n"基础上, 引用了虚拟服务器和动态cursor的概念。研究出适合分布式session服务器的一种高效hash分布算法,实际上session proxy没有session位置存储，所以session proxy可以是多台。此文的不成熟之处，望请大家多多提出来，我好改正。谢谢大家
最近在一些PHP群里经常能看到PHP被黑的消息。一直以为是某些人开的玩笑，没放在心上。
刚才按照惯例打开 http://cn2.php.net/sqlite3 再打开连接,出现不可思议情况, 所有链接跳到7xxx.com网站上.把 网址发给 "PHP高级群的兄弟"，大家都点开链接，都跳到 7xxx.com网站上. 为了安全起见, 大家最近下php源码包等一些软件，还是选择国外的镜像站吧。
一直想要个自己的BLOG,到今天这个多年的愿望终于实现了。开这个BLOG主要和各位兄弟交流一下技术。欢迎各位兄弟来踢馆,嘿嘿。我的MAIL: lijinxing#Gmail.com PHP高级研究QQ群: 62116204