Redis到底该如何利用?

Redis是个好东西,经过上两个星期的研究和实践,目前正在项目里大规模的替换掉原来的本地内存cache。但是替换过程中却发现,Redis这东西高端,大气上档次,似乎不是我想象里的使用方法。

在没有深入Redis之前,在我的概念里,缓存,就是key-value。而使用方式肯定不需要改动多少代码,一切都是Get/Set。但是实际用的时候却发现,我错了,不是所有的场景都是简单的Get/Set。也不是所有的数据都适合key-Value,于是有了这个问题,Redis到底该如何使用?我问自己,也向园子里的朋友们求助,希望帮忙解答。当然,这篇文章抛砖引玉,先谈谈我这两周的感悟。

使用场景

在我的项目里,有一个提供给Autocomplete的功能,数据量大概在几万。这篇文章里我用姓名检索的例子来说明,列表请戳来自Redis作者的Demo

在这样的列表里全是用户名,例如我们的系统里有一个用户对象:

public Class User
{
     public string Id{get; set;}
     public string Name {get; set;}
     ....
     public string UserHead {get; set;}
}

系统里需要一个用户的下拉列表,由于数据量大不能一次显示完,于是就加上了一个AutoComplete功能。如果是不用Redis这样的集中式缓存,直接缓存在本机内存里,那么结构很简单如下:

var users = new List<User>{...};//读到一个用户列表
MemoryCache.Set("capqueen:users", users);//放入内存

//读取
var users = MemoryCache.Get<List<User>>("capqueen:users");

因为都是在内存里,所以直接存List就可以了,搜索的时候也可以直接的如下:

var findUsers = users.Where(user => user.Name.StartWith("A")).ToList();例如输入的字符是 “A“

相当简单,完全不用考虑如何存储,存储的数据结构。但是换到了Redis这些集中式缓存服务之后,咱们再来思考,该如何存储。

方案一:类似内存式的缓存实现。

本文里使用的Redis链接库是StactkExchange.Redis,出自StackOverFlow的开源产品。

var db = redis.GetDataBase();//获取0数据库

var usersJson = JsonConvert.SerializeObject(users)//序列化

db.StringSet("capqueen:users", usersJson);//存储

var usersString = db.StringGet("capqueen:users");
var userList = JsonConvert.DeserializeObject<List<User>>(users);//反序列化

上面的方式逻辑上是没有问题的,编译也可以通过。但是仔细想一想,Redis作为独立的缓存服务和appSever是分开来的,这样的读取方式对redis服务器的IO是个负担,甚至这样的读取比本地内存缓存慢了太多了。

那如何解决呢?试想key-value的精髓是在于Key,那么对于List来说应该要把item分开来存储。

方案二:Keys模糊匹配。

在查看了Redis的命令文档(见参考资料4)之后,发现了命令Keys,如获至宝,立马修改了方案。首先我们需要把要搜索的关键词建立为key,这里我把key定义为 "capqueen:user:{id}:{name}",其中{}内的是要用item对应属性替换的。代码如下:

var redis = ConnectionMultiplexer.Connect("localhost");
var db = redis.GetDatabase();

var users = new List<User> {
    new User{Id = 6, Name = "aaren", Age=10},
    new User{Id = 7, Name = "issy", Age=11},
    new User{Id = 8, Name = "janina", Age=13},
    new User{Id = 9, Name = "karena", Age=14}
};

users.ForEach(item => {
   var key = string.Format("capqueen:user:{0}:{1}", item.Id, item.Name);
   var value = JsonConvert.SerializeObject(item);
   db.StringSet(key, value);
});

建立好的缓存如下图所示:

所有的user都以单独的Key-Value方式存储,那么如何利用Keys搜索呢?我们来看下Redis的Keys命令:

KEYS pattern

查找所有符合给定模式 pattern 的 key 。

KEYS * 匹配数据库中所有 key 。
KEYS h?llo 匹配 hello , hallo 和 hxllo 等。
KEYS h*llo 匹配 hllo 和 heeeeello 等。
KEYS h[ae]llo 匹配 hello 和 hallo ,但不匹配 hillo 。
特殊符号用 \ 隔开

也就是说Keys能够进行简单的模糊匹配,那么我们这里的搜索就可以换成如下的方式:

var redis = ConnectionMultiplexer.Connect("192.168.10.178");
var db = redis.GetDatabase();
var server = redis.GetServer("192.168.10.178", 6379);
var keys = server.Keys(pattern: "capqueen:user:*:a*");
var values = db.StringGet(keys.ToArray());

//反序列化
var jsonValues = new StringBuilder("[");
values.ToList().ForEach(item => jsonValues.Append(item).Append(","));
jsonValues.Append("]");
var userList = JsonConvert.DeserializeObject<List<User>>(jsonValues.ToString());

注意以上的代码里,因为每个value是一个json,为了增加转化时的效率,我先处理成json arry再进行反序列化。

这种方案,确实是解决了我目前的问题,然而我注意到了Redis文档里的一段话:

KEYS 的速度非常快,但在一个大的数据库中使用它仍然可能造成性能问题,如果你需要从一个数据集中查找特定的 key ,你最好还是用 Redis 的集合结构(set)来代替。

这段话换而言之就是慎用Keys搜索的意思,那么有什么更好的解决方案呢?由于这篇文章我拖得很久了,这里留个问题在末尾,期待有大牛能够帮忙解答,感激不尽。当然还有下一篇内容,我会讲讲我目前的处理方法。

下篇文章里,我会根据Redis作者的博客(资料1)里的做法以及我最后查到的资料,做一个新的方案,请大家到时指教。

参考资料

  1. Redis作者博客,这是其中一篇讲如何基于Redis实现AutoComplete的文章:http://oldblog.antirez.com/post/autocomplete-with-redis.html
  2. Redis 第三方管理工具 For Windows:http://redisdesktop.com/
  3. Redis .NET链接工具的Top20:http://nugetmusthaves.com/Tag/Redis
  4. Redis命令中文文档:http://redisdoc.com/
时间: 2024-08-29 18:46:01

Redis到底该如何利用?的相关文章

Redis到底该如何利用?【转自:http://www.cnblogs.com/capqueen/p/HowToUseRedis.html】

Redis是个好东西,经过上两个星期的研究和实践,目前正在项目里大规模的替换掉原来的本地内存cache.但是替换过程中却发现,Redis这东西高端,大气上档次,似乎不是我想象里的使用方法. 在没有深入Redis之前,在我的概念里,缓存,就是key-value.而使用方式肯定不需要改动多少代码,一 切都是Get/Set.但是实际用的时候却发现,我错了,不是所有的场景都是简单的Get/Set.也不是所有的数据都适合key-Value,于是有了 这个问题,Redis到底该如何使用?我问自己,也向园子里

Redis到底该如何利用(三)?

上两篇受益匪浅,秉着趁热打铁,不挖到最深不罢休的精神,我决定追加这篇.上一篇里最后我有提到实现分级缓存管理应该是个可行的方案,因此今天特别实践了一下.不过缓存分级之后也发现了一些问题,例如下图: 当appServerA修改了数据,并同步到Redis/DB之后,如何让appServerB也能更新本地缓存呢?虽然Redis的出现是为了解决这个问题的,但是分级方案里,MemoryCache还是需要保留.那么如何保存呢?我尝试了下面的几种方式,现在我们逐一来看. 全数据增量同步 所谓全数据校验,即所有的

记录一次攻击事件(redis 未授权漏洞利用直接登录服务器)

听到朋友说接到阿里云的报障,提示黑客把他的服务器当肉鸡了,当时有点怕怕,继而官方的网络带宽也爆了进而系统处于瘫痪,当时我需要帮他处理这个问题 1 在没有查到杀手之前我是先把带宽&端口用iptables 做了限制这样能保证我能远程操作服务器才能查找原因 2 在各种netstat –ntlp  的查看下没有任何异常 在top 下查到了有异常进程还有些异常的这里就截图一个 3 结果果断把进程给kill -9  了  没想到再去ps的时候又来了意思就是会自动启动它 这就让我想到了crond 这个自动任务

Redis到底是多线程还是单线程?线程安全吗

redis是单线程,线程安全 redis可以能够快速执行的原因: (1) 绝大部分请求是纯粹的内存操作(非常快速)(2) 采用单线程,避免了不必要的上下文切换和竞争条件(3) 非阻塞IO - IO多路复用 IO多路复用中有三种方式:select,poll,epoll.需要注意的是,select,poll是线程不安全的,epoll是线程安全的 redis内部实现采用epoll,采用了epoll+自己实现的简单的事件框架.epoll中的读.写.关闭.连接都转化成了事件,然后利用epoll的多路复用特

Redis 到底是怎么实现“附近的人”这个功能的呢?

作者简介 万汨,饿了么资深开发工程师.iOS,Go,Java均有涉猎.目前主攻大数据开发.喜欢骑行.爬山. 前言:针对“附近的人”这一位置服务领域的应用场景,常见的可使用PG.MySQL和MongoDB等多种DB的空间索引进行实现.而Redis另辟蹊径,结合其有序队列zset以及geohash编码,实现了空间搜索功能,且拥有极高的运行效率.本文将从源码角度对其算法原理进行解析,并推算查询时间复杂度. 要提供完整的“附近的人”服务,最基本的是要实现“增”.“删”.“查”的功能.以下将分别进行介绍,

Redis 到底是如何实现“附近的人”这个功能呢?

针对“附近的人”这一位置服务领域的应用场景,常见的可使用PG.MySQL和MongoDB等多种DB的空间索引进行实现.而Redis另辟蹊径,结合其有序队列zset以及geohash编码,实现了空间搜索功能,且拥有极高的运行效率.本文将从源码角度对其算法原理进行解析,并推算查询时间复杂度. 操作命令 自Redis 3.2开始,Redis基于geohash和有序集合提供了地理位置相关功能. Redis Geo模块包含了以下6个命令: GEOADD: 将给定的位置对象(纬度.经度.名字)添加到指定的k

《四大点,搞懂Redis到底快在哪里?》

一.开发语言 二.纯内存访问 三.单线程 四.非阻塞多路I/O复用机制 前言 Redis是一种基于键值对(Key-Value)的NoSQL数据库 ,Redis的Value可以由String,hash,list,set,zset,Bitmaps,HyperLogLog等多种数据结构和算法组成. Redis还提供了键过期,发布订阅,事务,Lua脚本,哨兵,Cluster等功能. Redis执行命令的速度非常快,根据官方给的性能可以达到10w+qps. 那么本文主要介绍到底Redis快在哪里,主要有以

【redis】spring boot利用redis的Keyspace Notifications实现消息通知

前言 需求:当redis中的某个key失效的时候,把失效时的value写入数据库. github: https://github.com/vergilyn/RedisSamples 1.修改redis.conf 安装的redis服务默认是: notify-keyspace-events "",修改成 notify-keyspace-events Ex; 位置:redis安装目下的redis.windows-service.conf 或 redis.windows.conf.(具体看re

Redis官网——如何利用Redis做服务器集群的分布式锁

链接:http://redis.io/topics/distlock 原理很简单,一段时间内轮询加锁的key 重点,不同语言的开源实现 Before describing the algorithm, here are a few links to implementations already available that can be used for reference. Redlock-rb (Ruby 实现). There is also a fork of Redlock-rb th