[Today’s Coding] Step3. Backend - database connection

‘Today’s Coding’ mailing service made with JAVA 17, Spring Boot 3.0.2, Gradle, MySQL, and Redis

Database connection method

---

Since the big goal of this project is to use both Redis and MySQL, we decided to use Redis Cache in a write-through method. Even if the two databases were updated in the project, the proportion was not large and the expected target audience was not large, so we predicted that there would be no problem in performance.

I wanted to create many parts that could be quickly accessed without going through RDB by importing the service list at once and using Redis Cache, and there were also parts that needed to be accessed in RDB instead of in cache, so the Write-Through method was suitable.

MySQL, Redis Connection Test

---

We conducted a MySQL and Redis connection test. I used the following code to make sure both were connected well, and I hope it helps people who have the same problem as me.

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-data-redis'
runtimeOnly 'com.mysql:mysql-connector-j'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.3.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.3.1'
testImplementation 'org.springframework.boot:spring-boot-starter-test'

MySQL Connection Test

package com.toco.trialService.databaseTest;
import org.junit.jupiter.api.*;
import java.sql.Connection;
import java.sql.DriverManager;
public class DatabaseConnectionTest {
private static final String URL = "jdbc:mysql://127.0.0.1:3306/world";
private static final String User = "root";
private static final String Password = "0000";  // 임의의 패스워드
@Test
public void rdbConnectionTest() {
try(Connection conn = DriverManager.getConnection(URL, User, Password)) {
System.out.println(conn);
// com.mysql.cj.jdbc.ConnectionImpl@3697186
}catch(Exception e){
System.out.println(e.getMessage());
}
}
}

Redis Connection Test

package com.toco.trialService.databaseTest;
import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.sync.RedisCommands;
import org.junit.jupiter.api.*;
import static org.springframework.test.util.AssertionErrors.assertTrue;
public class RedisConnectionTest {
private RedisClient redisClient;
private StatefulRedisConnection connection;
private RedisCommands redisCommands;
@BeforeEach
public void beforeConnectDatabase(){
redisClient = RedisClient.create("redis://localhost:6379");
connection = redisClient.connect();
redisCommands = connection.sync();
}
@AfterEach
public void afterConnectDatabase(){
connection.close();
redisClient.shutdown();
}
@Test
public void inMemoryConnectionTest() {
assertTrue("Redis connection test failed", redisCommands.ping().equals("PONG"));
}
}

※

Lettuce version 3.0.5 no longer uses the DefaultClientResources class, but uses RedisClient by creating a new Redis client object. When creating, use create([url]) as in the code above, and when finished using shutdown(); Let's take care of it.

Considerations based on Redis Caching strategy

---

Is it right to use this as a caching strategy?

I think I had to worry about this the most while creating the project.

I had a lot of concerns about how to use Redis Caching. The method will vary depending on the business and service, but the project I want to create now needs to provide concurrency, and I wanted to prevent data loss as much as possible, so the method I chose was Write-Through.

However, there is also a Write-Around method, and in this case, the possibility of loss must be considered when processing large volumes of services. Since the RDBMS data may not be up to date, a method of regularly pushing the RDBMS data into in-memory is used.

Depending on the caching strategy, having unnecessary cache data can lead to memory waste and thus reduce performance.

Therefore, only key data (that does not generate many UPDATEs) required for proper TTL processing and performance improvement were used after @RedisCache processing. In this project, it was applied only to items that are not expected to have many updates, such as Program, ProgramDetail, and Categories.