Cache predecessor Practice __ Cache

When it comes to caching, it may be most familiar with caching usage and update policies. There are many advantages to using caching, which can improve the response speed and reduce the reading and writing pressure of storage such as database. The key is to become "fast". There is a lot of attention to using caching, such as when to use caching, what data is appropriate for caching, and when the cache expires. Caching is a "silver bullet" for improving program performance, but this is not about how caching is used, but about the idea and practice of caching the predecessors.

Cache Front

The cache here refers to the application cache, or the local cache, then the cache predecessor refers to the server side of the local cache transfer to the client, so that the client can directly client application caching, only the server-side data updates will trigger the client to make a remote call.

The advantage of this is that the client can get the data directly in local memory, greatly increasing the response speed, from the execution link to reduce the consumption of network transmission.

Depending on the scenario partition, the cache predecessors can be divided into the following scenarios:

Allow short inconsistent data
Immediate effect

allow brief inconsistencies

Allowing short inconsistencies means that the server-side data update does not require immediate notification of client cache invalidation, such as 2 minutes. So that the client has a maximum of 2 minutes to read dirty data, can be in the server interface packaging a layer of local caching, the client only need to configure this bean can be used directly, to Java, Dubbo for example, there are ehcache, caffeine, guava cache.

This scenario is simpler, but the disadvantage is that the client originally used the Dubbo interface to change the code, but can reduce the number of client RPC calls, and improve response Rt.

Immediate effect

This scenario is complex, meaning that the wrapper class of the Dubo interface cannot simply set a cache expiration time, so how to resolve the server-side update immediately notifies the client of the failed local cache. Use the message.

Similar to the previous scenario, the Dubbo interface can be packaged in a layer of adapter, the logic inside is to subscribe to the service-side data Update message, and then parse the message to get the key that needs to be invalidated, the client local cache key clears. This allows the client to trigger an RPC call as soon as it receives a message, obtaining the latest data from the server.

In the case of Dubbo, you can use stub properties to configure a stub on the provider side, which is pseudo code as follows:

<dubbo:service interface= "Com.foo.BarService" stub= "Com.foo.BarServiceStub"/>

The above logic is implemented in Barservicestub and the following code is detailed in the official document Dubbo.

Package Com.foo Public
class Barservicestub implements Barservice {

    private final barservice barservice;

    constructor passing in the real remote proxy object
    //This barservice is Dubbo:reference's bean public
    (Barservice barservice) {
        This.barservice = Barservice;
    }

    Public String SayHello (string name) {
        //This code performs
        //implements message processing logic on the client, fails local cache//The
        local cache fails, and the interface of the server is tuned to
        try { return
            Barservice.sayhello (name);
        catch (Exception e) {
            //exception handling return
            "Fault tolerant Data"
        ;
    }
}}

Of course, you can implement your own adapter logic without the Dubbo stub, but at the client you need to configure a single bean, and then use the Dubbo:reference Bean's call place to replace the newly configured one.

The above is in the use of caching optimization experience, there may be omissions, welcome corrections.