听说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的用户就可以了。