redis 从入门到进阶

1.redis介绍
   1.（了解）redis是单线程模式！  
   2.redis 过期策略

         maxclients :最大的客户端连接数 :默认是10000个
        maxmemory :使用的最大内存,如果达到最大值会按照 maxmemory-policy 进行移除操作,默认不配置的话,进行操作会返回错误
                maxmemory-policy:redis rdb策略:
     
        maxmemory-policy:
                
                1.移除最近最少使用的key,默认设置了过期的  
                2.移除最近最少使用的key,

                3.随机移除,默认设置了过期的
                4.随机移除

                5.移除在规定时间内,更早的过期的key             

                maxmemeory-samples：
                设置样本数量，LRU 算法和最小的TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小
                 redis会检查这么多个key兵选择其中LRU的那个
    

        3、redis的持久化策略
        AOF + RDB
        RDB ：什么是RDB
                在指定的时间间隔内将内存中的数据集快照写入磁盘，  (在指定的时间内将内存中的数据写入磁盘，)
                也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里  （恢复时是将dump.rdb文件读取到内存中)
        原理：（必须记住）  
   
                Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
                一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

                整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能

                如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
                式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
----------------------------------------------------------------------------------------------------------------------
        RDB: 
                Redis会重新fork出一条子进程，这条子进程和主进程一模一样，
                因为cpu里面读和写的操作很慢,所以说fork出一条子进程，让它来进行读和写操作，
                当持久化操作完成之后，它就会将fork出来的子进程中的文件去替换原来进程中的那个配置文件，
                整个过程中，主进程不进行任何IO操作，这就确保了极高的性能，RDB适合进行大规模数据的恢复，
                因为它有一个缺点，就是最后一次持久化后的数据可能会丢失

                被动策略有3种，默认情况为900s触发1次，300s触发10次,60s触发1万次
        
                
----------------------------------------------------------------------------------------------------------------------
        fork：
           主动 
                 Save：save时只管保存，其它不管，全部阻塞
                 BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
                 flush操作
                 shutdown 操作
                        
        被动
            save ""  

可选
                   stop-writes-on-bgsave-error ：如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

          
             rdbcompression 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用
LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

            rdbchecksum： 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
            dbfilename:dump.rdb

-----------------                
         总结：
         优势
                适合大规模的数据恢复
         劣势
                在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
                fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
AOF
  
     appendonly.aof  
     

       1）、aof是什么
         以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
         只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
         重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
       2）、
        2.2如果两者都有  走的aof，那么采用哪个策略（修复）   ：./redis-check-aof --fix appendonly.aof 
      3）配置文件
          appendfsync 同步策略
                always：同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
                everysec：出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失

                        
                 以日志的形式来记录每个写操作   （命令）
                                always： 记录写操作，通过io写入到磁盘
                                everysec        :记录写操作，并不会立刻写入到磁盘(先存入到内存中)   --> 内存中中的这些命令写入到磁盘上
                 

         触发条件
                Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍并and文件大于64M时触发

         no-appendfsync-on-rewrite：重写时是否可以进行Appendfsync（持久化），用默认no即可，保证数据安全性。
        
      aof文件重写的条件
        auto-aof-rewrite-min-size： 64M
        auto-aof-rewrite-percentage：是原来的2倍时
         重写aof文件 ，放置aof文件过大

伪

主从备份
        也就是我们所说的主从复制，主机数据更新后根据配置和策略，
        自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
                
三： 一主二从的情况
         
         redis:  replication 
            核心机制：
                 1.redis 的采用异步的方式将数据复制到slave 节点上
                 2.一个master node 可以配置多个slave node
                 3.slave node 做复制的时候，master 可以正常工作
                 4.slave node 在做复制时，自己也能正常查询，它会用旧的数据提服务，但是复制完成时，就删掉以前的服务，加载新的服务
                   注意：
           master 一定要做持久化机制处理
             



        增量更新：每次更新的内容是添加的内容
        全局更新：将所有的内容进行添加 
                   开始生成一份rdb 快照文件，同时还会将从客户端的数据写入到内存中，rbd文件生成完毕后，master 会将这个rdb发送给slave ，slave 先写入到本地磁盘，然后再从本地磁盘加载到内存中，然后master 将内存中的数据 通过写指令->slave，slave 再进行数据的同步
         以上时有磁盘化复制
        
         无磁盘化复制
            master 在内存中创建rdb，然后发给salve，本地不会再有磁盘
            repl-diskless-sync
            repl-diskless-sync-delay : 等待的时间开始复制，需要更多的slave 重新连接
        
          master 和slave 底层都会维护一个offset ，->master和salve 都会去累加offset ，当在进行全量更新时，如果出现主机出现问题宕机，这个时候，会去得到slave的offset 的信息，这时就知道数据到底一致不一致了,按照从机的数据再次写入给从机


        4. 过期key 处理
                 slave 不会过期key，只会等待master 过期key，如果master 过期key，或者通过LRU 淘汰了一个key，那么会模拟一条del 命令发送给slave
                
         


四：哨兵模式
        哨兵： （sentinel）
                进行投票选取出新主机
                sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

        主从模式下： 什么情况可能出现问题
         1.异步复制
                 当客户端写入数据时，写给master，master 再异步给slave ->如果这个数据 还没有写给slave->哨兵检查到
master 挂掉，这个时候，哨兵选取某个slave 作为master ,则 master 数据丢失

         2.集群脑裂
                数据因为网络哨兵不能检测到master，出现了多个master -> 此时有两个大脑
                  当client 和脱离的 连接，继续写数据, 回来时，变为从机，数据丢失
             
                   min-slaves-to-write 1  
                        
                         min-slaves-max-lag 10 
                         要求至少有1个slave ，数据复制和同步的延迟不能超过10 秒
                   解决：
                  有了min-slaves-max-lag这个配置，就可以确保说，一旦slave 复制数据和ack延时太长，就认为可能master 宕机后损失太多数据，那么就决绝写请求，这样可以把master 宕机时由于部分数据来同步到slave 导致的数据丢失降低到可控



五：redis的事物
六：redis的集群配置  qingcheng  


  
原子性
    要么都成功， 要么都失败


弱原子性

   



redis的事物
    可以一次执行多个命令，本质是一组命令的集合。一个事务中的
    所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

exec  


    set k1 v1 
    set k2 v2
            

   redis的事物是弱原子性 弱事物的
   关系型数据库强原子性

    打开事物：
     multi   回复OK ！  
    discard 放弃本次操作


    case1：正常执行
    case2 放弃事物
    case3 全体连坐  语法有错  set k1 
    case4 冤头债主  逻辑有错  incr k1 

   
    
    case5 ：watch监控
   
   常用命令 
          开启事物
        multi
          取消事物
                 discard
          执行事物
         exec
        

           unwatch 
         取消watch命令对所有key的监视
           watch     
          监视一个或多个key，如果执行事物之前被其他key修改，那么事物会被打断   不能
          如果没有监视这个key，那么在事物中这个key被其他操作修改后，能成功吗？ 能

                
redis对事物的支持是部分支持

100 

初始化信用卡可用余额和欠额   
余额banlance  100
  

无加塞 操作数据
加塞
incrby 
decrby





单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚