Optimizing User Info Cache Expiration in Redis for High‑Traffic Systems

7.3.3 User Information Cache Expiration

In real‑world Redis usage we often cache frequently accessed resources to boost response speed and user experience, but limited server resources and cost prevent caching everything. For user information, the ideal approach is to load it from MySQL on the first request, store it in Redis, and serve subsequent requests directly from the cache, reducing database pressure. The key is to set a sensible expiration time based on user access patterns so the cache remains efficient without consuming excessive memory. For example, during a flash‑sale, frequent refreshes of a personal‑info page benefit from a well‑chosen TTL, lowering MySQL load and improving system stability.

Test Implementation

To evaluate how different expiration times affect MySQL and Redis performance under various access models, we modify the test case from section 2 by adjusting only the

test()

method. The full code resides in

org.funtester.performance.books.chapter07.section3.RedisExpireCase

:

@Override
public void test() {
    Integer userId = RandomTool.getRandomElement(userIds); // simulate real user behavior
    String key = redisPrefix + userId; // Redis key with FunTester prefix
    User user = null;
    try (Jedis jedis = jedisPool.getResource()) {
        String userInfo = jedis.get(key); // query Redis
        if (userInfo == null) {
            String querySql = String.format(selectFormat, userId);
            try (ResultSet resultSet = base.statement.executeQuery(querySql)) {
                if (resultSet.next()) {
                    user = new User(resultSet.getInt("id"), resultSet.getString("name"),
                                    resultSet.getInt("age"), resultSet.getString("address"));
                    String set = jedis.set(key, user.toString());
                    if (set.equals("OK")) {
                        // cache write success (statistics omitted)
                    }
                }
            } catch (SQLException e) {
                // database query failure (statistics omitted)
            }
        }
        user = User.init(userInfo); // initialize user object from Redis result
    }
}

The

RandomTool#getRandomElement

method randomly selects a user ID to mimic realistic access patterns, such as social‑media profile views or e‑commerce account checks during promotions. The test converts the retrieved data into a

User

object that matches server‑side business logic. Statistics like cache‑hit rate or query‑failure rate are omitted for simplicity.

Common Cache Expiration Scenarios and Test Plans

Cache expiration is a widely used optimization in distributed systems. Below are typical scenarios and corresponding testing focus:

User information frequent access : Users repeatedly request personal data (e.g., viewing a profile or placing orders). Cache the data after the first database load. Test points : Simulate high‑concurrency requests, vary TTLs (e.g., 5 min vs 30 min), and observe cache‑hit rate and database load.

Hot data rapid updates : In flash‑sale or live‑streaming contexts, inventory or viewer counts change rapidly. Use short TTLs to keep data fresh while preventing DB overload. Test points : Simulate high‑frequency reads/writes, test very short (1 s) vs long (1 h) TTLs for impact on consistency and performance.

Low‑frequency cold data : Historical orders or annual reports are accessed rarely but are expensive to query. Cache them with longer TTLs to reduce occasional DB spikes. Test points : Measure cache‑hit rate and memory usage with TTLs like 1 day or 1 week.

Session management in distributed systems : User sessions stored in Redis need expiration to clean up inactive sessions (e.g., 30 min timeout). Test points : Simulate login, activity, and logout flows; verify that expired sessions are removed and assess impact on user experience.