httpsql的安装与使用

httpsqs缓存队列,可用来解决高i/o问题,一般作为数据库写操作的外缓冲

1.安装libevent-2.0.12-stable.tar.gz
wget http://httpsqs.googlecode.com/files/libevent-2.0.12-stable.tar.gz
tar zxvf libevent-2.0.12-stable.tar.gz
cd libevent-2.0.12-stable/
./configure –prefix=/usr/local/libevent-2.0.12-stable/
make
make install
cd ../
2.安装tokyocabinet-1.4.47.tar.gz
wget http://httpsqs.googlecode.com/files/tokyocabinet-1.4.47.tar.gz
tar zxvf tokyocabinet-1.4.47.tar.gz
cd tokyocabinet-1.4.47/
./configure –prefix=/usr/local/tokyocabinet-1.4.47/
#注:在32位Linux操作系统上编译Tokyo cabinet,请使用./configure –enable-off64代替./configure,可

以使数据库文件突破2GB的限制。
#./configure –enable-off64 –prefix=/usr/local/tokyocabinet-1.4.47/
make
make install
cd ../
当执行第二步骤的会出错,是由于缺少bzip2-1.0.6.tar.gz
下面进行安装

http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz安装开始;
wget  http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz
tar -xvzf bzip2-1.0.6.tar.gz
cd bzip2-1.0.6.
make
make install
在重复安装tokyocabinet-1.4.47.tar.gz还是失败,由于缺少zlib-1.2.5.tar.gz
下面进行安装

http://www.winimage.com/zLibDll/zlib-1.2.5.tar.gz安装开始;
wget  http://www.winimage.com/zLibDll/zlib-1.2.5.tar.gz
tar -xvzf zlib-1.2.5.tar.gz
cd zlib-1.2.5.
./configure
make
sudo make instal
继续第2步骤 OK
3.安装httpsqs-1.7.tar.gz

wget http://httpsqs.googlecode.com/files/httpsqs-1.7.tar.gz
tar zxvf httpsqs-1.7.tar.gz
cd httpsqs-1.7/
make
make install
cd ../
4.测试

如果安装成功 执行httpsqs –h 会出现
————————————————————————————————


HTTP Simple Queue Service – httpsqs v1.7 (April 14, 2011)

Author: Zhang Yan (http://blog.s135.com), E-mail: net@s135.com
This is free software, and you are welcome to modify and redistribute it under the New BSD

License

-l <ip_addr>  interface to listen on, default is 0.0.0.0
-p <num>      TCP port number to listen on (default: 1218)
-x <path>     database directory (example: /opt/httpsqs/data)
-t <second>   keep-alive timeout for an http request (default: 60)
-s <second>   the interval to sync updated contents to the disk (default: 5)
-c <num>      the maximum number of non-leaf nodes to be cached (default: 1024)
-m <size>     database memory cache size in MB (default: 100)
-i <file>     save PID in <file> (default: /tmp/httpsqs.pid)
-a <auth>     the auth password to access httpsqs (example: mypass123)
-d            run as a daemon
-h            print this help and exit

 

5.设置

存储目录

#mkdir /usr/local/httpsqs_queue

mkdir /home/bf
vi /home/bf/httpsqs.sh
内容如下:
#! /bin/sh
ulimit -SHn 65535

启动方法

带密码

# /usr/bin/httpsqs -d -p 1218 -t 10 -c 10000 -m 512 -x /usr/local/httpsqs_queue -a pwd123

无密码

# /usr/bin/httpsqs -d -p 1218 -t 10 -c 10000 -m 512 -x /usr/local/httpsqs_queue

干掉的方法
# killall httpsqs

 

注意需要打开防火墙端口

vim /etc/sysconfig/iptables

添加下面一行,打开防火墙1218端口:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 1218 -j ACCEPT

重启防火墙

#/etc/init.d/iptables restart

 

 

6.使用

写队列
http://192.168.2.103:1218/?name=your_queue_name&opt=put&data=TEXT&auth=pwd123

 

读队列
http://192.168.2.103:1218/?charset=utf-8&name=your_queue_name&opt=get&auth=pwd123

 

写队列无密码
http://192.168.2.103:1218/?name=your_queue_name&opt=put&data=TEXT

 

读队列无密码
http://192.168.2.103:1218/?charset=utf-8&name=your_queue_name&opt=get
 

 

 

写队列
http://192.168.2.103:1218/?name=your_queue_name&opt=put&data=TEXT&auth=pwd123

 

读队列
http://192.168.2.103:1218/?charset=utf-8&name=your_queue_name&opt=get&auth=pwd123

 

7.php扩展

参考:http://code.google.com/p/php-httpsqs-client/

安装说明

# mkdir php_httpsqs_client 
# cd php_httpsqs_client 
# wget http://php-httpsqs-client.googlecode.com/files/php_httpsqs_client_0.2.1.tar.gz
# tar vzxf php_httpsqs_client_0.2.1.tar.gz
# /usr/local/php/bin/phpize
如果

运行/usr/local/webserver/php/bin/phpize时出现: Configuring for: PHP Api Version:         20041225 Zend Module Api No:      20060613 Zend Extension Api No:   220060519 Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF environment variable. Then, rerun this script. 根据网上的解决办法是: yum install m4 yum install autoconf

 

# ./configure --enable-httpsqs --with-php-config=/usr/local/php/bin/php-config 
# make && make install
#接着在php.ini中添加一行 
extension=httpsqs.so;

 

函数说明

/** 
 * 创建httpsqs连接 
 * @param string $host 服务器地址,可以为空,默认为127.0.0.1 
 * @param int    $port 服务器端口,可以为空,默认为1218 
 * @return resource 
 */ 
$hr = httpsqs_connect("127.0.0.1", 1218);
/** 
 * 写入队列数据 
 * @param resource $hr      服务器连接句柄 
 * @param string   $queue   队列名称 
 * @param string   $data    写入数据 
 * @param string   $charset 字符集,可以为空,默认为utf-8 
 * @return boolean 
 */ 
$putRes = httpsqs_put($hr, "testQueue", "This is a test Data", "UTF-8");
/**  
 * 获取队列最后一条数据 
 * @param resource $hr 
 * @param string   $queue 
 * @param boolean  $return_array 是否返回数组,可以为空,默认为false 
          返回数组格式:array('pos'=>'队列插入点', 'data'=>'数据值') 
 * @param string   $charset 可以为空 
 * @return mixed 
 */ 
$content = httpsqs_get($hr, "testQueue", true, "UTF-8");
/** 
 * 获取队列状态 
 * @param resource $hr 
 * @param string   $queue 
 * @param boolean  $return_json 是否返回状态的json格式,可以为空,默认为false 
 * @return string 
 */ 
$status = httpsqs_status($hr, "testQueue", true);
/** 
 * 获取队列某个点数据 
 * @param resource $hr 
 * @param string   $queue 
 * @param int      $pos 要获取的某条数据的位置 
 * @param string   $charset 可以为空 
 * @return string 
 */ 
$posData = httpsqs_view($hr, "testQueue", 10, "UTF-8");
/** 
 * 队列重置 
 * @param resource $hr 
 * @param string   $queue 
 * @return boolean 
 */ 
$resetRes = httpsqs_reset($hr, "testQueue");
/** 
 * 设置队列最大数据条数 
 * @param resource $hr 
 * @param string   $queue 
 * @param int      $maxqueue 队列最大数据条数 
 * @return boolean 
 */ 
$maxqueueRes = httpsqs_maxqueue($hr, "testQueue", 10000);
/** 
 * 修改定时刷新内存缓冲区内容到磁盘的间隔时间 
 * @param resource $hr 
 * @param string   $queue 
 * @param int      $synctime 间隔时间 
 * @return boolean 
 */ 
$synctimeRes = httpsqs_synctime($hr, "testQueue", 10);

 

对象调用

// 参数与httpsqs_connect对应 
$hr = new HttpSQS($host, $port); 

// 参数与httpsqs_get对应 
$hr->get($queuename, $return_array, $charset); 

// 参数与httpsqs_put对应 
$hr->put($queuename, $data, $charset); 

// 参数与httpsqs_status对应 
$hr->status($queuename, $return_json); 

// 参数与httpsqs_view对应 
$hr->view($queuename, $pos); 

// 参数与httpsqs_reset对应 
$hr->reset($queuename); 

// 参数与httpsqs_maxqueue对应 
$hr->maxqueue($queuename); 

// 参数与httpsqs_synctime对应 
$hr->synctime($queuename);

 

示例

// 取数据Daemon 
$hr = httpsqs_connect($host, $port); 
while (1) { 
    $data = httpsqs_get($hr, $queuename, $charset); 
    if ($data === false) { 
       sleep(1); 
    } else { 
      // do something... 
    } 
} 

// 或者 
$hr = new HttpSQS($host, $port); 
while (1) { 
    $data = $hr->get($queuename, $charset); 
    if ($data === false) { 
        sleep(1); 
    } else { 
      // do something... 
    } 
} 

// 写数据 
$hr = httpsqs_connect($hort, $port); 
httpsqs_put($hr, $queuename, $data, $charset); 

// 或者 
$hr = new HttpSQS($hort, $port); 
$hr->put($queuename, $data, $charset);

 

写入

<?php
$hr = httpsqs_connect(“127.0.0.1”, 1218);
$putRes = httpsqs_put($hr, “testQueue”, “Text”, “UTF-8”);
?>

读取

<?php
$hr = httpsqs_connect(“127.0.0.1”, 1218);
$content = httpsqs_get($hr, “testQueue”, true, “UTF-8”);
//print_r($content);
echo $content[‘data’];

?>

 

文章来源:http://blog.csdn.net/21aspnet/article/details/7467812#comments

nginx 安装问题

安装nginx报错

按理来说,装个nginx是很简单的,诸如用:yum install nginx,这个确实没什么问题,可是我想通过编译源码的方式安装,而且还要开启一些功能,例如:pcre zlib openssl。

开始把pcre(www.pcre.org),zlib(www.zlib.org),openssl(www.openssl.org) 都下载,编译安装好了,然后开始编译安装nginx-0.8.53。

./configure –prefix=/usr/local/nginx –user=www –group=www –with-http_gzip_static_module –with-http_stub_status_module –with-http_ssl_module –with-pcre=/usr/local/pcre –with-zlib=/usr/local/zlib –with-openssl=/usr/local/openssl –with-http_realip_module

这步没什么问题,接下来make,问题出来了:

cd /usr/local/pcre \
&& if [ -f Makefile ]; then make distclean; fi \
&& CC=”gcc” CFLAGS=”-O2 -fomit-frame-pointer -pipe ” \
./configure –disable-shared
/bin/sh: ./configure: No such file or directory
make[1]: *** [/usr/local/pcre/Makefile] Error 127
make[1]: Leaving directory `/software/nginx-0.8.53′
make: *** [build] Error 2

怎么捣鼓也没搞定,无意间 ./configure –help

看一下帮助说明:

–with-pcre=DIR set path to PCRE library sources

注意:set path to PCRE library sources是让你设置到源码目录,而不是编译安装后的目录,顿时恍然大悟。

迅速把上面几个依赖包的路径都改成源码路径:

./configure –prefix=/usr/local/nginx –with-http_gzip_static_module –with-http_stub_status_module –with-http_ssl_module –with-pcre=/software/pcre-8.10 –with-zlib=/software/zlib-1.2.5 –with-openssl=/software/openssl-1.0.0a –with-http_realip_module

重新执行,OK。

文章来源:http://hi.baidu.com/mchina_tang/item/0c3d00941e28775df042153d

vim ctrl+s 的问题

我在使用vim的时候,偶尔会碰到vim莫名其妙的僵在那里。在界面上输入什么都没有反应。甚至Ctrl+C、Ctrl+D也没有反应。

由于不是经常发生,也就没在意。每次很麻烦的关掉putty的窗口,重新再打开putty。今天发生了好几次,很是郁闷。就想看看究竟是怎么回事,结果发现每次按下Ctrl+S就会出现这个问题。

由于以前碰到过vim有些扩展有问题,这次就也怀疑是vim扩展的问题。结果删除了所有扩展和.vimrc文件,问题依旧。通过putty登录到别的系统,也是一样的问题。直接在ubuntu的命令行,按下Ctrl+S,问题也一样!

奥,原来是Linux的一个快捷键呀,干什么用的?

原来Ctrl+S在Linux里,是锁定屏幕的快捷键。如果要解锁,按下Ctrl+Q就可以了。

好吧,接受教训吧。以后碰到问题要勤快点,越早解决越少麻烦。
现在让我记牢点这两个组合键Ctrl+SCtrl+Q

转载自http://www.leonzhang.com/2010/06/09/vim_hangu_by_ctrl_s/

$_SERVER[‘PATH_INFO’] 获取不到报错

新搭建的web环境,使用kohana框架 地址重写后,报没有$_SERVER[‘PATH_INFO’] 的notice 错误,解决方案参考

一直以为是rewrite 出错了,没法获取到$_SERVER[‘PATH_INFO’]的值,对了apache的配置和.htaccess文件都没问题,
度娘没有得到理想的结果,于是自己想办法。
错误级别为notice错误,也就是说不是致命错误,查看php.ini 的error_reporting 配置,为E_ALL,就是会报所有的错误,
干脆注释掉
在测试,问题解决,我汗……

win7 64 wampserver 2.2 安装redis扩展

wampserver 2.2 安装redis扩展,不同wampserver的版本需要的不同的dll库,本题提供的下载地址是wampserver2.2专用的

下载php_redis.dll扩展库文件,放入php目录下的ext目录下
下载地址:
https://github.com/downloads/nicolasff/phpredis/php_redis-5.3-vc9-ts-73d99c3e.zip
在php.ini中添加
extension=php_redis.dll

Windows版的Redis

Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作 把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,Redis最大的魅力是支持保存List链表和Set集合的数据 结构,而且还支持对List进行各种操作,例如从List两端push和pop数据,取 List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数 据,Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能 的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。

Windows版的Redis可到此处下载,非官方版
http://code.google.com/p/servicestack/wiki/RedisWindowsDownload

Redis文件夹有以下几个文件
redis-server.exe:服务程序
指定redis的配置文件,如没有指定,则使用默认设置
D:\redis-2.0.0-rc2>redis-server.exe redis.conf

redis.conf配置选项如下
daemonize 是否以后台进程运行,默认为no
pidfile 如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid
bind 绑定主机IP,默认值为127.0.0.1(注释)
port 监听端口,默认为6379
timeout 超时时间,默认为300(秒)
loglevel 日志记录等级,有4个可选值,debug,verbose(默认值),notice,warning
logfile 日志记录方式,默认值为stdout
databases 可用数据库数,默认值为16,默认数据库为0
save <seconds> <changes> 指出在多长时间内,有多少次更新操作,就将数据同步到数据文件。这个可以多个条件配合,比如默认配置文件中的设置,就设置了三个条件。
save 900 1  900秒(15分钟)内至少有1个key被改变
save 300 10  300秒(5分钟)内至少有300个key被改变
save 60 10000  60秒内至少有10000个key被改变
rdbcompression 存储至本地数据库时是否压缩数据,默认为yes
dbfilename 本地数据库文件名,默认值为dump.rdb
dir 本地数据库存放路径,默认值为 ./
slaveof <masterip> <masterport> 当本机为从服务时,设置主服务的IP及端口(注释)
masterauth <master-password> 当本机为从服务时,设置主服务的连接密码(注释)
requirepass 连接密码(注释)
maxclients 最大客户端连接数,默认不限制(注释)
maxmemory <bytes> 设置最大内存,达到最大内存设置后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理后,任到达最大内存设置,将无法再进行写入操作。(注释)
appendonly 是否在每次更新操作后进行日志记录,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认值为no
appendfilename 更新日志文件名,默认值为appendonly.aof(注释)
appendfsync 更新日志条件,共有3个可选值。no表示等操作系统进行数据缓存同步到磁盘,always表示每次更新操作后手动调用fsync()将数据写到磁盘,everysec表示每秒同步一次(默认值)。
vm-enabled 是否使用虚拟内存,默认值为no
vm-swap-file 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享
vm-max-memory 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0。

Redis官方文档对VM的使用提出了一些建议:
当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大.
当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.
最好使用linux ext3 等对稀疏文件支持比较好的文件系统保存你的swap文件.
vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数.如果设置为0,那么所有对swap文件 的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.redis-cli.exe:命令行客户端,测试用
D:\redis-2.0.0-rc2>redis-cli.exe -h 127.0.0.1 -p 6379

设置一个Key并获取返回的值:
$ ./redis-cli set mykey somevalue
OK
$ ./redis-cli get mykey
Somevalue

如何添加值到list:
$ ./redis-cli lpush mylist firstvalue
OK
$ ./redis-cli lpush mylist secondvalue
OK
$ ./redis-cli lpush mylist thirdvalue
OK
$ ./redis-cli lrange mylist 0 -1
1. thirdvalue
2. secondvalue
3. firstvalue
$ ./redis-cli rpop mylist
firstvalue
$ ./redis-cli lrange mylist 0 -1
1. thirdvalue
2. secondvalue

redis-check-dump.exe:本地数据库检查

redis-check-aof.exe:更新日志检查

redis-benchmark.exe:性能测试,用以模拟同时由N个客户端发送M个 SETs/GETs 查询 (类似于 Apache 的 ab 工具).
./redis-benchmark -n 100000 –c 50
====== SET ======
100007 requests completed in 0.88 seconds (译者注:100004 查询完成于 1.14 秒 )
50 parallel clients (译者注:50个并发客户端)
3 bytes payload (译者注:3字节有效载荷)
keep alive: 1 (译者注:保持1个连接)
58.50% <= 0 milliseconds(译者注:毫秒)
99.17% <= 1 milliseconds
99.58% <= 2 milliseconds
99.85% <= 3 milliseconds
99.90% <= 6 milliseconds
100.00% <= 9 milliseconds
114293.71 requests per second(译者注:每秒 114293.71 次查询)

Windows下测试并发客户端极限为60

相关文章
http://www.rediscn.com/index.html
http://code.google.com/p/redis/(官网)
http://code.google.com/p/redis/wiki/CommandReference

EXT学习——mvc下,view列表中多store的运用

使用extjs两个星期了,昨天采用extjs的mvc制作列表时,由于外键的原因,需要在前端通过id到另一个store中获取数据,经过多次试验,终于完成了想要的功能,特此记录,以备下次需要

Ext.define(‘DC.view.xxx’, {
extend: ‘Ext.grid.Panel’,
alias: ‘widget.xxx’,
store: ‘xxxxx1’,
frame: true,
multiSelect: true,
initComponent: function() {

// 载入终端类型的数据代理
var xstore = Ext.data.StoreManager.lookup(‘xxxx2′);
// 定义局部变量,存放请求到的数据集
var xobj = {};
// 执行数据代理的载入的方法,获取数据集
xstore.load(function(records, operation, success){
// 取得数据集的数据主体放入已定义的局部变量(此处之所以有 .data 是因为返回结果为{”,”,’data’:{}}的结构)
xobj = Ext.JSON.decode(operation.response.responseText, true).data;
});

Ext.apply(this, {
columns: [{
header: ‘ID’,
dataIndex: ‘id’,
}, {
header: ‘字段’,
dataIndex: ‘ziduan’,
flex: 2,
renderer:function(value){
for(var i=0;i<xobj.length;i++){
if(xobj[i].id == value){
return xobj[i].name;
}
}
}
})
}

Session机制详解

虽然session机制在web应用程序中被采用已经很长时间了,但是仍然有很多人不清楚session机制的本质,以至不能正确的应用这一技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。

    一、术语session

在我的经验里,session这个词被滥用的程度大概仅次于transaction,更加有趣的是transaction与session在某些语境下的含义是相同的。

session,中文经常翻译为会话,其本来的含义是指有始有终的一系列动作/消息,比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为 一个session。有时候我们可以看到这样的话“在一个浏览器会话期间,…”,这里的会话一词用的就是其本义,是指从一个浏览器窗口打开到关闭这个 期间①。最混乱的是“用户(客户端)在一次会话期间”这样一句话,它可能指用户的一系列动作(一般情况下是同某个具体目的相关的一系列动作,比如从登录到 选购商品到结账登出这样一个网上购物的过程,有时候也被称为一个transaction),然而有时候也可能仅仅是指一次连接,也有可能是指含义①,其中 的差别只能靠上下文来推断②。

然而当session一词与网络协议相关联时,它又往往隐含了“面向连接”和/或“保持状态”这样两个含义,“面向连接”指的是在通信双方在通信之前要先 建立一个通信的渠道,比如打电话,直到对方接了电话通信才能开始,与此相对的是写信,在你把信发出去的时候你并不能确认对方的地址是否正确,通信渠道不一 定能建立,但对发信人来说,通信已经开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来,使得消息之间可以互相依赖,比如一个服务员能够认 出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者“一个POP3 session”③。

而到了web服务器蓬勃发展的时代,session在web开发语境下的语义又有了新的扩展,它的含义是指一类用来在客户端与服务器之间保持状态的解决方 案④。有时候session也用来指这种解决方案的存储结构,如“把xxx保存在session里”⑤。由于各种用于web开发的语言在一定程度上都提供 了对这种解决方案的支持,所以在某种特定语言的语境下,session也被用来指代该语言的解决方案,比如经常把Java里提供的 javax.servlet.http.HttpSession简称为session⑥。

鉴于这种混乱已不可改变,本文中session一词的运用也会根据上下文有不同的含义,请大家注意分辨。
在本文中,使用中文“浏览器会话期间”来表达含义①,使用“session机制”来表达含义④,使用“session”表达含义⑤,使用具体的“HttpSession”来表达含义⑥

  二、HTTP协议与状态保持

HTTP协议本身是无状态的,这与HTTP协议本来的目的是相符的,客户端只需要简单的向服务器请求下载某些文件,无论是客户端还是服务器都没有必要纪录 彼此过去的行为,每一次请求之间都是独立的,好比一个顾客和一个自动售货机或者一个普通的(非会员制)大卖场之间的关系一样。

然而聪明(或者贪心?)的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用,就像给有线电视加上点播功能一样。这种需求一方面迫使 HTML逐步添加了表单、脚本、DOM等客户端行为,另一方面在服务器端则出现了CGI规范以响应客户端的动态请求,作为传输载体的HTTP协议也添加了 文件上载、cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一 种在客户端与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠,然而一次性 消费5杯咖啡的机会微乎其微,这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案:

1、该店的店员很厉害,能记住每位顾客的消费数量,只要顾客一走进咖啡店,店员就知道该怎么对待了。这种做法就是协议本身支持状态。

2、发给顾客一张卡片,上面记录着消费的数量,一般还有个有效期限。每次消费时,如果顾客出示这张卡片,则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。

3、发给顾客一张会员卡,除了卡号之外什么信息也不纪录,每次消费时,如果顾客出示该卡片,则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

由于HTTP协议是无状态的,而出于种种考虑也不希望使之成为有状态的,因此,后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端 保持状态的方案,而session机制采用的是在服务器端保持状态的方案。同时我们也看到,由于采用服务器端保持状态的方案在客户端也需要保存一个标识, 所以session机制可能需要借助于cookie机制来达到保存标识的目的,但实际上它还有其他选择。

    三、理解cookie机制

cookie机制的基本原理就如上面的例子一样简单,但是还有几个问题需要解决:“会员卡”如何分发;“会员卡”的内容;以及客户如何使用“会员卡”。

正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。

而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie,如果某个cookie所声明的作用范围大于 等于将要请求的资源所在的位置,则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示,如果某家 分店还发行了自己的会员卡,那么进这家店的时候除了要出示麦当劳的会员卡,还要出示这家店的会员卡。

cookie的内容主要包括:名字,值,过期时间,路径和域。

其中域可以指定某一个域比如.google.com,相当于总店招牌,比如宝洁公司,也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com,可以用飘柔来做比。

路径就是跟在域名后面的URL路径,比如/或者/foo等等,可以用某飘柔专柜做比。路径与域合在一起就构成了cookie的作用范围。如果不设置过期时 间,则表示这个cookie的生命期为浏览器会话期间,只要关闭浏览器窗口,cookie就消失了。这种生命期为浏览器会话期的cookie被称为会话 cookie。会话cookie一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的。如果设置了过期时间,浏览器就会把cookie保存 到硬盘上,关闭后再次打开浏览器,这些cookie仍然有效直到超过设定的过期时间。

存储在硬盘上的cookie可以在不同的浏览器进程间共享,比如两个IE窗口。而对于保存在内存里的cookie,不同的浏览器有不同的处理方式。对于 IE,在一个打开的窗口上按Ctrl-N(或者从文件菜单)打开的窗口可以与原窗口共享,而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存 cookie;对于Mozilla Firefox0.8,所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗 口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很 大的困扰。

 

下面就是一个goolge设置cookie的响应头的例子

HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8;
expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分:

浏览器在再次访问goolge的资源时自动向外发送cookie:

使用Firefox可以很容易的观察现有的cookie的值,使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

IE也可以设置在接受cookie前询问:

这是一个询问接受cookie的对话框。

   四、理解session机制

session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。

当程序需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否已包含了一个session标识 – 称为session id,如果已包含一个session id则说明以前已经为此客户端创建过session,服务器就按照session id把这个session检索出来使用(如果检索不到,可能会新建一个),如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相关联的session id,session id的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie,这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID,而。比如weblogic对于web应用程序生成的 cookie,JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764, 它的名字就是JSESSIONID。

由于cookie可以被人为的禁止,必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面,附加方式也有两种,一种是作为URL路径的附加信息,表现形式为http://….. /xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面,表现形式为http://…../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的,只是服务器在解析的时候处理的方式不同,采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态,就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。比如下面的表单:

<form name=”testform” action=”/xxx”>
<input type=”text”>
</form>

在被传递给客户端之前将被改写成:

<form name=”testform” action=”/xxx”>
<input type=”hidden” name=”jsessionid” value=”ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764″>
<input type=”text”>
</form>

这种技术现在已较少应用,笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在谈论session机制的时候,常常听到这样一种误解“只要关闭浏览器,session就消失了”。其实可以想象一下会员卡的例子,除非顾客主动对店家 提出销卡,否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的,除非程序通知服务器删除一个session,否则服务器会一直保留,程 序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭,因此服务器根本不会有机会知道浏览器已经关闭,之所 以会有这种错觉,是大部分session机制都使用会话cookie来保存session id,而关闭浏览器后这个session id就消失了,再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上,或者使用某种手段改写浏览器发出的 HTTP请求头,把原来的session id发送给服务器,则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除,迫使服务器为seesion设置了一个失效时间,当距离客户端上一次使用session的时间超过这个失效时间时,服务器就可以认为客户端已经停止了活动,才会把session删除以节省存储空间。

    五、理解javax.servlet.http.HttpSession

HttpSession是Java平台对session机制的实现规范,因为它仅仅是个接口,具体到每个web应用服务器的提供商,除了对规范支持之外, 仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

首先,Weblogic Server提供了一系列的参数来控制它的HttpSession的实现,包括使用cookie的开关选项,使用URL重写的开关选项,session持 久化的设置,session失效时间的设置,以及针对cookie的各种设置,比如设置cookie的名字、路径、域,cookie的生存时间等。

一般情况下,session都是存储在内存里,当服务器进程被停止或者重启的时候,内存里的session也会被清空,如果设置了session的持久化 特性,服务器就会把session保存到硬盘上,当服务器进程重新启动或这些信息将能够被再次使用,Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

复制严格说来不算持久化保存,因为session实际上还是保存在内存里,不过同样的信息被复制到各个cluster内的服务器进程中,这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。

cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。

cookie的路径对于web应用程序来说是一个非常重要的选项,Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。

关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

六、HttpSession常见问题(在本小节中session的含义为⑤和⑥的混合)

    1、session在何时被创建

 一 个常见的误解是以为session在有客户端访问时就被创建,然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建,注意如果JSP没有显示的使用 <%@page session=”false”%> 关闭session,则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

 由于session会消耗内存资源,因此,如果不打算使用session,应该在所有的JSP中关闭它。

    2、session何时被删除

 综合前面的讨论,session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止(非持久session)

   3、如何做到在浏览器关闭时删除session

 严 格的讲,做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动 作,然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

    4、有个HttpSessionListener是怎么回事

 你 可以创建这样的listener去监控session的创建和销毁事件,使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销 毁动作触发listener,而不是相反。类似的与HttpSession有关的listener还有 HttpSessionBindingListener,HttpSessionActivationListener和 HttpSessionAttributeListener。

    5、存放在session中的对象必须是可序列化的吗

 不 是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化 的对象,在session销毁时会有一个Exception,很奇怪。

    6、如何才能正确的应付客户端禁止cookie的可能性

 对所有的URL使用URL重写,包括超链接,form的action,和重定向的URL,具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

   7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session

 参见第三小节对cookie的讨论,对session来说是只认id不认人,因此不同的浏览器,不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

    8、如何防止用户打开两个浏览器窗口操作导致的session混乱

 这 个问题与防止表单多次提交是类似的,可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端,同时保存在session里,客 户端提交表单时必须把这个id也返回服务器,程序首先比较返回的id与保存在session里的值是否一致,如果不一致则说明本次操作已经被提交过了。可 以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口,一般不设置这个id,或者使用单独的id,以防主窗口无法操作,建议不要再window.open打开的窗口里做修改 操作,这样就可以不用设置。

 9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
   
    做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变,需要向其他服务器进程复制新的session值。

    10、为什么session不见了

 排 除session正常失效的因素之外,服务器本身的可能性应该是微乎其微的,虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到 过;浏览器插件的可能性次之,笔者也遇到过3721插件造成的问题;理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题。
出现这一问题的大部分原因都是程序的错误,最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨论这个问题。

  七、跨应用程序的session共享

 常 常有这样的情况,一个大项目被分割成若干小项目开发,为了能够互不干扰,要求每个小项目作为一个单独的web应用程序开发,可是到了最后突然发现某几个小 项目之间需要共享一些信息,或者想使用session来实现SSO(single sign on),在session中保存login的用户信息,最自然的要求是应用程序间能够访问彼此的session。

 然 而按照Servlet规范,session的作用范围应该仅仅限于当前应用程序下,不同的应用程序之间是不能够互相访问对方的session的。各个应用 服务器从实际效果上都遵守了这一规范,但是实现的细节却可能各有不同,因此解决跨应用程序session共享的方法也各不相同。

 首 先来看一下Tomcat是如何实现web应用程序之间session的隔离的,从Tomcat设置的cookie路径来看,它对不同的应用程序设置的 cookie路径是不同的,这样不同的应用程序所用的session id是不同的,因此即使在同一个浏览器窗口里访问不同的应用程序,发送给服务器的session id也可以是不同的。


根据这个特性,我们可以推测Tomcat中session的内存结构大致如下。

笔 者以前用过的iPlanet也采用的是同样的方式,估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器,解决的思路很简单,实 际实行起来也不难。要么让所有的应用程序共享一个session id,要么让应用程序能够获得其他应用程序的session id。

iPlanet中有一种很简单的方法来实现共享一个session id,那就是把各个应用程序的cookie路径都设为/(实际上应该是/NASApp,对于应用程序来讲它的作用相当于根)。

<session-info>
<path>/NASApp</path>
</session-info>

需要注意的是,操作共享的session应该遵循一些编程约定,比如在session attribute名字的前面加上应用程序的前缀,使得setAttribute(“name”, “neo”)变成setAttribute(“app1.name”, “neo”),以防止命名空间冲突,导致互相覆盖。

在Tomcat中则没有这么方便的选择。在Tomcat版本3上,我们还可以有一些手段来共享session。对于版本4以上的Tomcat,目前笔者尚 未发现简单的办法。只能借助于第三方的力量,比如使用文件、数据库、JMS或者客户端cookie,URL参数或者隐藏字段等手段。

我们再看一下Weblogic Server是如何处理session的。

从截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/,这是不是意味着在Weblogic Server中默认的就可以共享session了呢?然而一个小实验即可证明即使不同的应用程序使用的是同一个session,各个应用程序仍然只能访问 自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下:

对于这样一种结构,在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量,比如使用文件、数据库、JMS 或者客户端cookie,URL参数或者隐藏字段等手段,还有一种较为方便的做法,就是把一个应用程序的session放到ServletContext 中,这样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下,
应用程序A :
context.setAttribute(“appA”, session);

应用程序B :
contextA = context.getContext(“/appA”);
HttpSession sessionA = (HttpSession)contextA.getAttribute(“appA”);

值得注意的是这种用法不可移植,因为根据ServletContext的JavaDoc,应用服务器可以处于安全的原因对于context.getContext(“/appA”);返回空值,以上做法在Weblogic Server 8.1中通过。

那么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢?原来是为了SSO,凡是共享这个session的应用程序都可以共享认证的信息。一 个简单的实验就可以证明这一点,修改首先登录的那个应用程序的描述符weblogic.xml,把cookie路径修改为/appA访问另外一个应用程序 会重新要求登录,即使是反过来,先访问cookie路径为/的应用程序,再访问修改过路径的这个,虽然不再提示登录,但是登录的用户信息也会丢失。注意做 这个实验时认证方式应该使用FORM,因为浏览器和web服务器对basic认证方式有其他的处理方式,第二次请求的认证不是通过session来实现 的。具体请参看[7] secion 14.8 Authorization,你可以修改所附的示例程序来做这些试验。

    八、总结

session机制本身并不复杂,然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器,服务器的经验当作普遍适用的经验,而是始终需要具体情况具体分析。

文章来源:http://justsee.iteye.com/blog/1570652

vim有字符的地方,背景颜色一样

vim全文颜色一样,原有的高亮功能没有了,看着很难看,可能是默认进入vim就搜索全文造成的

今天在用vim时出现一个很诡异的问题,整个文本内文字的背景变成了统一的黄色,没有高亮显示了,所有字符的背景全变成了一个颜色,多方查资料没有结果,差点就重新配置了vimrc,

后来在vim中搜索了一个字符串,结果原有的问题解决了,再一细看,发现被搜索的关键字的高亮背景和刚刚文本的背景颜色是一样的,退出后在vim进入,发现上一次搜索的关键字的高亮还在……

我的系统是centos的系统,vim是系统自带的,自己没有对其进行过配置,出现这种情况感觉是很诡异的,搜索了关键字后全文统一高亮的效果消失了,终于恢复正常了,但是想要重新找回搜索全文的状态就不知道怎么搞了,也不知道当时是怎么做到了,vim一打开就默认搜索全文内容,使全文高亮显示,还以为是不小心怎么改了配置了……

问题解决了,还是默认的看着舒服

 

json 与 XML的比较

在web开发中,使用json格式进行数据传输较XML的比较

JSON是一个新的人类可读( human readable)的数据格式,在过去几年中已变得非常受欢迎,尤其是在web开发中。
JSON和 XML非常的相似。它们都试图通过建立一种简单,人类可读的格式存储数据。直到最近,XML被用于任何类型的需要迅速发送一小部分数据的系统中。比如那些从服务器获取信息的API。在大多数情况下,XML做的很好。那么,为什么还需要JSON?
JSON在设计时是为Web考虑的,所以它在JavaScript中真的很好用。使用类似 eval()的方法(使用 jQuery会很大提升这个方法的表现),你可以很容易使用JSON中的信息填充一个Web页面。
JSON声称相对XML有许多好处,包括:
  • 容易阅读
  • 解析速度更快
  • 占用空间更少
尽管容易阅读是很难衡量的一点,但其它两点是很显然的。
很容易看出,存储相同的信息JSON确实需要更少的空间。快速浏览一下JSON的网站后,你会发现几个比较这两种格式的例子。从页面上可以很容易的看出:描述同样的信息JSON比XML少占用很多的空间。例如:第一个例子(词汇表结构)存储为XML需要502个字符,而存储为JSON只需345字符(大约少占30%的空间)。
对于“解析速度更快”这一点,有点难以测试。对此我写了一个快速测试来看看我能以多快的速度来把一个XML和JSON字符串转化为Java对象。
对于XML解析,我使用Java内置的 SAX解析器。SAX解析器允许遍历XML文件,并把XML值赋给对象中适当的字段。这种方法相对JSON解析是比较繁琐的,但不是没有道理。
JSON的解析,我使用了GSON库,只需用一行代码就可以很容易地在JSON和java对象之间转换,只需要一个这个类的定义就可以了(如Book类,字段名和JSON中的对应)。不过这使得这个类变量和JSON实例绑定到了一起。一旦类的实例名称或JSON字段名有了变化,将会出现问题。
首先,我用相同的数据创建了一个XML和JSON来表示它。下面的XML和JSON文件是使用 Programming Pearls中的信息创建的。
XML版本
01 <book>
02      <type>textbook</type>
03      <pages>256</pages>
04      <title>Programming Pearls 2nd Edition</title>
05      <description>The first edition of Programming Pearls was one of the most influential books I read early in my career...</description>
06      <rating>4.5</rating>
07      <coverType>paperback</coverType>
08      <genre>Computer Science</genre>
09      <author>Jon Bentley</author>
10      <publisher>Addison-Wesley Professional</publisher>
11      <copyright>1999</copyright>
12 </book>

 

JSON版本
01 {
02  "book": {
03      "type""textbook",
04      "pages""256",
05      "title""Programming Pearls 2nd Edition",
06      "description""The first edition of Programming Pearls was one of the most influential books I read early in my career...",
07      "rating""4.5",
08      "coverType""paperback",
09      "genre""Computer Science",
10      "author""Jon Bentley",
11      "publisher""Addison-Wesley Professional",
12      "copyright""1999"
13      }
14  }
 结果
 使用上面的XML和JSON文件分别运行解析测试10,000,000次。结果并不令人惊讶,解析和转换JSON成一个Java对象的速度比XML快30%左右。
  • JSON平均运行时间:3.647208974029518E-5
  • XML平均运行时间:5.011537916910817E-5
我得到的结论是:
    相对XML,JSON的解析速度提高了30%,占用空间少30%。这些结果似乎和多数开发社区对两种格式的看法一样。换用JSON处理数据在性能上可以有不小的提升,而且还会减少空间的占用。