Redis series cache principle design
Basic idea of caching
Cache usage scenarios
DB cache, reduce server stress
Typically, data is stored in a database and applications operate directly on the database. When thousands of applications are accessed, the pressure on the database suddenly increases. If you need to reduce the pressure on the database server, you can use the following methods:
Database read/write separation
Database sub - database sub - table
Use caching and implement change coarsening for your read and write separation
The cache is used to store content or data that has already been accessed by the application. When the application accesses the cache again, the cache hits the returned data. If not, query the database and save to the cache.
Improve system response
Database data is stored in files, that is, hard drives. When a large number of instant accesses (high concurrency) occur, the MySQL server cannot respond due to frequent I/OS.
MySQL InnoDB has row locks,
The data is cached in Redis, that is, in memory. Memory naturally supports high concurrent access. Can handle a large number of requests instantly. QPS reached 100,000 read requests
Separation of the Session
Traditionally, Sessions are maintained and managed by Tomcat itself. In a clustered or distributed environment, different Tomcats manage their own sessions. Session replication can only be performed between Tomcat servers over the network and Io, which greatly affects system performance.
The Session information after successful login is stored in Redis, so that multiple servers (Tomcat) can share the Session information.
Distributed and Optimistic locks (Redis)
- A distributed lock
Generally speaking, locks are multi-threaded locks, which can cause problems when multiple processes (JVM) in a process are concurrent. Distributed locks can also be used to control timing. SexNX is implemented using Redis
- Optimistic locking
Synchronous lock, row lock and table lock in the database are pessimistic locks. Pessimistic locks have low performance and poor responsiveness. High performance and high response (kill by seconds) Optimistic locks Redis can be used to achieve optimistic locks watch + INCR
Classification of common caches
Page caching: The page itself stores some or all of the elements and saves them as files.
Html5 :Cookie, WebStorage(SessionStorage and LocalStorage), WebSql, indexDB, ApplicationCache, etc
When a client requests a resource from the server, it arrives in the browser cache first, and if the browser has a copy of the resource to request, it can fetch the resource directly from the browser cache rather than from the original server.
Browser caching can be divided into mandatory caching and negotiated caching.
Forced cache: Use the browser's cached data directly
Negotiated cache: server resources are not modified, using the browser cache (304); Instead, use server resources (200)
Native apps cache data in memory, files, or a local database (SQLite). Like image files.
Network side cache
The proxy responds to client requests by returning data resources in the cache for repeated requests.
- Web Proxy Cache
You can cache static resources from native servers, such as styles, images, and so on. Such as the Nginx reverse proxy
- Edge caching
A typical commercial service for edge caching is CDN.
The full name of CDN is Content Delivery Network.
CDN, through edge servers deployed in various places, enables users to obtain the content they need nearby, reduces network congestion, and improves user access response speed and hit ratio.
The key technologies of CDN mainly include content storage and distribution. Now general public cloud service providers all provide CDN services.
Server side cache
Server - side cache is the core of the whole cache architecture. Including database level cache, platform level cache and application level cache.
Database level cache
Databases are used to store and manage data.
MySQL uses the query caching mechanism at the Server layer. Cache the queried data.
K-v structure, Key: hash Value of the select statement, Value: query result
The Buffer-pool in the InnoDB storage engine is used to cache InnoDB indexes and data blocks
Platform level cache
Platform level caching refers to an application framework with caching features. For example, GuavaCache, EhCache, and OSCache. Deployed on application servers, also known as server local caches.
- Application level cache
Middleware with caching function :Redis, Memcached, EVCache, Tair, etc. It is stored in K-V format.
Leveraging clustering supports high availability, high performance, high concurrency, and high scalability.
Advantages and costs of caching
Improve user experience
A purely subjective feeling created by a user during the process of using a product.
The use of cache can improve the responsiveness of the system and greatly improve user experience.
Reduce server stress
Client cache and network cache reduce the pressure on application servers.
Server side caching takes the strain off the database server.
Improve system performance
Shorten system response time
Reduce network transmission time and application latency
Improve system throughput
Example Increase the number of concurrent users of the system
It improves the utilization rate of database resources
Disadvantages and Costs
Additional hardware expenses
Caching is a space-for-time technique in software systems
Additional disk space and memory space are required to store data
Setting up a cache server cluster requires additional servers
The use of cloud server caching services eliminates the need for additional servers
Ali Cloud, Baidu Cloud, provide caching services
High concurrency cache failure
Cache invalidation (cache penetration, cache avalanche, cache breakdown) occurs in high concurrency scenarios
Cause instant database visits to increase, even crash
Cache synchronizes with database data
Caches and databases cannot synchronize data all the time
Redis cannot synchronize data from master to slave
Cache concurrency contention
- Multiple Redis clients performing set operations on a key at the same time can cause concurrency problems due to execution order
Read/write mode of cache
Caches generally have three read and write modes
Cache Aside Pattern
Cache Aside Pattern is the most classic Cache + database read/write Pattern.
- If the cache does not exist, read the database, and then fetch the data and put it in the cache, and return the response.
- When updating, update the database first and then delete the cache.
Three cases of high concurrent dirty reads
- 1. Update the database first, then update the cache
Update the cache between update and commit. If commit fails, the database data is inconsistent with the cache data
- Delete the cache first, and then update the database
The cache is empty. The database data read to the cache is old data. After the COMMIT, the database data is new data
- Update the database first, then delete the cache (recommended)
Read/Write Through Pattern
The application only operates on the cache, which operates on the database.
Read-through (Read Through/direct Read mode): The application reads the cache, but the cache does not. The cache is returned to the database and written to the cache.
Write-through (Write Through mode/Write direct mode): The application program writes to the cache.
This mode needs to provide the database handler, which is more complicated to develop.
Write Behind Caching Pattern
The application only updates the cache.
The cache asynchronously updates the data in batches or after merging to the DB. The data cannot be synchronized all the time, and may even be lost.
The design idea of cache architecture
The data type
Different data types are used according to different data types
Sentinel + master slave
Cache data structure design
1, consistent with the database table
- Database tables and caches correspond one to one
- The cached fields are smaller than the database tables
- Cached data is frequently accessed
2, the database table is not consistent
- You need to store relationships, aggregations, calculations, and so on