使用JetCache的异步API访问Redis缓存

摘要:
本文介绍了JetCache的异步API,通过异步方式访问缓存可以提升性能,降低RT。
JetCache的异步API和同步API是完全兼容的,甚至用同步的开发方式也能获得一部分异步带来的好处。

Jedis一直是Java中使用最广泛的Redis client,现在我们又有了一个新的选择:lettuce
lettuce由Pivotal(也就是目前维护Spring的公司)的Mark Paluch发起,支持异步API和Reactive API,连接可以复用,近期开发也非常活跃,成为Redis客户端中的一个新锐。

JetCache提供的统一API也支持异步操作方式,当前,只有使用lettuce访问Redis能实现异步。
当下层使用的驱动不支持异步,比如访问Tair或者使用Jedis访问Redis时,会自动退化为同步堵塞的方式。所以从API上说,是完全兼容和一致的。

JetCache提供了简单易用的常规API(正常方法命名)和具有完整返回值的大写方法名API,异步API基于这些大写方法名的方法。
关于JetCache API的介绍请参考这里:https://github.com/alibaba/jetcache/wiki/CacheAPI_CN

为什么要异步访问缓存呢?虽然大部分情况下Redis缓存访问很快,但毕竟是一个网络IO操作,同步访问缓存多少也会增加一点RT,特别是在循环中操作缓存时,就积少成多了。
比如下面的例子从jdbc结果集读取了数据,然后写缓存:

//......获取数据库连接,执行SQL,得到ResultSet,省略
while(resultSet.next()){
    User user = new User();
    user.setId(resultSet.getLong("user_id"));
    //.....省略一部分设置用户属性的代码
    
    cache.put(user.getId(), user);
}

仔细分析一下就会发现,其实这个put方法完全没有必要同步执行,因为我们并不关心它的返回值(很多类似的场景下即使操作缓存出现了错误,我们也不能干什么,只能忽略错误继续处理)。
使用JetCache和lettuce的时候,我们什么都不用做,上面的代码的put操作就是异步的,它会马上返回,后续自动异步更新缓存,是不是很酷?

如果要显式的使用异步API,以GET方法为例:

CacheGetResult<UserDO> r = cache.GET(userId);

如果使用底层驱动不支持异步,那么GET方法就会堵塞直到缓存操作完成。

如果支持异步,这一行代码执行完以后,缓存操作可能还没有完成,此时调用r.isSuccess()或者r.getValue()或者r.getMessage()将会堵塞直到缓存操作完成。
如果不想被堵塞,并且需要在缓存操作完成以后执行后续操作,可以这样做:

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

以上代码将会在缓存操作异步完成后,在完成异步操作的线程中调用thenRun中指定的回调。
CompletionStage是Java8新增的功能,如果对此不太熟悉可以先查阅相关的文档。
需要注意的是,既然已经选择了异步的开发方式,在回调中不能调用堵塞方法,以免堵塞其他的线程(回调方法很可能是在event loop线程中执行的)。

部分常规api(方法名小写字母开头)由于没有返回值,因此不需要任何修改,它们直接就是异步的,比如put和removeAll方法;而get方法由于需要取返回值,所以仍然会堵塞。

使用lettuce作为客户端访问Redis还有另一个好处,就是不用配置连接池。
lettuce的连接是线程安全的可以复用,所以一个服务器维持一个Redis连接就好了。
对于一些云上的Redis,连接数可能是受限的,要支持更多连接就要付更多钱,这个时候lettuce就非常有优势了。这方面可以参考lettuce的文档获得更多信息:
https://github.com/lettuce-io/lettuce-core/wiki/Connection-Pooling

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 使用JetCache的异步API访问Redis缓存

  • Trackback 关闭
  • 评论 (0)
  1. 暂无评论

return top