Redis face-to-face 1

1. Why is Redis so fast

advantage:

1. Excellent read and write performance, Redis can read at a speed of 110,000 times/s, and write at a speed of 81,000 times/s;

2. Support data persistence, support AOF and RDB two persistence methods;

3. Support transactions, all operations of Redis are atomic, and Redis also supports atomic operations after merging several operations;

4. The data structure is rich, in addition to supporting the value of the String type, it also supports data structures such as hash, set, zset, and list;

5. Support master-slave replication, the master will automatically synchronize data to the slave, which can separate read and write.

shortcoming:

1. The database capacity is limited by physical memory and cannot be used for high-performance reading and writing of massive data. Therefore, the suitable scenarios for Redis are mainly limited to high-performance operations and calculations with small data volumes;

2. Redis does not have automatic fault tolerance and recovery functions. The downtime of the host and slave machines will cause the front-end part of the read and write requests to fail. You need to wait for the machine to restart or manually switch the front-end IP to recover;

3. The host machine is down, and some data cannot be synchronized to the slave machine in time before the downtime, and data inconsistency will be introduced after IP switching, which reduces the availability of the system;

4. It is difficult for Redis to support online expansion, and online expansion will become very complicated when the cluster capacity reaches the upper limit. In order to avoid this problem, the operation and maintenance personnel must ensure that there is enough space when the system goes online, which causes a great waste of resources.

2. Why use Redis/Why use cache

• high performance:

Suppose a user accesses some data in the database for the first time. This process will be slower because it is read from the hard disk. The data accessed by the user is stored in the cache, so that the next time the data is accessed, it can be directly obtained from the cache. The operation cache is to directly operate the memory, so the speed is quite fast. If the corresponding data in the database changes, just change the corresponding data in the cache synchronously!

• High concurrency:

The requests that the cache can handle directly are much larger than the ones that directly access the database, so we can consider transferring some data in the database to the cache, so that some of the user's requests will go directly to the cache without going through the database.

3. Redis is single-threaded, why is it still so fast?

Redis single-thread means that the network request module uses one thread, that is, one thread handles all network requests, and other modules still use multiple threads.

Therefore, Redis is completely based on memory operations. The CPU is not the bottleneck of Redis. The bottleneck of Redis is most likely the size of the machine memory or the network bandwidth. Since single-threading is easy to implement, and the CPU will not be called a bottleneck, it is logical to use a single-threaded solution:

1. Redis is completely based on memory. Most of the requests are pure memory operations, which are very fast and the data is stored in memory. Similar to HashMap, the advantage of HashMap is that the time complexity of search and operation is O(1);

2. The data structure is simple, and the operation on the data is also simple;

3. Single thread is used to avoid unnecessary context switching and competition conditions, there is no CPU switching caused by multi-threading, there is no need to consider various lock problems, there is no lock release operation, and there is no performance consumption caused by deadlock problems;

4. Use multiplexed IO model, non-blocking IO;

5. The underlying models used are different, the underlying implementation methods between them and the application protocol for communication with the client are different. Redis directly builds the VM mechanism by itself, because when the general system calls system functions, it will waste certain events to move and requests.

4. Cache and database consistency issues

In a distributed environment, it is very easy to have data consistency problems between the cache and the database. If the project requires strong consistency in the cache, then do not use the cache. We can only use appropriate strategies to reduce the probability of data inconsistency between the cache and the database, but cannot guarantee strong consistency between the two. Appropriate strategies include appropriate cache update strategies, updating the cache in a timely manner after updating the database, and adding a retry mechanism when the cache fails.

5. Redis Avalanche

For example: If the expiration time of all keys is 12 hours, refreshed at 12:00 noon, and there is a big promotion event at zero o'clock, a large number of users flood in. Assuming 6,000 requests per second, the cache can resist 5,000 requests per second. But all keys in the cache are invalid. At this time, the 6000 requests per second all fall on the database, and the database must not be able to handle it. The real situation may be that the DBA hangs up without responding. At this time, if there is no special solution to deal with it, the DBA is very anxious. Restart the database, but the database is immediately killed by new traffic. This is cache avalanche.

Solution: When storing data in Redis in batches, just add a random value to the expiration time of each Key, so as to ensure that the data will not fail in a large area at the same time. If Redis is deployed in a cluster, evenly distributing hotspot data in different Redis libraries can also avoid all failures. Or set the hotspot data to never expire, just update the cache if there is an update operation (for example, if the operation and maintenance update the homepage product, then just refresh the cache, no need to set the expiration time), the data on the e-commerce homepage can also use this operation .