轻量级开源简单队列服务 HTTPSQS 1.6 版本发布
[
2011-4-21 18:12 | by 张宴 ]
2011-4-21 18:12 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2011.04.21 转载请注明原文链接：http://blog.zyan.cc/httpsqs_1_6/]
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过800行，适合二次开发。
HTTPSQS 1.6 版本更新内容：
一、服务器端：
1、修正了定时将内存缓冲区内容同步到磁盘，有时候出现段错误，导致进程崩溃的BUG。感谢以下网友的反馈：
2、修正了判断队列已满，遗漏的一种情况。感谢以下网友的反馈：
3、改为父子进程模式，生产环境稳定性更高。
4、改进了 ps 命令查看 httpsqs 的用户体验：
5、增加了密码校验功能（通过以下启动参数设置密码，通过URL参数“/?auth=密码”访问）：
6、改为静态编译，编译完成后的 HTTPSQS 二进制文件，运行不再依赖 Libevent、Tokyocabinet 动态链接库。
7、HTTPSQS 旧版本如何升级到 HTTPSQS 1.6 版本：
HTTPSQS 1.6 版本完全兼容以前版本：编译安装 HTTPSQS 1.6，替换旧的 HTTPSQS，然后“kill httpsqs的进程ID”，按原来的启动参数启动 HTTPSQS 即可，数据完全兼容。
二、客户端：
1、客户端代码不再集成在 HTTPSQS 源码包中，可通过链接自行查看。
HTTPSQS 1.6 版本的详细使用说明，请访问： http://blog.zyan.cc/httpsqs/
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过800行，适合二次开发。
HTTPSQS 1.6 版本更新内容：
一、服务器端：
1、修正了定时将内存缓冲区内容同步到磁盘，有时候出现段错误，导致进程崩溃的BUG。感谢以下网友的反馈：
2、修正了判断队列已满，遗漏的一种情况。感谢以下网友的反馈：
3、改为父子进程模式，生产环境稳定性更高。
4、改进了 ps 命令查看 httpsqs 的用户体验：
5、增加了密码校验功能（通过以下启动参数设置密码，通过URL参数“/?auth=密码”访问）：
6、改为静态编译，编译完成后的 HTTPSQS 二进制文件，运行不再依赖 Libevent、Tokyocabinet 动态链接库。
7、HTTPSQS 旧版本如何升级到 HTTPSQS 1.6 版本：
HTTPSQS 1.6 版本完全兼容以前版本：编译安装 HTTPSQS 1.6，替换旧的 HTTPSQS，然后“kill httpsqs的进程ID”，按原来的启动参数启动 HTTPSQS 即可，数据完全兼容。
二、客户端：
1、客户端代码不再集成在 HTTPSQS 源码包中，可通过链接自行查看。
HTTPSQS 1.6 版本的详细使用说明，请访问： http://blog.zyan.cc/httpsqs/
Tokyo Cabinet Key-Value数据库及其扩展应用PPT[原创]
[ 2010-4-3 00:12 | by 张宴 ]
2010-4-3 00:12 | by 张宴 ]
以下是我4月2日在“2010年数据库技术大会”的演讲PPT，介绍了 Tokyo Cabinet Key-Value 数据库的性能优化关键参数，以及金山逍遥网在Tokyo Cabinet基础上实现的TCSQL实时列表缓存数据库(Version 1.3)。
PDF格式下载：
下载文件
PDF格式下载：
下载文件
轻量级开源简单队列服务 HTTPSQS 1.2 版本发布[原创]
[ 2010-3-18 23:11 | by 张宴 ]
2010-3-18 23:11 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2010.03.18 转载请注明原文链接：http://blog.zyan.cc/httpsqs_1_2/]
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过700行，适合二次开发。
HTTPSQS 1.2 版本增加的功能：
1、服务器端：
● PUT入队列、GET出时，1.2版本在Header头增加了一行Pos，输出当前队列“写入点”或“读取点”。假设从队列取出一条消息，这条消息的队列读取点Pos为7，将这条消息插入数据库失败了，那么，就可以在失败Pos日志文件中记录这个队列点。过段时间后，只要该Pos点的数据未被覆盖，通过“http://127.0.0.1:1218/?charset=utf-8&name=your_queue_name&opt=view&pos=7”则可以再次取出该条消息，做失败原因分析或进一步处理。
● PUT入队列时，如果“队列写入点”追上“队列读取点”，会返回“HTTPSQS_PUT_END”，提示队列已满，而不是像1.1版本那样直接覆盖未读数据。
2、客户端：
● 增加了Perl版本的客户端。感谢网友tonny0830为HTTPSQS开发了Perl客户端。
● PHP客户端Class增加了函数$httpsqs->gets($host, $port, $charset, $name)、$httpsqs->pgets($host, $port, $charset, $name)，详细使用说明请见：http://blog.zyan.cc/httpsqs/
HTTPSQS 1.1 版本如何升级到 HTTPSQS 1.2 版本：
●服务器端版本完全兼容：编译安装 HTTPSQS 1.2，替换 HTTPSQS 1.1，然后“kill httpsqs的进程ID”，按原来的启动参数启动 HTTPSQS 即可，数据完全兼容。
●客户端版本完全兼容：HTTPSQS 1.1 版本的PHP客户端，仍可以直接操作 HTTPSQS 1.2。两个版本的PHP客户端函数使用方式、参数相同，1.2 版本的PHP客户端与 1.1 版本相比，增加了gets()和pgets()函数，用于从一个队列中取出文本信息和当前队列读取点Pos。
HTTPSQS 1.2 的生产环境典型应用案例架构：
HTTPSQS 1.2 版本的详细使用说明，请访问：http://blog.zyan.cc/httpsqs/
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过700行，适合二次开发。
HTTPSQS 1.2 版本增加的功能：
1、服务器端：
● PUT入队列、GET出时，1.2版本在Header头增加了一行Pos，输出当前队列“写入点”或“读取点”。假设从队列取出一条消息，这条消息的队列读取点Pos为7，将这条消息插入数据库失败了，那么，就可以在失败Pos日志文件中记录这个队列点。过段时间后，只要该Pos点的数据未被覆盖，通过“http://127.0.0.1:1218/?charset=utf-8&name=your_queue_name&opt=view&pos=7”则可以再次取出该条消息，做失败原因分析或进一步处理。
● PUT入队列时，如果“队列写入点”追上“队列读取点”，会返回“HTTPSQS_PUT_END”，提示队列已满，而不是像1.1版本那样直接覆盖未读数据。
2、客户端：
● 增加了Perl版本的客户端。感谢网友tonny0830为HTTPSQS开发了Perl客户端。
● PHP客户端Class增加了函数$httpsqs->gets($host, $port, $charset, $name)、$httpsqs->pgets($host, $port, $charset, $name)，详细使用说明请见：http://blog.zyan.cc/httpsqs/
HTTPSQS 1.1 版本如何升级到 HTTPSQS 1.2 版本：
●服务器端版本完全兼容：编译安装 HTTPSQS 1.2，替换 HTTPSQS 1.1，然后“kill httpsqs的进程ID”，按原来的启动参数启动 HTTPSQS 即可，数据完全兼容。
●客户端版本完全兼容：HTTPSQS 1.1 版本的PHP客户端，仍可以直接操作 HTTPSQS 1.2。两个版本的PHP客户端函数使用方式、参数相同，1.2 版本的PHP客户端与 1.1 版本相比，增加了gets()和pgets()函数，用于从一个队列中取出文本信息和当前队列读取点Pos。
HTTPSQS 1.2 的生产环境典型应用案例架构：
HTTPSQS 1.2 版本的详细使用说明，请访问：http://blog.zyan.cc/httpsqs/
基于HTTP协议的轻量级开源简单队列服务：HTTPSQS[原创]
[ 2009-12-30 07:01 | by 张宴 ]
2009-12-30 07:01 | by 张宴 ]
[文章作者：张宴 本文版本：v1.7.1 最后修改：2011.11.04 转载请注明原文链接：http://blog.zyan.cc/httpsqs/]
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过800行，适合二次开发。
1、HTTPSQS 1.7 压力测试：
采用Apache ab命令进行压力测试，开启10个线程，放入10万条文本数据（每条512字节）到队列中:
使用HTTP Keep-Alive时：23018 requests/sec
关闭HTTP Keep-Alive时：11840 requests/sec
采用Apache ab命令进行压力测试，开启10个线程，从队列中取出10万条文本数据（每条512字节）:
使用HTTP Keep-Alive时：25982 requests/sec
关闭HTTP Keep-Alive时：13294 requests/sec
详细测试内容：http://code.google.com/p/httpsqs/wiki/BenchmarkTest
生产环境应用：在金山游戏官网中，新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容实时写入HTTPSQS队列，全站搜索引擎增量索引准实时（1分钟内）更新的数据源取自HTTPSQS。HTTPSQS 2009年12月18日上线至今，运行稳定，既有来自Web服务器的入队列操作，也有来自命令行脚本的批量入、出队列操作。
2、HTTPSQS 的生产环境应用：
●金山通行证（https://my.xoyo.com）
队列应用类型：手机短信上行、手机短信下发、邮件下发
队列应用要求：稳定性高，存储数据量大
队列部署结构：一主、一备两台 HTTPSQS 热备模式
●金山用户行为分析系统（http://kbi.xoyo.com）
队列应用类型：用户鼠标点击、访问URL原始数据采集
队列应用要求：并发性能高，存储数据量大
队列部署结构：多台 HTTPSQS 应用层哈希分布式模式
●金山网络游戏运营平台 KingEyes
队列应用类型：用户操作日志记录
●金山逍遥网站内搜索
队列应用类型：索引准实时更新。在金山游戏官网中，新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容实时写入HTTPSQS队列，全站搜索引擎增量索引准实时（1分钟内）更新的数据源取自HTTPSQS。
●金山逍遥网全站通用评论系统
队列应用类型：评论发表
●金山《剑侠情缘》电视连续剧四大角色人物选秀活动（http://zt.xoyo.com/haixuan/）
队列应用类型：用户上传的照片异步裁剪、缩放处理
●新浪邮箱（http://mail.sina.com.cn）
队列应用类型：用户登陆日志记录
3、HTTPSQS 编译安装：
HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级开源简单消息队列服务，使用 Tokyo Cabinet 的 B+Tree Key/Value 数据库来做数据的持久化存储。
项目网址：http://code.google.com/p/httpsqs/
使用文档：http://blog.zyan.cc/httpsqs/
使用环境：Linux（同时支持32位、64位操作系统，推荐使用64位操作系统）
软件作者：张宴
队列（Queue）又称先进先出表（First In First Out），即先进入队列的元素，先从队列中取出。加入元素的一头叫“队头”，取出元素的一头叫“队尾”。利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。
HTTPSQS 具有以下特征：
● 非常简单，基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。
● 非常快速，入队列、出队列速度超过10000次/秒。
● 高并发，支持上万的并发连接，C10K不成问题。
● 支持多队列。
● 单个队列支持的最大队列数量高达10亿条。
● 低内存消耗，海量数据存储，存储几十GB的数据只需不到100MB的物理内存缓冲区。
● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。
● 可以实时查看队列状态（入队列位置、出队列位置、未读队列数量、最大队列数量）。
● 可以查看指定队列ID（队列点）的内容，包括未出、已出的队列内容。
● 查看队列内容时，支持多字符集编码。
● 源代码不超过800行，适合二次开发。
1、HTTPSQS 1.7 压力测试：
采用Apache ab命令进行压力测试，开启10个线程，放入10万条文本数据（每条512字节）到队列中:
使用HTTP Keep-Alive时：23018 requests/sec
关闭HTTP Keep-Alive时：11840 requests/sec
采用Apache ab命令进行压力测试，开启10个线程，从队列中取出10万条文本数据（每条512字节）:
使用HTTP Keep-Alive时：25982 requests/sec
关闭HTTP Keep-Alive时：13294 requests/sec
详细测试内容：http://code.google.com/p/httpsqs/wiki/BenchmarkTest
生产环境应用：在金山游戏官网中，新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容实时写入HTTPSQS队列，全站搜索引擎增量索引准实时（1分钟内）更新的数据源取自HTTPSQS。HTTPSQS 2009年12月18日上线至今，运行稳定，既有来自Web服务器的入队列操作，也有来自命令行脚本的批量入、出队列操作。
2、HTTPSQS 的生产环境应用：
●金山通行证（https://my.xoyo.com）
队列应用类型：手机短信上行、手机短信下发、邮件下发
队列应用要求：稳定性高，存储数据量大
队列部署结构：一主、一备两台 HTTPSQS 热备模式
●金山用户行为分析系统（http://kbi.xoyo.com）
队列应用类型：用户鼠标点击、访问URL原始数据采集
队列应用要求：并发性能高，存储数据量大
队列部署结构：多台 HTTPSQS 应用层哈希分布式模式
●金山网络游戏运营平台 KingEyes
队列应用类型：用户操作日志记录
●金山逍遥网站内搜索
队列应用类型：索引准实时更新。在金山游戏官网中，新闻、论坛帖子、客服公告、SNS社区等发生的增、删、改操作，文本内容实时写入HTTPSQS队列，全站搜索引擎增量索引准实时（1分钟内）更新的数据源取自HTTPSQS。
●金山逍遥网全站通用评论系统
队列应用类型：评论发表
●金山《剑侠情缘》电视连续剧四大角色人物选秀活动（http://zt.xoyo.com/haixuan/）
队列应用类型：用户上传的照片异步裁剪、缩放处理
●新浪邮箱（http://mail.sina.com.cn）
队列应用类型：用户登陆日志记录
3、HTTPSQS 编译安装：
为列表页缓存而生：TCSQL实时列表缓存数据库帮助文档[原创]
[ 2009-9-25 13:27 | by 张宴 ]
2009-9-25 13:27 | by 张宴 ]
[文章作者：张宴 本文版本：v1.1 最后修改：2010.09.03 转载请注明原文链接：http://blog.zyan.cc/tcsql/]
曾经有人提出，一般数据库缓存分为四种。第一种：单个对象的缓存（一个对象就是数据库一条记录），对于单个对象的临时缓存或永久缓存，用HashMap就可以了，Key-Value方式的Memcached、Memcachedb、Tokyo Tyrant都可以，或者直接对查询数据库的网页采用Squid做缓存，没什么太难的；第二种：列表缓存，就像论坛里帖子的列表；第三种：记录条数的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。第四种：复杂一点的group，sum，count查询，比如一个论坛里按点击数排名的最HOT的帖子列表。第一种比较好实现，后面三种比较困难，虽然可以通过各种方法来解决，但截至目前，似乎还没有使用即简单、并发处理能力又强、实时性又高的解决办法。
TCSQL为列表页的实时缓存而生，是金山逍遥网技术支持部平台组以Tokyo Cabinet DBM为底层存储与索引，结合类似Memcached的Key-Value内存对象缓存，借鉴SQL语句的SELECT、INSERT、UPDATE、DELETE思想与功能开发的实时列表缓存数据库，能够较好地解决上述前三种类别，特别是第二种、第三种类别的高并发读写问题。
TCSQL采用HTTP GET/POST协议＋JSON数据交换格式在客户端、服务器端之间进行数据交互，支持HTTP协议的任何客户端或语言（例如JavaScript、PHP、JSP、Perl、Python等），都能够连接TCSQL服务器进行操作。这就意味着，一些查询量非常大的应用，甚至可以直接使用运行在用户浏览器端的JavaScript代码访问TCSQL数据库，当然，为了安全起见，你可以在中间用Nginx配以rewrite规则，对TCSQL做个反向代理，限制一下查询权限。
利用开源的MySQL UDF自定义函数扩展lib_mysqludf_urlencode、lib_mysqludf_urlencode，以及我们平台组周洋同学编写的lib_mysqludf_http_post扩展，配以MySQL触发器，我们可以在MySQL的某张表发生插入、更新、删除操作时，自动将数据同步到TCSQL数据库，使得TCSQL可以当MySQL从库一样使用。
TCSQL实时列表缓存数据库单机能够支撑1万以上的并发连接，QPS（每秒查询率）能够达到5000～15000次。
以下是TCSQL在10000并发连接情况下的查询速度（服务器为浪潮NF190服务器，两颗双核Xeon(TM) CPU 2.80GHz、4GB内存、1万转SCSI硬盘。）：
1、第一种类型A：主键查询并取出倒序第1条记录（“=”运算）：12155次请求/秒
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=pkey:NUMEQ:随机数值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1
测试结果：
2、第一种类型B：其他索引键查询并取出倒序第1条记录（“=”运算）：11897次请求/秒
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=uid:NUMEQ:随机数值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1
测试结果：
3、第二种类型：根据复合条件查询并取出倒序前10条记录：8778次请求/秒（相当于SELECT * FROM table WHERE dateline >= 随机时间戳 AND idtype = '变换的文本' ORDER BY pkey DESC LIMIT 0,10）
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=dateline:NUMGE:随机时间戳|idtype:STREQ:变换的文本&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=10
测试结果：
4、第三种类型：统计符合查询条件的记录数量：9160次请求/秒（相当于SELECT count(*) FROM table WHERE dateline >= 随机时间戳 AND idtype = '变换的文本'）
查询内容：http://192.168.8.34:3888/?command=select&type=count&where=dateline:NUMGE:随机时间戳|idtype:STREQ:变换的文本
测试结果：
曾经有人提出，一般数据库缓存分为四种。第一种：单个对象的缓存（一个对象就是数据库一条记录），对于单个对象的临时缓存或永久缓存，用HashMap就可以了，Key-Value方式的Memcached、Memcachedb、Tokyo Tyrant都可以，或者直接对查询数据库的网页采用Squid做缓存，没什么太难的；第二种：列表缓存，就像论坛里帖子的列表；第三种：记录条数的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。第四种：复杂一点的group，sum，count查询，比如一个论坛里按点击数排名的最HOT的帖子列表。第一种比较好实现，后面三种比较困难，虽然可以通过各种方法来解决，但截至目前，似乎还没有使用即简单、并发处理能力又强、实时性又高的解决办法。
TCSQL为列表页的实时缓存而生，是金山逍遥网技术支持部平台组以Tokyo Cabinet DBM为底层存储与索引，结合类似Memcached的Key-Value内存对象缓存，借鉴SQL语句的SELECT、INSERT、UPDATE、DELETE思想与功能开发的实时列表缓存数据库，能够较好地解决上述前三种类别，特别是第二种、第三种类别的高并发读写问题。
TCSQL采用HTTP GET/POST协议＋JSON数据交换格式在客户端、服务器端之间进行数据交互，支持HTTP协议的任何客户端或语言（例如JavaScript、PHP、JSP、Perl、Python等），都能够连接TCSQL服务器进行操作。这就意味着，一些查询量非常大的应用，甚至可以直接使用运行在用户浏览器端的JavaScript代码访问TCSQL数据库，当然，为了安全起见，你可以在中间用Nginx配以rewrite规则，对TCSQL做个反向代理，限制一下查询权限。
利用开源的MySQL UDF自定义函数扩展lib_mysqludf_urlencode、lib_mysqludf_urlencode，以及我们平台组周洋同学编写的lib_mysqludf_http_post扩展，配以MySQL触发器，我们可以在MySQL的某张表发生插入、更新、删除操作时，自动将数据同步到TCSQL数据库，使得TCSQL可以当MySQL从库一样使用。
TCSQL实时列表缓存数据库单机能够支撑1万以上的并发连接，QPS（每秒查询率）能够达到5000～15000次。
以下是TCSQL在10000并发连接情况下的查询速度（服务器为浪潮NF190服务器，两颗双核Xeon(TM) CPU 2.80GHz、4GB内存、1万转SCSI硬盘。）：
1、第一种类型A：主键查询并取出倒序第1条记录（“=”运算）：12155次请求/秒
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=pkey:NUMEQ:随机数值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1
测试结果：
引用
Benchmarking: 10000 clients, running 60 sec.
Speed=729324 pages/min, 8031913 bytes/sec.
Requests: 60777 susceed, 0 failed.
Speed=729324 pages/min, 8031913 bytes/sec.
Requests: 60777 susceed, 0 failed.
2、第一种类型B：其他索引键查询并取出倒序第1条记录（“=”运算）：11897次请求/秒
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=uid:NUMEQ:随机数值&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=1
测试结果：
引用
Benchmarking: 10000 clients, running 60 sec.
Speed=713856 pages/min, 7865884 bytes/sec.
Requests: 59488 susceed, 0 failed.
Speed=713856 pages/min, 7865884 bytes/sec.
Requests: 59488 susceed, 0 failed.
3、第二种类型：根据复合条件查询并取出倒序前10条记录：8778次请求/秒（相当于SELECT * FROM table WHERE dateline >= 随机时间戳 AND idtype = '变换的文本' ORDER BY pkey DESC LIMIT 0,10）
查询内容：http://192.168.8.34:3888/?command=select&type=*&where=dateline:NUMGE:随机时间戳|idtype:STREQ:变换的文本&order_by=pkey&order_sort=NUMDESC&limit_skip=0&limit_max=10
测试结果：
引用
Benchmarking: 10000 clients, running 60 sec.
Speed=526680 pages/min, 8971878 bytes/sec.
Requests: 43890 susceed, 0 failed.
Speed=526680 pages/min, 8971878 bytes/sec.
Requests: 43890 susceed, 0 failed.
4、第三种类型：统计符合查询条件的记录数量：9160次请求/秒（相当于SELECT count(*) FROM table WHERE dateline >= 随机时间戳 AND idtype = '变换的文本'）
查询内容：http://192.168.8.34:3888/?command=select&type=count&where=dateline:NUMGE:随机时间戳|idtype:STREQ:变换的文本
测试结果：
引用
Benchmarking: 10000 clients, running 5 sec.
Speed=549648 pages/min, 714542 bytes/sec.
Requests: 45804 susceed, 0 failed.
Speed=549648 pages/min, 714542 bytes/sec.
Requests: 45804 susceed, 0 failed.
亿级数据的高并发通用搜索引擎架构设计[原创]
[ 2008-12-9 08:47 | by 张宴 ]
2008-12-9 08:47 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.12.09 转载请注明原文链接：http://blog.zyan.cc/post/385/]
曾经在七月，写过一篇文章──《基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
曾经在七月，写过一篇文章──《基于Sphinx+MySQL的千万级数据全文检索（搜索引擎）架构设计》，前公司的分类信息搜索基于此架构，效果明显，甚至将很大一部分带Where条件的MySQL SQL查询，都改用了Sphinx+MySQL搜索。但是，这套架构仍存在局限：一是MySQL本身的并发能力有限，在200～300个并发连接下，查询和更新就比较慢了；二是由于MySQL表的主键与Sphinx索引的ID一一对应，从而无法跨多表建立整站查询，而且新增加类别还得修改配置文件，比较麻烦；三是因为和MySQL集成，无法发挥出Sphinx的优势。
最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒（查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”），并且能够支撑高达5000的并发连接；而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。
“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时（1分钟内）完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。
图示说明：
1、搜索查询接口：
利用Tokyo Tyrant构建兼容Memcached协议、支持故障转移、高并发的分布式key-value持久存储系统[原创]
[ 2008-8-7 08:53 | by 张宴 ]
2008-8-7 08:53 | by 张宴 ]
[文章作者：张宴 本文版本：v1.4 最后修改：2010.06.11 转载请注明原文链接：http://blog.zyan.cc/read.php/362/]
Tokyo Cabinet 是日本人 平林幹雄 开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。
Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。
Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。这一点，跟新浪的Memcachedb性质一样。
相比Memcachedb而言，Tokyo Tyrant具有以下优势：
1、故障转移：Tokyo Tyrant支持双机互为主辅模式，主辅库均可读写，而Memcachedb目前支持类似MySQL主辅库同步的方式实现读写分离，支持“主服务器可读写、辅助服务器只读”模式。
这里使用 $memcache->addServer 而不是 $memcache->connect 去连接 Tokyo Tyrant 服务器，是因为当 Memcache 客户端使用 addServer 服务器池时，是根据“crc32(key) % current_server_num”哈希算法将 key 哈希到不同的服务器的，PHP、C 和 python 的客户端都是如此的算法。Memcache 客户端的 addserver 具有故障转移机制，当 addserver 了2台 Memcached 服务器，而其中1台宕机了，那么 current_server_num 会由原先的2变成1。
引用 memcached 官方网站和 PHP 手册中的两段话：
2、日志文件体积小：Tokyo Tyrant用于主辅同步的日志文件比较小，大约是数据库文件的1.3倍，而Memcachedb的同步日志文件非常大，如果不定期清理，很容易将磁盘写满。
3、超大数据量下表现出色：
Tokyo Cabinet 是日本人 平林幹雄 开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。
Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。
Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。这一点，跟新浪的Memcachedb性质一样。
相比Memcachedb而言，Tokyo Tyrant具有以下优势：
1、故障转移：Tokyo Tyrant支持双机互为主辅模式，主辅库均可读写，而Memcachedb目前支持类似MySQL主辅库同步的方式实现读写分离，支持“主服务器可读写、辅助服务器只读”模式。
这里使用 $memcache->addServer 而不是 $memcache->connect 去连接 Tokyo Tyrant 服务器，是因为当 Memcache 客户端使用 addServer 服务器池时，是根据“crc32(key) % current_server_num”哈希算法将 key 哈希到不同的服务器的，PHP、C 和 python 的客户端都是如此的算法。Memcache 客户端的 addserver 具有故障转移机制，当 addserver 了2台 Memcached 服务器，而其中1台宕机了，那么 current_server_num 会由原先的2变成1。
引用 memcached 官方网站和 PHP 手册中的两段话：
引用
http://www.danga.com/memcached/
If a host goes down, the API re-maps that dead host's requests onto the servers that are available.
http://cn.php.net/manual/zh/function.Memcache-addServer.php
Failover may occur at any stage in any of the methods, as long as other servers are available the request the user won't notice. Any kind of socket or Memcached server level errors (except out-of-memory) may trigger the failover. Normal client errors such as adding an existing key will not trigger a failover.
If a host goes down, the API re-maps that dead host's requests onto the servers that are available.
http://cn.php.net/manual/zh/function.Memcache-addServer.php
Failover may occur at any stage in any of the methods, as long as other servers are available the request the user won't notice. Any kind of socket or Memcached server level errors (except out-of-memory) may trigger the failover. Normal client errors such as adding an existing key will not trigger a failover.
2、日志文件体积小：Tokyo Tyrant用于主辅同步的日志文件比较小，大约是数据库文件的1.3倍，而Memcachedb的同步日志文件非常大，如果不定期清理，很容易将磁盘写满。
3、超大数据量下表现出色：
