[Redis] Advanced Redis

One, Redis.conf detailed explanation

  1. Basic configuration informationInsert picture description here
  2. INCLUDES (import configuration file)Insert picture description here
  3. NetWork (Network)
绑定的ip:		bind 127.0.0.1     

保护模式:		protected-mode yes  

绑定的端口号:	port 6379  
  1. General
后台运行,默认no,需要设为yes:			 daemonize no  

后台运行需要指定pid文件:    	 pidfile /var/run/redis_6379.pid

默认数据库个数: 				 databases 16

是否总是显示logo:			 always-show-logo yes

日志级别:
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)    测试开发阶段
# verbose (many rarely useful info, but not a mess like the debug level)   
# notice (moderately verbose, what you want in production probably)   重要通知,生产环境
# warning (only very important / critical messages are logged)  关键信息
loglevel notice  # 日志的文件位置名
  1. SNAPSHOTTING (snapshot)
    Endurance operation
    Insert picture description here
# 900s内,1个key进行了修改,我们进行持久化操作
save 900 1

# 300内,10个key进行了修改,我们进行持久化操作
save 300 10

# 60s内,10000个key进行了修改,我们进行持久化操作
save 60 10000

# 持久化出错,是否继续工作
stop-writes-on-bgsave-error yes

# 是否压缩rdb(持久化文件)文件
rdbcompression yes

#保存rdb文件,错误校验
rdbchecksum yes

# rdb持久化存储文件
dbfilename dump.rdb

# rdb文件保存目录
dir ./
  1. REPLICATION (master-slave replication)
    Insert picture description here
  2. SECURITY (security)
# 设置密码 默认没有密码
requirepass 1234
命令设置密码:
CONFIG SET requirepass 1234
命令获取密码:
CONFIG GET requirepass
密码登陆:
AUTH 1234 

Insert picture description here

  1. CLIENTS (restrictions)
# 最大客户端连接数
maxclients 10000

# 最大内存容量
maxmemory <bytes>

# 内存到达上线的处理策略
maxmemory-policy  noeviction
				1、volatile-lru:只对设置了过期时间的key进行LRU(默认值) 
				2、allkeys-lru : 删除lru算法的key   
				3、volatile-random:随机删除即将过期key   
				4、allkeys-random:随机删除   
				5、volatile-ttl : 删除即将过期的   
				6、noeviction : 永不过期,返回错误
  1. APPEND ONLY MODE (mode)
# 默认不开启aof模式,默认rdb模式,大多数情况是够用的
appendonly no

# 持久化文件名称
appendfilename "appendonly.aof"

# appendfsync always  # 修改一次执行一次
appendfsync everysec  # 每秒执行一次,sync可能会丢失
# appendfsync no 	  # 自己同步

Second, endurance

RDB

  • rbd storage file: dbfilename dump.rdbInsert picture description here
    If there is a .rdb file in this directory, the data in it will be automatically restored after startup
    127.0.0.1:6379> CONFIG GET dir

  • advantage:

    1. Suitable for large-scale data recovery
    2. Low requirements for data integrity
  • Disadvantages:

    1. A certain time interval is required. If redis is closed unexpectedly, the last modification cannot be saved
    2. Fork process will occupy memory control

AOF

Record all executed commands

  • Manually modified to: appendonly yes (default no) will be automatically created after restart
    Insert picture description here
  • advantage
    1. Every modification will be synchronized with good integrity
    2. Real-time synchronization
  • Disadvantage
    1. For data files, aof is greater than rdb, and the recovery speed is very slow

Three, publish and subscribe

  • subscription

SUBSCRIBE [channel]

  • release

PUBLISH [channel] [message]

  • Monitor published data in real time

Four, master-slave replication

  • One master two slave strategy
    1. Specify the host to follow: slaveof [host port number]
    2. View master-slave configuration: info replication
      Insert picture description here
  • Configure slave
  1. Execute
    cp redis.conf redis80.conf
    cp redis.conf redis81.conf in turn
  2. Modify the prot, log, pid, and rdb in the redis80.conf and redis81 files to the prot of the new host (if you need to set the machine in the configuration file, modify the replication, as shown below)
    Insert picture description here
  • Data replication principle After the
    slave starts successfully, it sends a sync command to the master.
    When the master receives the instruction, it transmits all the data files to the slave in the background for synchronization.
  1. Full copy: After the slave service receives the database file, it loads it into the memory.
  2. Incremental replication: The master executes a stored command and transmits it to slvae in turn to complete synchronization.

Five, cache penetration cache avalanche

  • Cache penetration: The data corresponding to the key does not exist in the data source. Every time a request for this key cannot be obtained from the cache, the request will go to the data source, which may overwhelm the data source. For example, using a non-existent user id to obtain user information, whether there is no cache or database, if hackers use this vulnerability to attack, it may overwhelm the database.
  • Cache breakdown: The data corresponding to the key exists but expires in redis. At this time, if a large number of concurrent requests come in, these requests will generally load data from the backend DB and reset it to the cache when the cache expires. This is a large concurrent request It may overwhelm the back-end DB instantly.
  • Cache avalanche: When the cache server restarts or a large number of caches fail in a certain period of time, it will also put a lot of pressure on the back-end system (such as DB) when it fails.

Guess you like

Origin blog.csdn.net/m0_46537958/article/details/108543355