Designing Redis Storage and Scheduled Sync for Blog Likes Using Quartz

Table of Contents

1. Overall Idea

2. Development Design Redis storage structure Workflow Show whether each user has liked a post Scheduled sync to database Current development shortcomings

3. Current Development Shortcomings

1. Overall Idea

Because likes and favorites are high‑frequency operations, writing each event directly to the database would create heavy pressure. The solution is to use Redis to count likes/favorites and browse counts, then periodically batch‑write the aggregated data to the database, relieving the database load.

1. Design of Redis Storage Structure

The idea is to use a Redis hash where the key is blog_like . Each field in the hash is an article ID, and the value is a set containing the user IDs that have liked that article.

This structure allows a one‑to‑one mapping between an article and the set of users who liked it; the cardinality of the set gives the like count, and checking whether a specific userId exists in the set determines if that user has already liked the article.

2. Development

1. Workflow

1. Receive the like request from the front‑end.

2. Retrieve the set for the corresponding article from Redis; if the set exists, add the new userId to it, otherwise create a new set for that article.

3. After insertion, the set appears in Redis as a string representation.

2. Scheduled Sync to Database

1. Quartz is used to implement the scheduled task.

2. Maven dependency:

<dependency>
  <groupId>org.quartz-scheduler</groupId>
  <artifactId>quartz</artifactId>
  <version>2.2.1</version>
</dependency>

3. Create a job class extending QuartzJobBean and override executeInternal to write the cached likes from Redis to MySQL.

public class LikeTask extends QuartzJobBean {
    @Autowired
    BlogService blogService;

    @Autowired
    RedisMapper redisMapper;

    /**
     * Retrieve like data from Redis hash and persist to MySQL.
     */
    @Override
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
        // implementation goes here
    }
}

4. Configure Quartz with a job detail and trigger:

@Configuration
public class QuartzConfig {
    @Bean
    public JobDetail quartzDetail_1() {
        // withIdentity specifies the job ID
        return JobBuilder.newJob(LikeTask.class)
                .withIdentity("LIKE_TASK_IDENTITY")
                .storeDurably()
                .build();
    }

    @Bean
    public Trigger quartzTrigger_1() {
        SimpleScheduleBuilder scheduleBuilder = SimpleScheduleBuilder.simpleSchedule()
                .withIntervalInSeconds(20) // run every 20 seconds
                .repeatForever();
        return TriggerBuilder.newTrigger()
                .forJob(quartzDetail_1())
                .withIdentity("USER_TRENDS_TRIGGER")
                .withSchedule(scheduleBuilder)
                .build();
    }
}

5. The author notes that the Quartz usage is a straightforward copy‑and‑paste; the main focus is the idea of persisting the cached data to the database.

3. Show Whether Each User Has Liked a Post

Since each article's liked users are stored in a Redis set, the workflow is to retrieve the current user's ID, check its presence in the set, and set a boolean flag accordingly before returning the data to the front‑end.

1. Add a non‑persistent field in the entity class to hold the like flag:

// Used to determine if the user has liked this blog
@TableField(exist = false)
private boolean liked;

2. After fetching data from the database, extract the like set from Redis, check if the userId is present, and update the flag.

3. The front‑end uses this flag to decide whether to display the like icon as active, thereby indicating to the user whether they have already liked the article.

This also gives the front‑end a list of users who have liked the article, enabling additional features.

3. Current Development Shortcomings

Insufficient mastery of Java core data structures such as collections and map interfaces.

Missing exception handling in several places; only simple null checks are present.

Need deeper consideration of the order and synchronization between Redis and database persistence.

Potential incompleteness of the StringUtil utility class.

Thank you for reading, hope this helps :) Source: blog.csdn.net/m0_60394632/article/details/126606186