redis学习系列--8.redis-实用特性

1.安全性.

如何给redis设置登录密码.

1. 修改配置文件“redis.windows-service.conf”(在安装的目录下找到并打开“redis.windows-service.conf”文件你可以找到如下的文字：)

################################## SECURITY ###################################

# Require clients to issue AUTH <PASSWORD> before processing any other
# commands.  This might be useful in environments in which you do not trust
# others with access to the host running redis-server.
#
# This should stay commented out for backward compatibility and because most
# people do not need auth (e.g. they run their own servers).
#
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
# requirepass foobared

设置密码的方式就是加入一行

requirepass 你的密码

比如我要设置密码为：we9fh34v9we4hfg35hbqwif234lhtzxmcsdh
的话，就加入一行下面的文字,然后重启.

requirepass we9fh34v9we4hfg35hbqwif234lhtzxmcsdh

2.主从复制

redis
主从复制配置和使用都非常简单。通过主从复制可以允许多个 slave server 拥有和

master server 相同的数据库副本。

2.1redis主从复制的特点:

1).master可以拥有多个slave
2).多个slave可以连接同一个master外,还可以连接到其他slave
3).主从复制不会阻塞master,在同步数据时,master可以继续处理client请求.
4).提高系统的伸缩性.

2.2.
redis主从复制的过程:

当配置好slave后,slave与master建立连接,然后发送sync命令,无论是第一次连接还是重新连接,master都会启动一个后台进程,将数据快照保存到文件中,同时master主进程会开始收集新的写命令并缓存,后台进程完成写文件后,master就发送文件给slave,slave
将文件保存到硬盘上,在加载到内存中,接着master就会把缓存的命令转发给slave,后续master将收到的写命令发送给slave.如果master同时收到多个slave发来的同步连接命令,master只会启动一个进程来写数据库镜像,然后发送给所有的slave.
(Redis的主从复制功能非常强大，一个master可以拥有多个slave，而一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构)

2.3 如何配置(linux版,windows类似)

1、上面安装好的一个Redis作为master，然后使用VirtualBox的虚拟机克隆功能将刚刚那个linux系统克隆一份作为slave，并修改其IP为192.168.0.110。
2、修改slave的redis配置文件：slaveof 192.168.0.100 6379  (映射到主服务器上),如果master设置了验证密码，还需配置 masterauth。楼主的

设置了验证密码为admin，所以配置masterauth admin。配置完之后启动slave的Redis服务,主从配置完成。

主从复制如何分辨主从, 需要调用info命令就可以得到主从信息了. 里面有一个角色标识, 来判断是主库还是从库, 

master_link_status 用于标明主从是否异步，如果此值=up，说明同步正常；如果此值=down，说明同步异步, db0:keys=1, expires=0， 用于说明数据库有几个 key,以及过期 key 的数量.

3. 事务控制

redis的事务和数据库的事务有些差别,  数据库事务: 当提交发生异常后操作会全部回滚, 但是redis事务会把未发生异常的命令提交,只回滚异常的命令. 是不完全的回滚.

3.1 如何取消一个事务

discard 命令用来取消一个事务,让事务回滚.

4.  持久化机制

redis 是一个支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到磁盘来保证持久化。redis 支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是 Append-only file（缩写 aof）的方式.

4.1 snapshotting(快照)方式

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置.

save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存
save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存

4.2aof 方式

另外由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化方式。下面介绍 Append-only file:

aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式时,redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于 os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样 aof 方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。有三种方式如下（默认是：每秒
fsync 一次）

appendonly yes //启用 aof 持久化方式 (在配置文件中改)

# appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化

appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中

# appendfsync no //完全依赖 os，性能最好,持久化没保证

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的。因为要恢复数据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下

1、redis 调用 fork ，现在有父子两个进程

2、子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令

3、父进程继续处理 client 请求，除了把写命令写入到原来的 aof 文件中。同时把收到的写命

令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。

4、当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然

后父进程把缓存的写命令也写入到临时文件。

5、现在父进程可以使用临时文件替换老的 aof 文件，并重命名，后面收到的写命令也开始

往新的 aof 文件中追加。需要注意到是重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库

内容用命令的方式重写了一个新的 aof 文件,这点和快照有点类似。

5. 发布及订阅消息

发布订阅(pub/sub)是一种消息通信模式，主要的目的是解耦消息发布者和消息订阅者之间的耦合，这点和设计模式中的观察者模式比较相似。pub/sub 不仅仅解决发布者和订阅者直接代码级别耦合也解决两者在物理部署上的耦合。redis 作为一个 pub/sub 的 server，在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过 subscribe 和 psubscribe 命令向 redisserver 订阅自己感兴趣的消息类型，redis 将消息类型称为通道(channel)。当发布者通过publish 命令向 redis server 发送特定类型的消息时。订阅该消息类型的全部 client 都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个channel,也可以向多个channel发送消息。

6.pipeline批量发送请求(待定)

7.虚拟内存的使用

首先说明下 redis 的虚拟内存与操作系统的虚拟内存不是一码事，但是思路和目的都是相同的。就是暂时把不经常访问的数据从内存交换到磁盘中，从而腾出宝贵的内存空间用于其他需要访问的数据。尤其是对于 redis 这样的内存数据库，内存总是不够用的。除了可以将数据分割到多个 redis server 外。另外的能够提高数据库容量的办法就是使用虚拟内存把那些不经常访问的数据交换的磁盘上。如果我们的存储的数据总是有少部分数据被经常访问，大部分数据很少被访问，对于网站来说确实总是只有少量用户经常活跃。当少量数据被经常访问时，使用虚拟内存不但能提高单台 redis server 数据库的容量，而且也不会对性能造成太多影响。

redis 没有使用操作系统提供的虚拟内存机制而是自己在实现了自己的虚拟内存机制，主要
的理由有两点:
1、操作系统的虚拟内存是已 4k 页面为最小单位进行交换的。而 redis 的大多数对象都远小于 4k，所以一个操作系统页面上可能有多个 redis 对象。另外 redis 的集合对象类型如 list,set可能存在与多个操作系统页面上。最终可能造成只有 10%key 被经常访问，但是所有操作系统页面都会被操作系统认为是活跃的，这样只有内存真正耗尽时操作系统才会交换页面。
2、相比于操作系统的交换方式，redis 可以将被交换到磁盘的对象进行压缩,保存到磁盘的对象可以去除指针和对象元数据信息，一般压缩后的对象会比内存中的对象小10倍，这样redis的虚拟内存会比操作系统虚拟内存能少做很多 io 操作。下面是 vm 相关配置
vm-enabled yes #开启 vm 功能
vm-swap-file /tmp/redis.swap #交换出来的 value 保存的文件路径
vm-max-memory 1000000 #redis 使用的最大内存上限
vm-page-size 32 #每个页面的大小 32 个字节
vm-pages 134217728 #最多使用多少页面
vm-max-threads 4 #用于执行 value 对象换入换出的工作线程数量
redis 的虚拟内存在设计上为了保证 key 的查找速度，只会将 value 交换到 swap 文件中。所以如果是内存问题是由于太多 value 很小的 key 造成的，那么虚拟内存并不能解决，和操作系统一样 redis 也是按页面来交换对象的。redis 规定同一个页面只能保存一个对象。但是一个对象可以保存在多个页面中。在 redis 使用的内存没超过 vm-max-memory 之前是不会交换任何 value 的。当超过最大内存限制后，redis 会选择较过期的对象。如果两个对象一样过期会优先交换比较大的对象，精确的公式 swappability = age*log(size_in_memory)。对于vm-page-size 的设置应该根据自己的应用将页面的大小设置为可以容纳大多数对象的大小，太大了会浪费磁盘空间，太小了会造成交换文件出现碎片。对于交换文件中的每个页面，redis会在内存中对应一个 1bit 值来记录页面的空闲状态。所以像上面配置中页面数量(vm-pages134217728 )会占用 16M 内存用来记录页面空闲状态。vm-max-threads 表示用做交换任务的线程数量。如果大于 0 推荐设为服务器的 cpu 内核的数量，如果是 0 则交换过程在主线程进行