Redis自我学习笔记和收藏

听说Redis已经很长时间，大多数时候都是按照memcache的缓存的方式使用它。

 

但是听说几种场景用redis实现比较好。

目前需要掌握的场景：

1，分布式锁（比如核心资源的竞争和分布式的同步）

2，分布式计数器（比如秒杀）

 

写一个学习笔记，持续更新学习状况

 

redis最经典的应该就是所谓的原子性了，因为原子性所以可以实现上述的功能。

 

基础内容

按照redis官网和redis中文网的文档挨个学习。

http://www.redis.cn/

http://redis.io/

试验了redis的命令行客户端的操作和相关命令。

命令列表网址为：http://redis.io/commands

 

学习使用了15分钟教程和系统介绍 ，熟悉了Redis的几种数据结构。

1，list

2，set

3，排序的set

4，hash(还需要继续学习)

以及几种简单的模式

1，订阅和发布。简单理解就是消息队列

2，超时

3，事务队列

对持久化、分布式、主从复制的功能研究还有待继续。

但是听说持久化会stop world，本身不支持分布式（必需通过其他组件来支持分布式的分发和一致性哈希），主从复制的时候会清空slave的数据（不支持增量数据）。

把听说的几篇文章贴下，省的以为我黑它……

 

分布式方案文章：

http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html

http://www.oschina.net/translate/utopian-redis-cluster

 

 

主从复制

http://www.cnblogs.com/zhoujinyi/archive/2013/05/27/3098447.html

(这个学习笔记不错)

 

 

 

 

 

关于场景使用

http://blog.nosqlfan.com/html/2235.html

http://www.tuicool.com/articles/zeYfyq

1，分布式锁

推荐

http://www.jeffkit.info/2011/07/1000/

http://phl.iteye.com/blog/2029944

顺便+上自己的一段思考

学习了很不错

因为JAVA的实现和伪代码的实现有所不同，所以仔细对比了一下
伪代码是通过  当前时间  和  getset返回的库里面的时间对比  判断谁应该拿到锁。
JAVA实现是通过 对比两次get 和 getset的返回值的不同，来判断谁应该拿到锁。

两种实现在大多数情况都不会出问题，但是也有失败的情况
1，伪代码失效的情况是 设置超时时间和get的网络开销不相上下的时候。这样容易让一行三次获取数据最后导致成功，很容易让锁失效，替代前一个锁，不过这不算问题，因为设置过小的锁超时时间本身就是程序bug，而且就算这种情况也可以保证每个获取锁的节点依次的进入锁。

2，JAVA实现的失效的情况是，两台完全同步的机器，每步代码执行的速度都一样，有可能让多个节点同时拿到锁。

个人比较赞同伪代码中的实现。
原因是伪代码 如果超时时间设置合理的话，后续的节点最多会把超时时间延迟个几个毫秒，但是后续的节点都不会拿到锁。

建议修改~

 

2，分布式计数器

 

淘宝秒杀100件商品

思路是使用incr原子操作，

使用获取的返回值，判断是否超过范围，如果在范围内的话就开始做业务逻辑处理，如果不在范围内的话，就可以直接返回错误页面了。高并发没办法控制精确到哪一位，这样就控制50个进入范围，在这50个按照业务规则筛选出win的用户就可以了。