项目Redis 应用实例

Redis 目前应用相当广泛，由于是内存存储，性能很好，所以也在很多业务场景下都有其适用性，前段时间经常有同事问到使用Redis 的细节问题，如该使用它的哪种类型来解决某种场景下的某些问题，本文总结整理后，并给出实际的使用实例。

首先Redis 是开源的，ANSI C语言编写，key-value 的存储系统，内存存储数据，也可以通过配置根据策略去持久化数据。 

包含五种数据结构：

 

一、String 字符串

      最基础的数据存储类型，并且是二进制安全，也就是说该类型可以接受任何格式数据，图像，文字等，应用场景主要适用于热数据的缓存；其主要操作有，get set 等;

      下边是一个常用的模式，当有数据的改动，需要同时同步到redis和db中，为了不存储太多不常用的数据，可以在key增加一个过期时间，当要获取数据时可以直接从redis中获取数据，如果已经过期，可以再从db中获取，来保证数据的有效性，这种模式在一定程度上很有效的减少对db磁盘的频繁访问，提高性能。

 

def update_info(info):
      save_info_to_db(info)
      save_info_to_redis(info)

def get_info(id):
      res = get_info_from_redis(id)
      if not res:
            return get_info_from_db(id)

 

二、Hash -字典

      Redis hash 是一个string 类型的 key -value 的映射表，特别适用于存储对象，如果没有该类型。我们常做的做法是把 对象的属性和值dump成json串来存储，但是要是获取某个属性值，或者是要修改某个属性值，只能是先get, 然后 json load,修改后还要json dump 再保存，既繁琐，又效率低下，而使用Redis hash 会很便捷高效，如下图，可以很方便的设置 user:info:1110 这个对象的各个属性和值，并且可以单独update 属性值；

      

 

三、List - 链表

       Redis 使用双端列表实现List,常见的应用是消息队列，可以使用*PUSH操作往队列中加入消息，工作的进程可以使用POP操作从队列中获取消息，理解Redis List 首先要把它想成是一个列表，列表的左端（Left） 也就是列表的前段，右端（Right）也就是列表的后端，所有L开头的操作，都是在列表的左端，也就是头部进行操作，所有R开头的操作，都是在列表的右端，也就是尾部进行操作，那我们就不难理解，RPUSH 和 LPUSH了，分别是从列表的左边和右边插入数据。LPOP和RPOP是从两端移除并获取数据。BLPOP和BRPOP 是阻塞式的POP。在工作进程较为常用，没有任务就一直阻塞，有任务就获取出来执行。 还有一些LLEN LINDEX也较为常用。详细命令可以参考 http://redis.readthedocs.io/

 

四、Set - 集合

       特点：就是一堆不重复的数据的组合，并且Redis 提供了对集合求交集，差集，并集的操作。基于这两个特点，就可以应用于很多业务场景，

       （1）由于其天生具有去重的功能，所以很多要求唯一性的记录就可以使用set 类型，比如系统要记录今天所登录的账号列表，就可以使用Set,每次登录的时候放入到今天的key中；

       （2）接着上边的例子，如果想要知道连续三天内都登录的账号列表，那么使用刚才三天的set 取交集就可以轻松的搞定；

 

五、Sorted Set - 有序集合

       特点：在Set 的基础上增加 权重参数 score，集合中的元素会自动按照score进行排序，常见的应用，比如获取业务中的TOP N 数据，可以使用该数据结构高效的获取。

        sorted set 是比较有意思而且很使用的一种数据类型，就在前两天体验到了它的力量。这里分享给大家：

        背景：系统中要做数据的异步celery统计。一个站点有很多漏洞，每个漏洞变化后就要触发一次站点统计任务，当然漏洞变化的地方很多。所以把触发统计任务抽成一个接口供各模块来调用。但是问题来了。很多情况下，一个站点的多个漏洞会在一段时间内都改变，所以接口会在较短的时间内接受到多次同一个站点的统计任务。

        思路：把站点id 和 当时的timestap 放入 sorted set 中, 后台进程把sorted set 中timestamp 小于 某个值得获取到，下发。思想主要是避免了一个站点下多个漏洞状态更新，导致的多个统计任务执行，通过延迟下发，比较时间来避免这种多次的下发任务。

        下图是业务中的celery 任务情况，在使用sorted set 方法优化前，任务量和增加速度比较大。优化后观察，在15个worker下，基本上可以做到消息的实时处理。这就是sorted set 的一个应用。其实在业务中做数据TOP N的场景，使用sorted set 更方便。

 

                                                            图二：7点左右的任务量

  

                                                   图三：8点左右的任务量

 

 

  图四：Redis Sorted Set 控制下发

总结：Redis 这五种类型的数据，可以应用在我们业务的不同场景中，帮助我们提高性能，而不仅仅是缓存和消息队列~， 当然如果不清楚现有的使用方式是否合理时，可以通过INFO MONITOR SLOWLOG 来排查和发现一些潜在问题；