Scenario
Generally, when the existing system already has bottlenecks, the hot query business needs to be migrated to DCS first. Data changes are still within the database and are not transparent to the new business system.
Business Requirements
l Data is saved by other reliable storage devices, and DCS only saves hotspot data.
l Ensure DCS updates by setting cache expiration time.
l If the cached data does not exist, retrieve it again.
l Add data verification tool to refresh cache asynchronously.
Analysis
1. Create users, Redis data partitions, access partitions, and select hot storage templates (disk flushing policies and active-standby synchronization policies are different);
2. After setting up the environment, create a group (table) and verify that the group is available based on the development example;
3. To use cache APIs, see the development sample code;
4. Use the API to set the cache key timeout;
5. For cache usage and loading, see the cache construction for hot keys;
6. Use scheduled tasks to scan the data source to obtain updated incremental data, modify the cache, or update the cache at the business code for the data change event to be sent.
The issue to note: cache penetration.
Reliable Storage Solution
If the data configuration has high data consistency requirements or hotspot data changes very frequently, you can consider the reliable storage scenario and design a solution accordingly. However, this solution requires transparent modification of business data and all the data can be migrated to DCS. The design of the following part will become simple
Business Requirements:
l Data is saved in cache and is not allowed to be lost.
Analysis: Configuration data as a whole can be used as hotspot data and stored in a cache to simplify the system architecture solution.
l Establish a Redis data partition and select a persistent storage template (the disk flushing policy and the active-standby synchronization policy are different);
l To use cache APIs, see the development sample code.