This article introduced JetCache’s asynchronous API, which can improve performance and reduce RT by accessing the cache asynchronously. JetCache’s asynchronous and synchronous apis are fully compatible, and even synchronous development can reap some of the benefits of asynchrony.

Jedis has always been the most widely used Redis client in Java, and now we have a new option: lettuce. Founded by Mark Paluch of Pivotal (the company that currently maintains Spring), the Database supports asynchronous apis and Reactive apis, and the connection can be reused. The database is also under active development recently, making it one of the most popular Redis clients.

The uniform API provided by JetCache also supports asynchronous operations. Currently, only using lettuce access to Redis can be implemented asynchronously. When the underlying driver does not support asynchronous access, such as accessing Tair or accessing Redis using Jedis, it will automatically degenerate into synchronous blocking. So it’s completely compatible and consistent from an API point of view.

JetCache provides an easy-to-use regular API (normal method naming) and an UPPERcase method name API with full return values. The asynchronous API is based on methods with these uppercase method names. The JetCache API can be found here: github.com/alibaba/je….

Why access the cache asynchronously? Although Redis cache access is fast in most cases, it is still a network IO operation, and the amount of synchronous cache access can add up to a bit of RT, especially if the cache is operated in a loop. For example, the following example reads data from a JDBC result set and writes to the cache:

[Java] Plain text view copy code?

/ /… While (resultSet.next()){User User = new User(); user.setId(resultSet.getLong(“user_id”)); / /… Omit part of the code that sets user attributes cache.put(user.getid (), user); }

A closer look reveals that the put method doesn’t need to be executed synchronously at all because we don’t care about its return value (there are many similar scenarios where even if the operation cache fails, we can do nothing but ignore the error and proceed). When using JetCache and lettuce, we don’t have to do anything, the above code put operation is asynchronous, it will return immediately, and then automatically update the cache asynchronously, isn’t that cool?

To explicitly use the asynchronous API, take the GET method as an example:

[Java] Plain text view copy code? CacheGetResult

r = cache.GET(userId);

If the underlying driver does not support asynchrony, then the GET method is blocked until the cache operation is complete.

If asynchracy is supported, the cache operation may not complete after this line of code is executed, and calls to R.issuccess () or r.getvalue () or r.getMessage() will block until the cache operation is complete. If you do not want to be blocked and need to perform subsequent operations after the cache operation is complete, you can do this:

[Java] Plain text view copy code? CompletionStage

future = r.future(); future.thenRun(() -> { if(r.isSuccess()){ System.out.println(r.getValue()); }});

The above code will invoke the callback specified in thenRun in the thread that completed the asynchronous operation after the cache operation completes asynchronously. CompletionStage is a new Java8 feature, so if you’re not familiar with it, check out the documentation. It is important to note that since asynchronous development has been chosen, blocking methods cannot be called in the callback to block other threads (the callback methods are likely to be executed in the Event Loop thread).

Some of the regular apis (method names that start with a lowercase letter) do not need to be modified because they do not return values. They are directly asynchronous, such as the PUT and removeAll methods. The GET method, on the other hand, is still clogged because it needs to fetch the return value.

Using lettuce as a client to access Redis has the additional benefit of not having to configure connection pooling. The lettuce connection is thread-safe and reusable, so a server should maintain a Redis connection.