redis的高级应用之一（Redis安全性\主从复制\事务处理）

redis的高级应用。

    (1).redis 的安全性：设置客户端连接之后，进行任何其他指令之前都需要使用的密码。

    【warn】：由于redis数据非常快，在一台非常好的服务器下，一个用户可以在1s进行150K次密码尝试；所以需要指定非常强大的密码来防止暴力破解。

    设置密码： 在redis.conf文件下#requirepass foobared 下requirepass 自己设置的密码，设置完了之后要重启服务。 linux下 vi 编辑conf文件。

    设置好了之后，pkill 掉redis-server 服务，重启redis服务(redis/bin/redis-server redis/etc/redis.conf)；

    登陆客户端（client）之后，你会发现你的操作无法进行;有个操作被限制的错误

    redis 127.0.0.1:6379> keys *
    (error) ERR operation not permitted
    redis 127.0.0.1:6379> set dj avicii
    (error) ERR operation not permitted

    这说明我们没有权限操作,需要我们授权。 方式一：auth 密码口令

    redis 127.0.0.1:6379> auth zeng
    OK
    redis 127.0.0.1:6379> keys *
     1) "key2"
     2) "mimi"
     3) "mama"
     4) "age"
     5) "test"
     6) "name"
     7) "myset"
     8) "zeng"
     9) "email"
    10) "key"
    11) "key10"
    12) "key1"
    redis 127.0.0.1:6379> set dj avicii
    OK
    redis 127.0.0.1:6379> get dj
    "avicii"

     方式二，不想每次进来之后 操作的时候就授权，可以在登陆客户端的时候 后面就跟上授权密码 ： redis-cli -a 密码口令

    （2）reids 的主从复制☆☆☆

        Redis 的主从复制配置和使用都比较简单，通过主从复制可以允许多个slave server（从服务器）拥有和master server（主）相同的数据库副本。

        ①Redis主从复制特点：

        1.一个master可以拥有多个slave；

        2.多个slave 除了可以连接master之外，还可以连接其他的slave。

        3.主从复制不会阻塞master，在同步数据时，master服务器可以继续接受和处理client的请求操作

        4.提高系统的伸缩性

        ②Redis主从复制的过程：

        1.slave与master建立连接，并且发送sync同步请求；

        2.master会启动一个后台进程，将数据库快照保存到文件中；同时master主进程会开始客户端client新的读写命令并缓存；（两个进程互不影响）

        3.后台保存完成后，将此文件发送给slave

        4.slave将文件保存到硬盘

        ③配置主从服务器

        1.找到slave的redis.conf 文件 ，找到# slaveof <masterip> <masterport>  下配置slaveof 主机ip 端口（6379），

        2.找到# masterauth <master-password> ，配置主机的授权masterauth 主机密码

        【注】：如何区分那个主从机服务器， 在客户端使用命令：info 主机的话  可以看到role：master  和连接上去的slave 的ip和端口 是主机

        role 为 slave 的为从机。

        ④设置成功之后，在主机set 一个key； 然后再 在slave 中keys *， 发现也能在数据库找到这个key ；这样就完成主从复制

    (3)redis的事务处理

    ①.redis目前还是支持比较简单的事务处理,redis只能保证一个client发起的事务中的命令连续执行,而中间不会插入其他client的命令.

    一个client在一个连接中发起multi命令,这个链接会进入事务的上下文,该链接后续的命令不会被立即执行；而是先放到一个队列中，当执行exec命令后，redis会顺序执行队列中的命令。

    如果不行执行这个事务的话，可以用discard命令取消事物；队列中的命令会被取消，事务回滚掉。

    demo：

    redis 127.0.0.1:6379> get age
    "20"
    redis 127.0.0.1:6379> multi        【进入事务上下文】
    OK
    redis 127.0.0.1:6379> set age 100    【进入一个队列】
    QUEUED
    redis 127.0.0.1:6379> set age 50
    QUEUED
    redis 127.0.0.1:6379> exec        【exec 后 依次执行命令】
    1) OK
    2) OK
    redis 127.0.0.1:6379> get age
    "50"

    redis 127.0.0.1:6379> multi
    OK
    redis 127.0.0.1:6379> set age 30
    QUEUED
    redis 127.0.0.1:6379> discard    【取消事务】
    OK
    redis 127.0.0.1:6379> get age    【事务没有被执行】
    "50"

    redis 为什么只支持简单事务呢，可以看下面一个demo：

    demo2：

redis 127.0.0.1:6379> get name        
"leonardo.com"
redis 127.0.0.1:6379> incr name            【对一个字符串自加 是会报错的】
(error) ERR value is not an integer or out of range
redis 127.0.0.1:6379> multi                   【进入一个事务】
OK
redis 127.0.0.1:6379> incr age        
QUEUED
redis 127.0.0.1:6379> incr name            【把自加这个命令放到队列中】
QUEUED
redis 127.0.0.1:6379> exec             1) (integer) 51
2) (error) ERR value is not an integer or out of range

redis 127.0.0.1:6379> get age             【这个demo中exec之后，发现命令还是会被执行，第一条自加age命令被执行成功，而且不像我们关系型数据库中整个事物该被回滚；这个就redis事务的欠妥的方面了】
"51"

    ②.redis 乐观锁的复杂事物实现:

    (1).首先介绍什么事乐观锁和悲观锁？

       乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此Version+1。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

        悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

    (2).Redis乐观锁实例:对于一个key为name,我们开2个session对这个key进行赋值 ;看这个demo:

        第一步: session1中: 对这个key 进行监听，并进入事务上下文

        redis 127.0.0.1:6379> get name
        "leonardo.com"
        redis 127.0.0.1:6379> watch name        [注]：对key为name的键进行监听，
        OK
        redis 127.0.0.1:6379> multi                    [注]：进入事务上下文
        OK
        redis 127.0.0.1:6379> set name leo-zeng    【注】：set该key，并提交到事务队列中
        QUEUED

        第二步： 在session2 中： 在另外一个session中，直接对name的key进行赋值，

         redis 127.0.0.1:6379> set name alex-zeng
        OK
        redis 127.0.0.1:6379> get name
        "alex-zeng"
        redis 127.0.0.1:6379>

        第三步：返回到session1 中，进行exec 操作，发现会返回个null ，发现该事务执行不成功。可以说明我们在另外一个session中已经对该监控的key进行了一个修改并提交到服务器中，我们在另外一个会话中对这个事务处理到一半的可以提交事务就会不成功。这个就是乐观锁的redis实例了。

        redis 127.0.0.1:6379> exec
        (nil)
        redis 127.0.0.1:6379> get name
        "alex-zeng"
        redis 127.0.0.1:6379>

        结论：watch命令会监视给定的key，当exec的时候如果该key在watch后发生过变化的话，则整个事物就会失败；也可以调用watch对多个key进行监视，这样就可以对多个key加乐观锁了。注意watch指定的key只对整个连接有效的，事务也是如此；若连接断开，监视会自动删除。