• 一个 master 可以有多台 slave。
• Slave 机器可以被其他的 Slave 服务器连接。除了多台 Slave 可以连接到同一台 Master，多台 Slave 也可以连接到同一台 Slave 机器。
• 在 master 端 Redis replication 是非阻塞的,这表示 Master 即使在执行和其他 Slave 的同步命令时，依旧可以完成别的查询服务。
• 在 Slave 端，Replication 也是非阻塞的。如果你在 redis 的配置文件 redis.conf 中做过配置，Slave 在没有完成一次同步时，依旧可以使用旧版本的数据来提供查询服务。另外你还可以配置 Slave，当 Slave 和 Master 的连接断开时，若有客户端查询，则返回错误。
• Replication 可被用于解决性能问题和简单的数据冗余问题。当你有大量的 read-only 请求时，多台 Slave 可以很好的为你的系统分担压力。比如繁重的 SORT 操作可以分配给 Slave 来完成。
• Replication 可以避免在 Master 端执行 save 指令，只要在 Master 端的 redis.conf 文件注释掉 “save” 即可。接着将某台 Slave 配置为实时 save。

Redis replication 是如何工作的？

如果你配置好一台 Slave，连接建立之后它会发送一个 SYNC 命令。而本次连接是首次连接还是再连接无关紧要。

接着 master 开始后台 save，并且开始整理所有会影响到数据库的新命令。当后台 save 完成后，master 将保存在硬盘上的数据文件加载到内存中并发送给 slave。Master 会将所有累计的和新的会修改到数据库的命令都发给 Slave。这个过程被设计成使用命令流的形式，且和 Redis 自己的协议采用同一种格式。

你可以用 telnet 自己试试看。当 Redis 在工作的时候 telnet 到它的端口，然后打入 SYNC 命令。这时候你会看到一大块的数据传输，接着你会看到所有 master 接受到的命令会在 telnet 回话中重复。

当 Slave 和 Master 的连接断开后，Slave 可以自己重连至 Master。当 Master 收到多个并发的 Slave 同步请求时，它仅在后台用一个 save 进程来给多个 Slave 提供服务。

当 Master 和 Slave 在连接中断后重连上了，他们需要做一个完整的同步。

配置

Replication 的配置非常简单: 只要把下面这行配置加入 Slave 的配置文件:

slaveof 192.168.1.1 6379

当然你需要把 192.168.1.1 6379 换成你 Master 的地址和端口。 或者你可以执行 SLAVEOF 命令来触发 master 和 slave 来做一次同步。

配置 Slave 和 Master 之间的验证

如果你的 Master 需要一个密码验证。Slave 端的配置也非常简单。

用 redis-cli 在已经开启的 Slave 实例上执行命令：

config set masterauth

把下面内容加入配置文件，如果你想要永久保存密码的话：
本文由 latteye 翻译，文章永久地址为 http://latteye.com/2011/11/redis-replication.html

masterauth “password”
请将双引号替换为大于小于号。

原文地址 Redis Replication,此译文整理于 latteye doc 页面。

No related posts.

• 二进制安全的 字符串 string
• 二进制安全的 字符串列表 list of string
• 二进制安全的 字符串集合 set of string，换言之：它是一组无重复未排序的element。可以把它看成Ruby中的 hash–其key等于element，value 都等于‘true’。
• 有序集合sorted set of string，类似于集合set，但其中每个元素都和一个浮点数score（评分）关联。element根据score排序。可以把它看成Ruby中的 hash–其key等于element，value等于score，但元素总是按score的顺序排列，无需额外的排序操作。

Redis 键

Redis key值是二进制安全的，这意味着可以用任何二进制序列作为key值，从形如”foo”的简单字符串到一个JPEG文件的内容都可以。空字符串也是有效key值。

关于key的几条规则：

• 太长的键值不是个好主意，例如1024字节的键值就不是个好主意，不仅因为消耗内存，而且在数据中查找这类键值的计算成本很高。
• 太短的键值通常也不是好主意，如果你要用”u:1000:pwd”来代替”user:1000:password”，这没有什么问题，但后者更易阅读，并且由此增加的空间消耗相对于key object和value object本身来说很小。当然，没人阻止您一定要用更短的键值节省一丁点儿空间。
• 最好坚持一种模式。例如：”object-type:id:field”就是个不错的注意，像这样”user:1000:password”。我喜欢对多单词的字段名中加上一个点，就像这样：”comment:1234:reply.to”。

字符串类型

这是最简单Redis类型。如果你只用这种类型，Redis就像一个可以持久化的memcached服务器（注：memcache的数据仅保存在内存中，服务器重启后，数据将丢失）。
我们来玩儿一下字符串类型：

$ redis-cli set mykey "my binary safe value"
OK
$ redis-cli get mykey
my binary safe value

正如你所见到的，通常用SET command 和 GET command来设置和获取字符串值。
值可以是任何种类的字符串（包括二进制数据），例如你可以在一个键下保存一副jpeg图片。值的长度不能超过1GB。
虽然字符串是Redis的基本值类型，但你仍然能通过它完成一些有趣的操作。例如：原子递增：

$ redis-cli set counter 100
OK $ redis-cli incr counter
(integer) 101
$ redis-cli incr counter
(integer) 102
$ redis-cli incrby counter 10
(integer) 112

INCR 命令将字符串值解析成整型，将其加一，最后将结果保存为新的字符串值，类似的命令有INCRBY, DECR and DECRBY。实际上他们在内部就是同一个命令，只是看上去有点儿不同。

INCR是原子操作意味着什么呢？就是说即使多个客户端对同一个key发出INCR命令，也决不会导致竞争的情况。例如如下情况永远不可能发生：『客户端1和客户端2同时读出“10”，他们俩都对其加到11，然后将新值设置为11』。最终的值一定是12，read-increment-set操作完成时，其他客户端不会在同一时间执行任何命令。

对字符串，另一个的令人感兴趣的操作是GETSET命令，行如其名：他为key设置新值并且返回原值。这有什么用处呢？例如：你的系统每当有新用户访问时就用INCR命令操作一个Redis key。你希望每小时对这个信息收集一次。你就可以GETSET这个key并给其赋值0并读取原值。

列表类型

要说清楚列表数据类型，最好先讲一点儿理论背景，在信息技术界List这个词常常被使用不当。例如”Python Lists”就名不副实（名为Linked Lists），但他们实际上是数组（同样的数据类型在Ruby中叫数组）

一般意义上讲，列表就是有序元素的序列：10,20,1,2,3就是一个列表。但用数组实现的List和用Linked List实现的List，在属性方面大不相同。

Redis lists基于Linked Lists实现。这意味着即使在一个list中有数百万个元素，在头部或尾部添加一个元素的操作，其时间复杂度也是常数级别的。用 LPUSH 命令在十个元素的list头部添加新元素，和在千万元素list头部添加新元素的速度相同。

那么，坏消息是什么？在数组实现的list中利用索引访问元素的速度极快，而同样的操作在linked list实现的list上没有那么快。

Redis Lists are implemented with linked lists because for a database system it is crucial to be able to add elements to a very long list in a very fast way. Another strong advantage is, as you’ll see in a moment, that Redis Lists can be taken at constant length in constant time.

Redis Lists用linked list实现的原因是：对于数据库系统来说，至关重要的特性是：能非常快的在很大的列表上添加元素。另一个重要因素是，正如你将要看到的：Redis lists能在常数时间取得常数长度。

Redis lists 入门

LPUSH 命令可向list的左边（头部）添加一个新元素，而RPUSH命令可向list的右边（尾部）添加一个新元素。最后LRANGE 命令可从list中取出一定范围的元素

$ redis-cli rpush messages "Hello how are you?"
OK
$ redis-cli rpush messages "Fine thanks. I‘m having fun with Redis"
OK
$ redis-cli rpush messages "I should look into this NOSQL thing ASAP"
OK
$ redis-cli lrange messages 0 2
1. Hello how are you?
2. Fine thanks. I‘m having fun with Redis
3. I should look into this NOSQL thing ASAP

注意LRANGE 带有两个索引，一定范围的第一个和最后一个元素。这两个索引都可以为负来告知Redis从尾部开始计数，因此-1表示最后一个元素，-2表示list中的倒数第二个元素，以此类推。

As you can guess from the example above, lists can be used, for instance, in order to implement a chat system. Another use is as queues in order to route messages between different processes. But the key point is that you can use Redis lists every time you require to access data in the same order they are added. This will not require any SQL ORDER BY operation, will be very fast, and will scale to millions of elements even with a toy Linux box.

正如你可以从上面的例子中猜到的，list可被用来实现聊天系统。还可以作为不同进程间传递消息的队列。关键是，你可以每次都以原先添加的顺序访问数据。这不需要任何SQL ORDER BY 操作，将会非常快，也会很容易扩展到百万级别元素的规模。

例如在评级系统中，比如社会化新闻网站 reddit.com，你可以把每个新提交的链接添加到一个list，用LRANGE可简单的对结果分页。

在博客引擎实现中，你可为每篇日志设置一个list，在该list中推入进博客评论，等等。

向Redis list压入ID而不是实际的数据

在上面的例子里 ，我们将“对象”（此例中是简单消息）直接压入Redis list，但通常不应这么做，由于对象可能被多次引用：例如在一个list中维护其时间顺序，在一个集合中保存它的类别，只要有必要，它还会出现在其他list中，等等。

让我们回到reddit.com的例子，将用户提交的链接（新闻）添加到list中，有更可靠的方法如下所示：

$ redis-cli incr next.news.id
(integer) 1
$ redis-cli set news:1:title "Redis is simple"
OK
$ redis-cli set news:1:url "http://code.google.com/p/redis"
OK
$ redis-cli lpush submitted.news 1
OK

我们自增一个key，很容易得到一个独一无二的自增ID，然后通过此ID创建对象–为对象的每个字段设置一个key。最后将新对象的ID压入submitted.news list。

这只是牛刀小试。在命令参考文档中可以读到所有和list有关的命令。你可以删除元素，旋转list，根据索引获取和设置元素，当然也可以用LLEN得到list的长度。

Redis 集合

Redis集合是未排序的集合，其元素是二进制安全的字符串。SADD命令可以向集合添加一个新元素。和sets相关的操作也有许多，比如检测某个元素是否存在，以及实现交集，并集，差集等等。一例胜千言：

$ redis-cli sadd myset 1
(integer) 1
$ redis-cli sadd myset 2
(integer) 1
$ redis-cli sadd myset 3
(integer) 1
$ redis-cli smembers myset
1. 3
2. 1
3. 2

我向集合中添加了三个元素，并让Redis返回所有元素。如你所见它们是无序的。

现在让我们检查某个元素是否存在：

$ redis-cli sismember myset 3
(integer) 1
$ redis-cli sismember myset 30
(integer) 0

“3″是这个集合的成员，而“30”不是。集合特别适合表现对象之间的关系。例如用Redis集合可以很容易实现标签功能。

下面是一个简单的方案：对每个想加标签的对象，用一个标签ID集合与之关联，并且对每个已有的标签，一组对象ID与之关联。

例如假设我们的新闻ID 1000被加了三个标签tag 1,2,5和77，就可以设置下面两个集合：

$ redis-cli sadd news:1000:tags 1
(integer) 1
$ redis-cli sadd news:1000:tags 2
(integer) 1
$ redis-cli sadd news:1000:tags 5
(integer) 1
$ redis-cli sadd news:1000:tags 77
(integer) 1
$ redis-cli sadd tag:1:objects 1000
(integer) 1
$ redis-cli sadd tag:2:objects 1000
(integer) 1
$ redis-cli sadd tag:5:objects 1000
(integer) 1
$ redis-cli sadd tag:77:objects 1000
(integer) 1

要获取一个对象的所有标签，如此简单：

$ redis-cli smembers news:1000:tags
1. 5
2. 1
3. 77
4. 2

而有些看上去并不简单的操作仍然能使用相应的Redis命令轻松实现。例如我们也许想获得一份同时拥有标签1, 2, 10和27的对象列表。这可以用SINTER命令来做，他可以在不同集合之间取出交集。因此为达目的我们只需：

$ redis-cli sinter tag:1:objects tag:2:objects tag:10:objects tag:27:objects
... no result in our dataset composed of just one object ...

在命令参考文档中可以找到和集合相关的其他命令，令人感兴趣的一抓一大把。一定要留意SORT命令，Redis集合和list都是可排序的。

题外话：如何为字符串获取唯一标识

在标签的例子里，我们用到了标签ID，却没有提到ID从何而来。基本上你得为每个加入系统的标签分配一个唯一标识。你也希望在多个客户端同时试着添加同样的标签时不要出现竞争的情况。此外，如果标签已存在，你希望返回他的ID，否则创建一个新的唯一标识并将其与此标签关联。

Redis 1.4将增加Hash类型。有了它，字符串和唯一ID关联的事儿将不值一提，但如今我们如何用现有Redis命令可靠的解决它呢？

我们首先的尝试（以失败告终）可能如下。假设想为标签“redis”获取一个唯一ID：

• 为了让算法是二进制安全的（意即不考虑字符串的编码或空格等等，只将注意力放在标签上）我们对标签做SHA1签名。SHA1(redis)=b840fc02d524045429941cc15f59e41cb7be6c52。
• 检查这个标签是否已与一个唯一ID关联，用命令GET tag:b840fc02d524045429941cc15f59e41cb7be6c52:id
• 如果上面的GET操作返回一个ID，则将其返回给用户。标签已经存在了。
• 否则… 用INCR next.tag.id命令生成一个新的唯一ID（假定它返回123456）。
• 最后关联标签和新的ID，SET tag:b840fc02d524045429941cc15f59e41cb7be6c52:id 123456
• 并将新ID返回给调用者。

多美妙，或许更好…等等！当两个客户端同时使用这组指令尝试为标签“redis”获取唯一ID时会发生什么呢？如果时间凑巧，他们俩都会从GET操作获得nil，都将对next.tag.id key做自增操作，这个key会被自增两次。其中一个客户端会将错误的ID返回给调用者。幸运的是修复这个算法并不难，这是明智的版本：

• 为了让算法是二进制安全的（意即不考虑字符串的编码或空格等等，只将注意力放在标签上）我们对标签做SHA1签名。SHA1(redis)=b840fc02d524045429941cc15f59e41cb7be6c52。
• 检查这个标签是否已与一个唯一ID关联，用命令GET tag:b840fc02d524045429941cc15f59e41cb7be6c52:id
• 如果上面的GET操作返回一个ID，则将其返回给用户。标签已经存在了。
• 否则… 用INCR next.tag.id命令生成一个新的唯一ID（假定它返回123456）。
• 下面关联标签和新的ID，(注意用到一个新的命令)

SETNX tag:b840fc02d524045429941cc15f59e41cb7be6c52:id 123456。如果另一个客户端比当前客户端更快，SETNX将不会设置key。而且，当key被成功设置时SETNX返回1，否则返回0。那么…让我们再做最后一步运算。

• 如果SETNX返回1（key设置成功）则将123456返回给调用者，这就是我们的标签ID，否则执行GET tag:b840fc02d524045429941cc15f59e41cb7be6c52:id 并将其结果返回给调用者。

有序集合

集合是使用频率很高的数据类型，但是…对许多问题来说他们也有点儿太不讲顺序了;)因此Redis1.2引入了有序集合。他和集合非常相似，也是二进制安全的字符串集合，但是这次带有关联的score，以及一个类似LRANGE的操作可以返回有序元素，此操作只能作用于有序集合，它就是，ZRANGE 命令。

从某种程度上说，有序集合是SQL世界的索引在Redis中的等价物。例如在刚才的reddit.com例子中，并没有提到如何根据用户投票和时间因素将新闻组合生成首页。下面我们会用有序集合解决这个问题，我们先从最简单的事情开始，阐明这个高级数据类型是如何工作的。让我们添加几个黑客，并将他们的生日作为“score”。

$ redis-cli zadd hackers 1940 "Alan Kay"
(integer) 1
$ redis-cli zadd hackers 1953 "Richard Stallman"
(integer) 1
$ redis-cli zadd hackers 1965 "Yukihiro Matsumoto"
(integer) 1
$ redis-cli zadd hackers 1916 "Claude Shannon"
(integer) 1
$ redis-cli zadd hackers 1969 "Linus Torvalds"
(integer) 1
$ redis-cli zadd hackers 1912 "Alan Turing"
(integer) 1

对有序集合来说，按生日排序返回这些黑客易如反掌，因为他们已经是有序的。有序集合是通过一个dual-ported 数据结构实现的，它包含一个精简的有序列表和一个hash table，因此添加一个元素的时间复杂度是O(log(N))。这还行，但当我们需要访问有序的元素时，Redis不必再做任何事情，它已经是有序的了：

$ redis-cli zrange hackers 0 -1
1. Alan Turing
2. Claude Shannon
3. Alan Kay
4. Richard Stallman
5. Yukihiro Matsumoto
6. Linus Torvalds

你知道Linus比Yukihiro年轻吗

无论如何，我想反向对这些元素排序，这次就用 ZREVRANGE 代替 ZRANGE 吧：

$ redis-cli zrevrange hackers 0 -1
1. Linus Torvalds
2. Yukihiro Matsumoto
3. Richard Stallman
4. Alan Kay
5. Claude Shannon
6. Alan Turing

一个非常重要的小贴士，ZSets只是有一个“默认的”顺序，但你仍然可以用 SORT 命令对有序集合做不同的排序（但这次服务器要耗费CPU了）。要想得到多种排序，一种可选方案是同时将每个元素加入多个有序集合。

区间操作

有序集合之能不止于此，他能在区间上操作。例如获取所有1950年之前出生的人。我们用 ZRANGEBYSCORE 命令来做：

$ redis-cli zrangebyscore hackers -inf 1950
1. Alan Turing
2. Claude Shannon
3. Alan Kay

我们请求Redis返回score介于负无穷到1950年之间的元素（两个极值也包含了）。

也可以删除区间内的元素。例如从有序集合中删除生日介于1940到1960年之间的黑客。

ZREMRANGEBYSCORE 这个名字虽然不算好，但他却非常有用，还会返回已删除的元素数量。

回到Reddit的例子

最后，回到 Reddit的例子。现在我们有个基于有序集合的像样方案来生成首页。用一个有序集合来包含最近几天的新闻（用 ZREMRANGEBYSCORE 不时的删除旧新闻）。用一个后台任务从有序集合中获取所有元素，根据用户投票和新闻时间计算score，然后用新闻IDs和scores关联生成 reddit.home.page 有序集合。要显示首页，我们只需闪电般的调用 ZRANGE。

不时的从 reddit.home.page 有序集合中删除过旧的新闻也是为了让我们的系统总是工作在有限的新闻集合之上。

更新有序集合的scores

结束这篇指南之前还有最后一个小贴士。有序集合scores可以在任何时候更新。只要用 ZADD 对有序集合内的元素操作就会更新它的score（和位置），时间复杂度是O(log(N))，因此即使大量更新，有序集合也是合适的。

这篇指南远未尽言，这只是从Redis开始的基础，欲深入之请读命令参考文档。

谢谢阅读。Salvatore。

本文整理在 latteye doc 页面

No related posts.

刚用电脑的时候其实对键盘不是特别在意。自从千年特意买了个 Dell 8175 键盘之后（上图那黑黑的一块，呵呵），对键盘也算有点小要求。8175 的确是个好键盘，适中的键程，柔软的触感，恰到好处的反弹，让人一上手就有一种肉乎乎的感觉。

Macbook Air 自带的键盘其实还是不错的，我不是很喜欢这种巧克力键盘，总觉得他拉大了键距。但是 MBA 的巧克力键盘没有给我任何不爽的感觉，也没花多少时间去适应他。

由于要将笔记本连接到外置显示器使用，所以一个外置 Apple 键盘就成了必备配件。
可惜的是 Apple 并没有给你太多的选择，由于特有的 Command 按键，你必须使用 Apple 自家的键盘。先上手的是 G6 有线键盘。

这款键盘的排列其实和笔记本还是略有不同的。手感上相差了很多，最大的区别是硬，一天用下来我的手指好想有点痛的感觉，悲催～
其实各人使用习惯不一，我按键比较用力，所以键程短的键盘肯定不适合我。容易让我觉得痛。外加这块键盘硬……

在用了1个月不到，感觉空格键也有点小问题之后今天果断入 G5 键盘。

其实就外观而言，我更喜欢G5.这种油乎乎肥嘟嘟的感觉让人心情愉悦。
但是今天一天用下来，体验并不是很好，我不知道我买的这个是不是真的，这是另外的话题了～

首先，键程比 Dell 的 8175 要长，我觉得过长了。于是小几率的，我会按不到某个键。另外键距比 Apple G6 要宽，使用起来感觉有点累。同时由于键宽和造型的不一，盲打的时候命中率比平时略低了一点。可能需要一点时间适应吧。
G5 的造型的确是花了心思的，这种弯曲的造型能让你在按上面几排按键的时候，手指要伸出的距离略短。但其实上面几排去按的几率还是比较小的。
另外，其实我很喜欢 G6 无线版本的按键排布，主要是键盘短了。我根本不需要小键盘，F14 F15 这种按键，Home键我也几乎不用。而键盘短了以后右手伸出去握鼠标的舒适度大大增加。

真希望G5能出一个改进版本。

No related posts.

不工作的配置：

 <VirtualHost *:80>
     ProxyPass / balancer://appCluster/ stickysession=JSESSIONID
     ProxyPassReverse / balancer://appCluster/
 </VirtualHost>
 
 <Proxy balancer://appCluster>
     BalancerMember ajp://172.16.5.154:8009 smax=5 route=jvm1 retry=60 ttl=60
     BalancerMember ajp://172.16.5.154:8010 smax=5 route=jvm2 retry=60 ttl=60
 </Proxy>

工作的配置：

<VirtualHost *:80>
	ProxyPass / balancer://appCluster/
	ProxyPassReverse / balancer://appCluster/
</VirtualHost>
 
<Proxy balancer://appCluster>
    BalancerMember ajp://172.16.5.154:8009 smax=5 route=jvm1 retry=60 ttl=60
    BalancerMember ajp://172.16.5.154:8010 smax=5 route=jvm2 retry=60 ttl=60
    ProxySet stickysession=JSESSIONID
</Proxy>

按照 ProxySet 的解释，它也只是到了后面的一种替代配置方式。而按照 ProxyPass 的说明，这两种配置方式都应该是工作的。于是我开始做跟进一步的跟踪。

配置 balancer log：

LogFormat "\"%{MYCOOKIE}C\" \"%{Set-Cookie}o\" \"%{BALANCER_SESSION_STICKY}e\" \"%{BALANCER_SESSION_ROUTE}e\" \"%{BALANCER_WORKER_ROUTE}e\" \"%{BALANCER_ROUTE_CHANGED}e\"" session
CustomLog logs/session_log session

工作的 log：

"-" "-" "-" "-" "jvm1" "1"
"-" "-" "-" "-" "jvm2" "1"
"-" "-" "-" "-" "jvm1" "1"
"-" "JSESSIONID=8B23E43DC6CA0C11BFB14A7D40A3C489.jvm2; Path=/ewallet/; HttpOnly" "-" "-" "jvm2" "1"
"-" "-" "JSESSIONID" "jvm2" "jvm2" "-"
"-" "-" "JSESSIONID" "jvm2" "jvm2" "-"
"-" "-" "JSESSIONID" "jvm2" "jvm2" "-"
"-" "-" "JSESSIONID" "jvm2" "jvm2" "-"

不工作的 log：

"-" "JSESSIONID=8277BFA34D8B787722F39251F223A837.jvm1; Path=/ewallet/; HttpOnly" "-" "-" "jvm1" "-"
"-" "-" "-" "-" "jvm2" "-"
"-" "-" "-" "-" "jvm1" "-"
"-" "-" "-" "-" "jvm2" "-"

给我的感觉是 balancer 模块完全没有意识到需要按照 sessionid 的方式去选择 route。很明显 balancer 模块已经看到 cookie 了。

全局打开 debug 模式，工作的log：

mod_proxy_balancer.c(46): proxy: BALANCER: canonicalising URL //appCluster/ewallet/account
mod_proxy_balancer.c(280): proxy: BALANCER: Found value AAE5BBF643F75BFFE91FA4F7841B3847.jvm1 for stickysession JSESSIONID
mod_proxy_balancer.c(290): proxy: BALANCER: Found route jvm1
mod_proxy_balancer.c(581): proxy: BALANCER (balancer://appcluster) worker (ajp://172.16.5.154:8009) rewritten to ajp://172.16.5.154:8009/ewallet/account

不工作的 log：

mod_proxy_balancer.c(46): proxy: BALANCER: canonicalising URL //appCluster/ewallet/login.jsp
 mod_proxy_balancer.c(1003): proxy: Entering byrequests for BALANCER (balancer://appcluster)
 mod_proxy_balancer.c(1046): proxy: byrequests selected worker "ajp://172.16.5.154:8009" : busy 0 : lbstatus 0
 mod_proxy_balancer.c(581): proxy: BALANCER (balancer://appcluster) worker (ajp://172.16.5.154:8009) rewritten to ajp://172.16.5.154:8009/ewallet/login.jsp

基本上可以确定为是一个 bug。然后我去 RedHat bugzilla 搜索了一下，看到一个类似的问题：mod_proxy_balancer: strange behaviour of multiple session identifiers [NEEDINFO] 。不过原提交人未再给出详细的信息了。

Related posts:

1. MongoDB 笔记 1
2. 使用 Winbind 将 Linux 加入 Windows 域环境
3. 发布一个 A.P.I

一、音箱
上篇说到 EL34 胆机。胆机之后自然就是音箱了。
起初我希望将音箱控制在 2000元 的价位。转了一圈以后发现这个价位是比较尴尬的。买国产音箱 2000 元好像有点浪费。虽然惠威这些年做的的确也蛮好，但是总觉得不值这个价格。但是买欧美箱子，2000 元够买个2手的。一开始看了 Roger 乐爵士的一些音箱。比较中意他的价位。网上谈了一些卖家，深圳那里的比较多，但总有点不放心。一来距离比较远，运输过程出了问题很难处理。而来对音箱真假没把握。后来也接触了一些上海的音箱代理商家，不过没什么深入了解。

8月那段时间，工作上处于比较轻松的阶段。突然想，既然要性价比高，不如自己做一个吧。于是开始逛音箱 DIY 论坛。发现 DIY 里面用西雅士单元的人很多。这个品牌的单元口碑非常好。技术工艺也已经发展到了金属盆，以前一直以为单元只能用纸盆做呢。
在淘宝上你可以看到很多的 DIY 音箱产品。炒的比较红的有款式叫中大4号。Google 了一下 Alesis 6.5 寸单元可能在 140 元的价位。通常高频单元不会比中低频贵，所以一套音箱基本成本大约在 600 以内。卖价 900 多也算是比较厚道了。而且我买 EL34 的小店也有推荐他们的音箱。
还是顺着西雅士的路线来看，找到了一个卖家自己 DIY 音箱的。同城，联系了一下，可以试听。找了一个晚上就跑去了。去之前还在犹豫是否要把自己一对先锋的组合音箱给带去做比较。去了之后庆幸幸好没带！带了就太废柴了！

这款音箱彻底、完全、重新定义了我对音箱的看法（当然，以前也没听过 Hi-Fi，呵呵）。虽然 3200 略微有点超出预算，但还是感觉超值！

西雅士 H1212+H1224 的组合非常普遍，很成熟的方案了。卖家的分频器好像是自己做的。试听的时候，我都开始不由自主的笑了！这才是音乐啊！声场、深度、力量、柔美完全结合在了一起。那种声音的包围感、水乳交融的感觉很难描绘出来。
卖家自己的系统模拟味很重，一开始听伊凡塞斯的Fallen 居然有点甜甜的感觉了。后来听 Yanni 的一张专辑，完全感觉不到数码的味道。（Yanni 的数码味那是相当的重啊！搞的和电子乐一样的感觉。）

乐呵呵的把音箱抱回家之后，果然有了很大的提升。应该不能用“提升”，应该说“颠覆”。这是完全不一样的声音。

不过，由于之前在卖家那里听了好的器材了（卖家说他的解码器就要 2w，我才花了 400块钱买解码器，差距是肯定有的啦⋯⋯），利马就能感觉到自己系统声音的缺陷。密度差了2个档次，声音有些松散。于是又开始折腾了。

二、胆管
胆管可能是整套系统里面投资最不值得的一部分了。并不是说它没效果，而是性价比不高。原来胆机配的是南京曙光的胆管，我对应的换了两种胆管：

JJ 蓝瓶 EL34

话说这瓶子是很好看！蓝瓶的好喝的！

天梭 6SL7

其中，6SL7 是用来将接收到的信号放大的。EL34 是用来推动音箱的。还有一个将电源整流的瓶子没有换，那个因素相对比较小。
换了瓶子之后，还是有所提升的。密度感好一些。貌似仅此而已⋯⋯，而4个瓶子好像就要 500 元左右。

后来看过一个卖解码器的卖家说，整套系统里面，在预算有限的情况下，建议是两头重、中间轻。也就是花多点钱在解码（CD、DAC）和音箱上，而功放相对少花点。我现在也非常赞同这点。

三、网罩
胆机的确是可以煮鸡蛋的。有个同事的小孩差点把手摸上去。所以我定做了一个网罩。

只能说做的马马虎虎、凑合凑合。我没给中评已经很够意思了⋯⋯ 不过价钱比在自己家门口做便宜了不少。

四、运放
某天回头转回到解码器，发现之前买的解码器可以很轻松的换运放。一开始也不知道运放什么作用，后来知道原来运放是做解析的。
咬了咬牙买了套 金封 627SM，这个运放我买了 100 元，很多人可能是 140元左右收入的。我也不知道我买的是真的还是假的。

这是原配的 2604AP 的照片，这个运放大约是 15元。所以比较而言 627SM 真的是很昂贵了。

说说 627SM 的听后感吧。
一入耳的感觉是明亮了，但是明亮不代表是好，因为很多信号放大如果直接导致某部分音量变大（高音居多），也会给人一时的这种感觉。所以这个运放大约认真听了1个小时才明确了性能。

低音：低音的改善很明显，比较而言 2604 听一些 Punk EMO 的时候，鼓声和贝斯声都是挤在一起的。而 627SM 把声音解析的非常到位，一来分开了层次，而来鼓声变的很有弹性，你能够感觉到鼓被敲下然后弹上来的过程。
高音：高音的解析无敌了。我以前从来没感觉到阿桑的《寂寞在唱歌》是有齿音和唇音的，太牛了！
声场：不止是低音的层次被分开，整体的声音声场都能拉开的。音乐变的有起伏、音乐性感觉很强。我之前一直不理解别人说的“动态”是什么意思，现在可能有一点点感觉了。

晚上老婆下班回来，听了一会热，立刻也能感觉到更好的变化。运放的投入还是很值的。

四、音乐管理
由于要上 3T 硬盘，所以把 Homeserver 改成了 ArchLinux 系统。使用 mpd 来管理音乐文件，mpd 的优点是各个平台都有对应的 client 来控制。远程遥控很方便。
切换过来能明显感觉到 linux mpd alsa 的声音更加实在一些。对比而言，foobar 的声音就像是加了味精一样。似乎 foobar 通过一些软件的方式让声音更加有声场。但是这种感觉并不好，听的时间一长，会很厌烦。这种虚拟出来的声场真的不太舒服。
目前 mpd 工作的很好，软件作者也保持着很积极的态度在更新。我甚至连 alsa service 都没有装，由 mpd 自己控制 alsa 模块做 soft 音量控制。

OK，到这里 PC Low-Fi 的流水账就完结了。

No related posts.

1. MongoDB 对数据的保障性不是我们所需要的。这不是 MongoDB 的错误，这是我们选择产品的错误。我觉得 MongoDB 其实就是放弃了这样的数据保障性才获得了更好的性能。所以才更适合类似 facebook twitter 对消息保障性要求不高，但是量大的应用。
2. Javascript 的 driver 略显不成熟。其实各类开发速度都很快，同时我对他们的熟悉程度还不够好。所以总的感觉现在还没到用的时候。

这里对第二点做个流水账式样的记录，在学习的过程中发现相关的英文和中文资料都比较缺乏。

我所测试到的 Driver 有：

node-mongodb-native
mongolian
mongoose

这三个 Driver 里，mongolian 和 mongoose 都是依赖 native 的。不过在这里mongolian的作者提到 mongolian对 native db class 部分并不调用。看来依赖的程度有所不一。
所测试的内容是 failover。MongoDB 推荐的 failover 方案为 Replica Set，这个架构逻辑上不难理解。至少三个节点，至多七个节点；各个节点可以有 0-99 的优先级等一系列特性让他成为非常优秀的 HA 方案。

测试方法： 插入 N 条数据，并且在插入的过程中将 Primary 进程杀死。查看客户端（node.js）是否正常转移到新的 Primary ，并且最终检查数据一致性。可以接受插入不了数据，但是一定要有错误返回。返回错误的数量一定要和数据库内未插入的数据数量一致。

一、native
先给出 native 的测试脚本：

var mongodb = require('mongodb');
var Db = require('mongodb').Db,
  Connection = require('mongodb').Connection,
  Server = require('mongodb').Server,
  ReplSetServers = require('mongodb').ReplSetServers;
 
var replStat = new ReplSetServers([
	new Server('172.16.5.151', 28010, { auto_reconnect: true }),
	new Server('172.16.5.152', 28010, { auto_reconnect: true }),
	new Server('172.16.5.153', 28010, { auto_reconnect: true })
	],
	{rs_name: 'rs1'} 
);
 
var db = new Db('a', replStat);
db.open(function (error, client) {
  if (error) throw error;
  var collection = new mongodb.Collection(client, 'blogposts');
 
function test_read(t)
{
  console.log('enum elements...');
  var start = new Date;
  var times = 0;
  for(var i = 1; i <= t; i++ )
  {
	collection.find({'_id':i}, {limit:1}).nextObject(function(err, docs) {
	    if (err) console.warn(err.message);
	    //else console.dir(docs);
	    if(++times >= t)
		console.log('enum finished:cost time:' + (new Date - start) + 'ms');
	  });
  }
}
 
function test_write(t)
{
  var start = new Date;
  var times = 0;
  console.log('add elements...');
  for(var i = 1; i <= t; i++ )
  {
  	collection.insert({date: (new Date()).getTime(), body:'sadf', title:'abc', _id:i}, {safe:{w:2, wtimeout: 10000}},
                    function(err, objects) {
	    if (err) console.warn(err.message);
	    if(++times >= t)
	    {
		console.log('add finished:cost time:' + (new Date - start) + 'ms');
		test_read(t);
	    }
  	});
  }
}
 
var wtimes = 10000;
test_write(wtimes);
//test_read(wtimes);
});

三个 driver 中文档工作做的最好的就是 native 了，example 也比较多。不过作者在 Replica Set 的 examples 中给了个让人很莫名的开头：

var port1 = 27018;
var port2 = 27019;
var server = new Server(host, port, {});
var server1 = new Server(host, port1, {});
var server2 = new Server(host, port2, {});
var servers = new Array();
servers[0] = server2;
servers[1] = server1;
servers[2] = server;
 
var replStat = new ReplSetServers(servers);

对于我这种不写代码的人来说，您老写成这样着实让我纠结了一番⋯⋯

测试结果： 在插入的过程中将 Primary kill 后大约有 1/3 的概率 node.js crash 了。其余 2/3 的概率 node.js 彻底卡住。MongoDB 端 Primary 正常转移，但未见数据继续插入进来。我很想贴一点 log 上来，但 native driver 真的没有任何 log，就是单纯的卡住了⋯⋯卡住⋯⋯卡⋯⋯

Crash log：

[root@localhost bin]# ./node ~/native_test.js 
2
3
4
add elements...
node: src/uv-common.c:92: uv_err_name: Assertion `0' failed.
已放弃

在经过几天的搜索以后[1 2 3 ] 我发现似乎有人和我做过类似的测试，但是从来没有得到明确的答案。昨天我也将这个问题发到的 native 论坛上，目前还没有人回复。
但是后来又随后开始怀疑自己的脚本，同时看到新的解答[4]，于是开始尝试不在一个 db.open 里面写 for，而在 for 里面反复的 db.open 和 db.close。但是没有成功，循环插入10条数据，成功插入的只有第一条。无论有没有 db.close 都是这个现象。这个不工作的代码就不贴上来了，如果有那位做过类似测试希望可以交流一下。

二、mongoose
测试脚本：

var mongoose = require('mongoose');
mongoose.createSetConnection('mongodb://172.16.5.151:28010/a,mongodb://172.16.5.152:28010/a,mongodb://172.16.5.153:28010/a');
 
var Schema = mongoose.Schema,
    ObjectId = Schema.ObjectId;
 
var BlogPost = new Schema({
//    author    : ObjectId
    _id       : Number
  , title     : String
  , body      : String
  , date      : Date
});
 
mongoose.model('BlogPost', BlogPost);
var post = mongoose.model('BlogPost');
 
function test_read(t)
{
	var start = new Date();
	var times = 0;
	console.log('enum elements...');
	for(var i = 1; i <= t; i++)
	{
		//console.log("read:"+i);
		post.findById(i, function(err, doc){
			if(err)
				console.log(err);
			//else
			//	console.log(doc);
			if(++times >= t)
			{
				var end = new Date();
				console.log('enum finished:cost time:' + (end - start) + "ms");
			}
		});
	}
};
 
function test_write(t)
{
	var start = new Date();
	var times = 0;
	console.log('add elements...');
	for(var i = 1; i <= t; i++)
	{
		//console.log("write:"+i);
 
		var p = new post();
		p._id = i;
		p.title = 'abc';
		p.body = 'sadf';
		p.date = (new Date()).getTime();
		p.save(function(err){
			if(err)
			{
				console.log(err);
			}
			if(++times >= t)
			{
				var end = new Date();
				console.log('add finished:cost time:' + (end - start) + "ms");
				test_read(t);
			}
		});
	}
}
 
var wtimes = 10000;
test_write(wtimes);
//process.exit(0);

首先！连接 Replica Set 要用createSetConnection：

mongoose.createSetConnection('mongodb://172.16.5.151:28010/a,mongodb://172.16.5.152:28010/a,mongodb://172.16.5.153:28010/a');

你或许和我一样走过一些弯路[5 6]。

测试结果： OSE 的测试结果几乎和 native 一样，唯一好一点的是它从来没把 node.js 弄 crash 过。它唯一的反应就是 卡住⋯⋯卡住⋯⋯
OSE 和 native 在这个测试上的区别是，native 一边产生数据一边插入。OSE 先将数据在内存中产生出来以后，再一次插入数据库。而 node.js 存在一个内存限制的问题 （一个浏览器有什么理由需要2G的内存呢？），所以当 OSE driver 占用超过 1.9G 内存之后，node.js 不出意料的 crash。

PS. google 论坛上有人说可以通过参数让 node.js 支持任何大小的内存。经过我的测试(CentOS 6 x86-64,0.5.x,0.4.x)没有成功过。可工作的最高数值为 1900M。

你可以注意到了 native 驱动有一个 auto_reconnect 参数（尽管它没有 reconnect），而 mongoose 脚本里面没看到。OSE 的确也有设置 auto_reconnect 的方式[7]，但是只看到给普通连接设置的方式。没有看到给 Replica Set 用的方式。自己胡乱尝试了几个设置方式无一成功。希望 ose 的作者能再多花点时间在文档方面。另一方面也可以看到，OSE 其实对 native 依赖还是蛮严重的。这种设置方式的出现似乎只是传递给 native 驱动，我猜测 OSE 自己没有对这块做任何处理。

三、mongolian
测试脚本：

var mongodb = require('mongolian');
var server = new mongodb(
    "172.16.5.151:28010",
    "172.16.5.152:28010",
    "172.16.5.153:28010"
)
var db = server.db("a")
var blogposts = db.collection("blogposts")
 
function test_read(t)
{
  console.log('enum elements...');
  var start = new Date;
  var times = 0;
  for(var i = 1; i <= t; i++ )
  {
	blogposts.find({'_id':i}, {limit:1}).nextObject(function(err, docs) {
	    if (err) console.warn(err.message);
	    //else console.dir(docs);
	    if(++times >= t)
		console.log('enum finished:cost time:' + (new Date - start) + 'ms');
	  });
  }
}
 
function test_write(t)
{
  var start = new Date;
  var times = 0;
  console.log('add elements...');
  for(var i = 1; i <= t; i++ )
  {
  	blogposts.insert({date: (new Date()).getTime(), body:'sadf', title:'abc', _id:i},
                    function(err, objects) {
	    if (err) console.warn(err.message);
	    if(++times >= t)
	    {
		console.log('add finished:cost time:' + (new Date - start) + 'ms');
		test_read(t);
	    }
  	});
  }
}
 
var wtimes = 10000;
test_write(wtimes);
//test_read(wtimes);

测试结果： mongolian(以下简称lian) 的反应是这三个驱动中最好的。首先当开启 node 的时候，lian 会给出 debug 信息，明确告诉你他连接到了哪台 mongodb，作者也明确说了这个 log 是为 Replica Set 做的 [8 9]。当 Primary 被 kill 掉之后，lian 会告诉你连接丢失。在后面的插入lian会明确的告诉你插入失败，并且是每一次插入就给出一个 log，而且程序会一路走下去，不会卡住。

[root@localhost ~]# node lian_test.js 
add elements...
[debug] mongo://172.16.5.151:28010: Disconnected
[error] mongo://172.16.5.151:28010: Error: ECONNREFUSED, Connection refused
[debug] mongo://172.16.5.152:28010: Connected
[debug] mongo://172.16.5.153:28010: Connected
[debug] mongo://172.16.5.152:28010: Initialized as secondary
[debug] mongo://172.16.5.153:28010: Initialized as primary
[info] mongo://172.16.5.153:28010: Connected to primary
[debug] Finished scanning... primary? mongo://172.16.5.153:28010

我觉得 lian 的这种工作模式可以从它的代码编写方式里面体现出来。lian 的代码里面不存在打开一个 connection 或者 db.open 这样的概念，所以我估计 lian 是每一次 insert 就会尝试打开一次 connection。虽然他没有再次找到正确的 Primary，但至少他知道自己连接丢失了。
但是 lian 没能再次找到正确的 Primary 可能意味着他先打开了一个 ConnectionPool （你可以通过 poolSize 在 native 里面设置 pool 的大小），只有打开 ConnectionPool 的时候才会尝试去做 Primary 判断。
另外 lian 的插入速度也不错，感觉比 OSE 好，几乎和 native 一样。

实验做到后面，我极度怀疑自己的测试脚本写的不对。因为 native 是有 auto_reconnect 的参数的，但是缺没有工作。作者应该考虑了这个问题的。
而也肯定有一种方式让我在 for 里面打开 connection 、写完、关闭 connection。只是我现在没找到正确的写法。
希望有经验的朋友给予一些帮助。

虽然已经决定在最近做的项目中不再使用 MongoDB 但我会持续关注这款数据。

Related posts:

1. MongoDB 笔记 2
2. MongoDB 笔记 1
3. MongoDB 笔记 3