RedisStudio客户端连接工具
链接：http://pan.baidu.com/s/1gf9dknp 密码：hfyd 如果无法下载请联系作者。
里面包含两个工具，一个安装版的一部免安装版的，建议使用免安装版的，简单，界面清洁，界面如下
Redis 持久化储存机制
虽然是内存数据库，一般来说为了保险起见，还是会有一些持久化的机制，Redis 采用了其中两种方式，一是 RDB(Redis DataBase)，也就是存数据，另一种是 AOF(Append Only File)，也就是存操作。当然，即使是 Redis 本身提供的，我们也可以选择用还是不用，如果两种都不用的化，Redis 就和 memcache 差不多了。
1-1）、定时快照方式（RDB）
RDB 方式，是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
Redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于 RDB 方式，redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。
虽然 RDB 有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近 5 分钟的数据丢失。所以，redis 还提供了另一种持久化方式，那就是 AOF。
1-2）、基于语句追加文件的方式（AOF）
AOF（Append Only File）方式实际类似 mysql 基于语句的 binlog 方式，即每条会使 Redis 内存数据发生改变的命令都会追加到一个 log 文件中，也就是说这个 log 文件就是 Redis 的持久化数据。
aof 的方式的主要缺点是追加 log 文件可能导致体积过大，当系统重启恢复数据时如果是 aof 的方式则加载数据会非常慢，几十G的数据可能需要几小时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写 log，所以使用 AOF的方式，Redis 的读写性能也会有所下降。
1-3）、虚拟内存（vm）
diskstore 方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的 B-tree 的方式，目前仍在实验阶段，后续是否可用我们可以拭目以待。
1-4）、Diskstore 方式
diskstore 方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的 B-tree 的方式，目前仍在实验阶段，后续是否可用我们可以拭目以待。
Redis 事物的处理
在数据库中能确保数据不丢失的就是事务的设置，应该把状态恢复到之前的执行该整体之前的状态，Redis的事务包括MULTI,EXCE,DISCARD,WARCH这是个事务
MULTI：用来组装一个事务
EXCE：用来执行一个事务
DISCARD：用来取消一个事务
WARCH：用来监视一些KEY,一旦这些KEY在事务之前被改变，则取消事务的执行。
1-1）、MULTI事务的使用
127.0.0.1:6379> set oneId 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCR oneId
QUEUED
127.0.0.1:6379> INCR oneId
QUEUED
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec
1) (integer) 3
2) (integer) 4
3) PONG
4) PONG
127.0.0.1:6379> INCR oneId
(integer) 5
在以上的例子中可以看出当执行MULTI命令后会开启队列的事务，再有数据进入时则会把数据放入到队列中，当执行EXCE是，会把所有的数据进行提交。
对于事务的执行来说，如果Redis开启了AOF持久化的话，那么一旦事务执行成功，事务中的命令就会通过write命令一次性把数据写入到磁盘，如果再想磁盘写入的过成功出现断电，硬盘事故的情况下那么就会出现部分的文件被AOF持久化了，这是AOF就会存在不完整的情况，这时我们可以使用redis-check-aof工具来进行修复这一问题，这个工具可以把不完整的数据进行移除，以确保AOF文件的完整性。
1-2）、WATCH 事务的使用
127.0.0.1:6379> set username xiaozhang
OK
127.0.0.1:6379> WATCH username
OK
127.0.0.1:6379> set username xiaowang
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set username xiaoxiao
QUEUED
127.0.0.1:6379> get username
QUEUED
127.0.0.1:6379> EXEC
(nil)
WATCH可以实现乐观锁的效果，即是CAS(check and set )。WACTH 本身就是监听KEY值的变化，也可以监听多个KEY的值的变化的情况，如果没有触发事务，那么WACTH也会认真的去工作，一旦发现KEY被修改了，在执行EXEC时就会返回NIL,表示事务无法触发。
在执行EXEC之前被改变了，可以任务这个数据是脏数据，对于以后的操作就没有意义了，所以就不会去执行了。
