[本人汉语翻译]Redis 群集实例教程（中）
摘要：$ redis-cli -c -p 7000redis 127.0.0.1:7000 set foo bar- Redirected to slot [12182] located at 127.0.0.1:7002redis 127.0.0.1:7002 set hello world- Redirected to slot [866] located at 127.0.0.1:7000redis 127.0.0.1:7000 get foo- Redirected to s...
$ redis-cli -c -p 7000 redis 127.0.0.1:7000 set foo bar - Redirected to slot [12182] located at 127.0.0.1:7002 redis 127.0.0.1:7002 set hello world - Redirected to slot [866] located at 127.0.0.1:7000 redis 127.0.0.1:7000 get foo - Redirected to slot [12182] located at 127.0.0.1:7002 bar redis 127.0.0.1:7000 get hello - Redirected to slot [866] located at 127.0.0.1:7000 world留意：假如你应用角本建立的群集，你的连接点将会监视不一样的端口号，默认设置状况下从30001刚开始。 redis-cli对群集的适用是是非非常基本的，因此他一直应用Redis群集连接点将顾客端跳转一个到恰当连接点。一个健全的顾客端能够做的更强，而且缓存文件hash槽和连接点详细地址的投射，用以立即应用恰当的联接到恰当的连接点。这一投射仅有在群集配备有变化时才会被更新，比如常见故障迁移以后或是系统软件管理方法员根据详细地址改动群集层或清除连接点以后。 撰写一个redis-rb-cluster案例程序 在展现怎样实际操作redis群集，像这种实行常见故障迁移，或是再次分块(resharding)以前， 大家必须建立一些实例程序，最少能搞清楚简易的Redis群集顾客端互动词义。 那样大家能够运作一个实例同时试着让连接点产生常见故障，或是刚开始再次分块(resharding)，以掌握在真正自然环境中Redis群集的个人行为。这针对掌握当群集沒有载入指令时产生了甚么并不是十分有协助。 这节应用2个实例来表述redis-rb-cluster的基本使用方法。下边是第一个，它是redis-rb-cluster发售版本号内的example.rb文档。
1 require ./cluster
3 if ARGV.length != 2
4 startup_nodes = [
5 {:host = 127.0.0.1 , :port = 7000},
6 {:host = 127.0.0.1 , :port = 7001}
8 else
9 startup_nodes = [
10 {:host = ARGV[0], :port = ARGV[1].to_i}
11 ]
12 end
14 rc = RedisCluster.new(startup_nodes,32,:timeout = 0.1)
16 last = false
18 while not last
19 begin
20 last = rc.get( __last__ )
21 last = 0 if !last
22 rescue = e
23 puts error #{e.to_s}
24 sleep 1
25 end
26 end
28 ((last.to_i+1)..).each{|x|
29 begin
30 rc.set( foo#{x} ,x)
31 puts rc.get( foo#{x} )
32 rc.set( __last__ ,x)
33 rescue = e
34 puts error #{e.to_s}
35 end
36 sleep 0.1
37 }
这一程序干了十分简易的事儿，他以foo number 的方式，一个接一个的设定键数值number，因此假如你运作这一程序它的結果是下边的指令流： SET foo0 0 SET foo1 1 SET foo2 2 And so forth... 这一程序看上去比一般运用更繁杂，由于他被设计方案为在显示屏上显示信息不正确信息内容，而并不是产生出现异常撤出，因此每个与群集实行的实际操作都被包在begin recue块中。 在程序中第一4行编码是第一处有趣的地区，他建立了Redis群集目标，应用起动连接点（startup nodes ）目录做为主要参数，容许联接这一目标相匹配不一样连接点的较大总数，最终在给定的实际操作超后被觉得常见故障 。 起动连接点不用群集内的全部连接点。关键的是最少有一个连接点是可浏览的。留意要是redis-rb-cluster能联接到一个连接点便会升级起动目录。你应当希望别的严苛的顾客端也是有那样的个人行为。 如今大家早已有Redis群集目标的案例储存在rc自变量中，大家提前准备好像应用一一样的redis目标案例一样应用这一目标。 它是的确产生在 18 到 26行：当我们们重新启动个这实例，面不愿再次从foo0刚开始，因此大家把这一计数储存在Redis内。上边的编码被设计方案为载入这一电子计数器，或是假如这一电子计数器不会有，就设定为0. 但是留意他是一个如何的while循环系统，因为大家想一次又一次的试着，即便群集已关掉而且回到不正确。不一样的运用程序不用那么当心。 28到37行刚开始关键的的循环系统，循环系统里设定键值或是显示信息不正确信息内容。 留意在循环系统的最终启用了sleep。在你的检测中假如你要载入到群集的速率充足快那么就把sleep除掉(相对性于快这儿仅仅一个经常的循环系统，自然并不是真实的高并发，那样在最好的情况下，你一般会获得15k ops/s)。 一般状况下针对实例程序能非常容易的被别人类追随会把载入速率减慢。 刚开始这一运用程序后就造成下边的輸出：
ruby ./example.rb ^C (I stopped the program here)我觉得是一个十分趣味的程序，大家一会儿会应用一个更强的，可是大家早已能看到在程序执行起來后在分块期内产生了甚么。 群集的再次分块(Resharding) 如今大家提前准备试着群集的再次分块。因此必须example.rb程序维持运作，因而能看到是不是对程序执行全过程中有危害。一样的在分块期内以便更严苛的载入负荷你可以能将会想注解掉sleep启用。 再次分块大部分寓意着把哈希槽 从一组连接点移动到另外一组连接点，如同应用redis-trib好用专用工具进行群集的建立一样。 只需键入下边的编码便可以刚开始再次分块：
./redis-trib.rb reshard 127.0.0.1:7000你唯一必须做的便是特定一个连接点，redis-trib会全自动的寻找别的的连接点。 一般状况下必须管理方法员的适用reids-trib才可以再次分块,你没能说只从这一连接点移动槽的5%到其他连接点（可是它是很室内空间完成的）。因此从了解刚开始。第一就是你要想做多少的分块：
How many slots do you want to move (from 1 to 16384)?
大家能够试着对1000个哈希槽分块，假如实例仍然不在启用sleep的状况下运作，那麼它早已包括了一些关键的键。
这时候，redis-trib必须了解分块的总体目标什么叫 。换句话说即将接受哈希槽的连接点。我将应用第一个主连接点，也便是127.0.0.1：7000，可是我必须特定案例的连接点ID。根据redis-trib早已在一个目录内复印出去了，可是假如必须我常常应用下边的指令来找连接点的ID：$ redis-cli -p 7000 cluster nodes | grep myself 97a3a6466747d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5460
ok因此大家的总体目标连接点是 97a3a6466747d683e4c8db5858b1.
如今你能获得一个了解你要从什么连接点来取这种键，以便能从其他全部的主连接点取下一些哈希槽我只需键入all. 在最终的配备后，你能见到每个redis-trib要从一个连接点移动到另外一个连接点的槽的信息内容，而且会为每个从一个连接点移动到另外一个连接点的具体的键复印一个点。 在分块全过程中你能见到对你运作中的实例是沒有危害的。在分块期内，要是你要，你可以以数次终止或重新启动你的实例程序 。 分块完毕后，你可以令其用下边的指令来检测群集的身心健康： 一般将遮盖全部的槽，但这种主连接点127.0.0.1：7000 将有大量的哈希槽，大概为6461.
