置顶
===========================================================
===========================================================
隆重推荐：甲骨碎
从故事的时间线来看，《甲骨碎》这本书承接《百年诅咒》，前部书中幸存的二号女主角韩裳，于《泰尔》首演当日蹊跷死亡，而她临死前做过的事情中，最重要的一件就是约定与本书中男主角孙镜的会面，尽管最终男主角见到了她，但那时她已经倒在了血泊里。我心里其实很为韩裳不平，这么可爱聪明人长的美还有钱的当之无愧的现形白富美，连续在两部书中都只能做2号女主~
有些人活着它已经死了，有些人死了它却还活着，这么有禅机的话如果结合本书来看就不是那么难理解。韩裳虽然死了，但她死前已经成功拉上了男主孙镜，2号女主虽然去了，但1号女主早已先她闪亮登场，而且从作者书中的描述来看，1号更美更可爱，钱虽然没有太多，但在书中也长期冒充了归国女富豪，白富美的称号也是当的上的。
从故事上来说，本书也是承接着《百年诅咒》，作者用三百多页文字证明九洲祭器比西洋神器高一个档次都不止~~~
如果喜欢悬疑类的小说，不妨看看本书，只需要3分钟，你就放不下~
隆重推荐：那多 - 甲骨碎
===========================================================
===========================================================
隆重推荐：百年诅咒
斯蒂芬·茨威格(StefanZweig，1881－1942)是奥地利的著名作家，他善于运用各种体裁，写过诗、小说、戏剧、文论、传记，还从事过文学翻译，但他的作品中以传记和小说最为著称。经历了一次世界大战后的灾难：饥馑、寒冷和通货膨胀，以及希特勒上台纳粹的迫害，一九四二年二月二十三日，茨威格和他的妻子在巴西服毒自杀。他在去世之前，完成了《昨日的世界---一个欧洲人的回忆录》，这部书是他一生的历史，也是他那一代人的历史；这是对昨日的世界，亦即对在第二次世界大战中沉沦的资产阶级世界的回忆。
在这本自传中，茨威格以亦真亦幻的笔法回忆了他本人的一些奇异事迹，就是所谓的茨威格诅咒。说的是他自己写的几部戏剧，在即将上映或筹备过程中，几个主演戏剧的演员离奇死亡，比如在《忒耳西忒斯》这部戏剧中，德意志民族最伟大的两位演员之一阿达尔贝尔特·马特考夫斯基有意出演，经过一次次的彩排效果非凡，等演出即将公映时，报纸上登出了马特考夫斯基逝世的消息。而后德意志民族最伟大的另外一位演员约瑟夫·凯恩茨主动找上门来想要出演，几个星期以后，作者站在他的灵柩旁无言。若干年后，茨威格重新振作精神创建了一出剧本--《大海旁的房子》，城堡剧院的新经理阿尔弗雷德·贝格尔男爵——他是一位杰出的戏剧行家和演讲大师有意出演，但事实是：十四天后，在初次排练开始以前，他就死了。1931年茨威格完成了一部新剧《穷人的羔羊》。他把手稿寄给了朋友亚历山大·莫伊西，有一天茨威格接到他的电报，问是否可以在首演时为他保留那个主角……不过，茨威格是在他的灵柩前而非排练场见到他最后一面。。。。
本书的故事正是围绕着茨威格诅咒展开。
费克群(注意不是岳不群)的手里就有一份茨威格未公开过的戏剧手稿：《泰尔》。费克群先生是国内娱乐圈里的大腕，目前他正在筹备着要将这部戏剧搬上荧幕。可是遗憾的是，一次网聊之后不幸哮喘发作，因未能及时就医，加之一系列的偶然因素交织发生，意外身故~~
现在，《泰尔》手稿落到费克群的侄子费城手里了。由于自己的叔叔身故过程中出现的巧合太多，疑点从从，费城认为警方“自杀”的结论太过仓促，并决定自己着手进行调整，在调查过程中，偶然的因素获取了这部手稿，并认识到这部剧作的价值，他也按捺不住了。一直以来费城对自己的状态就不很满意，他最自诩的其实是编剧甚至导演方面的能力，但毕业之后，不得已却只能去当经纪人。
并且当叔叔之前的好友夏绮文－－国内知名的一线女明星，为了帮助故人的侄子，表示愿意出马担当女主角时，这一刻叔叔死亡的疑点被他暂时抛到了脑后，这本厚重的手稿似乎让他看见了，自己的未来正徐徐展开。
这个倒霉催的孩子，决心要把它弄出来，他找来了投资方 - 一家影视公司的老总，找来了好友周训做道具师，联系场地服装等等，并且决定自己担纲男一号。
为了能够导演好这部剧作，费城收集了大批茨威格的著作细心研读，这其中也包括自传《昨日的世界》，当看到作者描述的诡异的事件后，费城也被吓着了，但他发现已经停不下手了，而后女主角死，男主角也死，但是，故事没有结束，因为接替主女角的女二号主角找到了祖辈留下的遗产，成功由女屌丝升级为女富婆，现在，她准备把这部戏继续下去....
本书内容尽管是从古典戏剧讲起，但内容绝对主流，做为一本08年出版的作品，书中尚且不乏：偷窥、裸聊、监听、同性恋、偷拍、被自杀等等关键字，即使放在2012年的今天也依然属于站在潮流的浪尖之上。
隆重推荐：那多 - 百年诅咒
===========================================================
===========================================================
Redis安装和使用示例
Redis是目前众多NoSQL产品中非常有特点的一款，支持的数据类型和方法都非常丰富，做为一款具备持久化功能的软件，实际使中更多却是将其做为cache。
三思在个人的测试环境中安装使用了两三天，这期间尽管文档看了不少，但其实收获不多，不过对于NoSQL产品的整体看法一直没变，我觉着各类型NoSQL产品都还只是工具，并且是小工具，称不上产品。小工具能起大作用这不假(redis目前在国内最知名的案例应该是新浪微博)，但前提是为其找到适合的应用场景，深入的了解才能用好它。
本文简要描述了linux环境安装redis的过程，redis相关参数以及简单的使用。
１、安装
下载源码包：
# wget http://redis.googlecode.com/files/redis-2.4.10.tar.gz
解压缩：
# tar xvfz redis-2.4.10.tar.gz
进入目录：
# cd redis-2.4.10
编译：
# make
接下来不需要make install
Src目录下的redis-server和redis-cli两个命名就是redis服务端和客户端的应用程序，这两个命令可以直接调用，建议直接复制到用户bin目录下，以方便调用：
# cp src/redis-* /usr/local/bin/
安装至此完成。
２、配置
直接执行redis-server就可以启动redis服务，默认监听端口为6379，而后客户端即可以连接服务端，执行操作。有朋友看到这里可能按捺不住的惊奇，这也太简了吧。没错，确实可以如此简单，好的工具都有这样的特点，上手特别容易，但是想要用好，还是需要深一步研究的。
Redis也是如此，它提供了若干参数，可以用来定制redis服务，以达到更好的性能和匹配业务端的需求。源码包中有一个名为redis.conf的配置文件，其中包含redis各参数的示例和功能描述。
daemonize：默认值no，该参数用于定制redis服务是否以守护模式运行。
pidfile：默认值/var/run/redis.pid，指定redis服务的进程号文件路径，以守护模式运行时需要配置本参数；
port：默认值6379，指定redis服务的端口；
bind：绑定ip，默认是本机所有网络设备；
timeout：客户端空闲n秒后断开连接；
loglevel：设置服务端的日志级别，有下列几种选择：
debug：记录详细信息，用于开发或调试；
verbose：提供很多有用的信息，但是又不像debug那么详尽，默认就是这一选项；
notice：适度提醒，多用于产品环境；
warning：仅显示重要的警告信息；
logfile：指定日志的输出路径，默认值stdout，表示输出到屏幕，守护模式时则输出到/dev/null；
如果要输出日志到syslog中，可以启动syslog-enabled yes，默认该选项值为no。
databases：指定数据库的数量，默认为16个，默认使用的数据库是DB 0。
以下为快照相关的设置
save <seconds> <changes>：指定多长时间刷新快照至磁盘，这个选项有两个属性值，只有当两个属性值均满足时才会触发；可以设置多种级别，例如默认的参数文件中就设置了：
save 900 1：每900秒(15分钟)至少一次键值变更时被触发；
save 300 10：每300秒(5分钟)至少10次键值变更时被触发；
save 60 10000：每60秒至少10000次键值变更时被触发；
rdbcompression：默认值yes，当dump数据库时使用LZF压缩字符串对象，如果CPU资源比较紧张，可以设置为no，选择不压缩；
dbfilename：默认值dump.rdb，dump到文件系统中的文件名；
dir：默认值./，即当前目录，dump出的数据文件的存储路径；
以下为复制相关的设置，复制默认是不启用的，因此在默认的参数文件下列表参数均被注释
# slaveof <masterip> <masterport>：指定主端ip和端口，用于创建一个镜像服务；
# masterauth <master-password>：如果master配置了密码的话，此处也需做设置；
slave-serve-stale-data：默认值yes。当slave丢失与master端的连接，或者复制仍在处理，那么slave会有下列两种表现：
当本参数值为yes时，slave为继续响应客户端请求，尽管数据已不同步甚至没有数据(出现在初次同步的情况下)；
当本参数值为no时，slave会返回"SYNC with master in progreee"的错误信息；
# repl-ping-slave-period：默认值10，指定slave定期ping master的周期；
# repl-timeout：默认值60，指定超时时间。注意本参数包括批量传输数据和ping响应的时间。
以下为安全相关的设置
# requirepass：指定一个密码，客户端连接时也需要通过密码才能成功连接；
# rename-command：重定义命令，例如将CONFIG命令更名为一个很复杂的名字：
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52；
rename-command CONFIG ""：取消这个命令；
以下为资源限制方面的设置
# maxclients：指定客户端的最大并发连接数，默认是没有限制，直到redis无法创建新的进程为止，设置该参数值为0也表示不限制，如果该参数指定了值，当并发连接达到指定值时，redis会关闭所有新连接，并返回'max number of clients reached'的错误信息；
# maxmemory：设置redis最大可使用内存。当达到最大内存后，redis会尝试按照设置的回收策略删除键值。如果无法删除键值，或者保留策略设置为不清除，那么redis就会向发出内存的请求返回错误信息。当把redis做为一级LRU的缓存时本参数较为有用。
# maxmemory-policy：默认值volatile-lru，指定清除策略，有下列几种方法：
volatile-lru -> remove the key with an expire set using an LRU algorithm
allkeys-lru -> remove any key accordingly to the LRU algorithm
volatile-random -> remove a random key with an expire set
allkeys->random -> remove a random key, any key
volatile-ttl -> remove the key with the nearest expire time (minor TTL)
noeviction -> don't expire at all, just return an error on write operations
# maxmemory-samples：默认值3，LRU和最小TTL策略并非严谨的策略，而是大约估算的方式，因此可以选择取样值以便检查。
以下为APPEND ONLY模式的设置，默认情况下redis采用异步方式dump数据到磁盘上，极端情况下这可能会导致丢失部分数据(比如服务器突然宕机)，如果数据比较重要，不希望丢失，可以启用直写的模式，这种模式下redis会将所有接收到的写操作同步到appendonly.aof文件中，该文件会在redis服务启动时在内存中重建所有数据。注意这种模式对性能影响非常之大。
appendonly：默认值no，指定是否启用直写模式；
# appendfilename：直写模式的默认文件名appendonly.aof；
appendfsync：调用fsync()方式让操作系统写数据到磁盘上，数据同步方式，有下列几种模式：
always：每次都调用，比如安全，但速度最慢；
everysec：每秒同步，这也是默认方式；
no：不调用fsync，由操作系统决定何时同步，比如快的模式；
no-appendfsync-on-rewrite：默认值no。当AOF fsync策略设置为always或everysec，后台保存进程会执行大量的I/O操作。某些linux配置下redis可能会阻塞过多的fsync()调用。
auto-aof-rewrite-percentage：默认值100
auto-aof-rewrite-min-size：默认值64mb
以下为慢日志相关的设置，用以记录执行时间超出阀值的查询。执行时间不包括I/O操作或发送数据到客户端等占用的时间，而是真正执行命令所花费的时间(即线程阻塞不能接受其它请求的时间)：
slowlog-log-slower-than：默认值10000，单位微秒，定义为慢的执行的阀值；
slowlog-max-len：默认值1024，慢日志的最大数据。注意这会占用内容资源，如果要清空它可以执行SLOWLOG RESET命令；
以下为虚拟内存相关的设置，虚拟内存在2.4版本废弃，这里也略过不提了
vm-enabled no
vm-swap-file /tmp/redis.swap
vm-max-memory 0
vm-page-size 32
vm-pages 134217728
vm-max-threads 4
以下为高级配置相关的设置
hash-max-zipmap-entries：默认值512，当某个map的元素个数达到最大值，但是其中最大元素的长度没有达到设定阀值时，其HASH的编码采用一种特殊的方式(更有效利用内存)。本参数与下面的参数组合使用来设置这两项阀值。设置元素个数；
hash-max-zipmap-value：默认值64，设置map中元素的值的最大长度；这两个
list-max-ziplist-entries：默认值512，与hash类似，满足条件的list数组也会采用特殊的方式以节省空间。
list-max-ziplist-value：默认值64
set-max-intset-entries：默认值512，当set类型中的数据都是数值类型，并且set中整型元素的数量不超过指定值时，使用特殊的编码方式。
zset-max-ziplist-entries：默认值128，与hash和list类似。
zset-max-ziplist-value：默认值64
activerehashing：默认值yes，用来控制是否自动重建hash。Active rehashing每100微秒使用1微秒cpu时间排序，以重组Redis的hash表。重建是通过一种lazy方式，写入hash表的操作越多，需要执行rehashing的步骤也越多，如果服务器当前空闲，那么rehashing操作会一直执行。如果对实时性要求较高，难以接受redis时不时出现的2微秒的延迟，则可以设置activerehashing为no，否则建议设置为yes，以节省内存空间。
以下为包含方面的设置
include：用于指定包含其它参数文件；
创建一个conf文件(当然也可以直接使用redis自带的redis.conf)并根据实际情况设定好参数，而后启动Redis服务时，指定配置文件即可，例如：
# more redis.conf
daemonize yes
pidfile /data/software/redis/redis.pid
port 6379
logfile /data/software/redis/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /data/software/redis/
# redis-server /data/software/redis/redis.conf
３、应用
Redis自己也提供了一个命令行的客户端工具，可用于学习redis中数据操作的各项命令，这里进行一些简单的增删改查测试。
插入数据：
redis 127.0.0.1:6379> set name jss
OK
查询数据：
redis 127.0.0.1:6379> get name
"jss"
改数据，不说了，还是set
删除数据：
redis 127.0.0.1:6379> del name
(integer) 1
验证键值是否存在：
redis 127.0.0.1:6379> exists name
(integer) 0
操作结构化数据：
redis 127.0.0.1:6379> hset tech:dep sa 10
(integer) 1
redis 127.0.0.1:6379> hset tech:dep dba 3
(integer) 1
redis 127.0.0.1:6379> hset tech:dep arch 6
(integer) 1
redis 127.0.0.1:6379> hgetall tech:dep
1) "sa"
2) "10"
3) "dba"
4) "3"
5) "arch"
6) "6"
Redis的命令非常多，详细可以参考官方文档：http://redis.io/commands
英文不好的朋友可以参考这个网站，它提供各个命令中文版说明：http://readthedocs.org/docs/redis/en/latest/
Redis支持的客户端极为广泛，具体可以参考：http://redis.io/clients。
４、帮助
遇到错误怎么办！
1、which: no tclsh8.5 ....错误
[root@redis1 redis-2.4.10]# make test
cd src && make test
make[1]: Entering directory `/data/software/redis-2.4.10/src'
which: no tclsh8.5 in (/usr/local/mysql55/bin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)
You need 'tclsh8.5' in order to run the Redis test
make[1]: *** [test] Error 1
make[1]: Leaving directory `/data/software/redis-2.4.10/src'
make: *** [test] Error 2
原因：缺少tcl组件
解决方案，安装即可，详细可参考http://www.linuxfromscratch.org/blfs/view/cvs/general/tcl.html
安装步骤：
# wget http://downloads.sourceforge.net/tcl/tcl8.5.10-src.tar.gz
# tar xvfz tcl8.5.10-src.tar.gz
# cd tcl8.5.10/unix
# ./configure --prefix=/usr
--enable-threads
--mandir=/usr/share/man
# make
# sed -i
-e "s@^(TCL_SRC_DIR=').*@1/usr/include'@"
-e "/TCL_B/s@='(-L)?.*unix@='1/usr/lib@"
tclConfig.sh
# make install
# make install-private-headers
# ln -v -sf tclsh8.5 /usr/bin/tclsh
# chmod -v 755 /usr/lib/libtcl8.5.so
===========================================================
===========================================================
隆重推荐：唐德纲 - 晚清七十年
历史本来就被团迷雾遮掩着，摸不着，看不清，猜不透，时间又像是层纱，随着时间的流逝，一层一层覆盖之上，历史的细节就更加越来越看不清。可以有些人这样仍然不放心，还要故意竖起一道墙，可是这样一来，连他们自己也想吹嘘的华夏九州上下五千年的历史也被遮挡在墙外了，怎么办呢，他们采取最土也最有效的办法，把他们认可的“历史”写在墙上，看吧，你们随便看吧，这倒应了乔治。奥威尔在《一九八四》里“老大哥”的“新话”：“谁掌握了现在，就掌握了过去”。
随着时间的推移，墙上的历史甚至连他们也都看不下去了，于是墙里再竖墙，墙又挨着墙，以墙为强，逞强竖墙，以此往覆，以自残的方式切断自己的种种辉煌，他们自己也委屈，是啊，想想就能理解，自家院落立满了墙，自己行动不便，施展腾挪的空间也越来越小了，更别提院落里生活的那些下人们了，那真是比墙外的野狗都不如，活着没地儿住，死了没地儿埋。可是即使这样，还是要继续竖墙，他们说，帝国主义亡我之心不死，如果没有这道墙，连院子都是别人的，可是帝国主义到底指的是谁，他们自己也说不清楚了，因为最近一堵墙上已经不写这样的历史~~
历史袁老师点评中国近代史，说目前官方的历史其真实性拿百分比评判只占个位数，这个数字耸人听闻，但是考虑到“墙”的因素，还真是无法估量。
幸好这堵墙只在东方建了一面，西面还是开阔的，不过即使这样，因为有迷雾和时间面纱的遮扰，看穿历史仍旧不可能，即使仅谈近代史也是很难的，有些勉力看穿个二三层就敢于著书立传的，实在是误人子弟，浪费纸张的。归根结底，态度很重要了。
我看过的历史书中，论中国近代史，首推《晚清七十年》，作者唐德纲老先生是位学贯中西，拥有独立思想的历史大家，秉承胡适之先生“有几分证据，说几分话”的训诫，其文风诙谐趣味横生，叙述历史事件并下推断又证据确凿。
老先生赴美后先后在哥伦比亚大学、纽约市立大学，长期从事历史研究与教学工作，历史观已成体系，即有对传统史学观点的包容，又肯花大力气小心求证，在本书自序中作者这样写道：“
在此将近半个世纪的教学生涯中，什九是在美国纽约的两所大学里度过去了。在哥大研究院专授两门课，整整地教了七年。一门可说是包罗经史子集、诗词歌赋的汉学概述，另一门则是包含中国近现代史的史料学。在纽约市立大学则前后教了近四十年。前二十年在市大各分校兼课，后二十年则在市大本部的市立学院作专任。其中十二年则兼亚洲学系的系主任，并负责设计和教授多种课目。在纽约市政府和联邦政府所主办的中学教师训练班中，也曾担纲教授多种课目。总之，四十年中在纽约市大所设计和教授的课目几近二十种之多。加以纽约市大的学生和家长们都来自世界各地，种族、宗教和政治背景皆万般复杂。作为一个历史科目的教师，尤其是设计人，各方面可能发生的问题，都得面面顾到。上课时往往是推着整书车“史料”进课室的。”
每一位关心社会现状和国家前景的人，处在这样的时代都不免心生愁闷，吃不安，住不上，学不成，医不起，受自身层次的制约又看不清方向，在本书，唐德纲老先生的社会转型论中的“三峡”说看的我心潮澎湃，他这样描述：“近一个半世纪中国变乱的性质便是两千年一遇的“社会转型”的现象。在历史的潮流里，“转型期”是个瓶颈，是个三峡。长江通过三峡是滩高水急、波翻浪滚、险象环生的。在这激流险滩中，摇橹荡舟、顺流而下的大小船夫舵手，风流人物，触礁灭顶，多的是可歌可泣和可悲可笑的故事......我们要通过这个可怕的三峡，大致也要历时两百年。自一八四〇年开始，我们能在二〇四〇年通过三峡，享受点风平浪静的清福，就算是很幸运的了。如果历史出了偏差，政治军事走火入魔，则这条“历史三峡”还会无限期地延长下去。那我民族的苦日子就过不尽了。——不过不论时间长短，“历史三峡”终必有通过之一日。这是个历史的必然。到那时“晴川历历汉阳树，芳草萋萋鹦鹉洲”，我们在喝采声中，就可以扬帆直下，随大江东去，进入海阔天空的太平之洋了。”
转型期快些过去吧，最后的一段航程浪涛汹涌。只要我们的儿孙们能够航行在平缓的海面上，我们今日所处种种再过艰难也是值得的。
隆重推荐：唐德纲 - 晚清七十年
本书在国内命运舛，于1999年被《岳麓书店》引进了本书的第一部“中国社会文化转型综论”，尽管大陆版本在内容已做大量删节，但随后不久该社社长被撤职，编辑被查办，书籍被罚没，如今想找到一本都很不容易，这里有篇文章记录了一位有心人士淘买大陆版晚清七十年的经历：
-----------------------------------------------------------
淘《晚清七十年》记 http://gift05.bokee.com/4087814.html
去年（2001年）11月，一位熟人知道我要在第二天去上海，便委托我去上海福州路——最大的图书市场购买两本《晚清七十年》。
熟人的托付，乃是信任，何况是助人之举，我当义不容辞，便欣然应允。
由于每次都是利用双休去上海，在上海停留的时间总是很短暂，家里人很有意见。家里亲人多，相互之间总有讲不完的话，父母，兄长，还有我那96岁高龄的老奶奶。
这次身负重托去上海，不免想提早离家逛书市，可硬是被奶奶的眼泪阻止了。我便将购书一事委托给了兄长。
一个星期后，兄长来电说他不仅跑遍了福州路所有的书店，还在其他各大小书店数十家都去找过，没有这本书。
购书的事就此搁浅。
一天，一位经常联系的朋友来访，言谈之间与他说起购书之事。他告诉我，他的一个很好的朋友，是江苏最大的书商，或许能帮我解决这个难题。当即，他给朋友去了电话，让他马上来我的办公室。
约莫十五分钟左右，他朋友来了。在进行了一番相互介绍和寒暄之后，未及我细细打量对方，朋友的话已切入正题：
“让你来，请你帮个忙。”
“说吧，什么忙？”
“找本书，《晚清七十年》。”
“哦，这是禁书。现在，国家有关部门对它封锁得很严，我存放在苏州书库的都已经被查封了。不知南京书库是否还有，我得去找找。”
来去几句话，给我莫大希望。我一下子握住他的手“谢谢你，真太谢谢你了！”
象吃了颗定心丸，这段时间我那一直悬挂的心，此时终于落定。
三天后，这位朋友从南京来电：“已经翻遍了在南京所有书库，没能找到。印象中的三本，不知怎么也失踪了。”，
为了不让我失望，他接着说，“曾有一文化局长买过此书，我去向他借出来给你。”
又过一天，电话里的他语调迟缓、沮丧：“对不起，看来我帮不上你这个忙了。那文化局长无论如何都不愿借。”
希望又一次破灭。
没想到，一本《晚清七十年》竟被封锁得如此严密。
据一位知情者说，书中有篇文章的矛头有所指向。这让我大有非读不可的欲望。我发誓：不达目的，誓不罢休！
十二月初，我再赴上海探亲。我比往常提早一天去了上海，这次我抽足了时间，抱着一丝的侥幸，在福州路上硬是泡了六个小时。最终败兴而回。
由于工作原因，我常去省城开会。省里，有一些我很好的朋友和同事。其中与我联系最多、关系最为密切的是小洵，她是南京军区司令员的女儿。同时，她还是一个民间读书会社社员。每次去南京，她总会骄傲地拉着我去参观她的书柜，偶尔，还让我和她一道去参加晚间读书社活动。
今年元月初，我去南京开会一周。我俩一见面，很自然地又谈起了读书和购书。知道我要找的书，她拉着我就走：“找我爸去！”
“找你爸能有用？”
“他们有军需处嘛！”
“这书是军用物资么？”
“管它呢，总会有办法的。”
我们相视而笑。
经过一番周折，结果未能如愿。
第二天晚上，她仍不甘心地拉我去了读书社，拜访了她的一些朋友，并逐一打探此事。仍无果。
到此，购书之事多少有些让我心灰意冷。
第三天晚上，送走了来访的客人，感到百无聊赖，想起购书无门，顿生丝丝阑珊之意。突然想起有位在广州工作的好友，是位历史学者，或许他能有办法。我拨通了他家的电话....购书的希望越来越渺茫。
第四天早上用餐，刚自选完食品，挑一个僻静的角落坐定，听得身后传来乡音：“请问，我可以坐这里吗？”
抬头一看，是我市组织部X部长。
我起身、握手、让座：“当然可以！”
他在我对面坐下，似想起了什么：“你什么时候回苏州？我带着车，可以等你一起走。”
“不必了，我这边会议还要二三天才结束呢。”
“哦。我用过早饭就可以回苏州了。今天上午，我打算去南京长三角书城转转。”
听说他要去书城，我来了兴致：
“啊！去买书？”
“买书、看书！”他微笑着说。
过去，我曾耳闻这位部长靠笔杆子打下半壁江山，还听说，他有一流的篆刻技术，很多人前去向他求石刻印章，据说，都不太容易。
这么看来，他也爱书。
“那今天上午我请假，陪你去书城如何？顺便，我也想去淘我的书。”
“你淘什么书？”他问。
“《晚清七十年》。”
“ 那可是禁书呀，好！一言为定！”
我们驱车来到长三角书城。书城共有三层，每一层都很大。书城内，集聚着数百家来自全国各地的书店和出版社的售点。
看到这情况，我俩觉得不宜同时挨着次序去找书。经过合计，遂采取分工合作的方式 ：他包三楼，我包二楼，然后在一楼会合。
我快步跑上二楼，每到一个售点，就直奔主题。当我俩把三个楼层跑完再回到车上时，彼此都已感觉上气不接下气了。随后，我们又去了临近的十来家书店，还是没能找到。我几乎已不抱什么希望了。
南京有一位旧友，在省人大工作，前些日子刚迁住新居。10月份我去南京时，他就邀我去他家一聚，但由于白天事忙，晚上应酬多，一直没能挤出时间前去拜访，心里总觉得对他有颇多的歉疚。
第四天的下午，会议结束较早，我便主动与他联系。
不多会，他赶到我的住所——省委西康宾馆。我们一起去了餐厅。
几杯酒下肚，话便多了起来。闲谈之中，淘书当然是个不能不说的话题。
“你要找什么书？”他问。
“哎！别提啦！很冷门的书，却哪里都没有啊！”我漫不经心地说。
“说来听听！”
我报了书名，顺便补上一句：“你不会有的。”
“谁说我没有？我有！”他回答很坚决。
我惊异地看着他，见他面带微笑，满眼真诚，一副认真的表情，不象在开玩笑。
“真的....？”我半天才吐出这两个字来。
“我什么时候骗过你？”
我很快控制住自己喜悦的情绪，问他，“那能否借我一读？”
“不借！”仍然很坚决。
我一愣，无言。停顿了一会，他看着我说，“我想送给你。”
闻此言，我不禁为之一颤，“那不成，我不能夺人所爱！”
“我给你寄过去。星期一你上班就能收到！”他说得是那么平静。
从心里讲，我非常想得到这本书，但是，我怎么能……“我不要，我不能要……”我不断地重复着这句话。
星期一，南京开会回来的第一个工作日，按照平时工作习惯，上班的第一件事便是打开电脑收发电子邮件。信箱里有一封主题为“暂时找不到书”的新邮件，是前面提到的那位广州朋友发来的，内容如下：
如虹贤弟：
《晚清七十年》一书我在广州没找到。真不好意思，有负所托。
此书的状况，我将与我朋友的来往信函同时发与你，你便得知，也不用我说了。以后再问问我朋友看能不能在香港市场买到它。因书这是台北前些年就出版的书，按香港书店之周转速度，不一定有了。而大陆版的应是不会出现在香港市面上的。
……
（下面是他委托朋友买书的信）
老兄：
有一事想请老兄帮忙。我想找唐德刚的《晚清七十年》一书，这是岳麓书社1999年版的（买台北版的），但在广州找不到。有私人书店的店主说，唐德刚的书不给卖了。我想老兄在湖南也是个有点名气的文化人，在岳麓书社应有个把认识的人，可否帮忙问问还有没有这本书。有的话帮忙弄一两本。如能弄到的话，我再汇书款去。拜托。
……
（他朋友的复信）
老弟，你好：
信见。唐刚德的《晚清七十年》早已查封。编辑因此受到处分，社长撤职。我早有耳闻。且想买此书，但省委宣传部严令禁止此书的外流。你的要求只能说抱歉。长沙的书市比广州天河那边的书城大，个体书商很活跃，折扣书也很多，有些是精品。你适时抽空到湖南走走，我陪你逛逛书市。岳麓书社我也不是没有熟人，《晚清七十年》一书，我抽空再打听打听。有消息再告。
……
我深深地感动着。
中午，单位的收发员交给我两个邮包：一个来自于南京的特快专递，厚厚的篮色信封里，凭直觉就知道这里面装着一本书；另一个是由市直机关交换信箱转来的。我先打开它，内有一个小方盒，还有一页薄薄的信纸，信纸上寥寥数语：
小赵：
难得女子那么爱书。
休息日为你刻制了一枚书章，不成敬意。
希望你能喜欢。
一股暖流沁入心底。再打开南京寄来的特快专递，里头也有一封信：
小赵：
书送给你作个纪念。我知道你喜欢它，需要它。
不要再推辞了，如果你实在过意不去，那权当是我长久存放在你那里的我们共同的物品，这样，你就可以心安理得了。
二个多月的淘书经历，这本让我魂系梦牵了多少个日日夜夜的《晚清七十年》，终于摆放在了我的书桌上。此刻，我的心情丝毫都不觉得轻松，没有成功后的兴奋、幸喜、欣慰。看着眼前这本书，我百感交集，热泪纵横……
书是得到了，不久，我还将给委托我买书的熟人寄去，不为别的，仅仅是为了“与人交往，应以诚信为先”的做人原则。由此，我恳请这位熟人读完后一定原物奉还。我非常珍爱它。在我看来，她已经不是一般意义上的读物了。
淘书的过程远比得到这一本书的意义和价值来得更加深远，就让书留住这段美好的经历，成为永久的纪念吧！
在此，谨向这些帮助过我的朋友们表示深深地敬意和谢意。
===========================================================
===========================================================
配置CACTI监控MySQL数据库状态(5)增加MySQL监控模板
４、增加MySQL监控模板
下载模板：
#wget http://mysql-cacti-templates.googlecode.com/files/better-cacti-templates-1.1.8.tar.gz
# tar xvfz better-cacti-templates-1.1.8.tar.gz
# cd better-cacti-templates-1.1.8
# cp scripts/ss_get_mysql_stats.php /data/www/cacti/scripts/
导入模板，在cacti管理界面（Import Templates）导入templates/cacti_host_template_x_mysql_server_ht_0.8.6i-sver1.1.8.xml文件。如无异常应显示[success]。
修改脚本文件：
- # vi /data/www/cacti/scripts/ss_get_mysql_stats.php
修改
$mysql_user = ¨cacti¨;
$mysql_pass = ¨cacti¨;
$mysql_port = 3306;
$cache_dir = ¨/data/www/cacti/cache¨;
创建缓存目录并授予所有用户读写权限：
# mkdir /data/www/cacti/cache
# chown cacti:cacti /data/www/cacti/cache
# chmod 777 /data/www/cacti/cache
客户端的配置
以MySQL服务器172.16.1.110为例，创建监控mysql的用户并授予所需要的权限：
- mysql> grant process,super,replication client on *.* to ¨cacti¨@¨10.0.0.116¨ identified by ¨cacti¨;
安装net-snmp及关联组件，为简化操作直接使用yum安装了：
- # yum -y install net-snmp net-snmp-utils net-snmp-devel net-snmp-libs
配置net-snmp：
- # vi /etc/snmp/snmpd.conf
修改：
access notConfigGroup "" any noauth exact all none none
com2sec local localhost public
com2sec mynetwork 10.0.0.0/24 public
view all included .1 80
启动服务：
- # /etc/init.d/snmpd start
执行下列命令检查：
- # snmpwalk -v 2c -c public localhost sysUpTime
正常情况下应有返回。
返回到cacti浏览器管理界面，创建对刚刚配置好的客户端的监控，按照下列步骤操作：
Devices->Add
Description填写描述，Hostname填写客户端IP地址，这里是172.16.1.110，Host Template选择一个模板，这里选择的是预先定制好的模板MYSQLDB(如果没有，选择Local Linux Machine也可以，模板的优点是方便对监控项管理)，其它不变，点击create。
Devices->[刚刚创建的客户端名称]->Create Graphs for this host
根据需要，增加监控项即可。
配置完成后，就可以进入Graph Management中查看具体的监控项了。点击就可以看到图片。默认情况下cacti每5分钟收集一次数据，因此至少需要等待几分钟时间。
至此，配置基本完成。之后就可以根据实际情况，做各种定制化的监控方案。
N、错误处理
Apache日志中提示：
-
[Fri Mar 23 09:30:16 2012] [error] [client 10.0.10.199] PHP Warning: strtotime(): It is not safe to rely on the system¨s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ¨Asia/Chongqing¨ for ¨CST/8.0/no DST¨ instead in /data/www/cacti/include/global_constants.php on line 165
修改/data/www/cacti/include/global_constants.php文件，增加一行：
- date_default_timezone_set (¨Asia/Shanghai¨);
Apache日志中提示：[error] [client 10.0.10.199] File does not exist: /data/www/favicon.ico
手动创建一个该文件即可：
- # cat /dev/null > /data/www/favicon.ico
===========================================================
===========================================================
配置CACTI监控MySQL数据库状态(4)配置cacti
３、配置cacti
创建数据库：
- # mysql -uroot -h localhost -P 3306 -e "create database cactidb"
创建用户：
- # mysql -uroot -h localhost -P 3306 -e "grant all on cactidb.* to cacti@¨localhost¨ identified by ¨cacti¨"
导入数据：
- # mysql -ucacti -pcacti -h localhost -P 3306 -D cactidb < /data/www/cacti/cacti.sql
编辑cacti配置文件：
# vi /data/www/cacti/include/config.php
$database_type = "mysql";
$database_default = "cactidb";
$database_hostname = "localhost";
$database_username = "cacti";
$database_password = "cacti";
$database_port = "3306";
$database_ssl = false;
安装至此基本完成，接下来就可以在浏览器中操作了。
打开浏览器，访问：http://10.0.0.116/cacti/，按照提示进行第一次安装：
注意如果有提示NOT FOUND的项，要手工修正路径，这里需要修改rrdtool和php两个应用的路径。全部验证完后点击FINISH，然后就可以登录cacti了。第一次登录的默认用户名是admin，密码是cacti。
创建自动任务，让cacti能够定时收集数据：
# crontab -ucacti -e
*/5 * * * * /usr/local/webserver/php/bin/php /data/www/cacti/poller.php > /dev/null 2>&1
然后应该就能够在管理界面下看到图片了。
===========================================================
===========================================================
配置CACTI监控MySQL数据库状态(3)配置apache模块
２、配置apache模块
编译apache配置文件：
- vi /usr/local/webserver/apache2.2.21/conf/httpd.conf
修改用户：
User apache
Group apache
修改服务名称：
- ServerName 10.0.0.116:80
修改站点起始目录：
- DocumentRoot "/data/www"
修改目录：
-
<Directory "/data/www">
增加默认做为首页的文件名：
- DirectoryIndex index.html index.php
增加对php类型的支持：
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps然后:wq保存退出！
执行apachectl -t检查配置文件语法，正常情况下应返回Syntax OK：
# /usr/local/webserver/apache2.2.21/bin/apachectl -t
Syntax OK
启动snmp服务：
- # service snmpd start
启动apache服务：
- # /usr/local/webserver/apache2.2.21/bin/apachectl start
===========================================================
===========================================================
配置CACTI监控MySQL数据库状态(2)安装cacti相关软件包
１、安装软件包
1.1 安装APACHE
创建组/用户及安装apache：
# groupadd apache
# useradd -g apache apache
# chown apache:apache /data/www -R
# wget http://mirror.bjtu.edu.cn/apache/httpd/httpd-2.2.21.tar.gz
# tar xvfz httpd-2.2.21.tar.gz
# cd httpd-2.2.21
# ./configure
--prefix=/usr/local/webserver/apache2.2.21
--enable-so
--enable-deflate
--enable-cache
--enable-disk-cache
--enable-mem-cache
--enable-file-cache
--enable-modules=all
--enable-shared=max
--enable-rewrite
--enable-static-support
--enable-static-htpasswd
--enable-static-htdigest
--enable-static-rotatelogs
--enable-static-logresolve
--enable-static-htdbm
--enable-static-ab
--enable-static-checkgid
--enable-vhost-alias
--with-mpm=worker
# make
# make install
1.2 安装MySQL
自MySQL5.5版本之后，编译工具变成了CMake，这里首先安装CMake：
# wget http://www.cmake.org/files/v2.8/cmake-2.8.4.tar.gz
# tar xvfz cmake-2.8.4.tar.gz
# cd cmake-2.8.4
# ./configure
接下来安装MySQL，先创建用户，而后再执行编译。
# groupadd mysql
# useradd -g mysql mysql
# tar xvfz mysql-5.5.20.tar.gz
# cd mysql-5.5.20
# cmake . -DCMAKE_INSTALL_PREFIX=/usr/local/mysql
> -DDEFAULT_CHARSET=utf8
> -DDEFAULT_COLLATION=utf8_general_ci
> -DENABLED_LOCAL_INFILE=ON
> -DWITH_INNOBASE_STORAGE_ENGINE=1
> -DWITH_FEDERATED_STORAGE_ENGINE=1
> -DWITH_BLACKHOLE_STORAGE_ENGINE=1
> -DWITHOUT_EXAMPLE_STORAGE_ENGINE=1
> -DWITH_PARTITION_STORAGE_ENGINE=1
> -DWITH_PERFSCHEMA_STORAGE_ENGINE=1
> -DCOMPILATION_COMMENT=¨JSS for BKmysql¨
> -DMYSQL_UNIX_ADDR=/data/mysqldata/3306/mysql.sock
> -DSYSCONFDIR=/data/mysqldata/3306
# make
# make install
# chown mysql:mysql /usr/local/mysql -R
创建数据库并启动MySQL服务：
# sudo su - mysql
$ /usr/local/mysql/scripts/mysql_install_db --datadir=/data/mysqldata/3306/data
$ cp /usr/local/mysql/support-files/my-large.cnf /data/mysqldata/3306/my.cnf
$ /usr/local/mysql/bin/mysqld_safe --defaults-file=/data/mysqldata/3306/my.cnf &
这个mysql库是用于保存cacti收集到的数据及其自身配置的，也可以将这部分数据保存在当前已存在的数据库上，那就可以跳过本步了。
1.3 安装关联软件包
查询关联软件包是否已安装：
# rpm -q libxml2 libjpeg-6b freetype zlib libpng fontconfig gd net-snmp
libxml2-2.7.6-1.el6.x86_64
libjpeg-6b-46.el6.x86_64
freetype-2.3.11-5.el6.x86_64
zlib-1.2.3-25.el6.x86_64
libpng-1.2.44-1.el6.x86_64
fontconfig-2.8.0-3.el6.x86_64
package gd is not installed
net-snmp-5.5-37.el6_2.1.x86_64
如果显示not installed，则说明该包未安装。如上所示，这里gb包缺失，对于监控需求的cacti来说gd并非必选组件，它只是用来生成水印，在我们这个环境中实际上是用不到的。不过多数php环境一般都有此需求，就算是为了全面些吧，这里也选择将其补全。
下载gd源码包：https://bitbucket.org/pierrejoye/gd-libgd
# wget https://bitbucket.org/pierrejoye/gd-libgd/get/GD_2_0_33.tar.gz
# tar xvfz GD_2_0_33.tar.gz
# cd pierrejoye-gd-libgd-5551f61978e3/src/
# ./configure
# make
# make install
注意net-snmp非常重要，一定要确保其安装可用，可以通过下列命令检查：
- # snmpwalk -v 2c -c public localhost
正常情况下应返回一系列的系统信息。
1.4 安装PHP
# wget http://cn.php.net/get/php-5.3.8.tar.gz/from/cn2.php.net/mirror
# tar xvfz php-5.3.8.tar.gz
# cd php-5.3.8
# ./configure
--prefix=/usr/local/webserver/php
--with-apxs2=/usr/local/webserver/apache2.2.21/bin/apxs
--with-mysql=/usr/local/mysql55
--with-freetype-dir
--with-gd
--with-zlib
--with-jpeg-dir
--with-png-dir
--with-iconv=/usr/local/webserver/libiconv
--enable-short-tags
--enable-sockets
--enable-zend-multibyte
--enable-soap
--with-openssl
--enable-mbstring
--enable-static
--enable-gd-native-ttf
--with-curl
--with-iconv
--with-xsl
--enable-ftp
--with-libxml-dir
# make
# make install
# cp php.ini-production /usr/local/webserver/php/lib/php.ini
1.5 安装RRDTool
# wget http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.2.14.tar.gz
# tar xvfz rrdtool-1.4.4.tar.gz
# ./configure --prefix=/usr/local/rrdtool --disable-python --disable-tcl
# make
# make install
1.6 安装Cacti
# useradd cacti
# tar xvfz cacti-0.8.7i.tar.gz
# mv cacti-0.8.7i /data/www/cacti
# chown cacti:cacti /data/www/cacti -R
===========================================================
===========================================================
招聘MySQL DBA，走过路过别错过了~
招人啦招人啦，MySQL DBA看过来，收入有前景，要求不算高，能力在其次，人品是首要，只要基础好，经验何足道，您要心有意，简历请寄到：libingyang [at] hudong.com，也可以微博上与我联系~~
职位名称：MySQL DBA
公司名称：互动百科(www.hudong.com)
招聘人数：2名
薪酬待遇：有竞争力(由于公司薪酬方面的隐私策略，具体数字不能公布，对该职位感兴趣的朋友可以私下问我)
工作地点：北京朝阳区安定门外安苑里1号奇迹财富广场互动百科大厦
岗位职责：
1、建立和完善MySQL数据库的日常维护计划，保持数据库的正常运作
2、监控MySQL数据库运行状态，并就性能瓶颈，分析和设计改进方案
3、设计MySQL数据库日常备份、恢复策略
4、向开发人员提供技术支持，协助优化SQL语句，部署测试环境
任职要求：
1、熟悉数据库建模及对象设计，具备一定的文档编写能力
2、熟悉MySQL数据库体系结构，了解数据库运行机制
3、熟悉SQL的开发，并能对SQL语句进行分析，优化，具备快速排障能力
4、熟悉Linux的基本操作，具备shell/perl编程经验
5、二年及以上DBA岗位的从业经验，具备MySQL数据库批量运维和管理经验
6、具备良好的沟通能力，善于学习，抗压能力强
===========================================================
===========================================================
隆重推荐：小强升职记
我曾经觉着自己的效率很高，轻重缓急判断准确，算法极优，干活超快。尽管如此，但当处在某个寂静的时刻，回忆或总结近段时间的种种收获，又会觉着自己的时间浪费很严重，一个很典型的场景：明确的知道有一系列的预订计划待实施，但自己却在无聊的翻看着浏览器中的网页，思维极度发散，甚至有点大脑一片空白的感觉，不知道在做什么，不知道想做什么，不知道接下来会做什么。等回过神意识到自己的无聊，想干点正事儿，眼神一瞥又发现了闪动的QQ/MSN头像，点开查看内容，话题极有意思，参与讨论，或者是看到群内有人推荐的某网页，打开瞧瞧，于是思绪再次飘荡发散无间~~
曾子曰：吾日三省吾身，我虽然实践的不好，但是察觉到自己的不足后，也在有意识的调整，比如尽可能的少开(没说不开)无关网页，尽可能少用即时通讯工具(筒子们反映QQ上找不着我？哎，对不住，兄弟现在确实不咋上)，新邮箱提醒取消显示等等，以保证思绪不被干扰，老实讲这些举措对集中精力做事确实有助力。
虽然自己早就有制订工作计划的习惯，但是，由于日程安排上执行的不好，工作效率并不稳定，快时极快，慢时也能慢到自己都能察觉的超乎寻常的慢，使得日常计划常被拖延，我能够做的更好，无数次我这样对自己说，可是迟迟没找到落实的方法。我知道我陷入到时间管理上的困境，尽管看的通透，却没有能力脱身。
如同人人都知道时间的宝贵，可是平日最常见的情形却是随意的挥霍~~
庆幸的是，终于，还是让我读到了这本书：小强升职记。看书名，似乎会让人觉着这又是本泛泛而谈的职场成功学，实际上完全不是如此。这是一本实践性很强的时间管理方面的优秀图书，介绍的是号称风靡美日的GTD(Getting Things Done)时间管理法。
这本书虽然写的是听起来枯燥的管理方法，可是作者笔法高明，写得故事性/可读性都很强，主线明确，套用主角小强的成长之路，将时间管理的各项技巧，比如“避开时间黑洞的小策略，找到最有效的时间段，确定价值观。。。”等等，通过主角小强的职场实践一一展现，借助小强成长过程中的困惑/疑虑/难题，作者也成功的将枯燥的理论知识点，如“猴子法则，四象限原则”等引申开来，甚至大到“工作和人生的规划”这类主题都讲的形象生动。
我注意到技术部的开发同事们近段时间任务繁重，持续加班加点追赶工期，我感到在这个关键的阶段，“小强升职记”这本书一定能给大家带来实质性帮助。
我一直都觉着与其加班“抢时间”，不如有效利用时间，高效的工作。
就像书中提到的那样“水流的方向是由渠道决定的，没有渠道的水只会向四面八方渗透，然后干枯在土地之中，永远也到不了大海。时间也是一样，如果不给它合适的渠道，它会消失于无形。我们学习时间管理正是为了掌握自己的渠道，让时间的涓涓细流流向我们想让它去的地方。”
隆重推荐：小强升职记
曾听说“高效能人士的七个习惯”这本书是锤炼高效管理的圣经，扉页上为这本书做推荐序的都是国际政/企业的高层人物，买来后我也翻过数十页，书里说的很好，但感觉距离自己太远，当然这应该是个人层次太低的缘故。图书市场还有一本时间管理方面的畅销书：高效冠军。在我看来，高效冠军与小强升职记两本书读一即可，两本书关键内容相似度不低于80%，只是出现的顺序不同，描述的方式不同。看评论“高效冠军”更被推崇，但是我觉着对我来说小强升职记更适合我，当然，这应该还是我个人层次太低的缘故:)
另外还发现一个很有意思的现象，业内颇多赞誉的“高效能人士的七个习惯”和“高效冠军”两本书网上找不到完整的电子版，各大书城倒是敞开了卖，我是很不情愿的买了实体书，而个人感觉对我帮助很大的“小强升职记”，想去买实体书时却发现各大商城均缺货，网上倒是轻易就找到了全本的电子版，这是个么什情况，又是我个人层次太低的缘故吗~~
===========我是分隔线===============
书中提供了职业价值观的计算表(见PDF版本)，由于题目较多，挨个计算不易，附一条SQL，可用于生成计算结果
计算的SQL:
with t1 as
(select rownum id, column_value c
from
table(sys.odcivarchar2list('c','c','b','c','c','c','c','c','c','d','d','b','b','b','b','b','b','d','c','c','d','b','b','b','d','c','b','c','c','c','c','b','c','b','c','c','b','d','c','c','c','c','c','b','b','c','b','c','d','b','c','d'))),
tt
as
(select rownum rn, c, decode(c, 'a', 5, 'b', 4, 'c', 3, 'd', 2, 1)
score
from t1)
select sum(score), '得他主义' from tt where rn in (2, 30,
36, 46) union all
select sum(score), '美感' from tt where rn in (7, 20, 41,
52) union all
select sum(score), '智力刺激' from tt where rn in (1, 23, 38, 45)
union all
select sum(score), '成就感' from tt where rn in (13, 17, 44, 47)
union all
select sum(score), '独立性' from tt where rn in (5, 15, 21, 40) union
all
select sum(score), '社会地位' from tt where rn in (6, 28, 32, 49) union
all
select sum(score), '管理' from tt where rn in (14, 24, 37, 48) union
all
select sum(score), '经济报酬' from tt where rn in (3, 22, 39, 50) union
all
select sum(score), '社会交际' from tt where rn in (11, 18, 26, 34) union
all
select sum(score), '安全感' from tt where rn in (9, 16, 19, 42) union
all
select sum(score), '舒适' from tt where rn in (12, 25, 35, 51) union
all
select sum(score), '人际关系' from tt where rn in (8, 27, 33, 43) union
all
select sum(score), '变异性' from tt where rn in (4, 10, 29, 31) order by
1
===========================================================
===========================================================
配置CACTI监控MySQL数据库状态(1)准备工作
MySQL数据库做为开源数据库软件中的佼佼者，虽然应用领域众多，但其自身在性能监测方面很不给力，尽管MySQL也提供的专用了GUI工作，可是监测只是其中的一个很小的功能点，监测项少且很不灵活，当拥有多个MySQL数据库实例时，如何能够高效快速的查看众多实例的性能状态，想必很多MySQL DBA都在苦苦寻找~~
近日三思经过一凡尝试，在多个流行方式中最终选择通过Cacti监测（注意是监测而非监控）MySQL数据库状态。借助cacti+rrdtool强大的绘图功能，加上专用的mysql模板，能够灵活快速的创建对多个MySQL实例的监测。
下面简要罗列Cacti监测MySQL性能状态的配置。
Cacti是一套拿PHP编写的应用软件，因此需要有PHP+APACHE的运行环境，出图是基于RRDTool，数据存储则保存在MySQL数据库中，因此安装Cacti前需要首先安装下列关联的软件：
- RRDTool：
- MySQL：
- PHP：
- WebServer(Apache/IIS等)：
如果是RPM方式安装，需要下列RPM包：
- httpd
- php
- php-mysql
- php-snmp
- mysql
- mysql-server
- net-snmp*
０、准备工作
本次安装Cacti及相关软件均为源码编译方式安装，首先下载相关的软件源码包：
主角：
Cacti：http://www.cacti.net/downloads/
幕后主角：
Apache：http://httpd.apache.org/download.cgi
Php：http://www.php.net/downloads.php
MySQL：http://dev.mysql.com/downloads/mysql/
RRDTool：http://oss.oetiker.ch/rrdtool/download.en.html
NET-SNMP：http://net-snmp.sourceforge.net/
===========================================================
===========================================================
处理MySQL复制环境Slave故障的一个案例
处理一则MySQL Slave环境出现ERROR 1201 (HY000): Could not initialize master info structure的案例。
冷备份方式复制一份新的slave，初始化参数中已经修改了相关文件路径及server_id等关联参数。
但在启动slave时发现error_log中出现下列错误信息：
120326 11:10:23 [ERROR] /usr/local/mysql//libexec/mysqld: File '/data/mysqldata/3306/binlog/mysql-relay-bin.000002' not found (Errcode: 2)
120326 11:10:23 [ERROR] Failed to open log (file '/data/mysqldata/3306/binlog/mysql-relay-bin.000002', errno 2)
120326 11:10:23 [ERROR] Failed to open the relay log '/data/mysqldata/3306/binlog/mysql-relay-bin.000002' (relay_log_pos 126074557)
120326 11:10:23 [ERROR] Could not open log file
120326 11:10:23 [ERROR] Failed to initialize the master info structure
由于新的slave改变了服务端口和文件路径，分析应该是由于mysql-relay-bin.index中仍然保存着旧relay日志文件的路径，而这些路径下又找不到合适的文件，因此报错。
对于这类问题解决起来是比较简单的，重置slave的参照即可，执行命令如下：
mysql> reset slave;
Query OK, 0 rows affected (0.01 sec)
mysql> change master to
-> master_host='10.0.0.101',
-> master_port=3306,
-> master_user='repl',
-> master_password='repl',
-> master_log_file='mysql-bin.000011',
-> master_log_pos=1;
ERROR 29 (HY000): File '/data/mysqldata/3306/binlog/mysql-relay-bin.000001' not found (Errcode: 2)
看来应该还是mysql-relay-bin.index的问题，删除该文件及关联的relay-bin文件。再次配置master：
mysql> change master to
-> master_host='10.0.0.101',
-> master_port=3306,
-> master_user='repl',
-> master_password='repl',
-> master_log_file='mysql-bin.000011',
-> master_log_pos=1;
ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
出现了新的错误，按照提示查看error_log也没发现更多错误信息,error_log中只是显示一条：
120326 11:14:27 [ERROR] Error reading master configuration
在操作系统端查看master/slave的配置文件，发现是两个0字节文件：
-rw-rw---- 1 mysql mysql 0 Mar 26 11:13 master.info
-rw-rw---- 1 mysql mysql 0 Mar 26 11:13 relay-log.info
会不会是这个原因呢，直接删除这两个文件，然后尝试重新执行change master：
mysql> change master to
-> master_host='10.0.0.101',
-> master_port=3306,
-> master_user='repl',
-> master_password='repl',
-> master_log_file='mysql-bin.000011',
-> master_log_pos=1;
Query OK, 0 rows affected (0.00 sec)
成功，启动slave并查看状态：
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.101
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000011
Read_Master_Log_Pos: 101
...........
故障解决。
===========================================================
===========================================================
索引优化使MySQL整机负载降低百倍的一个案例~
收到某个MySQL服务器负载高于预警的报告，连接到该服务器后，首先查看负载情况：
[jss@BKmysql-03 ~]$ w
16:34:33 up 54 days, 4:22, 5 users, load average: 67.31, 70.10, 51.90
loadavg已经飙到双位数了，确实非常高，通过TOP查看进程的占用如下：
[jss@BKmysql-03 ~]$ top
top - 16:34:40 up 54 days, 4:22, 5 users, load average: 67.77, 70.15, 52.01
Tasks: 198 total, 3 running, 195 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.4%us, 0.2%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 33554432k total, 32247564k used, 1306868k free, 426440k buffers
Swap: 49150856k total, 80k used, 49150776k free, 20735220k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22646 mysql 15 0 9.9g 5.5g 7036 R 614.4 17.3 9267:32 mysqld
...................
...................
top - 16:35:08 up 54 days, 4:23, 5 users, load average: 70.47, 70.67, 52.77
Tasks: 205 total, 3 running, 202 sleeping, 0 stopped, 0 zombie
Cpu0 : 7.1%us, 1.4%sy, 0.0%ni, 91.0%id, 0.1%wa, 0.0%hi, 0.3%si, 0.1%st
Cpu1 : 1.0%us, 0.4%sy, 0.0%ni, 98.5%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.5%us, 0.0%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.4%us, 0.0%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.4%us, 0.0%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.5%us, 0.0%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.4%us, 0.0%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.8%us, 0.0%sy, 0.0%ni, 99.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 33554432k total, 32254368k used, 1300064k free, 426440k buffers
Swap: 49150856k total, 80k used, 49150776k free, 20733516k cached
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22646 mysql 16 0 9.9g 5.5g 7036 R 793.2 17.3 9271:10 mysqld
18558 mysql 17 0 66048 1120 952 S 0.4 0.0 0:00.01 mymon.sh
1 root 15 0 10348 684 576 S 0.0 0.0 0:00.51 init
2 root RT -5 0 0 0 S 0.0 0.0 0:01.76 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
初始分析，CPU
上面的信息已经非常清晰的列出了最占资源的进程：mysqld，不过由于该机同时跑有多个MySQL实例，还需要进一步确认，最占资源的进程号是由哪个进程持有：
[jss@BKmysql-03 ~]$ ps -ef | grep 22646
jss 18584 18307 0 16:35 pts/5 00:00:00 grep 22646
mysql 22646 21712 12 Feb02 ? 6-10:32:03 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysqldata/3307/my.cnf --basedir=/usr/local/mysql --datadir=/data/mysqldata/3307/data --plugin-dir=/usr/local/mysql/lib/plugin --log-error=/data/mysqldata/3307/mysql-error.log --open-files-limit=8192 --pid-file=/data/mysqldata/3307/mysql.pid --socket=/data/mysqldata/3307/mysql.sock --port=3307
进入mysql命令行模式连接到该实例，查看当前MySQL的进程列表，发现一堆Query状态进程正在处理：
mysql> show processlist;
+-----------+----------------------+----------------------+----------+---------+---------+------------------+-----------+
| Id | User | Host | db | Command | Time | State | Info |
+-----------+----------------------+----------------------+----------+---------+---------+------------------+-----------+
..............
..............
| 360359253 | apps_read | 192.168.31.55:37464 | apps | Query | 613 | Sending data | SELECT ......... |
| 360371212 | apps_read | 192.168.31.52:34632 | apps | Query | 575 | Sending data | SELECT ......... |
| 360371411 | apps_read | 192.168.31.59:4209 | apps | Query | 518 | Sending data | SELECT ......... |
| 360371805 | apps_read | 192.168.31.66:44717 | apps | Query | 595 | Sending data | SELECT ......... |
...............
...............
+-----------+----------------------+----------------------+----------+---------+---------+------------------+-----------+
527 rows in set (0.00 sec)
大部分进程均在执行同一条SQL语句：
SELECT q.* FROM ask_questions q WHERE q.object_id=????? AND q.status = 1 AND product_id=1 AND NOT EXISTS (SELECT a.id FROM ask_answers a WHERE a.question_id=q.id AND a.status = 4) ORDER BY q.create_date DESC LIMIT 0, 8
查看该语句执行计划：
mysql> use apps;
Database changed
mysql> explain SELECT q.* FROM ask_questions q WHERE q.object_id=????? AND q.status = 1 AND product_id=1 AND NOT EXISTS (SELECT a.id FROM ask_answers a WHERE a.question_id=q.id AND a.status = 4) ORDER BY q.create_date DESC LIMIT 0, 8;
+----+--------------------+-------+-------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-------+-------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
| 1 | PRIMARY | q | ref | ind_ask_questions_object_id | ind_ask_questions_object_id | 5 | const | 565 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | a | index | NULL | idx_data_id_stat | 10 | NULL | 159386 | Using where; Using index |
+----+--------------------+-------+-------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
2 rows in set (0.01 sec)
通过执行计划可以看出该语句子查询的执行计划相当的不乐观，通过idx_data_id_stat索引每次居然需要遍历近16w记录。我们知道索引扫描属于随机I/O，频繁并且大量的随机I/O性能显然是很糟糕的。
看看子查询表的索引情况：
mysql> show index from ask_answers;
+-------------+------------+---------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------------+------------+---------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| ask_answers | 0 | PRIMARY | 1 | id | A | 144039 | NULL | NULL | | BTREE | | |
| ask_answers | 1 | ind_ask_answers_object_id | 1 | object_id | A | 5144 | NULL | NULL | YES | BTREE | | |
| ask_answers | 1 | idx_data_id_stat | 1 | create_date | A | 180 | NULL | NULL | YES | BTREE | | |
| ask_answers | 1 | idx_data_id_stat | 2 | question_id | A | 180 | NULL | NULL | | BTREE | | |
| ask_answers | 1 | idx_data_id_stat | 3 | status | A | 180 | NULL | NULL | | BTREE | | |
+-------------+------------+---------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
5 rows in set (0.00 sec)
强大呀，MySQL也有索引跳扫了吗，居然选择了idx_data_id_stat这项索引。
问了一下同事，原来是不久前根据慢查询的情况刚刚创建的，是为了优化查询时where create_date between ...的查询条件而创建，考虑到该查询同时需要过滤question_id和status，就创建了三列的复合索引。但是没想到给未附带create_date的查询语句造成了影响。
尽管该表并不大，十余万条记录，但每次查询都可能导致的十几万次随机读还是致使系统负载急速升高。
首要举措是删除这个不合理的索引：
mysql> alter table ask_answers drop index idx_data_id_stat;
Query OK, 0 rows affected (40.40 sec)
Records: 0 Duplicates: 0 Warnings: 0
查看执行计划，即使全表扫也会比走索引要快，因为全表扫多是顺序读：
mysql> explain SELECT q.* FROM ask_questions q WHERE q.object_id=????? AND q.status = 1 AND product_id=1 AND NOT EXISTS (SELECT a.id FROM ask_answers a WHERE a.question_id=q.id AND a.status = 4) ORDER BY q.create_date DESC LIMIT 0, 8 ;
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
| 1 | PRIMARY | q | ref | ind_ask_questions_object_id | ind_ask_questions_object_id | 5 | const | 565 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | a | ALL | NULL | NULL | NULL | NULL | 144039 | Using where |
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-------+--------+-----------------------------+
2 rows in set (0.00 sec)
然后再次show processlist时，基本上已经看不到Command列不等于Sleep的进程了：
mysql> show processlist;
+-----------+----------------------+----------------------+----------+---------+---------+------------------+-----------+
| Id | User | Host | db | Command | Time | State | Info |
+-----------+----------------------+----------------------+----------+---------+---------+------------------+-----------+
..............
..............
| 360310280 | apps_read | 192.168.31.58:64731 | apps | Sleep | 1 | | NULL |
| 360311110 | apps_read | 192.168.31.54:6988 | apps | Sleep | 1 | | NULL |
| 360311122 | apps_read | 192.168.31.58:64980 | apps | Sleep | 0 | | NULL |
..............
64 rows in set (0.36 sec)
进程数也大幅下降。
再次查看整机负载，已经在明显下降：
[mysql@BKmysql-03 3307]# w
16:46:05 up 54 days, 4:44, 4 users, load average: 18.72, 45.33, 55.43
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
jss pts/5 203.xx.xx.83 16:34 24.00s 0.13s 0.02s sshd: jss [priv]
jss pts/6 203.xx.xx.83 16:36 0.00s 0.05s 0.02s sshd: jss [priv]
[mysql@BKmysql-03 3307]# w
16:46:34 up 54 days, 4:44, 4 users, load average: 13.48, 41.53, 53.84
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
jss pts/5 203.xx.xx.83 16:34 10.00s 0.13s 0.02s sshd: jss [priv]
jss pts/6 203.xx.xx.83 16:36 0.00s 0.05s 0.02s sshd: jss [priv]
几分钟后，loadavg整机负载基本降至2-3，但是全表扫描也仍不理解，需要进一步优化。
考虑到该表除了上面这种查询形式外，还有基于create_date列的查询，因此决定创建两个索引，如下：
mysql> alter table ask_answers add index ind_create_date (create_date),add index ind_question_state (question_id,status);
Query OK, 0 rows affected (1.21 sec)
Records: 0 Duplicates: 0 Warnings: 0
没有了锁的竞争，这次创建索引操作执行也非常快，秒级完成。
再次查看执行计划：
mysql> explain SELECT q.* FROM ask_questions q WHERE q.object_id=????? AND q.status = 1 AND product_id=1 AND NOT EXISTS (SELECT a.id FROM ask_answers a WHERE a.question_id=q.id AND a.status = 4) ORDER BY q.create_date DESC LIMIT 0, 8 ;
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-----------------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-----------------+------+-----------------------------+
| 1 | PRIMARY | q | ref | ind_ask_questions_object_id | ind_ask_questions_object_id | 5 | const | 565 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | a | ref | ind_question_state | ind_question_state | 5 | apps.q.id,const | 720 | Using index |
+----+--------------------+-------+------+-----------------------------+-----------------------------+---------+-----------------+------+-----------------------------+
2 rows in set (0.00 sec)
重新多次刷新show processlist已经完全看不到有正在执行的任务了。
此时，整机的负载也恢复到极低的水平：
[mysql@BKmysql-03 3307]# w
17:55:46 up 54 days, 5:43, 3 users, load average: 0.25, 0.09, 1.32
从70到0.x，数百倍的差距。对于MySQL数据库来说，一条坏SQL的确有可能拖死整个服务。
===========================================================
===========================================================
MySQL数据库mysqldump命令备份异常的一个案例
MySQL中的命令行mysqldump做为常用的数据备份工具，虽说性能稍差，但优在易于调用，从长期应用的情况来看其表现也相当稳定，并且老实讲MySQL数据库下逻辑备份确实没有太多选择，因此mysqldump应用极为广泛，三思本人也是经常使用这个命令倒腾数据，整体感觉是个挺美好的东西，不过上周遭遇一次案例，认识到我对mysqldump的认识还有不足，记录下来，供有心的朋友参考。
事情是介个样子的，mysqldump命令常规方式创建备份拉到某机器上恢复，恢复执行很成功，一条错误信息都没看着，但等恢复完登录到数据库中一瞅，你猜怎么地，数据不全~~
第一反应当然是查看备份文件，经过检查，果然，恢复操作确实没有问题，因为备份集中的内容就不全，那么，为什么备份集内容不全呢~~
幸好原有执行场景均有记录，分析发现，原来是在导出某个视图对象时报错，mysqldump自动中止，因此所有该对象之后的就都没备份了~
这种情况模拟重现很简单，操作如下：
mysql> create table j1 (id int,vl varchar(100));
mysql> create view j1_view as select * from j1;
mysql> rename table j1 to j2;
# mysqldump --tables j1 j1_view > bak.sql
mysqldump: Got error: 1356: View 'test.j1_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them when doing LOCK TABLES
创建备份时，view对象引用的表对象不存在，执行LOCK TABLES失败，于是mysqldump就中止了，这其实真不怪mysqldump，因为mysqldump执行过程中遇到任何问题，默认情况下都是直接退出。
那么怎么处理这种情况呢，两种思路：
１、修正无效的视图，这点可以通过information_schema.views.IS_UPDATABLE列来判断，当IS_UPDATABLE列值为NO时，说明该视图状态异常，需要处理了；
２、执行mysqldump时附加--force参数，该参数功能是当遇到错误时忽略，继续执行后面的操作；
这个参数提供类似ORACLE数据库中exp命令的ignore=y参数的功能，事实上在ORACLE数据库中执行exp时通常都会指定ignore，对应到MySQL数据库，我想在执行mysqldump命令行过程中，--force参数也应做为必备参数调用。
===========================================================
===========================================================
隆重推荐：男人来自火星，女人来自金星
从前有一天，火星人遇见了金星人，于是他们相爱了。开始，他们接受并尊重对方的不同，因而关系融洽，生活幸福。后来，他们来到了地球上。一天早晨醒来，他们都得了健忘症，忘了他们本是来自不同的星球。
于是，他们开始了相互之间的冲突……”这就是约翰。格瑞在他的新书□编注：此前言为该书初版时所写□《男人来自火星，女人来自金星》中为说明男人和女人之间关系时所使用的比喻。虽然每个人都知道男人和女人是不同的，但怎样的不同对大多数人来说却并不清楚。这个比喻告诉人们，男人和女人就像是来自不同的星球，说不同的语言，有不同的感情需要，按不同的思维方式思考。如果不了解这些不同，男人和女人在相处时，就会常常误解对方，不知道为什么会出现这么些矛盾，而且不知道去如何解决。
于是，他们开始了相互之间的冲突……”这就是约翰。格瑞在他的新书□编注：此前言为该书初版时所写□《男人来自火星，女人来自金星》中为说明男人和女人之间关系时所使用的比喻。虽然每个人都知道男人和女人是不同的，但怎样的不同对大多数人来说却并不清楚。这个比喻告诉人们，男人和女人就像是来自不同的星球，说不同的语言，有不同的感情需要，按不同的思维方式思考。如果不了解这些不同，男人和女人在相处时，就会常常误解对方，不知道为什么会出现这么些矛盾，而且不知道去如何解决。
对于我们这些生活在异国的游子们，不论是先来的，还是后到的，每个人都会碰到许许多多的烦恼和困惑，或学业上的，或工作中的。家庭的和睦与温暖在我们的生活中更是举足轻重。但怎样才能使我们拥有一个甜蜜幸福的夫妻（男女）关系，享受到家庭的那份温馨和安宁，减轻我们心中的忧愁和失落，却仅仅有爱是不够的。相信约翰。格瑞这本书中的内容会对我们在这方面有所启迪，故摘译其中的若干章节，以飨大家。全文共分这样六小节：价值观的不同，对待压力的方式不同，女人的用语和男人的沉默，橡皮筋的男人和波动的女人，爱的计分方法不同，和情感需要的不同。最后，愿天下火星人金星人彼此更多一份了解，美满幸福地生活在地球上。
１．价值观的不同
女人对男人的最常抱怨是：他不听她说话。当她跟他说她的问题时，他要不心不在焉，要不就给她一个答案。可她想要的却是他的理解和关注。
男人对女人的最常抱怨是：她总是想改变他。不管他如何拒绝她的忠告和帮助，她仍是一有机会就告诉他该做什么，如何做。可他希望得到的却是她的完完全全的接受。
其原因，是男人和女人的价值观不同。
男人重视力量，能力，效率和成就。他们的自我价值是通过所获得的成就来定义的。能否实现预定的目标或独立完成要做的事情是他们能力的表现。所以男人最不愿意让人告诉他该如何做事。他没要求你就主动去帮助他，是对他的不信任，不相信他能独立完成要做的事情，这是对他的冒犯。男人对此非常敏感。
女人重视感情，交流，美和分享。她们花很多时间在相互帮助和相互安慰上。她们的自我价值是通过感觉和相处的好坏来定义的。只有分享和交流才使她们感到满足。当别人谈话时，她们从来不提供答案。耐心地倾听别人的谈话，理解别人的感觉，是她们爱和尊重别人的表示。
女人有一种观察并考虑到别人需要的直觉。她天性的一部分就是不断改进做事的方式，把事情做得更好。当她关心一个男人时，她就会向他指出什么地方需要改进，应该如何改进。在她，那是关心和爱护，且不知却恰恰触动了男人的那个敏感点。结果，在无意中她伤害和冒犯了她所爱的男人。
男人碰到问题时，不轻易说出来，他会将问题留给自己。只有当他需要从别人那里得到答案时，他才跟别人说。所以，一旦他跟别人谈论自己的问题，便意味着请求答案。因此当女人跟他说她的问题时，他自然以为她也在请求答案。他向她提供他的答案，那是他爱她帮助她的举动。
可是他发现，她得到他的答案后，并没有像他所期望那样感觉开始变好。这时，他便很难再继续听下去。因为他的答案被拒绝了，这让他感到自己的无能。其实，女人谈论问题是为了感情上的勾通，而不是为了答案，只要男人用心去听，表示他的关注，她就会感觉好起来。
了解了这一点，男人和女人就都会变得更加聪明。男人学会了耐心倾听女人的说话，女人学会了完全接受男人的做事方式。
２．对待压力的方式不同
当男人遇到压力时，他会变得心事重重，沉默寡言。这时他的思维走进了一个洞穴。他在洞穴里独自思考自己的问题。其它的一切他都视而不见。
如果他找到了解决问题的办法，便会走出洞穴，恢复以前的样子。如果他一时没有找到办法，他就会做些像看报纸看电视一类的事情，使自己忘掉烦恼，慢慢恢复正常。
和在洞穴里的男人相处是很困难的。这时侯的他，冷漠，疏远，自私。如果他回家后对女人说出他的问题，那么她也许会好受些。但是他不说，她不知道他有压力，她只觉得他不关心她，不理睬她。
女人以为男人也会跟她们一样，心里有问题就讲出来。在她们看来，和另一个人讲出自己的问题，是对那人的信任，而不是负担和责任。因此他不对她讲，同时也伤害了她。
了解到男人的这种反应是他应付压力的方式，而不是冲着她的，会有助于女人度过这种困难时候。当然这并不意味她的痛苦就完全消失。男人应意识到自己在洞穴里时是如何的冷漠，他要理解她的痛苦感觉是正当的。她有权力说出这种感觉，如同他有权力进入他的洞穴一样。如果她的这种感觉也不被理解，那么她的伤害就很难彻底得到医治。
当女人遇到压力时，她会一下子不知所措，情绪波动。这时她会在信任的人面前将烦恼说出来。谈论是女人应付压力的自然健康反应。当她感到她的话被人听进去了，她的感觉就会好起来。
她在说问题时，完全是杂乱无章，轻重不分的。她不像男人那样集中在一个问题上，而是将问题扩张，大大小小的问题全摆出来，甚至亲戚朋友的。她并不关心能否找到解决问题的办法，只是表达自己的感觉，只要得到理解和认同。
听女人这时的述说，对男人也很困难。因为男人只在指责别人或请求答案时才说出问题，所以，如果她在说时不太生气，他会认为她在寻求解决问题的答案，如果她在说时非常生气，他会认为她在指责他。若是前者，她说一个问题，他给她一个答案，可她继续更多的问题，有些是根本不存在答案的问题，他不知如何帮她。若是后者，他就会抽出他的剑防卫自己，他向她解释，企图阻止她的指责。然而，他越防卫，她越生气。
其实，如果他很聪明，只是听，那么一会儿，在她抱怨过他以后，她就会转移话题，说其它的问题，她也不是要他解决她的问题。他只要听她说，她就会觉得得到了支持。
总之，期望在洞穴里的男人有爱心和期望正在生气的女人有理智一样是不现实的。所以，女人要学会尊重男人有走进洞穴应付压力的需要，并不是他不再爱她。男人要学会尊重女人有谈论各种问题的需要，并不是指责他或向他寻求答案。
３．女人的用语和男人的沉默
当女人说：“你从来就没爱过我”，男人也许会回答说：“什么叫‘从来不’？”于是一场争执在所难免。为了强调她的感觉，女人说话时喜欢用“从来不”、“一点儿也不”、“总是”等一类的词。她不要你去抠字眼，她希望你从中了解她的感觉。男人在听到这样的话后，可参考下面的“金火词典”，理解她的真正含意，从而作出积极的回答。
如果说，对男人的最大挑战是当女人谈论她的感情时，他能正确理解她的话，并支持她，那么，对女人的最大挑战就是当男人不说话时，她能正确理解他的沉默并给予支持。
事实上，男人和女人只要做些小改变，不用牺牲各自的本性，相互的关系就可以得到改善。男人要学会说这几个字：“我会回来的。”你可以在走进洞穴时，告诉你的女人，你会回来的。女人实在需要这样的保证，特别是你想让她们少些焦虑的话。
如果因为女人不高兴他走进洞穴，男人就放弃他的这个需要，那他就犯了个大错。由于否认了自己的本性，他会变得易怒，过分敏感，消极，无精打采，吝啬。而且，他不知道他为什么会这么不快乐。
女人要学会说这几个字：“这不是你的错。”有了这几个字，当你在向他述说你的感情时，你就不会让它们听起来是在责备他。女人不需要压抑自己的感情，也不需要为了支持男人而改变自己的感情。然而她的确需要用一种不让他感到被责备的方式来表达自己的感情。
印第安人有这样一个说法：在年轻的女人结婚之前，母亲会告诫她，男人在生气或心绪不佳时会撤进他的洞穴，女人千万不要跟过去。如果她跟过去，守在洞边的龙就会喷出火来烧着她。
要让女人不替男人着想是很困难的。对女人来说，当所爱的人不高兴时，自己怎么能快乐呢？男人当然不希望女人快乐是因为他生气，但他确实希望她快乐。如果他的女人无忧无虑，男人也较容易走出洞穴。
那么，怎样做才能缩短男人呆在洞穴里的时间？女人可做这六件事：不要否认他有走进洞穴的需要；不要不断向他问问题，试图帮他解决问题；不要总是询问他的感觉以示安慰；不要守在洞边等着他出来；不要为他焦虑，觉得对不起他；做让你自己快乐的事情。
４．橡皮筋的男人和波动的女人
男人像橡皮筋，是指男人与女人的亲密程度。既使一个男人爱一个女人，他与她的关系也有亲近与疏远的循环。这不是他的决定或选择，是自然发生的。既不是他的错，也不是她的错。
男人之所以疏远是因为他有独立，自主的需要。分开一段时间后，他又会有爱和亲近的需要，那么他就会弹回来。
关系刚开始时，他的橡皮筋全部伸开着，他是强有力的。他希望接近她，打动她，满足她。他成功了，她也想接近他，她打开心扉，让他更近，更近一些。他们获得了亲密，他感觉奇妙无比。但一段时间后，发生了一些变化。
就像橡皮筋，靠得太近了，没有了力量和弹性。即使这时他们的关系很好，他也不可避免地开始有一种独立的渴望。从某种程度上说，与女人的亲近使男人失去了自己。拉开与女人的距离会让他重新建立自己，从而满足他自主的需要。
当男人没有任何理由的疏远时，女人会很惊慌，害怕地跟在他后面。她害怕他永远不再回来，她以为他在期待着她去重新建立亲密。她以为她做错了什么，才使得他这样，但她又不知道是什么原因。她问他，他也没有一个清楚的回答，只是更加疏远。她感到如此地无力，无助。
她不知道，这只是亲密程度循环的一部分。不了解这个循环，男人和女人都很容易开始怀疑他们的爱。女人会以为他不再爱她，而男人由于没有机会疏远，失去亲近的愿望，也会以为他不再爱她。
在学会让男人有他的距离和空间后，女人会发现他确实会回来的。当他撤退时，她要让自己不再跟在他后面，相信一切都正常。每一次他都会回来的。同时不要在他回来后，因为他的疏远而惩罚他。那会阻止他的正常循环。
有的男人也许根本不知道他有疏远的需要。这种男人比较敏感，他们总是设法让女人高兴，为此压制了他们的男性自我。还有的男人也许根本不知道如何亲近。这种男人对疏远没有问题，但他们却不敢回来，其内心深处是害怕自己不值得爱。
在了解到男人的这个秘密后，男人和女人都可以大大地松一口气。聪明的男人，懂得自己的正常循环，在他疏远时向他的女人说一声，他仍对她感兴趣，仍关心她。聪明的女人，在她的男人疏远时，不追随他，不惩罚他，给他想要的空间，完全接受这时的他，她不轻易放弃，相信他会回来的。
女人的情绪像波。当她在波峰时，她给出许多爱，对得到的爱也心存感激。但她的情绪会突然一下子降到波谷，这时的她，内心空虚，需要用爱来充满，可是这时的她，也许没有能力感激得到的爱。不过，这种下降是暂时的。一旦击到谷底，她的感觉会开始变好，情绪会自动上升。
处于爱之中的女人，如阳光一样耀人。大多数男人天真地希望这种光耀持续永远。这是不现实的。生活里充满了节奏。男人有男人的循环，女人有女人的升降。
男人常以为，女人情绪的突然变化，是因为他的缘故。所以当她突然不高兴起来，而他又不知道做错了什么时，他非常的迷惑不解。
男人要知道，当女人往谷底降时，这是她最需要他的时候，需要他给出无条件的爱。她需要他跟她一起朝下走，听她的絮叨，分担她的感情。她不需要他向她解释她不应该朝下落。他不要阻止她的下降，把她从半空中提起。她没有破碎，她只是需要他的爱，耐心和理解。
男人还要知道，即使他支持她，她并不一定会马上感觉好起来。她也许会感觉更糟。这实际上是她得到他的支持标志，他的支持帮助她一落到底。只要到底，她的感觉就会好起来，情绪开始上升。
女人上来后，她又变得可爱悦人。男人通常这时以为，使她下降的那些问题已得到解决。但当她的波又下降时，他发现同样的问题又出现了。他有点不可思议，他觉得这些问题已被解决了。
是什么样的感觉打扰她呢？不安全感，焦虑，不满，困惑，疲倦，绝望，伤感，疑虑等等。如果男人以为他的一次爱的支持就会永久解决女人的这些问题，那他是太天真了。
男人要让女人感觉到她能安全地经历这种波动，否则她会假装一切都一直很好，而压抑自己的负面的感情。负面感情被压抑，正面的感情也同样受到压抑。避免争吵当然是好的，但不是以压抑感情为代价。而且压是压不住的，最终她还会落入谷底，并也许会一发不可收拾。
那么，如果波谷和疏远同时出现怎么办？男人想要空间，女人想要相伴。这时男人可以从这三方面支持女人：首先，你要接受你自己，不能听时，别拭图听她的；其次，你要理解，这时她所需要的比你能给出的多，她的痛苦是合理的；最后，避免争执，告诉她，等你回来后你就能给她应得的支持和爱。
也许女人会说，他这样可以进入洞穴了，我怎么办？他得到了他的空间，我得到了什么？女人得到的是男人在这种时候能给予的最好的。当然这并不意味着女人放弃谈话的需要，而是放弃任何时候她想说他都必须听的要求。男人疏远时，女人该从朋友那里得到更多的支持。如果一个男人是一个女人爱和支持的唯一源泉，那对他的压力太大了。她需要有其他支持的来源，否则，她会不可避免地感到孤立无援。
５．爱的计分方法不同
男人认为，大事的分数要高些，小事的分数要低些。比如，为她买辆新车可能是三十分，帮她倒一次垃圾可能只有一分。基于这种方法，他将他的精力集中在为她做大事上，他相信这样他能最好地满足她。
而女人的计分方法是，不管爱的礼物的大小，都只有一分。一支玫瑰花和月房租的分数是相同的。
女人这种计分方法不只是一种偏爱，而是真正的需要。女人需要各种各样爱的表示。只有一两种爱，不管它们多重要，也不能满足她。
我们可以想像女人有个爱的桶，就跟汽油桶一样，它需要被一次一次地充满。做许多小事是充满女人的爱桶的秘诀。
正如男人要不断为女人做小事一样，女人要感激男人为她做的每件小事。一个微笑，一声谢谢，她就让他知道，他已经得了一分。男人需要这种感激和鼓励。
女人天生会感激男人为她做的小事，这是男人的福份。唯一的例外是，当她觉得分数很不平等时。这时女人不感到男人爱她，她有不满，她已经给了他多于他给出的。这种怨恨情绪妨碍了她感激小事情的能力。
当分数是四十比十时，女人会开始感到非常不满。下意识里，她把他的十分减掉，这下他们的比分是三十比零。数学上可以这么做，但实际上却不是这么回事。她减掉他的分数，他变成只有零分，但他不是零，他没有什么都没做，他给出了十分。他回到家，她冰冷的眼光，冷漠的语气都表明他是零。
这当然不公平，但不平等的分数让她很难感激他做的十分。到这一步，男人由于得不到感激，失去了做更多的动力，他也感到不满。于是她有更多的不满，情况越来越糟。
解决这个问题的办法是从理解对方着手。他需要被感激，她需要被支持。这时女人要负主要责任。她给出太多，致使分数不平等。她应该歇一歇，别给出太多，给他个机会，让他给她一些。而男人这时要理解，她要得到一会儿才能给出，包括他应该得到的感激。如果他继续给出，不因她不感激他而停止给出，那么分数就会慢慢地扳回来。
男人很少故意地多得少给。那为什么结果总是男人给的少呢？那是因为绝对的公平是男人给出的模式。一个男人会认为他一天的工作，已经得了五十分。他回到家里，坐在沙发上，等着她给出她的五十。他不知道，以她的方法，他只得了一分。他不再给出是因为他认为他已经给出很多，他等她给出五十分的爱来持平。他认为这很公平，也是爱，而女人的给出模式是无条件的给。一个女人总是尽她可能地给出。往往只有当她空了，她才注意到她得到的太少。女人开始时不计分，不像男人。女人慷慨地给，并以为男人也做同样的事。
女人不断地给，男人天真地以为她在计着分数，他想他一定还有不少分。他想不到他已经给出的少了。因为按他的公平模式，如果分数已很不平衡，他不会还不断地给出。
如果这时女人向男人要求得到爱和支持，他会给出的。一旦他知道自己给出的少了，他会想方设法地给出的。相反，如果女人不要求，还不停地给，他便以为分数接近平等或者他给出的多些。
有时，男人会给罚分。比如说，女人已经多出十分，但一场争吵之后，他觉得受到伤害，他也许给她负二十，这样她反而少他十分。罚分对俩人的关系很有破坏性。在这种时候，男人要多想女人的好处，原谅她，而不是惩罚她。让她知道她已经伤害了你，给她一个祢补的机会，向她要求你想要的支持。你会发现，这样做，你的感觉会好得多。
６．情感需要的不同
大多数男人和女人不知道他们有不同的感情需要。男人给出男人想要的，女人给出女人想要的。结果，双方都感到不满足。事实是，他们双方都给出了爱，却都不是对方想要的那种。
男人和女人各有六种不同爱的需要。
女人需要
︱
男人需要
︱
关心
︱
信任理解
︱
接受尊重
︱
感激专一
︱
崇拜认同
︱
赞许许诺
︱
鼓励
六种爱中每一种对男人和女人都是同等地重要。当然每个人最终都需要全部十二种爱，但只有这六种爱满足了，他或她才会感激其他种的爱。
了解对方有不同爱的需要是处理好相互关系一个最有力的秘密武器。比如，女人会以为向男人问很多问题是她关心他，是爱的表示。而他却觉得受到控制，是她不信任他。同样地，如果在女人生气时，男人尽量淡化她的问题，给她足够的空间让她自己去考虑，或让她进入洞穴。她会觉得他不关心她，不理解她。
更重要的是，这六种爱是一一对应，相涨相落的。比如，如果一个男人关心并理解一个女人，自然，她也更加信任他。当她信任他时，她就会敞开心胸，完全容纳接受他。其他几种亦然。恕不赘述。
下面的故事虽有些夸张，却说明了解男女爱的不同需要的重要性，应引以为鉴。
一个全身披甲的骑士在原野上纵驰，突然他听到女人急促的呼救声。他催马疾驶，来到一个城堡边。他发现，一个女人被一条龙困住。骑士英勇地抽出他的利剑，杀死了那条龙。城门打开了，全城人都热烈欢迎他，公主也热情款待他。他被英雄般地安置在城中。他和公主相爱了。
一个月后，骑士离城出发了。在他回来的路上，他又听到了呼救声。又一条龙在袭击城堡。骑士纵马抽出剑，准备与龙搏斗。
公主从城塔里跑出来，“别用剑，用这绳套，它更好用。”公主将绳套扔给他，并打手势告诉他怎么用。骑士犹豫了一下，照公主示意的那样，把绳套套在龙的脖子上，然后使劲地拉。龙被杀死了。全城人为他欢呼。
不知怎么的，骑士却觉得自己没什么了不起，不值得全城人的崇拜和信任。在庆祝晚宴上，骑士有点郁郁寡欢。过后，他忘了擦亮他的盔甲。
又一个月后，骑士又出发了。当他佩戴着他的剑离开时，公主提醒他小心，并告诉他带上绳套。在回来的路上，他又看到一条龙在袭击城堡。这一次，当他带着剑冲上前来时，他犹豫了一下，他想也许他该用绳套。在他犹豫的时候，龙喷出火来，火伤了他的右臂。困惑中，他抬头看见他的公主在城堡的窗口朝他挥舞。
“用毒药。”公主喊道，“绳套不好用。”
公主扔给他毒药，他将它们喷进龙的口里。龙被杀死了。全城人又一次欢呼。但骑士却感到羞耻。
又一个月后，骑士再次出发。当他带着他的剑离开时，公主提醒他小心，让他带上绳套和毒药。他对公主的建议有点不痛快，但还是带上了。
在他这一次的旅途中，他又听到一个女人的呼救声。当他冲向呼救声时，他的忧郁消失了，他的自信恢复了。但当他抽剑准备与龙拼搏时，他又一次犹豫了，他想，我该用剑，绳套，还是毒药？公主会说什么？
在这当口，他记起遇到公主之前的自己，那时他只有一把剑。于是他重新获得了信心，他扔掉绳套和毒药，用他的剑杀死了那条龙。全城人再一次欢呼。
但是，身着闪亮盔甲的骑士再也没有回到他的公主身边。
