jeffrey11223的博客

同事在初始化redis配置的时候，给Dial函数赋值时用了闭包，导致程序上线后，数据怎么都加载不到redis中去，排查了半个多小时，总算找到了罪魁祸首。虽然自己之前对闭包也算了解，但是看到他的那段代码的时候，乍一看竟也没发现出问题来，所以决定写篇文章加深印象，避免自己以后也犯类似的问题。         先上代码：func InitRedis() error { GRedis = make

Key（键） DEL 删除给定的一个或多个key，DEL name ，DEL name type website DUMP DUMP KEY，序列化给定 key ，并返回被序列化的值，使用 RESTORE 命令可以将这个值反序列化为 Redis 键 EXISTS 检查给定 key 是否存在。若 key 存在，返回 1 ，否则返回 0 。redis> EXISTS

redis作为提升web服务端数据交互能力的重要利器，其本身也有开销，为了让redis变得更快，有必要对和redis交互的地方进行性能优化。 今天说一下golang中比较著名的一个redis库—-redigo。它的conn.Do()、Send()、Flush()、Receive()的合理使用是很有必要的。 先上一个我本地测试的例子：func main(){ _=InitRedis(10,"

比较常用的缓存策略，同样这也是facebook的缓存策略： 1. 读：应用程序从cache中取数据，取到后返回。 2. 读：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 3. 增删改：先把数据存到数据库中，成功后，再让缓存失效。 这里针对第3点，会有一些其他的用法，乍一看都是很正常的，但后来细细一想其实都是有问题的。 比如（1）“先更新redis，然后更

本文转自：http://blog.youkuaiyun.com/qq_27623337/article/details/53201202众所周知，当redis中key数量越大，keys 命令执行越慢，而且最重要的会阻塞服务器，对单线程的redis来说，简直是灾难，终于找到了替代命令scan。SCAN cursor [MATCH pattern] [COUNT count] SCAN 命令及其相关的 SSCAN

今天无意中搜到了一个redis的操作，算是把redis指令发挥到了极致了。要解决的问题：用户签到，一天只能签到一次。由于redis开启了主从模式，写走主库，读走从库，如果用普通的set和get指令，万一面对高并发情况，刚刚在主库set完，还没到同步到从库的时候，去从库get，得到的还是未签到的状态，导致可能会重复签到多次。然后骚操作开始：利用 INCRBY key increment

redis是一个基于内存的kv数据库，其吞吐性能可想而知，随着redis应用得越来越广泛，以及对它的依赖程度越来越高，它的高可用便成了需要考虑的一个很重要的点。于是今天在自己电脑上实践了一下redis的主从模式和哨兵监控。基本架构：一主二从，加一哨兵先为master和slave编辑配置文件： 为它们配置ip和端口，这里6379是master，6380和6381为slave...