本文章转自：乐字节
文章次要解说：Redis
获取更多Java相干材料能够关注公众号《乐字节》 发送：999

缓存Cache

缓存的概念

  • 缓存是存储在计算机上的一个原始数据复制集，以便于拜访。

  • Web我的项目常见的缓存场景

缓存击穿

  • 概念：

    • 对于一些设置了过期工夫的key，如果这些key可能会在某些工夫点被超高并发地拜访，是一种十分“热点”的数据

  • 起因：

    • 缓存在某个工夫点过期的时候，恰好在这个工夫点对这个Key有大量的并发申请过去，该key没有命中，大量申请穿透到数据库服务器

  • 解决方案：

    • 对于热点数据，慎重考虑过期工夫，确保热点期间key不会过期，甚至有些能够设置永不过期。
    • 应用互斥锁（比方Java的多线程锁机制），第一个线程拜访key的时候就锁住，等查询数据库返回后，把值插入到缓存后再开释锁

缓存雪崩

  • 概念：

    • 大量的key设置了雷同的过期工夫，导致在缓存在同一时刻全副生效，造成刹时DB申请量大、压力骤增，引起雪崩。
    • 缓存服务器宕机，也算做缓存雪崩。
  • 起因：大量缓存在同一时间生效；大量申请落到后端DB上；

  • 解决方案：

    • 不同的key，设置不同的过期工夫(随机值)，让缓存生效的工夫点尽量平均；

    • 应用高可用的分布式缓存集群，确保缓存的高可用性

      • 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1生效时，能够拜访A2。

缓存穿透

  • 概念：

    • 拜访一个肯定不存在的key，缓存不起作用，申请会穿透到DB，流量大时DB会挂掉
    • 起因：key被高并发拜访；该key没有命中，去后端DB获取；大量申请穿透到数据库服务器

    • 解决方案：

      • 布隆过滤器，

        • 应用一个足够大的bitmap，用于存储可能拜访的key，不存在的key间接被过滤，防止对底层数据存储系统造成压力；
      • 拜访key未在DB查问到值，也将空值写进缓存，但能够设置较短过期工夫

缓存一致性

  • 概念：

    • 当数据时效性要求很高时，须要保障缓存中的数据与数据库中的保持一致，须要保障缓存节点和正本中的数据也保持一致，不能呈现差别景象。（集群同步）

  • 起因：

    • 对同一个数据进行读写，在数据库层面并发的读写并不能保障实现程序；
    • 产生了写申请A，A的第一步淘汰了cache；A的第二步写数据库，收回批改申请；
    • 产生了读申请B，B的第一步读取cache，发现cache中是空的；B的第二步读取数据库，收回读取申请，
    • 如果A的第二步写数据还没实现，读出了一个脏数据放入cache；

  • 解决方案：

    • 个别会在数据产生更改的时，被动更新缓存中的数据或者移除对应的缓存。

Redis的介绍

官网

  • http://www.redis.cn/
  • https://redis.io/

Redis简介

　Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它能够用作数据库、缓存和消息中间件。 它反对多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 汇合（sets）， 有序汇合（sorted sets） 与范畴查问， bitmaps， hyperloglogs 和 天文空间（geospatial） 索引半径查问。 Redis 内置了复制（replication），LUA脚本（Lua scripting），LRU驱动事件（LRU eviction），事务（transactions）和不同级别的 磁盘长久化（persistence）， 并通过Redis哨兵（Sentinel） 和主动分区（Cluster）提供高可用性（high availability）

Redis性能

　上面是官网的bench-mark数据：

　测试实现了50个并发执行100000个申请。设置和获取的值是一个256字节字符串。

　后果:读的速度是110000次/s,写的速度是81000次/s

Redis历史简介

　2008年，意大利一家守业公司Merzia的创始人Salvatore Sanfilippo为了防止MySQL的低性能，亲自定做一个数据库，并于2009年开发实现，这个就是Redis。

　从2010年3月15日起，Redis的开发工作由VMware主持。

　 从2013年5月开始，Redis的开发由Pivotal资助。

阐明：Pivotal公司是由EMC和VMware联结成立的一家新公司。Pivotal心愿为新一代的利用提供一个原生的根底，建设在具备领导力的云和网络公司一直转型的IT个性之上。Pivotal的使命是推广这些翻新，提供给企业IT架构师和独立软件提供商。

反对语言

反对的数据类型

　string、hash、list、set、sorted set

Redis的装置(SingleNode)

装置依赖

yum -y install gcc-c++ autoconf automake

下载并上传

解压

tar zxvf redis-5.0.3.tar.gz

预编译和装置

切换到解压目录

cd redis-5.0.3/## 编译源代码make MALLOC=libc## 创立redis的装置目录mkdir -p /opt/lzj/redis## 如果须要指定装置门路，须要增加PREFIX参数**make PREFIX=/opt/lzj/redis/ install

Redis-cli:客户端

Redis-server:服务器端

前台启动

##redis服务默认端口号为6379./redis-server

后盾启动

  • 复制redis.conf至装置门路下

    • ## 创立一个配置文件目录mkdir -p /opt/lzj/redis/conf## 拷贝配置文件到目录中

  • 批改装置门路下的redis.conf，将daemonize批改为yes

  • 启动时，指定配置文件门路即可

    windows客户端拜访

    装置Redis客户端

    批改配置文件redis.conf

    正文掉bind 127.0.0.1能够使所有的ip拜访redis，若是想指定多个ip拜访，但并不是全副的ip拜访，能够bind设置

    敞开保护模式，批改为no

    增加拜访认证

    咱们能够批改默认数据库的数量 默认16,批改database 32则默认为32个数据库

    批改后kill -9 XXXX杀死redis过程，重启redis

    再次建设连贯 -> 胜利

    <img src="https://i0.hdslb.com/bfs/album/ac98020a966ed38c74b3d5e295efa5d46e59c7aa.png" alt="image-20200717111412879" style="zoom: 80%;" />

    Redis的命令

    Redis-cli连贯Redis

    -h:用于指定ip

    -p:用于指定端口

    -a:用于指定认证明码

    PING命令返回PONG

    指定database

    Redis-cli操作Redis

    操作Key

    exists 查问key是否存在

    keys 查问是否存在指定的key

    type 查问key的数据类型

    scan 扫描以后库中所有的key

    操作String

    set:增加一条String类型数据

    get:获取一条String类型数据

    mset:增加多条String类型数据

    mget:获取多条String类型数据

    incr:在value根底上加1

    decr：在value根底上减1

    操作hash

    hset:增加一条hash类型数据

    hget:获取一条hash类型数据

    hmset:增加多条hash类型数据

    hmget:获取多条hash类型数据

    hgetAll:获取指定所有hash类型数据

    hdel:删除指定hash类型数据(一条或多条)

    操作list

    lpush:左增加(头)list类型数据

    rpush:右增加(尾)类型数据

    lrange: 获取list类型数据start起始下标 end完结下标 蕴含关系

    llen:获取条数

    lrem:删除列表中几个指定list类型数据

    lrem key count value count > 0   从前向后删除count个valuecount <0    从后向前删除  绝对值（count） 个valuecount = 0   删除所有的value

    操作set

    sadd:增加set类型数据

    smembers:获取set类型数据

    scard:获取条数

    srem:删除数据

    操作sorted set

    sorted set是通过分数值来进行排序的，分数值越大，越靠后。

    zadd:增加sorted set类型数据

    zrange:获取sorted set类型数据

    zcard:获取条数

    zrem:删除数据

    zadd须要将Float或者Double类型分数值参数，搁置在值参数之前

    zscore|ZINCRBY:ZINCRBY key increment member 为有序集key的成员member的score值加上增量increment

    操作namespace

    操作生效工夫

    Redis 有四个不同的命令能够用于设置键的生存工夫(键能够存在多久)或过期工夫(键什么时候会被删除) :

    EXPlRE <key> <ttl> :用于将键key 的生存工夫设置为ttl 秒。

    PEXPIRE <key> <ttl>:用于将键key 的生存工夫设置为ttl` 毫秒。

    EXPIREAT <key> < timestamp>:用于将键key 的过期工夫设置为timestamp所指定的秒数工夫戳。

    PEXPIREAT <key> < timestamp > :用于将键key 的过期工夫设置为timestamp所指定的毫秒数工夫戳。

    TTL:获取的值为-1阐明此key没有设置有效期，当值为-2时证实过了有效期。

    办法一

    办法二

    办法三

    　第一个参数：key

    　第二个参数：value

    　第三个参数：

    NX是key不存在时才set，避免笼罩

    XX是key存在时才set，不创立新的key

    　第四个参数：EX是秒，PX是毫秒

    删除

    del:用于删除数据（通用，实用于所有数据类型）

    hdel:用于删除hash类型数据

    Redis的事务机制

    Redis事务是一个独自的隔离操作：事务中的所有命令都会序列化、按程序地执行。事务在执行的过程中，不会被其余客户端发送来的命令申请所打断。
    Redis事务的次要作用就是串联多个命令避免别的命令插队

  • Multi、Exec、discard

    • 输出Multi命令开始，输出的命令都会顺次进入命令队列中，但不会执行，
    • 输出Exec后，Redis会将之前的命令队列中的命令顺次执行。
    • 组队的过程中能够通过discard来放弃组队、

  • 事务的错误处理

    • 组队阶段某个命令呈现了报告谬误，执行时整个的所有队列会都会被勾销。
    • 执行阶段某个命令报出了谬误，则只有报错的命令不会被执行，而其余的命令都会执行，不会回滚。

  • 事务锁的机制

    • 乐观锁
    • 乐观锁
    • Redis就是利用这种check-and-set机制实现事务的

    数据的长久化

    redis是一个内存数据库，数据保留在内存中，尽管内存的数据读取速度快，然而很容易产生失落。Redis还为咱们提供了长久化的机制，别离是RDB(Redis DataBase)和AOF(Append Only File)

    RDB(Redis DataBase)

  • RDB 长久化能够在指定的工夫距离内生成数据集的工夫点快照，这是默认的长久化形式
  • 这种形式是就是将内存中数据以快照的形式写入到二进制文件中,默认的文件名为dump.rdb

  • RDB提供了三种触发机制：save、bgsave、自动化

    • save触发形式

      • 该命令会阻塞以后Redis服务器，执行save命令期间，Redis不能解决其余命令，直到RDB过程实现为止。

    • bgsave触发模式

      • 执行该命令时，Redis会在后盾异步进行快照操作，快照同时还能够响应客户端申请。
      • Redis过程执行fork操作创立子过程，RDB长久化过程由子过程负责，实现后主动完结。阻塞只产生在fork阶段，个别工夫很短。

    • 主动触发

      • 主动触发是由咱们的配置文件来实现的。
      • #配置文件#   after 900 sec (15 min) if at least 1 key changed#   after 300 sec (5 min) if at least 10 keys changed#   after 60 sec if at least 10000 keys changedsave 900 1save 300 10save 60 10000#配置文件的意义服务器在 900 秒之内，对数据库进行了至多 1 次批改服务器在 300 秒之内，对数据库进行了至多 10 次批改服务器在 60 秒之内，对数据库进行了至多 10000 次批改
      • stop-writes-on-bgsave-error
      • # However if you have setup your proper monitoring of the Redis server# and persistence, you may want to disable this feature so that Redis will# continue to work as usual even if there are problems with disk,# permissions, and so forth.# 默认值为yes。当启用了RDB且最初一次后盾保留数据失败，Redis是否进行接收数据。stop-writes-on-bgsave-error yes
      • rdbcompression
      • # Compress string objects using LZF when dump .rdb databases?# For default that's set to 'yes' as it's almost always a win.# If you want to save some CPU in the saving child set it to 'no' but# the dataset will likely be bigger if you have compressible values or keys.# 默认值是yes。对于存储到磁盘中的快照，能够设置是否进行压缩存储。rdbcompression yes
      • rdbchecksum
      • # RDB files created with checksum disabled have a checksum of zero that will# tell the loading code to skip the check.# 默认值是yes。在存储快照后，咱们还能够让redis应用CRC64算法来进行数据校验，然而这样做会减少大概10%的性能耗费rdbchecksum yes
      • dbfilename
      • # The filename where to dump the DB# 设置快照的文件名，默认是 dump.rdbdbfilename dump.rdb
      • dir
      • # The working directory.# The DB will be written inside this directory, with the filename specified# above using the 'dbfilename' configuration directive.# The Append Only File will also be created inside this directory.# Note that you must specify a directory here, not a file name.# 设置快照文件的寄存门路，这个配置项肯定是个目录，而不能是文件名dir ./

  • RDB的劣势和劣势

    • 劣势：

      • RDB文件紧凑，全量备份，非常适合用于进行备份和劫难复原。
      • 生成RDB文件的时候，redis主过程会fork()一个子过程来解决所有保留工作，主过程不须要进行任何磁盘IO操作
      • RDB 在复原大数据集时的速度比 AOF 的复原速度要快。

    • 劣势

      • 当进行快照长久化时，会开启一个子过程专门负责快照长久化，子过程会领有父过程的内存数据，
      • 父过程批改内存子过程不会反馈进去，
      • 所以在快照长久化期间批改的数据不会被保留，可能失落数据。

    AOF(Append Only File)

  • 全量备份总是耗时的，有时候咱们提供一种更加高效的形式AOF，工作机制很简略，redis会将每一个收到的写命令都通过write函数追加到文件中。艰深的了解就是日志记录。

  • rewrite策略

    • 重写日志，缩小日志文件的大小，redis提供了bgrewriteaof命令。
    • 将内存中的数据以命令的形式保留到临时文件中，同时会fork出一条新过程来将文件重写。
    • 将整个内存中的数据库内容用命令的形式重写了一个新的aof文件

  • AOF配置信息

    • ############################## APPEND ONLY MODE ################################ By default Redis asynchronously dumps the dataset on disk. This mode is# good enough in many applications, but an issue with the Redis process or# a power outage may result into a few minutes of writes lost (depending on# the configured save points).## The Append Only File is an alternative persistence mode that provides# much better durability. For instance using the default data fsync policy# (see later in the config file) Redis can lose just one second of writes in a# dramatic event like a server power outage, or a single write if something# wrong with the Redis process itself happens, but the operating system is# still running correctly.## AOF and RDB persistence can be enabled at the same time without problems.# If the AOF is enabled on startup Redis will load the AOF, that is the file# with the better durability guarantees.appendonly no# The name of the append only file (default: "appendonly.aof")appendfilename "appendonly.aof"
    • # Redis supports three different modes:# no: don't fsync, just let the OS flush the data when it wants. Faster.# always: fsync after every write to the append only log. Slow, Safest.# everysec: fsync only one time every second. Compromise.# appendfsync alwaysappendfsync everysec# appendfsync no
    • # 重写的机会-条件# Automatic rewrite of the append only file.# Redis is able to automatically rewrite the log file implicitly calling# BGREWRITEAOF when the AOF log size grows by the specified percentage.## This is how it works: Redis remembers the size of the AOF file after the# latest rewrite (if no rewrite has happened since the restart, the size of# the AOF at startup is used).## This base size is compared to the current size. If the current size is# bigger than the specified percentage, the rewrite is triggered. Also# you need to specify a minimal size for the AOF file to be rewritten, this# is useful to avoid rewriting the AOF file even if the percentage increase# is reached but it is still pretty small.## Specify a percentage of zero in order to disable the automatic AOF# rewrite feature.auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

  • AOF的触发策略

    • 每批改同步always

      • 同步长久化 每次产生数据变更会被立刻记录到磁盘 性能较差但数据完整性比拟好

    • 每秒同步everysec：

      • 异步操作，每秒记录 如果一秒内宕机，有数据失落

    • 不同no：

      • 从不同步

  • AOF的劣势和劣势

    • 劣势

      • AOF能够更好的爱护数据不失落，个别AOF会每隔1秒，通过一个后盾线程执行一次fsync操作，最多失落1秒钟的数据。
      • AOF日志文件没有任何磁盘寻址的开销，写入性能十分高，文件不容易破损。
      • AOF日志文件即便过大的时候，呈现后盾重写操作，也不会影响客户端的读写。
      • AOF日志文件的命令通过十分可读的形式进行记录，这个个性非常适合做灾难性的误删除的紧急复原。

    • 劣势

      • 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

      • AOF反对的写QPS会比RDB反对的写QPS低

        • QPS：Queries Per Second意思是“每秒查问率”
        • TPS：是TransactionsPerSecond的缩写，也就是事务数/秒

RDB和AOF的抉择

  • 成年人不做选择题

    • 如果同时应用AOF和RDB，那么启动时以AOF为复原数据的模板
    • 抉择的话，两者加一起才更好。
    • 因为两个长久化机制你明确了，剩下的就是看本人的需要了，需要不同抉择的也不肯定，然而通常都是联合应用

主从复制集群

Redis尽管读取写入的速度都特地快，然而也会产生读压力特地大的状况。为了分担读压力，Redis反对主从复制，Redis的主从构造能够采纳一主多从或者级联构造，Redis主从复制能够依据是否是全量分为全量同步和增量同步。

搭建主从服务器

  • 在Redis主配置文件文件夹中创立配置文件

  • 主节点配置文件

    • ## 导入一个通用配置文件include /opt/lzj/redis/conf/redis.conf## 以后主服务器端口port 7100## 设置主服务明码requirepass 123456## 以后主服务过程IDpidfile /var/run/redis_7100.pid## 以后主服务RDB文件名称dbfilename dump7100.rdb## 以后主服务文件寄存门路

  • 从节点须要配置

    • 间接在配置文件中增加（永恒）
    • ## 导入一个通用配置文件include /opt/lzj/redis/conf/redis.conf## 以后主服务器端口port 7200## 以后主服务过程IDpidfile /var/run/redis_7200.pid## 以后主服务RDB文件名称dbfilename dump7200.rdb## 以后主服务文件寄存门路dir /opt/lzj/redis/conf/ ## 同步master节点的网络信息（低版本必须应用slaveof,高版本举荐应用replicaof）replicaof 127.0.0.1 7100## 设置master节点的明码信息masterauth 123456## 从节点只做读的操作，保障主从数据的一致性
    - 在redis客户端命令行中输出（长期）- replicaof 127.0.0.1 7100- config set masterauth 123456- 完结从服务器的命运（完结）- slaveof no one

数据同步机制

Redis的主从构造能够采纳一主多从或者级联构造，Redis主从复制能够依据是否是全量分为全量同步和增量同步

主从刚刚连贯的时候，进行全量同步；全同步完结后，进行增量同步。

  • 全量同步

    • Redis全量复制个别产生在Slave初始化阶段，这时Slave须要将Master上的所有数据都复制一份
    • 从服务器连贯主服务器，发送SYNC命令；
    • 主服务器接管到SYNC命名后，开始执行BGSAVE命令生成RDB文件并应用缓冲区记录尔后执行的所有写命令；
    • 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间持续记录被执行的写命令；
    • 从服务器收到快照文件后抛弃所有旧数据，载入收到的快照；
    • 主服务器快照发送结束后开始向从服务器发送缓冲区中的写命令；
    • 从服务器实现对快照的载入，开始接管命令申请，并执行来自主服务器缓冲区的写命令；

  • 增量同步

    • Redis增量复制是指Slave初始化后开始失常工作时主服务器产生的写操作同步到从服务器的过程。
    • 增量复制的过程次要是主服务器每执行一个写命令就会向从服务器发送雷同的写命令，从服务器接管并执行收到的写命令。

  • 主从复制的异步个性

    • 主从复制对于主redis服务器来说是非阻塞的

      • 这意味着当从服务器在进行主从复制同步过程中，主redis依然能够解决外界的拜访申请；

    • 主从复制对于从redis服务器来说也是非阻塞的

      • 这意味着，即便从redis在进行主从复制过程中也能够承受外界的查问申请，只不过这时候从redis返回的是以前老的数据

服务器断线重连

  • Redis 2.8开始，如果遭逢连贯断开，从新连贯之后能够从中断处持续进行复制，而不用从新同步
  • 局部同步的实现依赖于在master服务器内存中给每个slave服务器保护了一份同步日志和同步标识
  • 每个slave服务器在跟master服务器进行同步时都会携带本人的同步标识和上次同步的最初地位
  • 当主从连贯断掉之后，slave服务器隔断工夫（默认1s）被动尝试和master服务器进行连贯
  • 如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中
  • 那么就从slave发送的偏移量开始持续上次的同步操作
  • 如果slave发送的偏移量曾经不再master的同步备份日志中，则必须进行一次全量更新

Redis的哨兵

Redis的主从复制模式下，一旦主节点因为故障不能提供服务，须要手动将从节点降职为主节点，同时还要告诉客户端更新主节点地址

Sentinel哨兵是redis官网提供的高可用计划，能够用它来监控多个Redis服务实例的运行状况

哨兵性能与作用

  • 监控(monitoring)：

    • Sentinel 会一直地查看你的主服务器和从服务器是否运作失常。

  • 揭示(Notifation)：

    • 当被监控的某个 Redis 服务器呈现问题时， Sentinel 能够通过 API 向管理员或者其余应用程序发送告诉。

  • 主动故障转移(Automatic failover)：

    • 当一个主服务器不能失常工作时， Sentinel 会开始一次主动故障迁徙操作， 它会将生效主服务器的其中一个从服务器降级为新的主服务器， 并让生效主服务器的其余从服务器改为复制新的主服务器； 当客户端试图连贯生效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群能够应用新主服务器代替生效服务器。

哨兵工作原理

  • 在redis sentinel中，一共有3个定时工作，通过这些工作，来发现新增节点和节点的状态。

    • 每10秒每个sentinel节点对master节点和slave节点执行info操作
    • 每2秒每个sentinel节点通过master节点的channel（sentinel:hello）替换信息
    • 每1秒每个sentintel节点对master节点和slave节点以及其余的sentinel节点执行ping操作

  • 主观下线（SDOWN）：以后sentintel节点认为某个redis节点不可用。

    • 如果一个实例（instance）间隔最初一次无效回复PING命令的工夫超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。
    • 如果一个主服务器被标记为主观下线，那么正在监督这个主服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器确实进入了主观下线状态。

  • 主观下线（ODOWN）肯定数量sentinel节点认为某个redis节点不可用。

    • 如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至多要达到配置文件指定的数量）在指定的工夫范畴内批准这一判断，那么这个主服务器被标记为主观下线。
    • 在个别状况下，每个Sentinel会以每10秒一次的频率，向它已知的所有主服务器和从服务器发送INFO命令。当一个主服务器被Sentinel标记为主观下线时，Sentinel向下线主服务器的所有从服务器发送INFO命令的频率，会从10秒一次改为每秒一次。
    • Sentinel和其余Sentinel协商主节点的状态，如果主节点处于SDOWN状态，则投票主动选出新的主节点。将残余的从节点指向新的主节点进行数据复制。
  • 当没有足够数量的Sentinel批准主服务器下线时，主服务器的主观下线状态就会被移除。当主服务器从新向Sentinel的PING命令返回无效回复时，主服务器的主观下线状态就会被移除。

故障转移流程

  • 哨兵外部领导者选举

    • 1). 每个做主观下线的sentinel节点向其余sentinel节点发送下面那条命令，要求将它设置为领导者。

      2). 收到命令的sentinel节点如果还没有批准过其余的sentinel发送的命令（还未投过票），那么就会批准，否则回绝。

      3). 如果该sentinel节点发现自己的票数曾经过半且达到了quorum的值，就会成为领导者。

      4). 如果这个过程呈现多个sentinel成为领导者，则会期待一段时间从新选举。

  • Master选举

    • 抉择slave-priority最高的slave节点
    • 抉择复制偏移量最大的节点
    • 选runId最小的（启动最早）

  • 状态更换

    • 选举出新的master节点，其余的节点变更为新的master节点的slave节点
    • 原有的master节点从新上线，成为新的master节点的slave节点

  • 告诉客户端

    • 当所有节点配置完结后，sentinel会告诉客户端节点变更信息。
    • 客户端连贯新的master节点

哨兵环境搭建

  • 搭建多台计算机的主从集群

    • Host端口节点分类Sentinel
      192.168.58.16120601master20600
      192.168.58.16220601slave20600
      192.168.58.16320601slave20600

    • Master节点

      • ## 导入一个通用配置文件include /opt/lzj/redis/conf/redis.conf## 以后主服务器IP和端口bind 0.0.0.0port 20601## 去掉平安模式protected-mode no## 设置主服务明码requirepass 123456## 以后主服务过程IDpidfile /var/run/redis_20601.pid## 以后主服务RDB文件名称dbfilename dump20601.rdb## 以后主服务文件寄存门路dir /opt/lzj/redis/conf/ ## 设置master节点的明码信息masterauth 123456## 设置时候后盾启动

    • Slave节点

      • ## 导入一个通用配置文件include /opt/lzj/redis/conf/redis.conf## 以后主服务器IP和端口bind 0.0.0.0port 20601## 去掉平安模式protected-mode no## 设置主服务明码requirepass 123456## 以后主服务过程IDpidfile /var/run/redis_20601.pid## 以后主服务RDB文件名称dbfilename dump20601.rdb## 以后主服务文件寄存门路dir /opt/lzj/redis/conf/ ## 同步master节点的网络信息（低版本必须应用slaveof,高版本举荐应用replicaof）replicaof 192.168.201.101 20601## 设置master节点的明码信息masterauth 123456## 从节点只做读的操作，保障主从数据的一致性slave-read-only yes ## 设置时候后盾启动
      - 三台计算机别离启动Redis- redis-server /opt/lzj/redis/conf/redis20601.conf

  • 一个持重的RedisSentinel集群，应该应用至多三个Sentinel实例，并且保障将这些实例放到不同的机器上，甚至不同的物理区域

    ## redis-sentinel /opt/lzj/redis/conf/sentinel.conf## 设置哨兵的接口port 20600## sentinel monitor 关键字## master20601 给主从服务器集群起一个名字(监控主服务器，从服务器的信息也就获取了)## 192.168.58.161 20601 主服务器的IP和端口## 2主服务器生效的统计数，超过2票就认为生效sentinel monitor master20601 192.168.201.101 20601 2## 设置主服务器明码sentinel auth-pass master20601 123456## 主服务器下线超过10秒就进行切换（默认30S）sentinel down-after-milliseconds master20601 10000## 故障转移超时工夫 sentinel failover-timeout master20601 180000## 故障转移时，容许有多少个slave同时对新的master进行同步,这个数字越小，实现failover所需的工夫就越长sentinel parallel-syncs master20601 1## 敞开平安校验protected-mode no

Redis的高可用

在Redis中，实现高可用的技术次要包含长久化、复制、哨兵和集群，上面简略阐明它们的作用，以及解决了什么样的问题：

  • 长久化：长久化是最简略的高可用办法。它的次要作用是数据备份，行将数据存储在硬盘，保证数据不会因过程退出而失落。

  • 复制：复制是高可用Redis的根底，哨兵和集群都是在复制根底上实现高可用的。

    • 复制次要实现了数据的多机备份以及对于读操作的负载平衡和简略的故障复原。
    • 缺点是故障复原无奈自动化、写操作无奈负载平衡、存储能力受到单机的限度。
  • 哨兵：在复制的根底上，哨兵实现了自动化的故障复原。缺点是写操作无奈负载平衡，存储能力受到单机的限度。
  • 集群：通过集群，Redis解决了写操作无奈负载平衡以及存储能力受到单机限度的问题，实现了较为欠缺的高可用计划。

集群设计思维

  • cluster能够说是sentinel和主从模式的结合体，通过cluster能够实现主从和master重选性能
  • 不同节点别离治理不同的key
  • 同一个Key的操作只让一个master去解决
  • 为了保障master节点的（单点故障和效率）问题，每个主节点至多筹备一个slave节点
  • 集群是一个能够在多个 Redis 节点之间进行数据共享的设施
  • 集群不反对那些须要同时解决多个键的 Redis 命令

一致性Hash

业务场景

  • 一个电商平台，须要应用Redis存储商品的图片资源，存储的格局为键值对，key值为图片名称，Value为该图片所在的文件服务器的门路，咱们须要依据文件名，查找到文件所在的文件服务器上的门路，咱们的图片数量大略在3000w左右，依照咱们的规定进行分库，规定就是随机调配的，咱们以每台服务器存500w的数量，部署12台缓存服务器，并且进行主从复制

  • 应用Hash的形式，每一张图片在进行分库的时候都能够定位到特定的服务器

  • 问题：

    • Redis服务器变动时，所有缓存的地位都会产生扭转

      • Redis缓存服务器6台减少到了8台
      • Redis缓存服务器6台的服务器集群中呈现故障时缩小到5台

算法原理

  • 取模

    • 一致性的Hash算法是对2的32方取模
    • 整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^32-1
    • 这个由2^32个点组成的圆环称为Hash环

  • 服务器

    • 将各个服务器应用Hash进行一个哈希，这样每台机器就能确定其在哈希环上的地位

  • 数据

    • 数据key应用雷同的函数Hash计算出哈希值，并确定此数据在环上的地位

  • 定位

    • 沿环顺时针“行走”，第一台遇到的服务器就是数据应该定位到的服务器

算法容错性

  • 当咱们增加服务器或者删除服务器
  • 它只影响解决节点的下一个节点

数据歪斜与虚构节点

  • 平均一致性hash的指标是如果服务器有N台，客户端的hash值有M个，
  • 那么每个服务器应该解决大略M/N个用户的。也就是每台服务器负载尽量平衡

Redis的Slot槽

  • Redis集群应用数据分片（sharding）而非一致性哈希（consistencyhashing）来实现：
  • 一个Redis集群蕴含16384个哈希槽（hashslot），数据库中的每个键都属于这16384个哈希槽的其中一个，集群应用公式CRC16(key)%16384来计算键key于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和
  • 将一个哈希槽从一个节点挪动到另一个节点不会造成节点阻塞，所以无论是增加新节点还是移除已存在节点，又或者扭转某个节点蕴含的哈希槽数量，都不会造成集群下线。
  • 对象保留到Redis之前先通过CRC16哈希到一个指定的Node上
  • 每个Node被平均分配了一个Slot段，对应着0-16383，Slot不能反复也不能缺失，否则会导致对象反复存储或无奈存储。

  • Node之间也相互监听，一旦有Node退出或者退出，会依照Slot为单位做数据的迁徙

    • Node1如果掉线了，0-5640这些Slot将会均匀摊派到Node2和Node3上

  • 优缺点

    • 长处：

      • 将Redis的写操作摊派到了多个节点上，进步写的并发能力，扩容简略。

    • 毛病：

      • 每个Node承当着相互监听、高并发数据写入、高并发数据读出，工作工作沉重

搭建集群环境

节点散布

  • HostMasterSlave
    192.168.58.1613060130602
    192.168.58.1623060130602
    192.168.58.1633060130602

配置文件

  • ## 导入默认配置文件include /opt/lzj/redis/conf/redis.conf## 以后主服务器Host和端口bind 0.0.0.0port 30601## 后盾模式运行daemonize no## 敞开保护模式protected-mode no## 设置主服务明码requirepass 123456## 设置从服务器明码masterauth 123456## 以后主服务过程IDpidfile /var/run/redis_30601.pid## 以后主服务RDB文件名称dbfilename dump30601.rdb## 以后主服务文件寄存门路dir /opt/lzj/redis/conf/## 开启aof长久化形式appendonly yes   ## 设置AOF文件名字appendfilename "appendonly30601.aof"##集群相干cluster-enabled yescluster-config-file nodes-30601.confcluster-node-timeout 5000

  • 别离启动6个节点

    • redis-server /opt/lzj/redis/conf/redis20601.conf

构建集群

  • # --cluster-replicas 1  示意主从配置比，1示意的是1:1，前三个是主，后三个是从# 若配置文件中设置的明码，则还须要加上-a passwodredis-cli --cluster create 192.168.201.101:30601 192.168.201.102:30601 192.168.201.103:30601 192.168.201.101:30602 192.168.201.102:30602 192.168.201.103:30602 --cluster-replicas 1 -a 123456

  • 查看集群信息

    • redis-cli -h 127.0.0.1 -p 20601 -a 123456# 查看集群信息cluster info    # 查看节点列表
    ![image-20200718171927687](https://i0.hdslb.com/bfs/album/8cf3f1aa3c988e550f6d935dbb84239d8507f20c.png)![image-20200718172140358](https://i0.hdslb.com/bfs/album/f967b0b933ac661a006c7d68cc4ea9557c7e4cc2.png)

拜访集群

  • redis-cli -h bd1602 -p 30602 -a 123456
  • redis-cli -c -h bd1602 -p 30602 -a 123456

Redis的常见场景

用户回复频率管制

  • 我的项目的社区性能里，不可避免的总是会遇到垃圾内容，一沉睡来你会发现首页忽然会被某些歹意的帖子和广告刷屏了，如果不采取适当的机制来管制就会导致用户体验受到重大的影响
  • 管制广告垃圾贴的策略很多，高级一点的能够通过AI，最简略的形式是通过关键词扫描，还有比拟罕用的一种形式是频率管制，限度单个用户内容的生产速度，不通等级的用户会有不同的频率控制参数
  • 应用Redis来实现频率管制（青铜1小时3贴 白银1小时5贴 黄金1小时8贴）

斗鱼日榜

24小时热销榜

  • 如果小说榜单只有10个地位，那么对于第11名小说太不偏心
  • 那么如果借助于10个地位显示前20名的小说？？？

统计每日沉闷用户

  • Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的长处是，在输出元素的数量或者体积十分十分大时，计算基数所需的空间总是固定 的、并且是很小的。
  • 在 Redis 外面，每个 HyperLogLog 键只须要破费 12 KB 内存，就能够计算靠近 2^64 个不同元素的基 数。这和计算基数时，元素越多消耗内存就越多的汇合造成鲜明对比。

摇一摇疾速获取间隔

  • GEO性能在Redis3.2版本提供，反对存储地理位置信息用来实现诸如左近地位、摇一摇这类依赖于地理位置信息的性能.geo的数据类型为zset.
  • https://blog.csdn.net/qq_3420...

感激大家的认同与反对，小编会继续转发《乐字节》优质文章