上个星期同事做一个业务模块,需要将一个80M的数据存入到redis缓存中,想法总是好的,真操作的时候遇到了HSet超时,我们使用的是C#的

StackExchange.Redis驱动。

  <redisCacheClient allowAdmin="true" ssl="false" connectTimeout="5000" abortConnect="false" database="0">
<hosts>
<add host="192.168.202.129" cachePort="6379"/>
</hosts>
</redisCacheClient>

由于封装代码啥的都是网上下载的,第一反应就是把上面的“connectTimeout”设为5000 * 60 =3min,但是丝毫没有用处,也就是3min没有起

到作用,码蛋的,这可怎么办???只能硬着头皮去看StackExchange的源码,终于在1个小时的地毯式搜索中找到了两处凶杀现场,如下所示:

  

接着我发现其中的 timeoutMilliseconds 和  this.multiplexer.RawConfig.ResponseTimeout的取值决定着是否会抛异常,感谢感谢,接下来我继续

顺藤摸瓜,找到了两个属性的赋值处。

当我看到了上面的syncTimeout.GetValueOrDefault(1000)的时候一颗悬着的心也就放下了,也懒得改了,直接将这里的1000改成1000*60*5

就好啦,commit代码后让同事再运行下看看效果。。。终于拨开迷雾见青天,数据出来啦,遗憾的是,读写操作需要耗时3s,虽然问题表面上看似

解决了,但是问题来了,3s延时真的不是什么好事情,我们都知道redis是单线程的,那就意味着什么??? 意味着这3s的时间内其他redis客户端

是阻塞的。。。虽然心里是这么想的,但是还是存有一点侥幸心理觉得不是这样的,不过还是决定做一个实验看一看。

一:阻塞演示

  我决定开一个线程将一个txt中140M的数据插入到redis的hashset中,同时我开另一个线程1秒钟一次的从string中获取数据,同时记录下获

取时间,如果获取string的时间间隔太大,说明阻塞产生了,想法就是这样,说干就干。。。

  System.Threading.Tasks.Task.Factory.StartNew(() =>
{
try
{
var content = File.ReadAllText(@"D:\20151120-13\20151120-13.log", Encoding.Default); Console.WriteLine("主线程 读取txt内容完毕,准备插入redis {0}", DateTime.Now);
var result = CacheUtil.CacheClient.HashSet("myredis", "mykey", content); Console.WriteLine("主线程 插入Redis 成功:{0} , {1}", result, DateTime.Now); var r = CacheUtil.CacheClient.HashGet<string>("myredis", "mykey"); Console.WriteLine("主线程,读取Redis成功,总长度{0}, {1}", r.Length, DateTime.Now);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}); System.Threading.Tasks.Task.Factory.StartNew(() =>
{
try
{
var result = CacheUtil.CacheClient.Add<string>("myfruits", "asdfasdfasdfasdfasd"); for (int i = ; i < ; i++)
{
var content = CacheUtil.CacheClient.Get<string>("myfruits"); Console.WriteLine("第 {0} 次读取 {1} ,{2}", i, content, DateTime.Now); Thread.Sleep();
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
});

读取string的线程被Hashset阻塞了6s之多,很恐怖,这个就属于典型的慢查询,它的慢果然阻塞了其他client,接下来就拿着问题找同事,第一个想

法就是问同事为什么要存这么大的数据,得知为了避免海量运算必须要存这么大数据之后,没撤只能从假定80M的数据量做优化,第二个想法就是拆,

既然是80M的数据,我可以拆成8份10M的数据,这样有两个好处,第一个不会太拖长Hset的时间,第二个尽最大努力不阻塞其他client,但是呢,同

事不想改动代码,还要问我还有其他解决方案不???然后我就提了一个下下策,隔离你的缓存业务,既然你都是存储大数据,那我专门给你开一个

redis去存储缓存,几秒钟就几秒钟吧,估计对他业务还能够承受,我可不能让我的主redis因为这个吊毛业务挂了。。。

二:慢查询日志

  自从发生这个事情之后,我就有一个想法了,我是不是也需要记录一下主redis中那些“慢操作”的命令,然后找到相关的业务方,不然的话,阻塞

就不好玩了。然后就直接在redis手册中就找到了相关的命令。

SLOWLOG subcommand [argument]

什么是 SLOWLOG

Slow log 是 Redis 用来记录查询执行时间的日志系统。

查询执行时间指的是不包括像客户端响应(talking)、发送回复等 IO 操作,而单单是执行一个查询命令所耗费的时间。

另外,slow log 保存在内存里面,读写速度非常快,因此你可以放心地使用它,不必担心因为开启 slow log 而损害 Redis 的速度。

设置 SLOWLOG

Slow log 的行为由两个配置参数(configuration parameter)指定,可以通过改写 redis.conf 文件或者用 CONFIG GET 和 CONFIG SET 命令对它们动态地进行修改。

第一个选项是 slowlog-log-slower-than ,它决定要对执行时间大于多少微秒(microsecond,1秒 = ,, 微秒)的查询进行记录。

比如执行以下命令将让 slow log 记录所有查询时间大于等于  微秒的查询:

CONFIG SET slowlog-log-slower-than 

而以下命令记录所有查询时间大于  微秒的查询:

CONFIG SET slowlog-log-slower-than 

另一个选项是 slowlog-max-len ,它决定 slow log 最多能保存多少条日志, slow log 本身是一个 FIFO 队列,当队列大小超过 slowlog-max-len 时,最旧的一条日志将被删除,而最新的一条日志加入到 slow log ,以此类推。

以下命令让 slow log 最多保存  条日志:

CONFIG SET slowlog-max-len 

从上面这段话中,大概看出了两个属性:  slowlog-log-slower-than  和 slowlog-max-len,为了测试方便,我就不config set了,直接改掉

redis.conf文件即可。。。

# The following time is expressed in microseconds, so  is equivalent
# to one second. Note that a negative number disables the slow log, while
# a value of zero forces the logging of every command.
slowlog-log-slower-than # There is no limit to this length. Just be aware that it will consume memory.
# You can reclaim memory used by the slow log with SLOWLOG RESET.
slowlog-max-len

然后我简单测试一下,所有command都会被记录到slowlog里面去了,下图中的红色框框就是comand的执行时间。

有了这个,我现在是不是可以找到所有生产线上哪些慢的command命令呢???这样大家就不会扯皮了。。。最后我们简单看下他们的源码,从源码

中你可以看到其实slowlog是用List实现的,而我们也知道在Redis中List是用“双向链表”实现的。

15天玩转redis —— 第七篇 同事的一次缓存操作引起对慢查询的认识的更多相关文章

  1. 15天玩转redis —— 第十篇 对快照模式的深入分析

    我们知道redis是带有持久化这个能力了,那到底持久化成到哪里,持久化成啥样呢???这篇我们一起来寻求答案. 一:快照模式 或许在用Redis之初的时候,就听说过redis有两种持久化模式,第一种是S ...

  2. 15天玩转redis —— 第十一篇 让你彻底了解RDB存储结构

    接着上一篇说,这里我们来继续分析一下RDB文件存储结构,首先大家都知道RDB文件是在redis的“快照”的模式下才会产生,那么如果 我们理解了RDB文件的结构,是不是让我们对“快照”模式能做到一个心中 ...

  3. 15天玩转redis —— 第八篇 你不得不会的事务玩法

    我们都知道redis追求的是简单,快速,高效,在这种情况下也就拒绝了支持window平台,学sqlserver的时候,我们知道事务还算是个比较复杂的东西, 所以这吊毛要是照搬到redis中去,理所当然 ...

  4. 15天玩转redis —— 第六篇 有序集合类型

    今天我们说一下Redis中最后一个数据类型 “有序集合类型”,回首之前学过的几个数据结构,不知道你会不会由衷感叹,开源的世界真好,写这 些代码的好心人真的要一生平安哈,不管我们想没想的到的东西,在这个 ...

  5. 15天玩转redis —— 第五篇 集合对象类型

    这篇我们来看看Redis五大类型中的第四大类型:“集合类型”,集合类型还是蛮有意思的,第一个是因为它算是只使用key的Dictionary简易版, 这样说来的话,它就比Dictionary节省很多内存 ...

  6. 15天玩转redis —— 第四篇 哈希对象类型

    redis中的hash也是我们使用中的高频数据结构,它的构造基本上和编程语言中的HashTable,Dictionary大同小异,如果大家往后有什么逻辑需要用 Dictionary存放的话,可以根据场 ...

  7. 15天玩转redis —— 第三篇 无敌的列表类型

     据说60%的人使用redis看重的是redis中的list类型,那这个list有什么用呢???不用我说大家都明白,做队列使用呗,为什么用它呢,很简单呗, 因为有了它我就不需要专门的MQ产品啦,比如说 ...

  8. 15天玩转redis —— 第九篇 发布/订阅模式

    本系列已经过半了,这一篇我们来看看redis好玩的发布订阅模式,其实在很多的MQ产品中都存在这样的一个模式,我们常听到的一个例子 就是邮件订阅的场景,什么意思呢,也就是说100个人订阅了你的博客,如果 ...

  9. 15天玩转redis —— 第一篇 开始入手

    双十一终于还是过去了,我负责的mongodb由于做了副本集,最终还是挺过去了,同事负责的redis,还是遗憾的在早上8点左右宕机了,然后大家就是马不停 蹄的赶往公司解决问题,因为我对redis也不是很 ...

随机推荐

  1. SQL Server 性能优化之——T-SQL TVF和标量函数

    阅读导航 1. TVF(表-值行数Table-Valued Functions)         a. 创建TVF         b. 使用TVF的低性能T-SQL         c. 使用临时表 ...

  2. 7张图片学习VIM教程

    7张图片学习VIM教程 张图片设置为桌面背景,时不时的能看上一眼.慢慢就学会VIM了. VIM lesson 1 VIM lesson 2 VIM lesson 3 VIM lesson 4 VIM ...

  3. 使用oracle的大数据工具ODCH访问HDFS数据文件

    软件下载 Oracle Big Data Connectors:ODCH 下载地址: http://www.oracle.com/technetwork/bdc/big-data-connectors ...

  4. make file教程(转)

    最近在学习Linux下的C编程,买了一本叫<Linux环境下的C编程指南>读到makefile就越看越迷糊,可能是我的理解能不行. 于是google到了以下这篇文章.通俗易懂.然后把它贴出 ...

  5. EF架构~CodeFirst数据迁移与防数据库删除

    回到目录 本文介绍两个概念,防数据库自动删除,这是由于在code first模式下,当数据实体发生变化时,会对原来数据库进行删除,并将新数据表添加进来,但这对于我们的运营环境数据库,是万万不能接受的, ...

  6. Mybatis入门例子

    Mybatis是轻量级的持久化框架,的确上手非常快. Mybatis大体上的思路就是由一个总的config文件配置全局的信息,比如mysql连接信息等.然后再mapper中指定查询的sql,以及参数和 ...

  7. Atitit sql执行计划

    Atitit sql执行计划 1.1. 首先要搞明白什么叫执行计划? 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案,这个方案是由查询优化器自动分析产生的 Oracle中的执行计划 ...

  8. 1027 HTML

    body bgcolor(背景色)="#9900FF"(引号内呈现的是颜色代号,99是红色 00是绿色 FF是蓝色,所有颜色都是以这三个颜色调配) text (字体颜色)=&quo ...

  9. fir.im Weekly - 揭秘直播移动 APP 技术实现

    2016年直播似乎无处不在,作为一个开发者也许需要补充下关于直播技术点.本期 fir.im Weekly 整理了一些开发者对于直播实践项目中的技术经验与直播技术架构分析等内容,还有一些关于 iOS . ...

  10. ROC曲线与AUC值

    本文根据以下文章整理而成,链接: (1)http://blog.csdn.net/ice110956/article/details/20288239 (2)http://blog.csdn.net/ ...