一篇特殊的redis工具类 -- 独此一家

一、引言

本篇博客以redis缓存为主。至于什么是redis缓存？还有没有其它的缓存？哪个缓存的性能会更好？这里就不一一做介绍了！(有兴趣的可以自己去百度一下)

在日常的开发中，我们或多或少(必须)的会用到缓存。为了提高系统性能、提升用户体验度，用户体验是多么的重要；这就要求在软件设计时，不但要注重可靠性、安全性、可扩展性以及可维护性等等的一些指标，更要注重用户的体验，用户体验分很多方面，但是有一点非常重要就是对用户操作的响应一定要快；怎样提高用户访问的响应速度，这就是摆在架构设计中必须要解决的问题；说到提高服务的响应速度就不得不说缓存了；

从系统的层面说，CPU的速度远远高于磁盘IO的速度；所以要想提高响应速度，必须减少磁盘IO的操作，但是有很多信息又是存在数据库当中的，每次查询数据库就是一次IO操作；请求响应时间等于网络响应时间和服务器响应时间；网络我们控制不了，服务器响应时间包括CPU计算时间和磁盘IO时间，其中CPU计算时间这个有硬件资源决定的，我们尽量减少算法的复杂度来减少它，磁盘IO时间，这个时间是非常慢的，应该尽量减少；

当客户端调用某个接口获取信息的时候，执行顺序1、2、3、4；由于信息存放在DB中，所以2、3就有一次磁盘IO操作；这个看似非常简单业务逻辑，但是当你做架构设计的时候往往要考虑最坏的场景，或者当成千上万的用户频繁的调用这个接口应该怎么处理？如果按照上图这样的架构处理，这个看似简单业务的接口会使整个系统变慢，这样用户的请求就会长时间得不到响应；这样的问题怎么解决那，这时候就该缓存登场了；

缓存有很多种、也有很多种缓存策略。这里就不一一做探讨了，毕竟这篇博客是讲关于的工具类！总之一句话，要想提高系统的性能，尽量减少IO的操作，特别是磁盘IO的操作；使用缓存可以有效的避免这种情况；所以在架构设计过程中，涉及到查询数据库的时候，应该考虑一下是不是使用缓存技术来提高系统的性能，并且降低数据库的压力。

二、无知的痛(用get / set方式使用redis)

在根据某个需求设计业务的时候，比如说购物车：涉及到添加、查询、修改、删除。不说这四个具体实现时候的细节，这不就简单的对数据库增、删、改、查吗？但是，当成千上万的用户频繁访问的时候，简单的事情在高并发的情况下就会变的不简单！这个时候就需要有个东西来代替数据库，而且还要比数据库更快，来应对可能出现的高并发！所以我们想到了(redis)缓存，作为一个key / value 存在，很多开发者自然的使用set/get 方式来使用 redis ，实际上这并不是最优化的使用方法。尤其在未启用VM 情况下，redis 全部数据需要放入内存，节约内存尤其重要。 假如一个key-value单元需要最小占用512字节，即使只存一个字节也占了512字节(比如set/get，一个key-value对应一条数据)。这时候就有一个设计模式，可以把key复用，几个key-value作为一个大的value，大的value再作为一个value，set存入一个key中。这样同样512字节就会存放10-100倍的容量。 这就是为了节约内存，建议使用hash类型而不是set/get的方式来使用redis。

三、hash类型方式使用redis -- 指定返回类型

在日常开发中，我们会把业务中的所有特性封装成一个对象，再把这个对象存入到redis缓存中。在使用redis的时候，通常会把redis常用的方法封装成一个工具类。然后我们调用工具类中的方法，把存入的对象传到方法中。通常方法会把对象转换成string存入缓存，需要的时候再把string取出来，然后再转换成对象！大多数的情况就是如此，但是在我实际的开发中传入的是个和业务有关的对象，返给我的却是一个object对象(和业务没有半毛钱关系)。我想要让返回的对象和业务有关，还得强转一下！这返回的是单个对象，如果是个list呢？循环强转吗？那如果是map呢？当然肯定都是能转的，但是这样就增加了实际业务中的代码量！在我看来 多一行与业务无关的代码都是罪恶的(纵然它是为了和业务产生关联)，我想要的是 我给你存的是啥！返回的就是啥！别整那些没用的......

1.根据key和fieid返回hash中指定存储位置的值,指定返回类型

调用：

2.hvals()方法,获取hash中value的集合,指定返回的集合类型

调用：

3.以Map的形式返回hash中的存储和值,指定map中的value类型

调用：

4.关闭jedis连接,将jedis连接归还redis连接池

四、结尾

其实指定redis返回类型，没什么高大上的！就是用了ObjectMapper类，这个类是Jackson库的主要类。但是，我百度查过网上很多关于redis的连接工具类，发现却没有一个做过这方面的处理！其实这个也不难，在写业务的时候随手就能写出来。我也就是在用redis的时候偶尔蹦出来了这个想法，每次都要 多那么两三行与业务无关的代码让人非常的抓狂！