동시성이 높은 시나리오에서는 캐시 또는 데이터베이스를 먼저 업데이트해야 합니까?

캐싱 메커니즘은 일반적으로 데이터베이스 부담을 줄이기 위해 도입됩니다. 일단 캐싱이 도입되면 캐시와 데이터베이스 데이터 간의 불일치가 발생하기 쉽습니다. 오래된 데이터.

데이터 불일치를 줄이기 위해서는 캐시와 데이터베이스를 업데이트하는 메커니즘이 특히 중요합니다. 다음으로 함정을 안내하겠습니다.

캐시 따로

캐시 따로 보관 즉, 캐시 우회 는 일반적으로 사용되는 캐싱 전략입니다. Cache aside也就是旁路缓存，是比较常用的缓存策略。

（1）读请求(1)읽기 요청공통 프로세스

🎜

캐시 따로 읽기 요청

애플리케이션은 먼저 캐시에 데이터가 있는지 확인합니다. 캐시에 도달하면 데이터가 직접 반환됩니다. 캐시에 누락되면 캐시가 데이터베이스에 침투하여 데이터를 쿼리합니다. 데이터베이스에서 가져온 다음 다시 캐시에 쓰고 마지막으로 데이터를 클라이언트에 반환합니다.

(2)쓰기 요청공통 프로세스写请求常见流程

Cache aside 写请求

首先更新数据库，然后从缓存中删除该数据。

看了写请求的图之后，有些同学可能要问了：为什么要删除缓存，直接更新不就行了？这里涉及到几个坑，我们一步一步踩下去。

Cache aside踩坑

Cache aside策略如果用错就会遇到深坑，下面我们来逐个踩。

踩坑一：先更新数据库，再更新缓存

如果同时有两个写请求需要更新数据，每个写请求都先更新数据库再更新缓存，在并发场景可能会出现数据不一致的情况。

先更新数据库，再更新缓存

如上图的执行过程：

（1）写请求1更新数据库，将 age 字段更新为18；

（2）写请求2

🎜캐시 따로 쓰기 요청🎜🎜🎜업데이트 먼저 데이터베이스를 삭제하고 캐시에서 데이터를 삭제합니다. 🎜🎜쓰기 요청 사진을 본 후 일부 학생들은 다음과 같이 질문할 수 있습니다. 왜 캐시를 삭제해야 하나요? 그냥 직접 업데이트하면 안 되나요? 여기에는 몇 가지 함정이 있습니다. 단계별로 살펴보겠습니다. 🎜

캐시 제외 트랩

🎜캐시 제외 전략을 잘못 사용하면 직면하게 됩니다. 구덩이, 하나씩 들어가 보자. 🎜🎜🎜 함정 1: 데이터베이스를 먼저 업데이트한 다음 캐시를 업데이트하세요🎜🎜쓰기 요청은 데이터를 업데이트해야 합니다. 각 쓰기 요청은 먼저 데이터베이스를 업데이트한 다음 캐시를 업데이트합니다. 동시 시나리오에서 데이터 불일치가 발생할 수 있습니다. 🎜🎜🎜먼저 데이터베이스를 업데이트한 다음 캐시를 업데이트하세요🎜🎜🎜다음과 같이 실행 위에 표시된 프로세스: 🎜🎜(1)쓰기 요청 1데이터베이스를 업데이트하고 연령 필드를 18로 업데이트합니다. 🎜🎜(2)<code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left : 2px; 배경색: rgba(27, 31, 35, 0.05); 글꼴 계열: " operator mono consolas monaco menlo monospace break-all rgb>쓰기 요청 2데이터베이스를 업데이트하고 연령 필드를 20으로 업데이트합니다.🎜

(3)쓰기 요청 2캐시 업데이트 , 캐시 수명은 20으로 설정됩니다. 写请求2更新缓存，缓存 age 设置为20；

（4）写请求1更新缓存，缓存 age 设置为18；

执行完预期结果是数据库 age 为20，缓存 age 为20，结果缓存 age为18，这就造成了缓存数据不是最新的，出现了脏数据。

踩坑二：先删缓存，再更新数据库

如果写请求的处理流程是先删缓存再更新数据库，在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。

先删缓存，再更新数据库

如上图的执行过程：

（1）写请求删除缓存数据；

（2）读请求查询缓存未击中(Hit Miss)，紧接着查询数据库，将返回的数据回写到缓存中；

（3）写请求

(4) Write Request 1은 캐시를 업데이트하고 캐시 수명은 18로 설정됩니다. 🎜🎜실행 후 예상 결과는 데이터베이스 수명이 20, 캐시 수명이 20, 결과 캐시 수명이 18입니다. 이로 인해 캐시 데이터가 최신이 아니며 더티 데이터가 나타납니다. 🎜🎜함정 2: 먼저 캐시를 삭제한 다음 데이터베이스를 업데이트하세요🎜🎜If쓰기 요청 처리 흐름은 캐시를 먼저 삭제한 다음 데이터베이스를 업데이트하세요. 읽기 요청 및 쓰기 요청 동시 시나리오에서 데이터 불일치가 발생할 수 있습니다. 🎜

캐시를 먼저 삭제한 다음 데이터베이스를 업데이트하세요

🎜위 그림과 같은 실행 프로세스:🎜🎜(1)쓰기 요청캐시된 데이터 삭제; 🎜🎜(2)읽기 요청 캐시 누락(Hit Miss) 쿼리, 그런 다음 데이터베이스 쿼리 , 반환된 데이터를 캐시에 다시 씁니다. 🎜🎜(3)쓰기 요청입니다. 🎜

전체 과정을 거친 후 데이터베이스의 수명는 20, <code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px; background-color: rgba(27, 31, 35, 0.05) ;font-family: " operator mono consolas monaco menlo monospace break-all rgb>캐시연령 18, 캐시 데이터베이스 데이터와 일치하지 않으며 더티 데이터가 캐시에 나타납니다. 数据库中age为20，缓存中age为18，缓存和数据库数据不一致，缓存出现了脏数据。

踩坑三：先更新数据库，再删除缓存

在实际的系统中针对写请求还是推荐先更新数据库再删除缓存，但是在理论上还是存在问题，以下面这个例子说明。

先更新数据库，再删除缓存

如上图的执行过程：

（1）读请求先查询缓存，缓存未击中，查询数据库返回数据；

（2）写请求更新数据库，删除缓存；

（3）读请求回写缓存；

整个流程操作下来发现数据库age为20，缓存age为18

함정 3: 데이터베이스를 먼저 업데이트한 후 캐시를 삭제하세요

실제 시스템에서는 쓰기 요청 또는 권장데이터베이스를 먼저 업데이트한 후 캐시를 삭제하지만 다음 예와 같이 이론상 여전히 문제가 있습니다. 🎜

먼저 데이터베이스를 업데이트한 후 캐시를 삭제하세요

🎜위 그림과 같은 실행 프로세스:🎜🎜(1)읽기 요청은 먼저 캐시를 쿼리하고, 캐시에 적중되지 않은 경우 쿼리합니다. 데이터를 반환하는 데이터베이스; 27, 31, 35, 0.05 );font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(0, 0, 153);">쓰기 요청데이터베이스 업데이트, 캐시 삭제 🎜🎜(3)읽기 요청 다시 쓰기 캐시; 🎜🎜전체 프로세스 후에 데이터베이스 기간은 20, 캐시 수명은 18입니다. 즉, 데이터베이스와 캐시가 일치하지 않아 애플리케이션이 캐시에서 읽은 데이터가 오래된 데이터가 됩니다. 🎜🎜하지만 잘 생각해 보면 위의 문제가 발생할 확률은 실제로 매우 낮습니다. 왜냐하면 데이터베이스 업데이트 작업은 일반적으로 메모리 작업보다 몇 배 더 많은 시간이 걸리기 때문입니다. 위 그림의 마지막 단계는 데이터를 다시 작성하는 것입니다. 캐시(18세 설정)는 일반적으로 데이터베이스를 업데이트하기 전에 수행됩니다. 🎜

이런 극단적인 상황이 발생한다면? 우리는 해결책을 생각해야 합니다: 캐시 데이터 설정 만료 시간 . 일반적으로 시스템에서는 소량의 데이터가 짧은 시간 동안 불일치할 수 있습니다. 缓存数据设置过期时间。通常在系统中是可以允许少量的数据短时间不一致的场景出现。

Read through

在 Cache Aside 更新模式中，应用代码需要维护两个数据源头：一个是缓存，一个是数据库。而在 Read-Through 策略下，应用程序无需管理缓存和数据库，只需要将数据库的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。

Read-Through流程

如上图，应用程序只需要与Cache Provider交互，不用关心是从缓存取还是数据库。

在进行大量读取时，Read-Through 可以减少数据源上的负载，也对缓存服务的故障具备一定的弹性。如果缓存服务挂了，则缓存提供程序仍然可以通过直接转到数据源来进行操作。

Read-Through 适用于多次请求相同数据的场景

읽기

캐시 제외 업데이트 모드에서 애플리케이션 코드는 두 가지를 유지해야 합니다. 두 가지 데이터 소스가 있습니다. 하나는 캐시이고 다른 하나는 데이터베이스입니다. 그리고 Read-Through 전략, 적용됨 프로그램은 캐시와 데이터베이스를 관리할 필요가 없으며 데이터베이스 동기화를 캐시 공급자에게 맡기기만 하면 됩니다.캐시 제공자. 모든 데이터 상호작용은 추상 캐시 레이어 완료됨 . 🎜

읽기 프로세스

🎜위에 표시된 것처럼 애플리케이션은 캐시 제공자상호 작용(캐시에서 가져오든 데이터베이스에서 가져오든 관계 없음). 🎜🎜읽기량이 많은 경우 읽기 데이터 소스의 로드를 줄일 수 있으며 캐시 서비스 오류에 대한 복원력도 뛰어납니다. 캐시 서비스가 중단되더라도 캐시 공급자는 데이터 원본으로 직접 이동하여 계속 작동할 수 있습니다. 🎜🎜Read-Through는 동일한 내용에 대한 여러 요청에 적합합니다. 데이터 시나리오 , 이는 캐시 배제 전략과 매우 유사하지만 둘 사이에는 여전히 몇 가지 차이점이 있으므로 다시 강조합니다. 🎜

• 캐시 배제에서는 애플리케이션이 데이터 소스에서 데이터를 가져와 캐시로 업데이트하는 역할을 담당합니다.
• 읽기에서 이 논리는 일반적으로 독립 캐시 공급자(캐시 공급자)에 의해 지원됩니다.

쓰기

쓰기 전략에 따라 데이터 업데이트(쓰기)가 발생하면 캐시 공급자 캐시 제공자는 기본 데이터 소스 및 캐시 업데이트를 담당합니다. Write-Through 策略下，当发生数据更新(Write)时，缓存提供程序 Cache Provider 负责更新底层数据源和缓存。

缓存与数据源保持一致，并且写入时始终通过抽象缓存层到达数据源。

Cache Provider类似一个代理的作用。

Write-Through流程

Write behind

Write behind在一些地方也被成为Write back， 简单理解就是：应用程序更新数据时只更新缓存， Cache Provider每隔一段时间将数据刷新到数据库中。说白了就是延迟写入

캐시는 데이터 소스와 일치하며 쓰기는 항상 pass -color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(0, 0, 153); ">추상 캐싱 레이어가 데이터 소스에 도달합니다. 🎜🎜캐시 공급자는 프록시처럼 작동합니다. 🎜

쓰기 프로세스

🎜🎜🎜뒤에 쓰기🎜🎜뒤에 쓰기는 다시 쓰기, 간단히 이해하면 애플리케이션이 데이터를 업데이트할 때 캐시만 업데이트합니다. 캐시 공급자는 정기적으로 데이터베이스에 데이터를 새로 고칩니다. 직설적으로 말하면 지연 쓰기 . 🎜

Write Behind process

위 그림과 같이 애플리케이션이 두 개의 데이터를 업데이트하면 Cache Provider는 이를 즉시 캐시에 쓰지만 일정 시간이 지나면 일괄적으로 데이터베이스에 쓰게 됩니다.

이 방법에는 장점과 단점이 있습니다.

• 장점은 데이터 쓰기 속도가 매우 빠르고 빈번한 쓰기 시나리오에 적합하다는 것입니다. 优点是数据写入速度非常快，适用于频繁写的场景。

• 缺点

단점은 캐싱입니다. 이는 데이터베이스와 강력하게 일치하지 않으므로 일관성 요구 사항이 높은 시스템에서는 주의해서 사용해야 합니다.

요약하자면

• 많은 것을 배운 후에는 모두가 캐시 업데이트 전략을 명확하게 이해했다고 믿습니다. 마지막으로 약간의 요약입니다.
  캐시 업데이트에는 세 가지 주요 전략이 있습니다.
• 캐시 따로
• 읽기/쓰기

뒤에 쓰기

캐시 따로는 일반적으로 데이터베이스를 먼저 업데이트한 다음 캐시를 삭제합니다. 또한 데이터에 대한 캐시 시간을 설정합니다.

읽기/쓰기는 일반적으로 외부 읽기 및 쓰기 작업을 제공하기 위해 캐시 공급자가 제공하며, 애플리케이션은 캐시가 작동 중인지 데이터베이스가 작동 중인지 알 필요가 없습니다. 🎜🎜Write Behind는 쓰기가 지연된다는 점을 단순히 이해합니다. 캐시 공급자는 가끔씩 데이터베이스를 일괄적으로 입력합니다. 장점은 응용 프로그램이 매우 빠르게 쓴다는 것입니다. 🎜🎜알겠습니다. 오늘은 여기까지입니다. 교훈을 얻었나요? 🎜

위 내용은 동시성이 높은 시나리오에서는 캐시 또는 데이터베이스를 먼저 업데이트해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!