Um Dateninkonsistenzen zu reduzieren, ist der Mechanismus zur Aktualisierung des Caches und der Datenbank besonders wichtig. Als nächstes werde ich Sie durch die Fallstricke führen.
Bypass Cache
ist eine häufig verwendete Caching-Strategie. Cache aside
也就是旁路缓存
,是比较常用的缓存策略。
(1)读请求
(1)写请求
常见流程
首先更新数据库,然后从缓存中删除该数据。
看了写请求的图之后,有些同学可能要问了:为什么要删除缓存,直接更新不就行了?这里涉及到几个坑,我们一步一步踩下去。
Cache aside策略如果用错就会遇到深坑,下面我们来逐个踩。
踩坑一:先更新数据库,再更新缓存
如果同时有两个写请求
需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。
如上图的执行过程:
(1)写请求1
更新数据库,将 age 字段更新为18;
(2)写请求2
Schreibanforderung
muss Daten aktualisieren. Jede Schreibanforderung aktualisiert zuerst die Datenbank und dann den Cache. In gleichzeitigen Szenarien kann es zu Dateninkonsistenzen kommen. 🎜🎜🎜Aktualisieren Sie zuerst die Datenbank und dann den Cache.🎜🎜🎜Ausführung als oben gezeigt Prozess: 🎜🎜(1)Anfrage 2 schreiben
Aktualisieren Sie die Datenbank und aktualisieren Sie das Altersfeld auf 20;🎜
(3)写请求2
更新缓存,缓存 age 设置为20;
(4)写请求1
更新缓存,缓存 age 设置为18;
执行完预期结果是数据库 age 为20,缓存 age 为20,结果缓存 age为18,这就造成了缓存数据不是最新的,出现了脏数据。
踩坑二:先删缓存,再更新数据库
如果写请求
的处理流程是先删缓存再更新数据库
,在一个读请求
和一个写请求
并发场景下可能会出现数据不一致情况。
如上图的执行过程:
(1)写请求
删除缓存数据;
(2)读请求
查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中;
(3)写请求
Der Verarbeitungsablauf der Schreibanforderung
ist Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank
, in einem Read request
und ein Schreibanforderung
In gleichzeitigen Szenarien kann es zu Dateninkonsistenzen kommen. 🎜Write request
Cache-Daten löschen; 🎜🎜(2)Read request
Cache-Miss abfragen (Hit Miss) und dann die Datenbank abfragen , schreibe die zurückgegebenen Daten zurück in den Cache; 🎜🎜(3)Anfrage schreiben
zum Aktualisieren der Datenbank. 🎜Nach dem gesamten Vorgang habe ich festgestellt, dass 数据库
中age为20,缓存
中age为18,缓存和数据库数据不一致,缓存出现了脏数据。
踩坑三:先更新数据库,再删除缓存
在实际的系统中针对写请求
还是推荐先更新数据库再删除缓存
,但是在理论上还是存在问题,以下面这个例子说明。
如上图的执行过程:
(1)读请求
先查询缓存,缓存未击中,查询数据库返回数据;
(2)写请求
更新数据库,删除缓存;
(3)读请求
回写缓存;
整个流程操作下来发现数据库age为20
,缓存age为18
Schreibanfrage
oder empfohlenAktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache
, aber theoretisch gibt es immer noch Probleme, wie im folgenden Beispiel gezeigt. 🎜Read request
fragt zuerst den Cache ab. Wenn der Cache nicht erreicht wird, wird abgefragt Datenbank zur Rückgabe von Daten; 🎜🎜 (2)Datenbankalter ist 20
, Cache-Alter beträgt 18 code>, das heißt, die Datenbank und der Cache sind inkonsistent, was dazu führt, dass die von der Anwendung aus dem Cache gelesenen Daten alte Daten sind. 🎜🎜Aber wenn wir sorgfältig darüber nachdenken, ist die Wahrscheinlichkeit, dass das oben genannte Problem auftritt, tatsächlich sehr gering, da Datenbankaktualisierungsvorgänge normalerweise mehrere Größenordnungen mehr Zeit in Anspruch nehmen als Speichervorgänge. Der letzte Schritt im Bild oben ist das Zurückschreiben Cache (Alter 18 einstellen) sehr schnell. Dies geschieht normalerweise vor dem Aktualisieren der Datenbank. 🎜<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;text-align: justify;font-size: 15px;">Was tun, wenn dieses Extremszenario eintritt? Wir müssen uns eine Lösung überlegen: <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;word-break: break-all;color: rgb(0, 0, 153);“>Ablaufzeit der Cache-Dateneinstellung
. Normalerweise kann es im System vorkommen, dass eine kleine Datenmenge für kurze Zeit inkonsistent ist.
Read through
在 Cache Aside 更新模式中,应用代码需要维护两个数据源头:一个是缓存,一个是数据库。而在 Read-Through
策略下,应用程序无需管理缓存和数据库,只需要将数据库的同步委托给缓存提供程序 Cache Provider
即可。所有数据交互都是通过抽象缓存层
完成的。
如上图,应用程序只需要与Cache Provider
交互,不用关心是从缓存取还是数据库。
在进行大量读取时,Read-Through
可以减少数据源上的负载,也对缓存服务的故障具备一定的弹性。如果缓存服务挂了,则缓存提供程序仍然可以通过直接转到数据源来进行操作。
Read-Through 适用于多次请求相同数据的场景
Durchlesen
Im Cache Aside-Aktualisierungsmodus muss der Anwendungscode zwei beibehalten Es gibt zwei Datenquellen: eine ist der Cache und die andere ist die Datenbank. Und in Cache-Anbieter
. Alle Dateninteraktionen erfolgen über
Read-Through-Prozess 🎜Wie oben gezeigt, muss die Anwendung nur mit Cache Provider
Interaktion, unabhängig davon, ob sie aus dem Cache oder der Datenbank abgerufen wird. 🎜🎜Bei umfangreichen Lesevorgängen gilt:
In Cache-Aside ist die Anwendung dafür verantwortlich, Daten von der Datenquelle abzurufen und im Cache zu aktualisieren.
Bei Read-Through wird diese Logik normalerweise von einem unabhängigen Cache-Anbieter (Cache Provider) unterstützt.
Durchschreiben
Cache-Anbieter
ist für die Aktualisierung der zugrunde liegenden Datenquelle und des Caches verantwortlich. Write-Through
策略下,当发生数据更新(Write)时,缓存提供程序 Cache Provider
负责更新底层数据源和缓存。
缓存与数据源保持一致,并且写入时始终通过抽象缓存层
到达数据源。
Cache Provider
类似一个代理的作用。
Write behind
Write behind
在一些地方也被成为Write back
, 简单理解就是:应用程序更新数据时只更新缓存, Cache Provider
每隔一段时间将数据刷新到数据库中。说白了就是延迟写入
Der Cache stimmt mit der Datenquelle überein und Schreibvorgänge passieren immer -color: rgba(27, 31, 35, 0.05);font-family: „Operator Mono“, Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(0, 0, 153); ">Abstrakte Caching-Ebene
erreicht die Datenquelle. 🎜🎜
Write-Through-Prozess 🎜🎜🎜Hinterschreiben🎜🎜Write behind
wird an manchen Stellen auch Zurückschreiben
, ein einfaches Verständnis ist: Wenn die Anwendung Daten aktualisiert, aktualisiert sie nur den Cache, Cache Provider
aktualisiert in regelmäßigen Abständen Daten in der Datenbank. Um es ganz klar auszudrücken: Es istSchreiben hinter dem Prozess Wie im Bild oben gezeigt, schreibt der Cache-Anbieter beim Aktualisieren zweier Daten durch die Anwendung diese sofort in den Cache, nach einer gewissen Zeit werden sie jedoch stapelweise in die Datenbank geschrieben.
Diese Methode hat Vor- und Nachteile:
优点
是数据写入速度非常快,适用于频繁写的场景。
缺点
Zusammenfassend
- Nachdem ich so viel gelernt habe, glaube ich, dass jeder ein klares Verständnis der Cache-Update-Strategie hat. Abschließend noch eine kleine Zusammenfassung. Es gibt drei Hauptstrategien für die Cache-Aktualisierung:
-
Cache beiseite
-
Durchlesen/Schreiben
Nachschreiben
Cache beiseite aktualisiert normalerweise zuerst die Datenbank und löscht dann normalerweise den Cache legt außerdem eine Cache-Zeit für die Daten fest. Lesen/Schreiben wird im Allgemeinen von einem Cache-Anbieter für externe Lese- und Schreibvorgänge bereitgestellt, und die Anwendung muss nicht wissen, ob der Cache oder die Datenbank betrieben wird. 🎜🎜Write dahinter versteht einfach, dass es sich um einen verzögerten Schreibvorgang handelt. Der Cache-Anbieter führt von Zeit zu Zeit eine Stapeleingabe in die Datenbank durch. Der Vorteil besteht darin, dass die Anwendung sehr schnell schreibt. 🎜🎜Okay, das war's für heute. Hast du die Lektion gelernt? 🎜
Das obige ist der detaillierte Inhalt vonSollte in einem Szenario mit hoher Parallelität zuerst der Cache oder die Datenbank aktualisiert werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!