Extreme transaction Processing mode: Write-behind cache

Introduced

Applications typically use data caching to improve performance, especially for applications that are heavily used for read-only transactions. These applications update the database directly when the data is changed. The problem is that as the load increases, response times are extended as the updates grow. Databases are not good at performing concurrent transactions that handle a large amount of records. In contrast, processing bulk transactions is the strength of the database.

In fact, as the extra load increases, response times soar, and the database consumes CPU or disk. Traditionally, storage in-memory cache (In-memory caches) is limited to accommodate the free memory space of the JVM. Once we need to cache a larger amount of data, the cache releases the data continuously, leaving storage space for other data. Also, the required records must be read continuously, causing the cache to be invalid and exposing the database directly to the full read operation load.

There are already a number of available products, including IBM? Websphere? EXtreme scale,oracle Coherence and gigaspaces, both of which support the free memory of a cluster of JVMs as a cache rather than a single JVM. This makes the larger the number of merged JVMs, the greater the size of the cache support. If these JVMs are additional servers with CPUs, storage, and networks, the service for read requests is scalable. By using Write-behind technology, these products also provide scalable services for update requests. The scalability of the Write-behind cache allows it to resolve extreme transaction processing (extreme transaction processing, XTP) scenarios. Gartner defines XTP as: "An application style designed to support the design, development, deployment, management, and maintenance of distributed transactional applications, characterized by special requirements for performance, scalability, availability, security, manageability, and reliability." ”

This article will use the IBM WebSphere EXtreme scale to demonstrate how to optimize the performance of your application using Write-behind mode. The Write-behind feature enables batch updates to the backend database asynchronously, based on user-configured intervals. The obvious advantage of this approach is the ability to reduce database calls, thereby reducing transaction load and faster access to objects in the grid. It has a faster response time than the Write-through cache, which updates the cache and causes a timely update to the database. With Write-behind, the transaction is no longer required to wait for the write of the database to complete. In addition, it avoids database errors in the application because the Write-behind buffer remains unchanged through the memory copy unit until it transmits it to the database.

Defining and configuring Key concepts

What is the "write-behind" cache

In the Write-behind cache, data reads and updates are cached, and unlike the Write-through cache, the updated data is not immediately uploaded to the database. Conversely, once an update is made in the cache, the cache tracks the list of dirty records and periodically flushes the current dirty recordset to the database. As an additional performance improvement, the cache merges the dirty records. Merging means that if the same record is updated, or is marked as dirty in the buffer several times, only the last update is guaranteed. This approach can greatly improve performance for scenarios where value updates are very frequent, such as stock prices in financial markets. If the stock price changes 100 times per second, it means that there will be an X 100 updates in 30 seconds. Merge to reduce it to only once.

In the WebSphere EXtreme scale, the list of dirty records is replicated to ensure that the JVM exits while the user can specify the replication level by setting the number of synchronous and asynchronous replication. Synchronous replication means that when the JVM exits, there is no data loss, but because the main process must wait for a replica of the change information, the speed is slower. Asynchronous replication is faster, but if the JVM exits before it replicates, it can cause changes in the most recent transactions to be lost. The list of dirty Records is written to the data source using large batch transactions. If the data source is not available, the grid continues to process the request, and then try again. The grid can provide a shorter response time as the scale changes, because the changes are submitted individually to the grid, and the transaction can still be committed even if the database is stopped.

Write-behind caching does not universal. The nature of the write-behind is destined for the user to see changes that are not immediately reflected in the database even if they are submitted. This time delay is referred to as cache write latency (cached write latency) or database corruption (db staleness); The delay between the database change and update data (or invalidate the data) to reflect the changes in the cache is called " Cached read delay (cache read latency) or cache corruption (cached staleness). If each part of the system is accessing data through caching (for example, through a public interface), it is worthwhile to adopt Write-behind technology because the cache is always kept up to date with the correct record. It can be foreseen that the only way to make changes is to cache the system with Write-behind.

Whether it's a sparse cache or a full cache, it can be used for write-behind attributes. A sparse cache stores only a subset of the data, and can be populated by delay. It is typically accessed using keywords, because not all of the data in the cache can be used, and queries using the cache may not be executed. The full cache contains all the data, but it takes longer to load first. The third feasible strategy is to take both of the two strengths. First, a subset of the data is preloaded in a short period of time, and then the rest of the data is deferred. The subset data preloaded is about 20% of the total, but it can meet the 80% request.

The scenario for using a cached application in this way is: the partitioned data model for simple CRUD (create, read, update, and delete) patterns is applied.

Configuring Write-behind Features

For WebSphere Extrem scale, the Backingmap feature is enabled in the Objectgrid.xml configuration by adding the Writebehind attribute to the Write-behind element, as shown below. The value of the parameter uses the syntax "" [T (time)] [;] [C (count)] to specify when the database update occurs. When the set time is reached, or the number of changes in the queue set reaches the set count value, the update is written to the persistent storage.

Example of a list 1:write-behind configuration

<objectGrid　name="UserGrid">

<backingMap　name="Map"　pluginCollectionRef="User"　lockStrategy="PESSIMISTIC"　writeBehind="T180;C1000"　　/>