|
@@ -1347,3 +1347,21 @@ Write-through is a slow overall operation due to the write operation, but subseq
|
|
|
|
|
|
* When a new node is created due to failure or scaling, the new node will not cache entries until the entry is updated in the database. Cache-aside in conjunction with write through can mitigate this issue.
|
|
* When a new node is created due to failure or scaling, the new node will not cache entries until the entry is updated in the database. Cache-aside in conjunction with write through can mitigate this issue.
|
|
* Most data written might never read, which can be minimized with a TTL.
|
|
* Most data written might never read, which can be minimized with a TTL.
|
|
|
|
+
|
|
|
|
+#### Write-behind (write-back)
|
|
|
|
+
|
|
|
|
+<p align="center">
|
|
|
|
+ <img src="http://i.imgur.com/rgSrvjG.png">
|
|
|
|
+ <br/>
|
|
|
|
+ <i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
|
|
|
|
+</p>
|
|
|
|
+
|
|
|
|
+In write-behind, tha application does the following:
|
|
|
|
+
|
|
|
|
+* Add/update entry in cache
|
|
|
|
+* Asynchronously write entry to the data store, improving write performance
|
|
|
|
+
|
|
|
|
+##### Disadvantage(s): write-behind
|
|
|
|
+
|
|
|
|
+* There could be data loss if the cache goes down prior to its contents hitting the data store.
|
|
|
|
+* It is more complex to implement write-behind than it is to implement cache-aside or write-through.
|