Redis-Basic Introduction and Persistence
Introduction to Redis
Redis is an open source, ANSIC language, advanced key-value cache and NoSQL database product that supports persistent storage.
Redis uses an In-Memory dataset (DataSet).
Multiple data types are supported.
Runs on most POSIX systems such as Linux, *BSD, OS X, etc.
Author: Salvatore Sanfilippo
Redis Features
- 1) Transparency: Distributed systems are transparent to users. A distributed system behaves like a traditional single-processor time-sharing system in front of users, allowing users to use it without knowing the internal structure.
- 2) Scalability: The biggest feature of a distributed system is scalability. It can be expanded according to the increase in demand. The overall performance of the cluster can be linearly improved by horizontal expansion, or the server can be extended vertically by the performance of a single server. The performance of the cluster is improved.
- 3) Reliability: There is no single point of failure in distributed systems. Its basic idea is: if one server fails, other servers take over its work, which has the characteristics of continuous service.
- 4) High performance: High performance is the original intention of people designing distributed systems. If a transparent, flexible, and reliable distributed system is established, but it runs as slow as a snail, the system will fail.
Redis related website
- Official website: https://redis.io/
- Download site: http://download.redis.io/releases/
- Help site: http://redisdoc.com/
Redis software features
- 1) High-speed read and write
- 2) Rich data types
- 3) Support persistence
- 4) Various memory allocation and recycling strategies
- 5) Support things
- 6) Message queue, message subscription
- 7) Support high availability
- 8) Support distributed sharded cluster
Enterprise cache database solution comparison
Memcached:
1) Advantages: high-performance read and write, single data type, support for client-side distributed clusters, consistent hash multi-core structure, high multi-threaded read and write performance.
2) Disadvantages: No persistence, cache penetration may occur due to node failure, client-side implementation is required for distribution, data synchronization across computer rooms is difficult, and architecture expansion is complex
Redis:
1) Advantages: high-performance read and write, multi-data type support, data persistence, high-availability architecture, support for custom virtual memory, support for distributed sharded clusters, high single-threaded read and write performance
2) Disadvantages: Multi-threaded read and write is slower than Memcached
Tair:
1) Advantages: high-performance read and write, support for three storage engines (ddb, rdb, ldb), support for high availability, support for distributed sharded clusters, and support the cache of almost all Taobao businesses.
2) Disadvantage: In the case of a single machine, the read and write performance is slower than the other two products
in conclusion
- 1.Memcached: A multi-core cache service, which is more suitable for concurrent access by multiple users (application scenarios with fewer visits).
- 2.Redis: Single-core cache service, in the case of a single node, is more suitable for a small number of users, multiple access scenarios.
redis is generally in the enterprise, it is a single-machine multi-instance architecture
Configuring Redis in PHP
# Edit php.ini configuration vim /etc/php.ini session.save_handler = redis session.save_path = "tcp://172.16.1.51:6379" session.save_path = "tcp://172.16.1.51:6379?auth=123" # If there is a password in redis, use this method session.auto_start = 1 # Edit www.conf configuration vim /etc/php-fpm.d/www.conf ; php_value[session.save_handler] = files ; php_value[session.save_path] = /var/lib/php/session
Redis deployment
# 1. Download the software [root@db01 ~]# wget https://download.redis.io/releases/redis-6.2.6.tar.gz # 2. Unzip [root@db01 ~]# tar xf redis-6.2.6.tar.gz # 3. Enter the directory [root@db01 ~]# cd redis-6.2.6 # 4. Installation [root@db01 redis-stable]# make # 5. Move to the installation directory [root@db01 ~]# mv redis-6.2.6 /app/ # 6. Make soft links [root@db01 ~]# ln -s /app/redis-6.2.6 /app/redis # 7. Add environment variables [root@db01 ~]# echo 'export PATH="/app/redis/src:$PATH"' > /etc/profile.d/redis.sh # 8. Load environment variables [root@db01 ~]# source /etc/profile # 9.redis start service [root@db01 ~]# redis-server & # 10. Connect to redis [root@db01 ~]# redis-cli 127.0.0.1:6379> # 11. Create a redis configuration file directory [root@db01 ~]# mkdir /etc/redis/ -p # 12. Add configuration file [root@db01 ~]# vim /etc/redis/6379.conf daemonize yes #Daemon mode start port 6379 #port logfile /etc/redis/6379/redis.log #log file location # 13. Start redis after adding the configuration file [root@db01 ~]# mkdir /etc/redis/6379 [root@db01 ~]# redis-server /etc/redis/6379.conf # 14. Stop redis [root@db01 ~]# redis-cli shutdown # 15. Configure the pid file daemonize yes port 6379 logfile /etc/redis/redis.log pidfile /etc/redis/6379.pid # 16.systemd manages redis [root@db01 ~]# vim /usr/lib/systemd/system/redis.service [Unit] Description=Redis Server [Install] WantedBy=multi-user.target [Service] Type=forking ExecStart=/app/redis/src/redis-server /etc/redis/6379.conf ExecStop=/app/redis/src/redis-cli shutdown PrivateTmp=true # 17. Configuration files daemonize yes #Daemon mode, put into background execution port 6379 logfile /etc/redis/redis.log pidfile /etc/redis/6379.pid protected-mode no #Protected mode, whether to allow only local access bind 172.16.1.51 127.0.0.1 #Specify IP to listen on requirepass 123 #set password dir /etc/redis/6379 #Persistent data file storage location dbfilename dump.rdb #RDB persistent data file name # Redis connection method (with password) [root@db01 ~]# redis-cli -a 123 [root@db01 ~]# redis-cli 127.0.0.1:6379> AUTH 123 OK ## View all configurations 172.16.1.51:6379> CONFIG GET * ## View the specified configuration 172.16.1.51:6379> CONFIG GET bind 1) "bind" 2) "172.16.1.51 127.0.0.1" ## PHP connection redis configuration session.save_path = "tcp://172.16.1.51:6379" ;session.save_path = "tcp://172.16.1.51:6379?auth=123" #If redis has a password, use this method
Redis persistence
RDB
Introduction to RDB Persistence
Point-in-time snapshots of datasets can be generated at specified time intervals.
RDB persistence advantages:
- 1) RDB is a compact file representing Redis data at a point in time. RDB files are suitable for backup. For example, you might want to archive the last 24 hours of RDB files every hour and save nearly 30 days of RDB snapshots every day. This allows you to easily restore different versions of the dataset for disaster recovery.
- 2) RDB is very suitable for disaster recovery, as a compact single file, can be transferred to a remote data center.
- 3) RDB maximizes the performance of Redis, because the only thing that the Redis parent process needs to do when it is persistent is to start (fork) a child process, and the child process does all the remaining work. The parent process instance does not need to perform operations like disk IO.
- 4) RDB is faster than AOF when restarting instances that hold large datasets.
Disadvantages of RDB persistence
- 1) When you need to minimize data loss when Redis stops working (e.g. power outage), RDB is probably not so good. You can configure different save points to save RDB files (for example, at least 5 minutes and after 100 writes to the dataset, but you can have multiple save points). However, you usually create an RDB snapshot every 5 minutes or more, so once Redis stops working for any reason without shutting down properly, you have to be prepared for data loss in the last few minutes.
- 2) RDB needs to call fork() subprocess frequently to persist to disk. If the dataset is large, fork() is time-consuming, and as a result, when the dataset is very large and the CPU performance is not powerful enough, Redis will stop serving clients for a few milliseconds or even a second. AOF also requires fork(), but you can adjust how often to rewrite the log without trade-off durability.
Summary of advantages and disadvantages of RDB persistence
- Advantages: fast, suitable for backup, master-slave replication is also based on the RDB persistence function.
- Disadvantage: There will be data loss, causing the service to stop for a few seconds
How RDB snapshots work
1) By default, Redis saves a snapshot of the dataset to disk as a binary file named dump.rdb. You can set Redis to save the dataset when there are at least M changes to the dataset in N seconds, or you can manually call the SAVE or BGSAVE command.
2) In the above, we have done the corresponding configuration in the configuration file:
For example, this configuration would cause Redis to automatically dump the dataset to disk every 60 seconds when there are at least 1000 key changes:
save 60 1000
3) When Redis needs to save the dump.rdb file, the server does the following:
- Redis calls fork() and has both parent and child processes.
- The subprocess writes the dataset to a temporary RDB file. When the child process finishes writing to the new RDB file, Redis replaces the old RDB file with the new RDB file and deletes the old RDB file.
RDB persistence core configuration parameters
#Edit configuration file [root@db01 redis]# vim /etc/redis/6379/redis.conf dbfilename dump.rdb # persistent filename dir /etc/redis/6379 # Persistent file save location save 3600 1 # Within 3600 seconds (1 hour), if there is 1 change, save it save 300 100 # Save 100 changes within 300 seconds (5 minutes) save 60 10000 # 10000 changes in 60 seconds (1 minute), save # Save manually save # blocking persistence bgsave # non-blocking persistence
AOF
Introduction to AOF Persistence
AOF (append only file) only appends files, records all write commands performed by the server, and restores the dataset by re-executing these commands when the server starts. The commands in the AOF file are all saved in the Redis protocol format, and new commands will be appended to the end of the file.
AOF persistence advantages:
- 1) Using AOF Redis will be more durable: you can have many different fsync strategies: no fsync, fsync per second, fsync per request. With the default fsync per second policy, write performance is still good (fsync is done by a background thread, and the main thread continues to work hard on write requests), even if you only lose one second of write data.
- 2) The AOF log is an append file, so there is no need to locate it, and there is no corruption problem when the power is turned off. Even if for some reason the end of the file is a half-written command (disk full or whatever), the redis-check-aof tool can easily fix it.
- 3) When the AOF file becomes very large, Redis will automatically rewrite it in the background. Rewriting is absolutely safe because Redis continues appending to the old file, creating a brand new file with the minimal set of operations required to create the current dataset, and once the second file is created, Redis switches the two file and start appending to the new file.
- 4) The AOF file contains one operation after another, stored in a format that is easy to understand and parse. You can also easily export an AOF file. For example, even if you accidentally flush everything with the FLUSHALL command by mistake, you can still save your dataset if you don't perform a rewrite at this point, you just stop the server, delete the last command, and restart Redis.
Disadvantages of AOF persistence:
- 1) For the same dataset, AOF files are usually larger than equivalent RDB files.
- 2) AOF may be slower than RDB, depending on the exact fsync strategy. Usually fsync is set to once per second and the performance is still high, if fsync is turned off, it is as fast as RDB even under high load. However, even under heavy write load, RDB still provides good maximum latency guarantees.
- 3) In the past we have experienced some rare bug s for special commands (eg blocking commands like BRPOPLPUSH) which resulted in data loading not reverting to the way it was saved. These bugs are rare and we have also tested in a test suite that automatically randomly creates complex datasets and then loads them to check that everything works, however, these kinds of bugs are almost impossible to show up in RDB persistence. To make it a little clearer: Redis AOF is conceptually more robust by incrementally updating an already existing state, like MySQL or MongoDB, while RDB snapshots create everything from scratch again and again. However, 1) It should be noted that each time Redis rewrites AOF, it starts from the beginning with the real data in the current data set, compared to the AOF file that has been appended all the time (or one rewrite reads the old AOF file instead of reading the data in memory ) is more immune to bug s. 2) We have not received a single report of a user detecting a crash in the real world.
Summary of advantages and disadvantages of AOF persistence
- Advantages: It can ensure that data is not lost to the greatest extent
- Disadvantage: The amount of logging is relatively large
AOF persistence core configuration parameters
#Modify the configuration file [root@db01 redis]# vim /etc/redis/6379/redis.conf # Related parameters appendonly yes|no # Whether to enable the AOF log function appendfsync always # Every command is immediately synchronized to AOF appendfsync everysec # write every second appendfsync no # The writing work is handed over to the operating system, and the operating system determines the buffer size and writes it to the AOF uniformly # Perform rewrite manually BGREWRITEAOF