mybatis-plus 쿼리 결과가 일치하지 않도록하는 원인은 무엇입니까?

MyBatis-Plus 캐시로 인한 일관되지 않은 쿼리 결과 문제 분석

이 기사는 Mybatis-Plus의 이전 및 후속 검색 결과에서 불일치 문제를 분석합니다. 문제 현상 : 데이터베이스 필드의 last 값이 업데이트 된 후 첫 번째 쿼리는 새 값을 읽지 만 두 번째 쿼리는 이전 값을 읽은 다음 최신 값을 다시 읽습니다.

로그는 주요 정보를 표시합니다.

1. 첫 번째 쿼리 (17 : 49 : 09.423) : last 값은 22 인 다음 23으로 업데이트 된 다음 즉시 last = 23 으로 읽습니다.
2. 두 번째 쿼리 (17 : 50 : 00.010) : last 값은 비정상적으로 22로 돌아갑니다.
3. 세 번째 쿼리 (17 : 50 : 00.012) : last 값은 최신 값 1048을 올바르게 읽습니다.

이 현상은 mybatis-plus의 캐싱 메커니즘에 의해 발생할 수 있습니다. MyBatis-Plus는 기본적으로 레벨 1 캐시 (SQLSESSION 레벨) 및 레벨 2 캐시 (맵퍼 레벨)를 사용합니다.

보조 캐시를 사용하고 캐시 무효화 전략이 부적절한 경우, 두 번째 쿼리는 데이터를 업데이트 한 후 데이터베이스의 최신 데이터가 아닌 캐시에서 이전 데이터를 읽을 수 있습니다. 이것은 last 값이 여러 번 업데이트되고 1048에 도달하더라도 두 번째 쿼리 결과가 last = 22 이유를 설명합니다. 그 후 캐시가 무효 또는 지우고 최신 데이터는 세 번째 쿼리 후에 만 ​​읽습니다.

데이터베이스 트랜잭션 격리 수준은 또한 문제를 일으킬 수 있지만 로그는 두 쿼리 간격이 첫 번째 트랜잭션이 커밋되었음을 나타내 므로이 요인의 확률은 적습니다.

해결책:

mybatis-plus 캐시 구성을 확인하고 다음 시나리오를 고려하는 것이 좋습니다.

• 레벨 2 캐시 끄기 : 이것은 가장 직접적인 솔루션으로 캐시로 인한 데이터 불일치를 효과적으로 피할 수 있습니다.
• 캐시 실패 전략 조정 : 보조 캐시를 유지 해야하는 경우 캐시 타당성 시간 단축 또는보다 적절한 고장 전략을 사용하는 등 캐시 실패 전략을 조정해야합니다.
• 동시성 문제 확인 : 동시에 동일한 데이터를 업데이트하는 여러 스레드와 같은 코드의 데이터베이스에 동시에 액세스 할 수 있는지 문제 해결하십시오.

위의 메소드가 여전히 문제를 해결하지 못하면 데이터베이스 트랜잭션 격리 레벨 설정 및 코드의 기타 잠재적 문제를 추가로 확인해야합니다.

위 내용은 mybatis-plus 쿼리 결과가 일치하지 않도록하는 원인은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!