redis应用场景补充(一)

1. 前言

       在前面的两篇文章:浅谈redis数据结构之列表,浅谈redis数据结构之哈希,考虑到这两种数据结构的通用性及重要性,所以本篇专门为这两种数据结构的应用场景做个补充。

2. 应用场景之文章列表

       假设有这样一个需求:每个用户有属于自己的文章列表,现需要展示(分页)文章列表。此时可以考虑使用列表,因为列表不但是有序的,同时支持按照索引范围获取元素。

       我们利用redis的列表数据结构和哈希数据结构做个简单的实现。假设每篇文章有三个属性:标题(title)、时间(timestamp)、内容(content),每篇文章使用哈希结构存储。

       具体的操作如下所示:

redis应用场景补充(一)

       向文章列表(用户)添加文章,user:{id}:articles 作为用户文章列表的键(Key)。操作如下所示:

redis应用场景补充(一)

      分页获取文章列表(用户)。例如:获取用户id=1的前3篇文章,操作如下所示:

redis应用场景补充(一)

      使用列表类型保存和获取文章列表会存在两个问题:

      第一,如果每次分页获取的文章个数较多,我们会想到可以利用hgetall操作,但是如果需要多次执行此命令。此时可以考虑使用Pipeline进行批量获取,或者考虑将文章数据序列化为字符串类型,使用mget批量获取。

      第二,分页获取文章列表时,lrange命令在列表两端性能较好,但是如果列表较大,获取列表中间范围的元素性能会变差。此时可以考虑将列表做二级拆分,或者使用Redis 3.2的quicklist内部编码实现,它结合ziplist和linkedlist的特点,获取列表中间范围的元素时也可以高效完成。

3. 应用场景之关系型数据表

       假设有一个关系型的数据表,存储的是用户的基础数据。其中用户的属性作为表的列,每条用户的信息作为行,如下表所示:

idnameagecity
1tom23beijing
2mike30tianjin

       这样的表结构,对于小伙伴们在日常的工作或学习中,是再熟悉不过了。如果我们把这些用户的基础数据,按照redis的哈希数据结构进行存储的话,就如下图所示:

redis应用场景补充(一)

       对比这两种形式,使用字符串序列化缓存用户信息,哈希类型变得更加直观,并且在更新操作上会更加便捷。可以将每个用户的id定义为键后缀,多对field-value对应每个用户的属性,类似如下代码:

public UserInfo getUserInfo(long id) {
    // 用户id作为key后缀
    String userRedisKey = "user:info:" + id;
    // 使用hgetall获取所有用户信息映射关系
    Object userInfoMap = redis.hgetAll(userRedisKey);
    UserInfo userInfo;
    if (userInfoMap != null) {
        // 将映射关系转换为UserInfo
        userInfo = transferMapToUserInfo(userInfoMap);
    } else {
        // 从MySQL中获取用户信息
        userInfo = mysql.get(id);
        // 将userInfo变为映射关系使用hmset保存到Redis中
        redis.hmset(userRedisKey, transferUserInfoToMap(userInfo));
        // 添加过期时间
        redis.expire(userRedisKey, 3600);
    }
    return userInfo;
}

       需要注意的是哈希类型和关系型数据库有两点不同之处:

       第一,哈希类型是稀疏的,而关系型数据库是完全结构化的,例如哈希类型每个键可以有不同的field,而关系型数据库一旦添加新的列,所有行都要为其设置值(即使为 NULL),如图所示:

redis应用场景补充(一)

    

       第二,关系型数据库可以做复杂的关系查询,而使用Redis去模拟关系型复杂查询开发困难,维护成本高。

4. 应用场景之数据缓存方式

       就拿上一节的用户数据举例,截止到已经介绍的redis数据结构,以有三种缓存数据的方式,下面比较下这三种缓存数据的方式:

4.1 原生字符串类型

       给用户信息的每一个属性分配一个键。操作如下所示:

redis应用场景补充(一)

  • 优点:简单直观,每个属性都支持更新操作。
  • 缺点:占用过多的键,内存占用量较大,同时用户信息内聚性比较差,所以此种方案一般不会在生产环境使用。

4.2 序列化字符串类型

       将用户信息序列化后用一个键保存。操作如下所示:

redis应用场景补充(一)

  • 优点:简化编程,如果合理的使用序列化可以提高内存利用率。
  • 缺点:序列化和反序列化 有一定的开销,同时每次更新属性都需要把全部数据取出进行反序列化,更新后再序列化到Redis中。

4.3 哈希类型

       每个用户属性使用一对field-value,但是只用一个键保存。操纵如下所示:

redis应用场景补充(一)

  • 优点:简单直观,如果使用合理可以减少内存空间的使用。
  • 缺点:要控制和减少哈希在ziplist和hashtable两种内部编码的转换,hashtable会消耗更多内存。 

相关推荐