启动and连接

启动 用的是配置文件启动

redis-server .../redis.conf

redis-cli -p 6379

  1. [root@LJT redis]# redis-server redis.conf
  2. [root@LJT redis]# redis-cli -p 6379
  3. 127.0.0.1:6379> exit
  4. [root@LJT redis]# pwd
  5. /www/server/redis
  7. 用的是宝塔，默认在www用户下

关机

SHUTDOWN

JRedis

  1. <dependency>
  2.       <groupId>redis.clients</groupId>
  3.       <artifactId>jedis</artifactId>
  4.       <version>3.2.0</version>
  5. </dependency>

宝塔

我用的aliyun的www 宝塔的 redis 位置

cd /www/server/redis

Redis.conf

  1. 单位
  2. 配置文件对大小写不敏感
  3. # 1k => 1000 bytes
  4. # 1kb => 1024 bytes
  5. # 1m => 1000000 bytes
  6. # 1mb => 1024*1024 bytes
  7. # 1g => 1000000000 bytes
  8. # 1gb => 1024*1024*1024 bytes
  10. …………
  11. 包含
  12. # include /path/to/local.conf
  13. # include /path/to/other.conf
  15. …………
  16. bind 127.0.0.1		绑定的ip
  18. protected-mode yes		保护模式
  20. port 6379		端口
  22. ################################# GENERAL #####################################
  24. daemonize yes		守护进程方式运行，默认no
  26. pidfile /www/server/redis/redis.pid		如果以后台方式运行，要指定pid
  28. # Specify the server verbosity level.
  29. # This can be one of:
  30. # debug (a lot of information, useful for development/testing)
  31. # verbose (many rarely useful info, but not a mess like the debug level)
  32. # notice (moderately verbose, what you want in production probably)默认，生产环境
  33. # warning (only very important / critical messages are logged)
  34. loglevel notice
  35. logfile "/www/server/redis/redis.log"		位置
  37. # dbid is a number between 0 and 'databases'-1
  38. databases 16		默认16个数据库
  40. 持久化，redis是内存数据库，断电即失
  41. save 900 1		如果900s内至少有一个key修改，进行持久化操作
  42. save 300 10
  43. save 60 10000
  45. stop-writes-on-bgsave-error yes		持久化出错，是否继续工作
  47. rdbcompression yes		是否压缩 rdb 文件，要消耗一定的cpu资源
  49. rdbchecksum yes		保存 rdb 文件 是否要校验
  51. dbfilename dump.rdb		rdb 文件保存目录
  53. ################################# REPLICATION #################################
  55. ################################# SECURITY #################################
  56. # requirepass foobared		设置密码
  58. ################################### CLIENTS ####################################
  59. # maxclients 10000		最大的连接数
  61. ############################## MEMORY MANAGEMENT################################
  62. # maxmemory <bytes>		最大的容量
  64. # maxmemory-policy noeviction		内存满了怎么处理
  66. ############################## APPEND ONLY MODE ###############################
  67. aof的配置
  69. appendonly no		默认不开启，默认rdb够用了
  71. appendfilename "appendonly.aof"			持久化的文件的名字
  73. # appendfsync always		每次都要  sync
  74. appendfsync everysec		每秒执行一次  sync  可能会丢失一秒的数据
  75. # appendfsync no			不执行，操作系统自己同步数据

RDB

Redis DataBase redis 的持久化

保存的是dump.rdb

  1. 持久化，redis是内存数据库，断电即失
  2. save 900 1		如果900s内至少有一个key修改，进行持久化操作
  3. save 300 10
  4. save 60 10000
  6. stop-writes-on-bgsave-error yes		持久化出错，是否继续工作
  8. rdbcompression yes		是否压缩 rdb 文件，要消耗一定的cpu资源
  10. rdbchecksum yes		保存 rdb 文件 是否要校验
  12. dbfilename dump.rdb		rdb 文件保存目录
  1. save规则满足了 就自动的执行了
  2. 执行flushall
  3. 退出redis

这个时候是会有 dump.rdb。

怎么恢复RDB文件？

只要放到redis的启动目录就可以了，redis会自动检查。

优点：

  1. 适合大规模的数据恢复
  2. 对数据的完整性要求不高

缺点：

  1. 需要一定的时间间隔
  2. fork的时候会占用一定的内存空间

AOF（Append Only File）

将我们的所有的操作记录下来。

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之, redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复。

Aof保存的是appendonly.aof文件

  1. ############################## APPEND ONLY MODE ###############################
  2. aof的配置
  4. appendonly no		默认不开启，默认rdb够用了，这里改为yes就是开启了，重启redis就生效了
  6. appendfilename "appendonly.aof"			持久化的文件的名字
  8. # appendfsync always		每次都要  sync
  9. appendfsync everysec		每秒执行一次  sync  可能会丢失一秒的数据
  10. # appendfsync no			不执行，操作系统自己同步数据

vim 这个 appendonly.aof 文件，就可以看到自己的所有的操作

以日志级别记录我们的所有的写操作。

redis -check-aof

这个是会检查你的 appendonly.aof 。

  1. redis -check-aof  --fix appendonly.aof

可以用

  1. ps -ef|grep redis

看自己的reids是否开启了。

按照默认的配置，如果aof的文件大于64m，太大了，redis 会 fork 一个新的进程将我们的文件进行重写。

aof 默认的就是文件的无限追加。

优点

  1. 每一次的修改都同步，文件的完整性会更好
  2. 每秒同步一个，可能会丢失最后一秒的数据
  3. 从不同步，效率最高

缺点

  1. 相对于数据文件来说，aof 远大于 rdb，会很慢，运行效率也更低

扩展：

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。

AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。

Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。

在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

发布和订阅

通信 队列 发送者 ======== 订阅者

redis也是一种消息通信模式

redis可以订阅任意数量的频道

操作例子：

  1. 127.0.0.1:6379> SUBSCRIBE zwtjava
  2. Reading messages... (press Ctrl-C to quit)
  3. 1) "subscribe"
  4. 2) "zwtjava"
  5. 3) (integer) 1
  6. 1) "message"
  7. 2) "zwtjava"
  8. 3) "hello zwt"
  9. 1) "message"
  10. 2) "zwtjava"
  11. 3) "hello redis"
  1. 127.0.0.1:6379> PUBLISH zwtjava "hello zwt"
  2. (integer) 1
  3. 127.0.0.1:6379> PUBLISH zwtjava "hello redis"
  4. (integer) 1
  5. 127.0.0.1:6379>

主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。

前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower）， 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）。

默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能由一个主节点。

作用

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。

  2. 故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式

  3. 负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。

  4. 高可用基石：主从复制还是哨兵和集群能够实施的基础。

为什么使用集群？

  1. 单台服务器难以负载大量的请求
  2. 单台服务器故障率高，系统崩坏概率大
  3. 单台服务器内存容量有限

查看当前库的信息：

  1. [root@LJT redis]# redis-server redis.conf
  2. [root@LJT redis]# redis-cli -p 6379
  3. 127.0.0.1:6379> info replication
  4. # Replication
  5. role:master
  6. connected_slaves:0
  7. master_failover_state:no-failover
  8. master_replid:cf011df27ae3fb7062185a64f1a1b6f660d61b10
  9. master_replid2:0000000000000000000000000000000000000000
  10. master_repl_offset:0
  11. second_repl_offset:-1
  12. repl_backlog_active:0
  13. repl_backlog_size:1048576
  14. repl_backlog_first_byte_offset:0
  15. repl_backlog_histlen:0

一主二从

配置伪集群:

复制配置文件

  1. [root@LJT redis]# cp redis.conf redis79.conf
  2. [root@LJT redis]# cp redis.conf redis80.conf
  3. [root@LJT redis]# cp redis.conf redis81.conf
  5. [root@LJT redis]# ll
  6. total 436
  7. -rw-rw-r--  1 redis redis 28118 Jun  1 22:03 00-RELEASENOTES
  8. -rw-rw-r--  1 redis redis    51 Jun  1 22:03 BUGS
  9. -rw-rw-r--  1 redis redis  5026 Jun  1 22:03 CONDUCT
  10. -rw-rw-r--  1 redis redis  3384 Jun  1 22:03 CONTRIBUTING
  11. -rw-rw-r--  1 redis redis  1487 Jun  1 22:03 COPYING
  12. drwxrwxr-x  7 redis redis  4096 Jul 12 10:40 deps
  13. -rw-r--r--  1 root  root    104 Jul 21 16:30 dump.rdb
  14. -rw-rw-r--  1 redis redis    11 Jun  1 22:03 INSTALL
  15. -rw-rw-r--  1 redis redis   151 Jun  1 22:03 Makefile
  16. -rw-rw-r--  1 redis redis  6888 Jun  1 22:03 MANIFESTO
  17. -rw-rw-r--  1 redis redis 21567 Jun  1 22:03 README.md
  19. -rw-r--r--  1 root  root  61859 Jul 21 16:32 redis79.conf
  20. -rw-r--r--  1 root  root  61859 Jul 21 16:32 redis80.conf
  21. -rw-r--r--  1 root  root  61859 Jul 21 16:32 redis81.conf
  22. -rw-rw-r--  1 redis redis 61859 Jul 21 10:50 redis.conf
  24. -rw-r--r--  1 redis redis 15057 Jul 21 16:30 redis.log
  25. -rwxrwxr-x  1 redis redis   275 Jun  1 22:03 runtest
  26. -rwxrwxr-x  1 redis redis   279 Jun  1 22:03 runtest-cluster
  27. -rwxrwxr-x  1 redis redis  1046 Jun  1 22:03 runtest-moduleapi
  28. -rwxrwxr-x  1 redis redis   281 Jun  1 22:03 runtest-sentinel
  29. -rw-rw-r--  1 redis redis 13768 Jun  1 22:03 sentinel.conf
  30. drwxrwxr-x  3 redis redis 12288 Jul 12 17:32 src
  31. -rw-r--r--  1 root  root      5 Jul 12 10:42 start.pl
  32. drwxrwxr-x 11 redis redis  4096 Jun  1 22:03 tests
  33. -rw-rw-r--  1 redis redis  3055 Jun  1 22:03 TLS.md
  34. drwxrwxr-x  9 redis redis  4096 Jun  1 22:03 utils
  35. -rw-r--r--  1 root  root      5 Jul 12 10:45 version_check.pl
  36. -rw-r--r--  1 root  root      6 Jul 12 10:42 version.pl
  37. [root@LJT redis]#

修改对应的配置文件

  1. -rw-r--r--  1 root  root  61859 Jul 21 16:32 redis80.conf
  3. port 6380
  5. daemonize yes		开启服务
  7. logfile "/www/server/redis/redis80.log"
  9. dbfilename dump80.rdb
  11. 大概就是这样几个地方

连接三台主机，都是master，默认都是master，我们一般只用配置从机就可以。

主（79）从（80，81）

  1. 127.0.0.1:6379> info replication
  2. # Replication
  3. role:master
  4. connected_slaves:2
  5. slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1
  6. slave1:ip=127.0.0.1,port=6381,state=online,offset=42,lag=1
  7. master_failover_state:no-failover
  8. master_replid:4c97ee0b19fef1a3f8e4f2f97ec15b20c01d61b1
  9. master_replid2:0000000000000000000000000000000000000000
  10. master_repl_offset:42
  11. second_repl_offset:-1
  12. repl_backlog_active:1
  13. repl_backlog_size:1048576
  14. repl_backlog_first_byte_offset:1
  15. repl_backlog_histlen:42
  16. 127.0.0.1:6379>

SLAVEOF 127.0.0.1 6379

通过这个命令配置主从关系

  1. 127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
  2. OK
  3. 127.0.0.1:6380> info replication
  4. # Replication
  5. role:slave
  6. master_host:127.0.0.1
  7. master_port:6379
  8. master_link_status:up
  9. master_last_io_seconds_ago:5
  10. master_sync_in_progress:0
  11. slave_repl_offset:0
  12. slave_priority:100
  13. slave_read_only:1
  14. replica_announced:1
  15. connected_slaves:0
  16. master_failover_state:no-failover
  17. master_replid:4c97ee0b19fef1a3f8e4f2f97ec15b20c01d61b1
  18. master_replid2:0000000000000000000000000000000000000000
  19. master_repl_offset:0
  20. second_repl_offset:-1
  21. repl_backlog_active:1
  22. repl_backlog_size:1048576
  23. repl_backlog_first_byte_offset:1
  24. repl_backlog_histlen:0
  25. 127.0.0.1:6380>

这是用的命令实现的，不是永久的，永久的需要再配置文件里面实现，

配置中实现这个即可。

  1. # replicaof <masterip> <masterport>
  3. # masterauth <master-password>

细节了解：

主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动被从机保存！

  1. 127.0.0.1:6379> set k1 v1
  2. OK
  3. 127.0.0.1:6379> get k1
  4. "v1"
  5. 127.0.0.1:6379> 
  7. 127.0.0.1:6380> get k1
  8. "v1"
  9. 127.0.0.1:6380>
  10. 127.0.0.1:6380> set k2 v2
  11. (error) READONLY You can't write against a read only replica.

测试：主机断开，从机依旧连接，但是没有写操作。

​ 主机回来，恢复。

​ 从机断了，主机的写操作ok，从机回来，不可以拿到掉线的值。

​

复制原理

通过测试管观察原理：

  1. Slave启动成功连接到master后会发送一个sync命令
  3. Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传送整个数据文件到slave ,并完成一次完全同步。
  5. 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
  7. 增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步
  8. 但是只要是重新连接master , 一次完全同步(全量复制)将被自动执行。

宕机后的手动配置主机

主节点断开，info replication

  1. 127.0.0.1:6380> SLAVEOF no one
  2. OK
  3. 127.0.0.1:6380> info replication
  4. # Replication
  5. role:master
  6. connected_slaves:0
  7. master_failover_state:no-failover
  8. master_replid:7fc61819c4dd84b2476cc55cf827ab854177bdbf
  9. master_replid2:4c97ee0b19fef1a3f8e4f2f97ec15b20c01d61b1
  10. master_repl_offset:3538
  11. second_repl_offset:3539
  12. repl_backlog_active:1
  13. repl_backlog_size:1048576
  14. repl_backlog_first_byte_offset:1
  15. repl_backlog_histlen:3538
  16. 127.0.0.1:6380>

如果这个时候主机ok了，回来了，需要再配置。

哨兵模式

自动版的“选老大“。

主从切换技术的方法是：

当主服务器宕机后,需要手动把一台从服务器切换为主服务器，这就需要人工干预,费事费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。

Redis从2.8开始正式提供 了Sentinel (哨兵)架构来解决这个问题。

谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。

其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。

各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。

当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票 ，投票的结果由一个哨兵发起，进行failover[故障转移]操作。

切换成功后,就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。

测试：

目前是一主二从。

配置哨兵文件

  1. sentinel monitor mymaster 127.0.0.1 6379 1

后面的这个数字1 ，代表主机挂了，slave投票看让谁接替成为主机,票数最多的就会成为主机!

启动哨兵

  1. [root@LJT redis]# redis-sentinel sentinel79.conf
  2. 20183:X 21 Jul 2021 22:41:55.113 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
  3. 20183:X 21 Jul 2021 22:41:55.113 # Redis version=6.2.4, bits=64, commit=00000000, modified=0, pid=20183, just started
  4. 20183:X 21 Jul 2021 22:41:55.113 # Configuration loaded
  5. 20183:X 21 Jul 2021 22:41:55.114 * monotonic clock: POSIX clock_gettime
  6.                 _._
  7.            _.-``__ ''-._
  8.       _.-``    `.  `_.  ''-._           Redis 6.2.4 (00000000/0) 64 bit
  9.   .-`` .-```.  ```\/    _.,_ ''-._
  10.  (    '      ,       .-`  | `,    )     Running in sentinel mode
  11.  |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
  12.  |    `-._   `._    /     _.-'    |     PID: 20183
  13.   `-._    `-._  `-./  _.-'    _.-'
  14.  |`-._`-._    `-.__.-'    _.-'_.-'|
  15.  |    `-._`-._        _.-'_.-'    |           https://redis.io
  16.   `-._    `-._`-.__.-'_.-'    _.-'
  17.  |`-._`-._    `-.__.-'    _.-'_.-'|
  18.  |    `-._`-._        _.-'_.-'    |
  19.   `-._    `-._`-.__.-'_.-'    _.-'
  20.       `-._    `-.__.-'    _.-'
  21.           `-._        _.-'
  22.               `-.__.-'                                               
  24. 20183:X 21 Jul 2021 22:41:55.120 # Sentinel ID is 236bea779a3b0737574dc5022c37d17d825b0ccb
  25. 20183:X 21 Jul 2021 22:41:55.120 # +monitor master mymaster 127.0.0.1 6379
  26. quorum 1		#有一票 
  28. #它的俩个从节点
  29. 20183:X 21 Jul 2021 22:41:55.120 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
  30. 20183:X 21 Jul 2021 22:41:55.125 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
  32. #关闭主节点后的日志		failover		selected
  34. 20183:X 21 Jul 2021 22:42:49.558 # +sdown master mymaster 127.0.0.1 6379
  35. 20183:X 21 Jul 2021 22:42:49.558 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
  36. 20183:X 21 Jul 2021 22:42:49.558 # +new-epoch 1
  38. 20183:X 21 Jul 2021 22:42:49.558 # +try-failover master mymaster 127.0.0.1 6379
  39. 20183:X 21 Jul 2021 22:42:49.565 # +vote-for-leader 236bea779a3b0737574dc5022c37d17d825b0ccb 1
  40. 20183:X 21 Jul 2021 22:42:49.565 # +elected-leader master mymaster 127.0.0.1 6379
  41. 20183:X 21 Jul 2021 22:42:49.565 # +failover-state-select-slave master mymaster 127.0.0.1 6379
  43. 20183:X 21 Jul 2021 22:42:49.637 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
  44. 20183:X 21 Jul 2021 22:42:49.637 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
  45. 20183:X 21 Jul 2021 22:42:49.720 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
  46. 20183:X 21 Jul 2021 22:42:50.053 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
  47. 20183:X 21 Jul 2021 22:42:50.053 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
  48. 20183:X 21 Jul 2021 22:42:50.113 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
  49. 20183:X 21 Jul 2021 22:42:51.102 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
  50. 20183:X 21 Jul 2021 22:42:51.102 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
  51. 20183:X 21 Jul 2021 22:42:51.157 # +failover-end master mymaster 127.0.0.1 6379
  52. 20183:X 21 Jul 2021 22:42:51.157 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
  53. 20183:X 21 Jul 2021 22:42:51.158 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
  54. 20183:X 21 Jul 2021 22:42:51.158 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  55. 20183:X 21 Jul 2021 22:43:21.239 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  57. #再测试，果然 master 是 6380
  59. 127.0.0.1:6380> info replication
  60. # Replication
  61. role:master
  62. connected_slaves:1
  63. slave0:ip=127.0.0.1,port=6381,state=online,offset=9076,lag=0
  64. master_failover_state:no-failover
  65. master_replid:6d563979b4c421fde3bc7a8996b88d2f02f060ee
  66. master_replid2:1645d3e978dea3fea45f2f5219077322693e61a3
  67. master_repl_offset:9076
  68. second_repl_offset:1585
  69. repl_backlog_active:1
  70. repl_backlog_size:1048576
  71. repl_backlog_first_byte_offset:1
  72. repl_backlog_histlen:9076
  73. 127.0.0.1:6380> 
  75. #6379再次上线
  77. 20183:X 21 Jul 2021 22:42:51.157 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
  78. 20183:X 21 Jul 2021 22:42:51.158 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
  79. 20183:X 21 Jul 2021 22:42:51.158 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  80. 20183:X 21 Jul 2021 22:43:21.239 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  81. 20183:X 21 Jul 2021 22:47:03.632 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  82. 20183:X 21 Jul 2021 22:47:13.578 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
  84. #发现现在没有用，还是6380统治天下

**

优点:**

1、哨兵集群,基于主从复制模式,所有的主从配置优点，它全有

2、主从可以切换,故障可以转移,系统的可用性就会更好

3、哨兵模式就是主从模式的升级,手动到自动,更加健壮!

缺点:

1、Redis 不好啊在线扩容的,集群容量- -旦到达上限,在线扩容就十分麻烦!

2、实现哨兵模式的配置其实是很麻烦的,里面有很多选择!

Redis 缓存 穿透 和 雪崩（面试高频，工作常用）

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。

但同时,它也带来了一些问题。

其中,最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。

如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。

缓存穿透

缓存穿透的概念很简单，用户想要查询一个数据发现redis内存数据库没有，

也就是缓存没有命中,于是向持久层数据库查询。

发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。

这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案

布隆过滤器

是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护后端数据源。

但是这种方法会存在两个问题:

1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键。

2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存雪崩

缓存雪崩，是指在某一一个时间段，缓存集中过期失效。

产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来-波抢购,这波商品时间比较集中的放入了缓存，假设缓存-个小时。那么到了凌晨一点钟的时候 ，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增，造成存储层也会挂掉的情况。

解决方案

redis高可用

这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis ，这样一台挂掉之 后其他的还可以继续工作，其实就是搭建的集群。(异地多活! )

限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。

数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。

在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。

缓存击穿（量太大了，缓存过期）

例如：微博热搜

解决方案

设置热点不过期

加互斥锁

Redis-初见的更多相关文章

  1. 初见Redis

    Redis是什么,有什么特点和优势 Redis是一个开源用C语言编写的,基于内存,可以持久化,高性能的key-value数据库,并提供多种语言的API. 它也被称为数据结构服务器,因为值(value) ...

  2. MongoDB 初见指南

    技术若只如初见,那么还会踩坑么? 在系统引入 MongoDB 也有几年了,一开始是因为 MySQL 中有单表记录增长太快(每天几千万条吧)容易拖慢 MySQL 的主从复制.而这类数据增长迅速的流水表, ...

  3. 4、redis 分布式锁

    1. 前言 关于分布式锁的实现,目前常用的方案有以下三类: 数据库乐观锁: 基于分布式缓存实现的锁服务,典型代表有 Redis 和基于 Redis 的 RedLock: 基于分布式一致性算法实现的锁服 ...

  4. 【需要重新维护】Redis笔记20170811视频

    很多内容都是抄的,个人记录 1.windows下初见 安装 进入目录 修改配置文件(暂时使用默认,未配置环境变量) 目录下:redis-server.exe启动服务 新建命令提示符,目录下,redis ...

  5. 使用redis构建可靠分布式锁

    关于分布式锁的概念,具体实现方式,直接参阅下面两个帖子,这里就不多介绍了. 分布式锁的多种实现方式 分布式锁总结 对于分布式锁的几种实现方式的优劣,这里再列举下 1. 数据库实现方式 优点:易理解 缺 ...

  6. Ignite性能测试以及对redis的对比

    测试方法 为了对Ignite做一个基本了解,做了一个性能测试,测试方法也比较简单主要是针对client模式,因为这种方法和使用redis的方式特别像.测试方法很简单主要是下面几点: 不作参数优化,默认 ...

  7. mac osx 安装redis扩展

    1 php -v查看php版本 2 brew search php|grep redis 搜索对应的redis   ps:如果没有brew 就根据http://brew.sh安装 3 brew ins ...

  8. Redis/HBase/Tair比较

    KV系统对比表 对比维度 Redis Redis Cluster Medis Hbase Tair 访问模式    支持Value大小 理论上不超过1GB(建议不超过1MB) 理论上可配置(默认配置1 ...

  9. Redis数据库

    Redis是k-v型数据库的典范,设计思想及数据结构实现都值得学习. 1.数据类型 value支持五种数据类型:1.字符串(strings)2.字符串列表(lists)3.字符串集合(sets)4.有 ...

  10. redis 学习笔记（2）

    redis-cluster 简介 redis-cluster是一个分布式.容错的redis实现,redis-cluster通过将各个单独的redis实例通过特定的协议连接到一起实现了分布式.集群化的目 ...

随机推荐

  1. Mysql数据库基础知识(全)

    前言:本博文为个人笔记,记录了Mysql的一些基本操作,一般掌握本博文就可以了解数据库.表.数据项的增删改查,希望对大家的学习有所帮助. 首先下载PHPSTUDY,将Mysql配置为系统变量. 具体操 ...

  2. ffuf 基础食用指南

    PS: 1. 下文出现的某些字典 有可能是因为摆出效果 我自己瞎搞得字典 2. 分享一些好的工具 3. 其实Wfuzz也很好用的 4. 很早之前就在语雀写过Wfuzz和ffuf的笔记 但是一直没有公开 ...

  3. 我所学的c语言

    c语言结构 #include <stdio.h> int main(){    /* 我的第一个 C 程序 */    printf("Hello, World! \n" ...

  4. Docker部署netcore web实践

    1. 新建一个netcore的项目 2. 我们到项目的生成输出目录下,创建一个Dockerfile文件 3. 编辑Dockerfile文件 备注:红线圈住的地方,就是你生成的netcore的程序名称 ...

  5. Mantis安装过程笔记

    安装平台:Windows Server 2003 R2 Enterprise x64 Edition 软件: EasyPHP-5.3.6.1 mantisbt-1.2.6 安装过程: 首先安装Easy ...

  6. 5、Python断言及常用断言函数总结

    Python断言 Python assert 语句,又称断言语句,可以看做是功能缩小版的 if 语句,它用于判断某个表达式的值,如果值为真,则程序可以继续往下执行:反之,Python 解释器会报 As ...

  7. DVWA靶场之Command Injection（命令行注入）通关

    Command Injection Low: <?php if( isset( $_POST[ 'Submit' ]  ) ) { // Get input $target = $_REQUES ...

  8. 【网络编程】TCPIP-8-套接字的多种选项

    目录 前言 8. 套接字的多种选项 8.1 API getsockopt(); & setsockopt(); 8.2 套接字选项 8.3 缓冲区相关可选项 8.4 端口复用 8.4.1 ti ...

  9. Windows下安装RocketMQ

    目录 前言 环境 具体操作 下载 环境变量配置 启动 关闭 生产.消费实例 RocketMQ Console 前言 项目中用到了延迟消息队列,记录下一win10下rocketmq的安装 环境 win1 ...

  10. window 右键菜单中添加在vs code 打开

    原文链接: window 右键菜单中添加在vs code 打开 window 右键菜单中添加在vs code 打开 吃码小妖:以前安装VS code可以的,后面不知道为什么不能右键在VS code中打 ...