redis基础

#key-value cache and store
    持久化
    主从复制：借助于sentinel哨兵实现一定意义上的HA高可用
    Clustering（分布式）
#数据结构服务器：
    String、List、Hash、set、SortSet、Bitmap、HyperLoglog

#存储系统有三类：
    RDBMS：关系型数据库
    Nosql：非关系型数据库
        KV NoSQL:redis
        Column Family NoSQl：HBase
        Documentation Nosql：MOngoDb
    NewSQL：去中心化    
#Redis组件：redis.io 官网
    redis-server:服务器端
    redis-cli：客户端
    redis-benchmark：性能压力测试工具
    redis-check-dump & redis-check-aof：持久化工具
#Redis守护进程
    监听端口：6379/tcp
    
    help 用法：
    
    String：
        SET key value
        GET
        INCR
        DECR
        EXIST
    List：
        LPUSH
        RPUSH
        LPOP
        RPOP
        LINDEX
        LSET
    SETS:
        SADD
        SINIER
        SUNION
        SPOP
        SISMEMBER
    SORTED SET:
        ZADD
        ZRANGE
        ZCARD
        ZRANK
    HASH:
        HSET
        HSETNX
        HGET
        HKEYS
        HVALS
        HDEL
#认证实现方法：
    （1）、修改配置文件redis.conf
        requirepass PASSWORD
    （2）、客户端连接服务器
        redis-cli -h 主机IP地址
        SELECT 0 选择0号redis数据库（默认也是0号，默认有16个数据库） ，会报错，提示没有认证
        AUTH PASSWORD  必须认证后才能操作redis数据库
#清空数据库：
    FLUSHDB:清空当前数据库
    FLUSHALL:清空所有数据库

#事务：
    通过MULTI,EXEC,WATCH等命令实现十五功能：将一个或多个命令归并为一个操作提交给服务器按照舒徐执行的机制，不支持回滚操作
    
    MUTLI:启动一个事务
    EXEC：执行事务
        一次性将事务中的所有操作执行完成返回给客户端
    WATCH:乐观锁，在EXEC命令执行之前，用于监视指定数量键，如果监视中的某任意键数据被修改，则服务器拒绝执行事务
    
    单线程执行事务，redis本身也是单线程，事务天然存在隔离性，在执行事务时不会被终止，事务有没有持久性这一特点取决于服务器有没有开启持久性该项功能
#Connection相关的命令：
    AUTH
    ECHO
    PING
    QUIT
    SELECT
#Server相关的命令：
    CLIENT SETNAME:设置连接名名称
    CLIENT GETNAME:获取服务器连接名
    CLIENT KILL IP:PORT ：指明ip和端口可直接关闭
    
    CONFIG GET
    CONFIG RESETSTAT:重置info获取到的信息
    CONFIG SET parameter value：redis运行时修改指定参数的值，但是只是在内存中修改，要保存的话
    CONFIG REWRITE:将内存中修改的信息同步到文件中去
    DBSIZE：数据库大小
    monitor：实时监控
    
#持久化相关命令：
    BGSAVE
    SAVE

#发布与订阅功能（publish/subscribe）：
    频道：消息队列
    subscribe：订阅一个或多个队列
    PULISH:向频道发布消息
    UNSUBSCRIBE:退订此前订阅的频道
    PSUBCRIBE:模式订阅
#Redis持久化：
    RDB和AOF
        RDB：snapshot快照机制，RDB文件是经过压缩的二进制数据，按照事先定制的策略，定期性地将数据保存至磁盘，数据文件默认为dump.rdb
              客户端也可现时使用SAVE或BGSAVE命令启动快照保存机制
              SAVE：同步，在主线程中保存快照，注意主线程是用来处理客户端请求的，此时会阻塞所有客户端请求
              BGSAVE：异步方式，主线程不会被占用，客户端不会被阻塞
              
              优点：
                    基于快照持久化，书都快，一般用于备份，主从复制也是依赖于edb持久化功能
                    
                     1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复（将持久化到硬盘中的文件恢复即可）。
                     2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
                     3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
              缺点：
                    数据容易丢失
        AOF：Append only File
             以日志形式记录每一次写操作至指定的文件尾部实现持久化，当redis重启时，可通过执行AOF文件中的命令在内存中重建数据库
             
             优点：
                一追加方式记录redis操作日志文件，可以最大程度保证redis数据安全，最多丢失一秒的数据，类似于mysql的binlog
             缺点：
                文件会越来越大
             解决方法：
                BGREWRITEAOF：AOF文件重写，不会读取正在使用AOF文件，而通过将内存中的数据以命令方式保存到临时文件中，完成之后替换原来的AOF文件    
            
            aof配置文件详解：
                表示是否开启AOF持久化： 
                　　appendonly yes(默认no,关闭)  
                AOF持久化配置文件的名称： 
                　　appendfilename “appendonly.aof” 
                AOF持久化策略(默认每秒)： 
                　　appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好) 
                　　appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失) 
                　　appendfsync no  （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的） 
                AOF的Rewrite(重写) ： 
                　　定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制 
                        　　当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof 
                触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发 
                　　　　　auto-aof-rewrite-percentage 100  （一倍） 
                　　　　   auto-aof-rewrite-min-size 64mb 
                　　　　 
                AOF配置文件损坏修复方法： 
                　　进入redis安装路径 执行 redis-check-aof –fix AOF配置文件名称
            重写过程：
                （1）、redis主进程通过fork创建子进程
                （2）、子进程根据redis内存中的数据创建数据库重建命令序列与临时文件中
                （3）、父进程处理client请求，并会把这些请求中的写操作继续追加之原来的aof文件 而外地这些心得写请求还会放置于一个缓冲队列中
                （4）、紫禁城重写完成，发一个信号给父进程，父进程把缓冲中的命令写到临时文件中
                （5）、父进程用临时文件替换老的aof文件
        注意：持久本身不能取代备份，还应该制定备份计划，对redis数据库定期进行备份
        
    RDB和AOF同时启用时：
        （1）、BGSAVE和BGREWRITEAOF不会同时执行
        （2）、在redis服务器启动用于恢复数据时，会优先使用AOF

#redis实现主从复制：
    特点：
        一个Master可以有多个Slave，支持链式复制，且该方式较为稳定，Master以非阻塞方式同步数据至Slave
    从服务器Slave配置命令：
        SLAVEOF 主服务器ip 端口
    注意：
        如果master使用requirepass开启了认证功能，从服务器要使用masterauth PASSWORD来连入服务器前进行认证
        
#sentinel：哨兵
    主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
    
    哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
    
    这里的哨兵有两个作用
        1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
        2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

    然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
    
    故障切换（failover）的过程：
        假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，
        那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，
        一切都是透明的。
    
    主管下线和客观下线：
        主管下线：一个sentiel实力判断出某个节点下线
        客观下线：多个sentinel节点协商后判断出某个节点下线
    程序：
        redis-sentinel /path/to/file.conf
        redis-server /path/to/file.conf --sentinel
        
        (1)、服务器自身初始化，运行redis-server中专用于sentinel功能的代码
        (2)、初始化sentinel状态，根据给定的配置文件，初始化监控的master服务器列表
        (3)、创建联想master的连接
    专用配置文件：
        /etc/redis-sentinel.conf
#Clustering:集群
    分布式数据库，通过分片机制进行数据分布，clustering内的每个节点仅是数据库的一部分数据，每一个节点持有全局元数据