Redis基础概念

redis-server redis.windows.conf  redis启动命令
输入redis-cli并回车（redis-cli是客户端程序）如图正常提示进入，并显示正确端口号，则表示服务已经启动。
输入“auth 123456”并回车（123456是之前设定的密码）。返回提示OK表示验证通过。

windows安装：
Windows 安装 Redis_redis windows_羽之大公公的博客-CSDN博客

 一、redis五大数据类型：
Redis字符串（String)
Redis列表（List)
Redis集合（Set)
Redis哈希（Hash)
Redis有序集合（Zset)

 1)首先字符串（string)：
   String类型是二进制安全的，意思就是说只要这个内容能用字符串表示，那么都可以存到这里面去，比如说图片用字节形式表示做成字符串，放到文件中然后进行读取，然后将字符串转成一个图片，视频也能转成一个字符串，放在里面存储，然后再转换成一个视频。
   String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以512M。
        
 常用命令：
  flushdb 清空当前库；
  select  2 切换为2号数据库；
  dbsize  查看当前数据库的key的数量；
  flushall  通杀全部库；
  keys *   查看当前库所有key;
  set k1 v1,设置key为k1值为v1;   设置相同的key会把之前的覆盖掉
  get k1 ,获取key为k1键值；
  append k1 v1; 将v1加到k1原值的末尾
  strlen k1；获取k1值得长度
  setnx k1 v1;当k1不存在时，设置k1得值
  incr k1，将k1中存储得数字值增1，只能对数字操作，如果为空，新增值为1
  (Redis中增减时原子性操作，也就是不受多线程影响的操作。)
  decr k1,将key中存储得数字值减1
  incrby/decrby k1 num,将key中存储得数字值增减，自定义数字值
  mset k1 v1 k2 v2 k3 v3 ;设置多个key value。
  mget k1 k2 k3;获取多个值
  msetnx k1 v1 k2 v2 k3 v3；也是设置多个值，但是如果之前已经存在得话，就不会成功
 (设置多个值也是原子性得，有一个失败则都失败）
  getrange k1 start end；获取k1值得范围。
  setrange k1 3 abc；在k1值得第三个位置设置一个abc
  setex k1 time value；设置k1得值为value,然后过期时间时time
  getset k1 v1;以新换旧 将k1设置为v1，同时将旧值取出来；

  数据结构：

          内部为当前字符串的实际空间capacity一般要高于实际字符串长度len,当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M,扩容时一次只会多扩1M的空间。需要注意的是字符串的最大长度为512M.
 

        2)List列表
          单键多值：就是说一个key对应多个值。
           Redis列表就是简单的双向链表，按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
           它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会比较差。

        常用命令：
        1、lpush / rpush k1 v1 v2 v3 从左边右边插入一个多个值
        2、lrange k1 start stop;按照索引从左往右取值，lrange k1 0 -1 ;取出k1所有的值
      从左边插入，意思就是新插入的在原来值得左边。
      从右边插入就是新插入得在原来值的右边。

        3、lpop\rpop k1 从左边、右边吐出一个值，键在人在，值光健忘，也就是取出最后一个就没有了
        4、rpoplpush k1 k2 从k1列表右边吐出一个值，插到k2列表左边。
        5、index k1 index ; 按照索引下标获得元素（从左到右)；
        6、llen k2获得列表长度；
        7、linsert k1 before v1 v2 在v1的后面插入v2插入值
        8、irem k1 n v1；从左边删除n个value(从左到右）
        9、lset k1 index value ；将列表key下标为index的值替换成value

        数据结构:
        List的数据结构为快速链表quickList 
        首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构式zipList,也就是压缩列表
        它将所有的元素紧挨着一起存储，分配的是一块连续的内存
        当数据量比较多的时候才会改成quickList。
        因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev 和 next.    
            

         Redis将链表和zipList结合起来组成了quickList.也就是将多个zipList使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。
 

        3）Set集合
        Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以j自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的
        Redis 的 Set是string类型的无序集合，它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)
        一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变。

        常用命令：
        sadd k1 v1 v2 ；将一个或多个元素加入到集合key中，已经存在的member元素将被忽略
        smembers k1；取出该集合的所有值。
        sismember k1 v1；判断集合k1是否有该v1值，有1，没有0。
        scard k1；返回该集合元素个数。
        srem k1 v1 v2；删除集合中的某个元素
        spop k1；随机从该集合中取出一个值。
        srandmerber k1 n；随机从该集合中取出n个值，不会从集合中删除
        smove k1 k2 v3；将k1集合中的一个值从一个集合移动到另一个集合
        sinter k1 k2 ；返回两个集合的交集元素
        sunion k1 k2；返回两个集合的并集元素。
        sdiff k1 k2；返回两个集合的差集元素（k1中的，不包含k2中的）
 

        4）hash哈希
        Redis hash 是一个键值对集合；
        Redis hash 是一个string类型的field 和 value 的映射表，hash特别适合用于存储对象。
        类似于Java里面的Map<String,Object>
        

              key 是 user， 整体部分是value值。相当于嵌套key.Map<string,Map<key,vaule>>
               
               相关操作：
                hset k1 <field><value> 给key集合中的field赋值value.
                hget k1 <field>；从k1集合field中取出value.
                hmset k1 <field1><value1><field2><value2>..；批量设置hash值
                hexists k1 field；查看hash表key中，给定field是否存在；
                hkeys k1；列出该hash集合的所有field;
                hvals k1；列出该hash集合中所有value;
                hincrby k1 field increment；为哈希表key中的域field的值加上增量1
                hsetnx k1 field value；将哈希表key中的域field的值设置为value,当且仅当域field不存在

                数据结构：
                hash类型对应的数据结构是两种，ziplist压缩列表、hashtable哈希表，当field-value长度较短且个数较少时，使用ziplist,否则使用hashtable.
                

                5)有序集合Zset
                Redis 有序集合zset 与普通集合set非常相似，是一个美哟重复元素的字符串集合；
                不同之处就是有序集合的每个成员都关联了一个评分（score），这个评分score被用于按照从最低分导最高分的方式排序集合中的成员，集合的成员是唯一的，但是评分可以是重复的。
                因为元素是有序的，所以你也可以很快的根据评分score或者次序position来获取一个范围的元素。
                 访问有序集合的中间元素也是非常快的，因此你能够使用有序集合作为一个没有重复成员的智能列表。

                相关集合：
                zadd k1 score1 value1 score2 value2；将一个或者多个member元素及其score值加入到有序集key中。
                zrange k1 0 -1；取出最大值 最小值 
                zrange k1 0 -1 withsores；取出最大值最小值带评分。
                zrangebyscore topn 300 500(withscores);返回有序集 key 中，所有score值介于min和max之间包括等于min或max的成员。有序集成员按照score值递增（从小到大）排列
                zrevrangebyscore k1 max min(withscores);从大到小排列
                 zincrby k1 num value；为元素的score加上增量。
                zrem k1 value；删除该集合下，指定值的元素。
                zcount k1 min max；统计该集合，分数区间内的元素个数。
                zrank k1 v1；返回该值再集合中的排名，从0开始
                
                数据结构：
                zset 是Redis提供的一个非常特别的数据结构，一方面它等价于java中map的数据结构Map<String,Double>，可以给每一个元素value赋予一个权重score，另一方面他有类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表
                zset底层使用两个数据结构。
                1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的scroe值
                2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。
 

                跳跃表：
                有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名，对于有序集合的底层实现，可以用数组、平衡树、链表等。数据不使用元素的插入、删除；平衡树或者红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis采用的是跳跃表，跳跃表效率堪比红黑树，实现远比红黑树简单。
        
                

 

 

二、发布和订阅

        1）什么是发布和订阅
        Redis 发布订阅是一种消息通信模式：发送者（pub）发送消息，订阅者接收消息。
        Redis 客户端可以定于任意数量的频道.
        

 

 也就是说客户端订阅之后，发布到这个频道的消息就会被推送到订阅的客户端中
 

简单演示：
        开启两个客户端
        一个订阅 ，一个发布
订阅：

D:\redis>redis-server redis.windows.conf
[24580] 15 Aug 23:06:58.643 # Creating Server TCP listening socket *:6379: bind: No error

D:\redis>redis-cli
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> SUBSCRIBE channel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel"
3) (integer) 1
1) "message"
2) "channel"
3) "hello"

推送：

D:\redis>redis-server redis.windows.conf
[20536] 15 Aug 23:09:52.239 # Creating Server TCP listening socket *:6379: bind: No error

D:\redis>redis-cli
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> publish channel hello
(integer) 1
127.0.0.1:6379>

三、新数据类型

        1）Bitmaps
         现在计算机用二进制（位）作为信息的基础单位，1个字节等于8位，例如”abc"，字符串是由3个字节组成，但实际在计算机存储时将其用二进制表示，“abc”分别对应的ASCII码分别是97、98、99，对应的二进制分别是01100001、0110010和01100011，如下图
        

         合理的使用操作位能够有效的提高内存使用率和开发效率。
         Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：
        1）Bitmaps本身不是一种数据类型，实际上他就是（key-value）,但是它可以对字符串的位进行操作
        2）Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同，可以把Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量。

        常用命令：
        1、setbit；
        setbit key offset value：设置Bitmaps 中某个偏移量的值（0或1）；
        2、getbit;
        getbit key offset ；获取Bitmaps 中某个偏移量的值；获取键的第offset位的值（从0开始算）
        3、 bitcount key [start end]；
         统计字符串被设置为1的bit数，一般情况下，给定的整个字符串都会被进行技术，通过指定额外的start或end参数，可以让技术只在特定的位上进行，start和end参数的设置，都可以使用复数值，比如-1表示最后一个位，而-2表示倒数第二个位，start、end是指bit组的字节的下标数，二者皆包含。
        举例：k1 (01000001 01000000 00000000 00100001)
        对应下标为 0，1，2，3
        bitcount k1 1 2；统计下标1、2字节组中bit=1的个数，即01000000 00000000 
        得数就是1；
        bitcount k1 1 3；统计下标1、2、3字节组中bit=1的个数，即0100000 00000000 00100001
        得数就是3；
        bitcount k1 0 -2；统计下标 0 到下标倒数第2,字节组中bit=1的个数，
        得数就是3；
        4、bitop
        bitop and(or/not/xor) [key...]
        bitop 是一个复合操作，它可以做多个Bitmaps的and(交集)、or(并集)、not(非)、xor(异或)操作并将结果保存在destkey中。
        

        2）HyperLogLog
                简介：再工作当中，我们经常会遇到与统计相关的功能需求，比如网站PV(PageView页面访问量)，可以使用tRedis的incr、incrby轻松实现。
                但是像UV(UniqueVisitor,独立访客)、独立IP数、搜索记录数等需要去重和技术的问题如何和解决？这种求集合中不重复元素个数的问题称为基数问题。
                解决基数问题有很多种方案：
                1）数据存储在MYSQL表中，使用distinct count计算不重复个数
                2）使用Redis提供的hash、set、bitmaps等数据结构来处理
                以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。
                Redis推出了HyperLogLog。
                HyperLogLog是用来做技术统计的算法，HyperLogLog的优点是，在输入元素的数量或体积非常非常大时，计算基数所需的空间总是固定的，并且是很小的。
                在Redis里面，每个HyperLogLog键只需要花费12Kb内存，就可以计算接近2^64个不同元素的基数，这和计算基数时，元素越多内存就越多的集合形成鲜明对比。
                但是，因为HyperLogLog只会根据输入元素计算基数，而不会存储输入元素本身，所以HyperLogLog不能像集合那样，返回输入的各个元素。
                什么是基数：
                 比如数据集（1，3，7，5，7，8）那么这个数据集的基数为（1，3，5，7，8）基数（不重复的元素）为5，基数估计i局势在误差可接受的范围内，快速计算基数。

                常用命令：
                1、pfadd
                pfadd key1 v1 v2；将所有元素添加到指定HyperLogLog数据结构中，如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。
                2、pfcount
                pfcount k1 ；计算k1中的基数。
                3、pfmerge
                pfmerge k1 k2 k3 ；将k2，k3 中的ishu合并到k1中。

                

3）Geospatial
        简介：Redis3.2中增加了对GEO类型的支持，GEO,Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度，redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度hash等常见操作。
        相关命令：
        1）geoadd china:city 121.47 31.23 shanghai；添加key为china:city 经度为：121.47  维度为：31.23 城市名称为 shanghai
        两极无法添加，一般会下载城市数据，直接通过java程序一次性导入。有效的精度从-180度到180度，有效的维度从-85.05112878 度到85.05112878度。
        当坐标位置超出指定范围时，该命令将会返回一个错误。
        已经添加的数据，是无法再次往里面添加的。
        
        2）geopos china:city shanghai；从china:city中取出名为shanghai的经纬度。

        3）geodist china:city bejing shanghai km；从key为china:city 中查询名为bejing到shanghai单位为km的直线距离。

        4）georadius
        georadius china:city 110 30 km 从key中china:city中找出距离东经110，北纬30方圆1000公里以内的城市。
 

四、SpringBoot整合Redis
        1)首先引入springboot的相关依赖
        2）引入redis的依赖

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
        </dependency>

        3）redis相关配置

spring:
    redis:
      connect-timeout: 5000
      password: 123456
      database: 0
      host: 192.168.1.3
      port: 6379
      jedis:
        pool:
          max-active: 8   # 最大连接数(使用负值表示没有限制) 默认为 8
          max-wait: -1    # 最大阻塞等待时间(使用负值表示没有限制) 默认为 -1 ms
          max-idle: 8     # 最大空闲连接 默认为 8
          min-idle: 0

        4）redis配置类

@Configuration
public class RedisTemplateConfig {

    @Bean(name = "redisTemplate")
    public RedisTemplate redisTemplate(RedisConnectionFactory factory){
        System.out.println("redis序列化-->");
        RedisTemplate redisTemplate = new RedisTemplate();
        RedisSerializer redisSerializer = new StringRedisSerializer();
        //连接工厂
        redisTemplate.setConnectionFactory(factory);
        //键序列化
        redisTemplate.setKeySerializer(redisSerializer);
        //值序列化
        redisTemplate.setValueSerializer(redisSerializer);
        //key hashMap序列化
        redisTemplate.setHashKeySerializer(redisSerializer);
        //value hashMap序列化
        redisTemplate.setHashValueSerializer(redisSerializer);
        return redisTemplate;
    }

}

        5）调用redis命令简单实现

    @Autowired
    private RedisTemplate redisTemplate;


    @GetMapping("/test")
    public String test(){
        redisTemplate.opsForValue().set("name","lucy");
        return (String) redisTemplate.opsForValue().get("name");
    }

        五、Redis6的事务操作

        1)redis的事务定义
        redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
        Redis事务的主要作用就是串联多个命令防止别的命令插队。

        2）Multi、Exec、discard
        从输入Muti命令开始，输入的命令都会一次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令一次执行。
        组队过程中可以通过discard来放弃组队。
         

        3）redis事务中的异常处理
               1 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消
                2 如果组队过程中没有错误，但是命令执行中出现了错误，则报错的命令不会执行。而其他的命令都会执行，不会回滚

        4) 悲观锁、乐观锁
                
                悲观锁：顾名思义，就是很悲观，每次去拿数据得时候都任务别人会修改，所以每次在拿数据得时候都会上锁，这样别人想拿这个数据都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统得关系型数据库里面就用到了很多这样锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
                乐观锁：顾名思义，就是很乐观，每次去拿数据得时候都认为别人不会修改，所以不会上锁，但是在更新得时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读得应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
                        

六、持久化操作

        RDB
        AOF

        在指定得时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snaphot快照，他恢复时是将快照文件直接读到内存里。
         内存跟磁盘的区别：内存是cpu和硬盘数据之间的缓冲，cpu只能读取内存里的数据。这样内存就变成了一一个桥梁的作用；而硬盘是作为存储空间的。内存中的信息会随断电而丢失；硬盘中的信息可以长久保存。

        1、RDB
              备份是如何执行的：Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了较高的性能，如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。RDB是默认开启的，在启动目录下
        

        Fork：
        fork的作用四复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值与原进程一致，但是一个全新的进程，并作为原进程的子进程。
        在linux程序中，fork会产生一个和父进程完全相同给的子进程，但子进程在此后多会exec系统调用，处于效率考虑，liunx中引入”写时复制技术“
        一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。  

        劣势：
        1、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性u要考虑
        2、虽然Redis在Fork时使用了写时拷贝技术，到那时如果数据庞大时还是比较消耗性能。
        3、在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
        优势：
        1、适合大规模的数据恢复
        2、对数据完整性和一致行要求不高更适合使用
        3、节省磁盘空间
        4、恢复速度快 

        2、AOF
              以日志形式记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。
                AOF是默认不开启的，可以在redis.conf中配置文件名称，默认为appendonly.aof,AOF文件的保存路径，同RDB的路劲一致
                AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

        AOF持久化流程
        1、客户端的请求写命令会被append追加到AOF缓冲区内
        2、AOF缓冲区根据AOF持久化策略，将操作sync同步到磁盘的AOF文件中；
        3、AOF文件大侠超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩文件容量；
        4、redis服务重启时，会重新load加载AOF文件中的写操作到数据恢复的目的；

        AOF同步频率设置
        appendfsync always:始终同步，每次redis的写入都会立即记入日志，性能较差但数据完整性比较好。
        appendfsync everysec:每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
        appendfsync no：redis不主动同步，把同步文件交给操作系统，有操作系统决定是否同步

        rewrite压缩
        1、是什么：AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
        2、重写原理，如何实现重写
        AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename)，redis4.0版本后的重写，是指就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。意思就是说把复杂的指令简单化，省略中间操作，只记录最后的状态。
        触发机制，何时重写：
        Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
        重写过程跟RDB也是类似的，创建一个fork用临时文件覆盖之前的旧文件 

        优势：
        1、备份机制更稳健，丢失数据概率更低
        2、可读的日志文本，通过操作AOF稳健，可以处理误操作。
        劣势：
        1、比起RDB占用更多的磁盘空间
        2、恢复备份速度要慢
        3、每次读写都同步的话，有一定的性能压力
        4、存在个别bug,造成恢复不能

        总结：
        1、官方推荐两个都启用
        2、如果对数据不敏感，可以选单独用RDB
        3、不建议单独用AOF，因为可能会出现bug
        4、如果只是做纯内存缓存，可以都不用
        5、RDB持久化方式能够再指定的时间间隔对你的数据进行快照存储，AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。
        6、redis还能对aof文件进行后台重写，是的AOF文件的提价不至于过大
        7、只做缓存：如果你只希望你得数据再服务器运行的时候存在，你也可以不使用任何持久化方式
        8、同时开启两种持久化方式，在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为再通常情况下aof文件保存的数据集要比rdb文件保存的数据集要完整
        9、建议不要只开启aof，因为rdb更适合与备份数据库，快速重启，而且不会有aof可能潜在的bug,留着作为一个万一的手段。

        七、Redis主从复制
             
        1、是什么：主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slaver以读为主

        2、能干吗：读写分离，性能扩展，容灾快速恢复

        搭建：略

        1）一主二仆：从机不能写入只能读取，从机会同步所有数据，主机down掉原地待命，不会上位，从机down掉之后，再回来能跟上大部队，就是说数据也会同步。
              主从复制原理：当从连接上主服务器之后，从服务器向主服务器发送数据同步消息，告诉主服务器，要进行数据同步了，主服务器接到从服务器发送过来的同步消息之后，把主服务器数据进行持久化，放到rdb的文件中去，把rdb文件发送给从服务器，从服务器拿到rdb文件进行读取，每次主服务器进行写操作之后就会和从服务器进行数据同步，从服务器只有第一次会主动进行同步，后面都是主服务器主动同步的

        2）薪火相传：意思就是说一个主服务器中，有很多从服务器，在从服务器中继续选出组长，也就是说在从服务器中选出一个领导，当其他从服务器的主服务器，这样可以有效减轻master的写压力。
        3）反客为主：当一个主服务器宕机之后，后面的从服务器可以立刻升为主服务器，其后面的从服务器不做任何修改，需要手动更改，不太方便。

        4）哨兵模式：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转为主库
            搭建：略
             由于所有的写操作都是先在主服务器上操作，然后同步更新到从服务上，所以从主服务器同步到从服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，从机器的数量的增加也会使这个问题更加严重
                

                 优先级在redis.conf中默认：slave-priority 100，值越小优先级越高。
                  偏移量使只获得原主机数据最全的
                 每个redis实例启动后都会随机生成一个40的runid.

          
        八、redis集群

        1)无中心化集群：

         任何一台服务器都可以作为集群的入口，他们之间可以相互连通，订单的服务器可以访问商品服务器，商品服务器可以访问用户服务器。
        实际操作中一个redis服务占用一个linux服务器
        2）什么是集群：
                redis集群实现了对redis的水平扩容，即启动n个redsi节点，将整个数据库分布存储在这N个节点中，每个节点存储总数居的N分之一。也就是说将数据平均存储。
                redis集群通过分区来提供一定程度的可用性，即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。
        3）redis如何分配六个节点：
                一个集群至少要有三个节点，分配原则尽量保证每个主数据库运行在不同的ip地址，每个从库和主库不在一个ip地址上。实际中每台redis应该是在不同的linux服务器中，因为一台服务器挂了，所有的服务都会挂。
        4）什么是slots
               All 16384 slots covered:一个redis集群包含16384个插槽，数据库中的每个键都属于这16384个插槽中的其中一个。
                集群使用公式CRCI16(key)%16384来计算键key属于哪个槽，其中CRCI16(key)语句用于计算键key的CRCI16校验和

         什么是插槽：
                比如说我们执行一个set k1 v1；命令。具体的执行过程就是拿着k1做个计算，计算k1所在的插槽，假如说这个插槽是100，100在第一个主服务器的范围，那就在第一个服务器加入这个key和对应的值。插槽就是一个目的就是把我们的值平均的分摊到不同的集群中的主机中去。
                因为我们redis配置的是集群，所以不一定从哪个主机作为入口，当计算出来当前key属于哪个主机时，就会切换到对应的主机进行操作。
                如果某一段插槽的主从都挂掉了，而cluster-require-full-coverage为no,那么，该插槽数据全部都不能使用，也无法存储。如果为yes,那么整个集群都挂掉。

 

        八、Redis相关问题：

        1） 缓存穿透：应用服务器压力变大了、redis命中率降低、一直查询数据库

                解决方案：
                1、对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过5分钟
                 2、设置可访问白名单：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmaps里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
                 3、采用不用过滤器：是1970年布隆提出的，他实际上是一个很长的二进制向量和一系列随机映射函数，布隆过滤器可以用于检索一个元素是否在一个集合中，它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率，和删除困难
                 4、进行实时监控：当发现redis的命中率开始激素降低，需要排查访问对象和访问数据，和运维人员配合，可以设置黑名单限制服务。

        2）缓存击穿：数据库访问压力瞬时增加，可能是redis中某个key过期了，热门访问的key.。所以一瞬间压力过大。
        解决方案：
         1、预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
        2、实施调整：现场监控哪些数据热门，实际调整key的过期时长
        3、使用锁，就是在缓存失效的时候，判断拿出来的值为空，不是立即去取，

                

         3）缓存雪崩：数据库压力变大，服务器崩溃。在极少时间段，查询大量key的集中过期情况。
        解决方案：1、构建多级缓存架构：nginx缓存+redis缓存+其他缓存（ehcache等）
                           2、使用锁或队列：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，不适用高并发情况。记录混存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存。将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效时间。

        4）分布式锁
         随着业务的发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程，多进程并且分布在不同机器上，这将使原单机部署情况下的并发空值锁策略失效，单纯的java api并不能提供分布式锁的能力，为了解决这个问题，就需要一种跨JVM的互斥锁机制来控制共享资源的访问，这就是分布式锁要解决的问题

        分布式锁主流的实现方案：
        1、基于数据库实现分布式锁
        2、基于缓存（Redis等）
        3、基于Zookeeper
        每一种分布式锁解决方案都有各自的优缺点
        1、性能：redis最高
        2、可靠性：zookeeper最高