一、安全性
设置客户端连接后进行任何其他指定前需要使用的密码。
警告：因为redis速度相当快，所以一台比较好的服务器，一个外部用户可以在一秒钟进行15万次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。
1、设置redis密码：
在etc下的redis.conf文件中找到requirepass（vi命令下的搜索关键字：按下/后输入关键字）
在requirepass后跟设置的密码：
保存后重启redis服务。
虽然进入客户端不需要密码，但是如果不使用auth输入密码授权，则无法进行操作。
命令：auth zhaojw
也可以在进入客户端的时候输入密码，则进入后就不需要auth进行授权就可以操作。
命令： ./redis-cli -a zhaojw
二、主从复制
Redis的主从复制配置和使用都很简单，通过主从复制可以允许多个slave server（从服务器）拥有和master server（主服务器）想同的数据库复本。
Redis主从复制的特点：
1、Master可以拥有多个slave。
2、多个slave可以连接同一个master外，还可以连接其他的slave。当主机挡掉以后，某一个slave会立即变为主机。
3、主从复制不会阻塞master，在同步数据时，master可以继续处理client的请求。
4、提高系统的伸缩性。
Redis主从复制的过程：
1、slave与master建立连接，发送sync同步命令
2、Master会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存。
3、后台完成保存后，就将此文件发送给slave。
4、slave将文件保存到硬盘上。
配置主从服务器（/etc/redis.conf文件中）：
1、配置slave服务器：
在slave的配置文件中加入以下配置：
slaveof 主机master的ip 主机master的端口
masterauth 主机密码
可用info命令查看当前服务器的角色role是主还是从，以及连接信息。
三、事务处理
1、Redis对事物的支持目前还比较简单。Redis只能保证一个client发起的事物中的命令可以连续的之行，而不会插入其他client的命令。
当一个client在一个连接中发出multi命令时，这个连接会进入一个事物上下文，该链接后续的命令不会立即执行，而是放入一个队列中，当执行exec命令时，redis会顺序的执行队列中的所有命令。
127.0.0.1:6379[1]> set name zhaojw
OK
127.0.0.1:6379[1]> get name
"zhaojw"
127.0.0.1:6379[1]> multi
OK
127.0.0.1:6379[1]> set name zhaojw1
QUEUED
127.0.0.1:6379[1]> set name zhaojw2
QUEUED
127.0.0.1:6379[1]> set age 26
QUEUED
127.0.0.1:6379[1]> exec
1) OK
2) OK
3) OK
127.0.0.1:6379[1]> get name
"zhaojw2"
127.0.0.1:6379[1]> get age
"26"
discard：取消事物，清空事物的命令队列并退出事物上下文，也就是常说的事物回滚。
127.0.0.1:6379[1]> get name
"zhaojw2"
127.0.0.1:6379[1]> multi
OK
127.0.0.1:6379[1]> set name zhaojw
QUEUED
127.0.0.1:6379[1]> set name zhaojw1
QUEUED
127.0.0.1:6379[1]> discard
OK
127.0.0.1:6379[1]> get name
"zhaojw2"
2、redis中的事物的命令队列中的某一条命令执行错误时，不会回滚，也就是数其余没有错误的命令依然之行，只是错误的命令没有执行。
3、乐观锁复杂事物控制
乐观锁：大多数是基于数据版本(version)的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表里添加一个“version”字段来实现读取数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交的数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库的当前版本号，则予以更新，否则认为是过期数据。
watch命令会监视给定的key，当exec时候如果监视的key从调用watch后发生过变化，则整个事物会失败。也可以调用watch多次监视多个key，这样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的，事物也一样。如果连接断开，监视与事物都会被自动清除。当然，exec，discard，unwatch命令都会清除连接中的所有监视。
四、持久化机制
Redis是一个支持持久化的内存数据库，也就是说Redis需要经常将内存中的数据同步到硬盘来保证持久化。
Redis支持两种持久化方式：
1、snapshotting(快照)默认方式：
这中方式是将内存中数据以快照的方式写入二进制文件中，默认的文件名为dump.rdb（二进制文件无法查看）。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做成快照。
如：save 900 1 #900秒内超过1个key被修改，则发起快照保存。
save 300 10 #300秒内超过10个key被修改，则发起快照保存。
2、Append-only file（缩写：aof）的方式：
由于快照方式是在一定间隔时间做一次，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
aof比快照方式有更好的持久化性，是由于在使用aof时，redis会将每一个收到的写命令通过write函数追加到文件中，当redis重启时会通过重新之行文件中保存的写命令来在内存中重建整个数据库的内容。
当然由于os（ObjectStream）会在内核中缓存write做的修改，所以可能不是立即写到磁盘上，这样aof方式的持久化也还是有可能丢失部分修改。可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。
配置aof：
appendonly yes #启用aof持久化方式
appendfsync always：收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec ：每秒写入磁盘一次，在性能和持久化方面做了很好的折中。
appendfsync no ：完全依赖os，性能最好，但是持久化没保证。
五、发布订阅消息
发布与订阅（pub/sub）是一种信息通信模式，主要的目的是解除消息发布这与消息订阅者之间的耦合，Redis作为一个pub/sub的server，在订阅者和发布者之间起到了一个消息路由的功能。订阅者可以通过subscribe和psubcribe命令向redis server订阅自己感兴趣的消息类型，redis将消息类型成为通道(channel)。当发布这通过publish命令向redis server发送特定类型的信息时，订阅该信息类型的全部client都会收到此消息。
比如：第一个客户端：subscribe tv1
第二个客户端订阅tv1和tv2：subscribe tv1 tv2
第三个客户端在tv1上发布消息：psubcribe tv1 zhaojw。返回监听tv1的客户端个数。
那么第一个和第二个客户端都显示了zhaojw这条信息。
若第三个客户端在tv2上发布消息，那么只有第二个客户端才能收到这条消息。
六、虚拟内存的使用
Redis的虚拟内存与操作系统的虚拟内存不是一回事，但是思路和目的都是相同的。就是暂时把不经常访问的数据从内存交换到磁盘中，从而腾出宝贵的内存空间用于其他需要访问的数据。尤其是对于redis这样的内存数据库，内存总是不够用的。除了可以将数据分隔到多个redis server外。另外能够提高数据库容量的办法就是使用虚拟内存把那些不经常访问的数据交换写到磁盘上。
vm-enabled：是否开启虚拟内存支持
vm-swap-file /tmp/redis.swap：#交换出来的value保存的文件路径
vm-max-memory 10000000：设置redis使用的最大物理内存大小
vm-page-size 32：设置虚拟内存的页大小，即每个页面大小是32个字节
vm-pages 134413131：设置交换文件总的page数量，最多使用多少页面
vm-max-threads：设置VMIO同时使用的线程数量，用于执行value对象换入缓存的工作线程数量