Article directory
1. Cache Architecture Design
2. Cache common text and images
- data consistency
- cache penetration
- Cache Avalanche
- Cache high availability
- cache hotspot
The analysis of these problems and the corresponding solutions are introduced one by one below.
2.1 Data Consistency
Because the cache is a copy of the persistent data, there will inevitably be data inconsistencies. A condition that results in dirty reads or data that cannot be read. Inconsistent data is generally caused by network instability or node failure
Scenarios and Solutions
- Scenario 1. Write the cache first, then write to the database
- Description: The cache write is successful, but the write to the database fails or is delayed accordingly, then the next time the cache is read (concurrent read), a dirty read will occur
- Solution: This way of writing the cache itself is wrong. It needs to be changed to write the persistent medium first, and then write to the cache.
- Scenario 2. Write the database first, then write the cache
- Description: The writing to the database is successful, but the writing to the cache fails, then the next time the cache is read, the data cannot be read
- Solution 1 (not recommended): Judging based on the response written to the cache, if the cache write fails, roll back the database operation; this method increases the complexity of the program and is not recommended
- Solution 2 (recommended): When the cache is used, if the read cache fails, read the database first, and then write back the cache
- Scenario 3. Cache Asynchronous Refresh
- Description: The database operation and the write cache operation are not in the same operation step. For example, in a distributed scenario, it is impossible to write the cache at the same time or when asynchronous refresh is required.
- Solution: Determine which data is suitable for such scenarios; at the same time, determine the inconsistency time of reasonable data and the refresh interval of user data according to empirical values
2.2 Cache penetration, cache breakdown, cache avalanche
For the scenarios and solutions of cache penetration, cache avalanche, and cache breakdown, please refer to my other article "Seckill System" 2.2 - The introduction under the use of cache , I will not go into too much detail here.
2.3 Cache High Availability
Whether the cache is highly available depends on the actual scenario. Not all businesses require high availability of the cache. The solution needs to be designed in combination with the specific business and specific circumstances. For example, whether the critical point affects the back-end database.
Main solution:
- Distributed: realize massive cache of data
- Replication: High Availability of Cached Data Nodes
2.4 Cache hotspots
For some particularly hot data, high concurrent access to the same cached data results in excessive pressure on the cache server.
Solution: Copy multiple cache copies, distribute requests to multiple cache servers, and reduce the pressure on a single cache server caused by cache hot spots
3. Related cases
Here we take Sina Weibo as a case for analysis
3.1 Technical challenges
3.2 Cache Architecture
Feed cache architecture diagram:
3.3 Architecture Features
Sina Weibo applies SSD in distributed cache scenarios, and extends the traditional Redis/MC + Mysql mode to Redis/MC + SSD Cache + Mysql mode.
SSD Cache is used as L2 cache, which first reduces the cost of MC/Redis. The problem of high capacity and small capacity also solves the database access pressure caused by penetrating DB. It is
mainly optimized and enhanced in different aspects such as data architecture, performance, storage cost, and service.
Through the above concepts and related case studies, we can make the following conclusions:
When designing a cache architecture, we need to pay attention to the following:
- High availability within the cluster
- Intra-cluster scalability
- Component high performance
- storage cost
- Servicing
- service configuration
- Service Governance
- service monitoring