Java 동시 프로그래밍을 위한 데이터베이스 및 캐시 데이터 일관성 체계는 무엇입니까?

1. 서문

분산 동시 시스템에서 데이터베이스 및 캐시 데이터 일관성은 어려운 기술적 어려움입니다. 완전한 산업용 분산 트랜잭션 솔루션이 있다고 가정하면 데이터베이스와 캐시 데이터의 일관성은 쉽게 해결될 것입니다. 실제로 분산 트랜잭션은 현재 미성숙합니다.

2. 다양한 목소리

데이터베이스 및 캐시 데이터 일관성 솔루션에는 다양한 목소리가 있습니다.

• 데이터베이스를 먼저 작업한 다음 캐시 또는 캐시를 먼저 수행한 다음 데이터베이스

• 캐시를 업데이트해야 하는지 삭제해야 하는지

1 작업 순서

동시 시스템에서 이중 쓰기 시나리오 데이터베이스와 캐시의 동시성을 추구하기 위해 데이터베이스와 캐시의 운영은 동시에 발생하지 않을 것입니다. 전자의 작업은 성공적이며 후자는 비동기 방식으로 수행됩니다.

성숙한 산업용 데이터 저장 솔루션인 관계형 데이터베이스는 완전한 트랜잭션 처리 메커니즘을 갖추고 있습니다. 일단 데이터가 디스크에 저장되면 하드웨어 오류에 관계없이 데이터가 손실되지 않는다고 말할 수 있습니다.

캐시라고 불리는 것은 메모리에 저장된 데이터일 뿐입니다. 서비스가 다시 시작되면 캐시된 데이터는 모두 손실됩니다. 캐싱이라고 하므로 캐싱된 데이터가 손실될 수 있으므로 항상 대비하시기 바랍니다. Redis에는 지속성 메커니즘이 있지만 100% 지속성을 보장할 수 있나요? Redis는 데이터를 디스크에 비동기적으로 유지합니다. 캐시는 캐시이고 데이터베이스는 서로 다릅니다. 캐시를 데이터베이스로 사용하는 것은 매우 위험합니다.

데이터 보안의 관점에서 볼 때, 데이터베이스가 먼저 작동되고, 사용자 요청에 응답하기 위해 캐시가 비동기적으로 작동됩니다.

2. 캐시를 다룰 때의 태도

캐시를 업데이트하든 삭제하든 게으른 스타일과 전체 스타일에 해당합니다. 스레드 안전 관행의 관점에서 보면 캐시 작업을 삭제하는 것은 상대적으로 어렵습니다. 캐시 삭제를 전제로 쿼리 성능이 만족된다면 캐시 삭제를 선호합니다.

캐시를 업데이트하면 쿼리 효율성이 향상될 수 있지만 스레드로 인한 동시 더티 데이터는 처리하기가 더 까다롭기 때문에 서문에는 MQ와 같은 다른 메시지 미들웨어가 도입되어 있으므로 꼭 필요한 경우가 아니면 권장하지 않습니다.

3. 스레드 동시성 분석

스레드 동시성으로 인해 발생하는 문제를 이해하는 열쇠는 먼저 운영 체제가 작업을 예약할 때 인터럽트가 발생하는 것을 이해하는 것입니다. 이것이 스레드 데이터 불일치의 근본 원인입니다. 4스레드 및 8스레드 CPU를 예로 들면 최대 8스레드를 동시에 처리할 수 있지만 운영 체제에서는 8스레드보다 훨씬 많은 스레드를 관리하므로 스레드는 겉으로는 병렬 방식으로 진행됩니다.

데이터 쿼리

1. 비동시 환경

비동시 환경에서는 먼저 캐시를 쿼리하고, 캐시된 데이터가 없으면 데이터베이스를 쿼리하고, 캐시를 업데이트하고 결과를 반환합니다.

public BuOrder getOrder(Long orderId) {
    String key = ORDER_KEY_PREFIX + orderId;
    BuOrder buOrder = RedisUtils.getObject(key, BuOrder.class);
    if (buOrder != null) {
        return buOrder;
    }
    BuOrder order = getById(orderId);
    RedisUtils.setObject(key, order, 5, TimeUnit.MINUTES);
    return order;
}

고동시성 환경에 심각한 결함이 있는 경우: 캐시가 실패하면 대량의 쿼리 요청이 쏟아져 순식간에 DB에 도달합니다. 적어도 데이터베이스 연결 리소스가 고갈됩니다. 클라이언트는 500 오류로 응답하고 최악의 경우 데이터베이스에 과도한 서비스 중단이 발생합니다.

2. 동시 환경

따라서 동시 환경에서는 위의 코드를 수정해야 하며 분산 잠금을 사용합니다. 대량의 요청이 들어오면 잠금을 획득한 스레드는 데이터베이스에 접근해 데이터를 쿼리할 수 있는 기회를 갖게 되고 나머지 스레드는 차단된다. 데이터가 쿼리되고 캐시가 업데이트되면 잠금이 해제됩니다. 대기 중인 스레드는 캐시를 다시 검사하여 데이터를 얻을 수 있음을 발견하고 캐시된 데이터에 직접 응답합니다.

여기서 분산 잠금이 언급되었으니 테이블 잠금을 사용해야 할까요, 아니면 행 잠금을 사용해야 할까요? 동시성을 높이기 위해 분산 행 잠금을 사용합니다. 잠금을 얻기 위해 대기 중인 스레드가 신속하게 결과를 반환할 수 있도록 보장하는 보조 검사 메커니즘

@Override
public BuOrder getOrder(Long orderId) {
    /* 如果缓存不存在，则添加分布式锁更新缓存 */
    String key = ORDER_KEY_PREFIX + orderId;
    BuOrder order = RedisUtils.getObject(key, BuOrder.class);
    if (order != null) {
        return order;
    }
    String orderLock = ORDER_LOCK + orderId;
    RLock lock = redissonClient.getLock(orderLock);
    if (lock.tryLock()) {
        order = RedisUtils.getObject(key, BuOrder.class);
        if (order != null) {
            LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
            return order;
        }
        BuOrder buOrder = getById(orderId);
        RedisUtils.setObject(key, buOrder, 5, TimeUnit.MINUTES);
        LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
    }
    return RedisUtils.getObject(key, BuOrder.class);
}

Update data

1. 비동시 환경에서는 다음을 수행합니다. 코드가 발생할 수 있습니다. 데이터 불일치 문제(데이터를 덮어씁니다). 데이터베이스 수준 낙관적 잠금을 사용하면 데이터 덮어쓰기 문제를 해결할 수 있지만 잘못된 업데이트 트래픽은 여전히 ​​데이터베이스로 흐릅니다.

public Boolean editOrder(BuOrder order) {
    /* 更新数据库 */
    updateById(order);
    /* 删除缓存 */
    RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
    return true;
}

2. 동시 환경

위 분석에서 데이터베이스 낙관적 잠금을 사용하면 동시 업데이트 시 데이터가 덮어쓰이는 문제를 해결할 수 있습니다. 그러나 동일한 레코드 행이 수정되면 버전 번호가 변경되고 이후 동시 발생이 발생합니다. 데이터베이스에 대한 요청은 잘못된 트래픽입니다. 데이터베이스 압력을 줄이는 기본 전략은 데이터베이스보다 먼저 유효하지 않은 트래픽을 차단하는 것입니다.

분산 잠금을 사용하면 동시 트래픽이 데이터베이스에 순서대로 액세스하도록 보장할 수 있습니다. 데이터베이스 수준에서 낙관적 잠금이 사용된 점을 고려하면 잠금을 획득한 두 번째 및 후속 스레드는 데이터베이스를 잘못된 트래픽으로 작동합니다.

스레드는 잠금을 획득할 때 시간 초과 종료 전략을 채택합니다. 잠금을 기다리는 스레드는 시간 초과되어 빠르게 종료되고 사용자 요청에 신속하게 응답하며 데이터 업데이트 작업을 다시 시도합니다.

public Boolean editOrder(BuOrder order) {
    String orderLock = ORDER_LOCK + order.getOrderId();
    RLock lock = redissonClient.getLock(orderLock);
    try {
        /* 超时未获取到锁，快速失败，用户端重试 */
        if (lock.tryLock(1, TimeUnit.SECONDS)) {
            /* 更新数据库 */
            updateById(order);
            /* 删除缓存 */
            RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
            /* 释放锁 */
            LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
            return true;
        }
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return false;
}

환경에 따라 다름

위 코드는 잠금을 캡슐화하는 도구 클래스를 사용합니다.

<dependency>
  <groupId>xin.altitude.cms</groupId>
  <artifactId>ucode-cms-common</artifactId>
  <version>1.4.3.2</version>
</dependency>

잠금 상태에 따라 후속 작업을 수행합니다.

LockOptional4. 데이터베이스를 먼저 업데이트한 다음 캐시

데이터 일관성

1. 문제 설명

다음으로 데이터베이스를 먼저 업데이트한 다음 캐시를 삭제할 때 동시성 문제가 있는지 논의하겠습니다.

(1) 캐시가 방금 만료되었습니다

(2) A에게 데이터베이스를 쿼리하고 이전 값을 가져오도록 요청

(3) B에게 데이터베이스에 새 값을 쓰도록 요청
(4) B에게 캐시 삭제를 요청
( 5) 요청 A는 캐시에 기록된 이전 값을 찾습니다

위 동시성 문제의 핵심은 3단계와 4단계 후에 5단계가 발생한다는 것입니다. 이러한 상황이 발생할 수 있다는 것은 운영 체제 중단이라는 불확실한 요인을 통해 알 수 있습니다.

2. 솔루션

실제 상황에서 Redis에 데이터를 쓰는 것은 데이터베이스에 데이터를 쓰는 것보다 훨씬 짧습니다. 비록 발생 확률은 낮지만 여전히 발생합니다.

• (1) 캐시 만료 시간 늘리기

캐시 만료 시간을 늘리면 다음 동시 업데이트가 발생할 때까지 특정 시간 범위 내에 더티 데이터가 존재할 수 있어 더티 데이터가 나타날 수 있습니다. 더티 데이터는 주기적으로 존재합니다.

• (2) 업데이트와 쿼리는 행 잠금을 공유합니다

업데이트와 쿼리는 행 분산 잠금을 공유하므로 위의 문제는 더 이상 존재하지 않습니다. 읽기 요청이 잠금을 획득하면 쓰기 요청이 차단된 상태가 되어(시간 초과가 실패하고 빠르게 반환됨) 3단계 전에 5단계가 수행되도록 합니다.

• (3) 캐시 삭제 지연

RabbitMQ를 사용하여 캐시 삭제를 지연하여 5단계의 영향을 제거합니다. 비동기식 방법을 사용하면 성능에 거의 영향을 미치지 않습니다.

특별한 상황

데이터베이스에는 작업 성공을 보장하는 트랜잭션 메커니즘이 있습니다. 단일 Redis 명령은 원자성이지만 조합에는 원자성 특성이 없습니다. 특히 데이터베이스 작업이 성공한 후 애플리케이션이 비정상적으로 중단됩니다. , Redis 캐시가 삭제되지 않습니다. 이 문제는 Redis 서비스 네트워크 연결 시간이 초과될 때 발생합니다.

캐시 만료 시간이 설정되면 캐시가 만료되기 전에 더티 데이터가 항상 존재하게 됩니다. 만료 시간을 설정하지 않으면 다음 번 데이터 수정 시까지 더티 데이터가 존재하게 됩니다. (데이터베이스 데이터가 변경되었고 캐시가 아직 업데이트되지 않았습니다.)

해결 방법

데이터베이스를 운영하기 전에 RabbitMQ에 지연된 캐시 삭제 메시지를 작성한 후 데이터베이스 작업을 수행하고 캐시 삭제 작업을 수행합니다. 코드 수준 캐시가 성공적으로 삭제되었는지 여부에 관계없이 MQ는 보장된 작업으로 캐시를 삭제합니다.

위 내용은 Java 동시 프로그래밍을 위한 데이터베이스 및 캐시 데이터 일관성 체계는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!