Shulou(Shulou.com)06/02 Report--

With the explosive growth of Web applications, SOA, and other server applications dealing with large-scale transactions, data storage cannot keep up with application growth because it cannot continue to add more servers to scale, unlike highly scalable application architectures.

In this case, the in-memory distributed cache provides an excellent solution to the data storage bottleneck. It centralizes memory across multiple servers (called clusters), keeps caches synchronized between all servers, and can grow cache clusters like application servers, which reduces the pressure on data storage and is no longer a bottleneck for scalability.

There are two main ways to use distributed caching:

Cache: this is where the application is responsible for reading and writing to the database. Cache does not interact with the database. Cache "kept aside" is a faster, more scalable in-memory data storage. The application needs to check the Cache before reading anything from the database. Moreover, the application automatically updates the Cache after updating the database, ensuring that the application can ensure the synchronization of the Cache with the data in the database.

Read-through/write-through (RT / WT): this is where the application stores Cache as primary data and reads data from it and writes data to it. The cache is responsible for reading and writing this data to the database, thus reducing the burden on the application. Read-Through, the business code first calls Cache. If the Cache misses, the Cache is pulled back to SoR instead of the business code (that is, the SoR is read by Cache). Write-Through, called penetrating write mode / write-through mode, the business code first calls Cache to write (add / modify) data, and then Cache is responsible for writing cache and SoR, rather than business code.

▲ read-through / write-through cache architecture

Cache-aside is a very powerful technology, that is, the business code is written around Cache, and the cache is maintained directly by the business code, which allows users to make complex database queries, including join and nested queries, and process the data in any way they want. However, Read-through / Write-through has a variety of advantages over Cache, as follows:

Simplify application code: in the Cache-aside approach, if multiple applications process the same data, the application code will continue to be complex and directly dependent on the database, or even execute the code repeatedly. Read-through / Write-through moves part of the data access code from the application to the Cache layer, greatly simplifying the application and extracting data more clearly.

Better scalability through Read-through: in many cases, the database load is significantly higher when cache entries expire and multiple parallel user threads eventually trigger the database, multiplying it by millions of cache items and thousands of parallel user requests. However, when getting the latest copy from the database, "Read-through" saves the cache-item to the cache and gets the latest copy from the database. The end result is that the application never goes to the database to get these cache-items, and the database load is kept to a minimum.

Use Write-behind for better write performance: in cache-aside, the application updates the database synchronously. Write-behind allows applications to quickly update the cache and return. Then, let cache update the database in the background.

Better database scalability with Write-behind: with Write-behind, users can specify constraints, so database writes are not as fast as cache updates, so the database is not too stressful. In addition, users can schedule database writes to take place during off-peak hours to minimize pressure again.

Automatic cache refresh upon expiration: using Read-through, Cache can automatically reload objects from the database. This means that the application does not have to click on the database during peak hours, because the latest data is always in Cache.

Automatically refresh Cache when the database changes: Read-through allows Cache to automatically reload objects from the database when the corresponding data in the database changes. This means that the cache is always up to date, and the application does not have to click on the database during busy hours, because the latest data is always in the Cache.

Read / write (RT/WT) does not apply to all data access in an application and is best suited for reading a single row from a database or reading data that can be mapped directly to a single cache item. Even if the data changes periodically, frequent reading is implemented in Cache.

Develop Read-Through Handler

Read-Through Handler registers with the cache server and allows cache to read data directly from the database. The NCache server provides a Read-through handler interface. This enables NCache to call the Read-through handler.

Start () performs some resource allocation tasks, such as establishing a connection to the primary data source, while Stop () means resetting all allocations, and Load is the method that cache uses to call the read-through object.

Develop Write-Through Handler

Write-Through Handler is called when cache needs to write to the database when the cache is updated. Typically, applications publish updates to cache by adding, inserting, or deleting them.

Start () performs resource allocation tasks, such as establishing a connection to the data source, while Stop () means resetting all allocations, and Save is the cache method that invokes the write-through object.

Call Read-Through and Write-Through from the application

The following sample code shows how to use the read-through/write-through feature from a simple Windows application, cache.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.