Redis自我学习笔记和收藏

blovekyo

　　听说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.iyunv.com/blog/2029944
　　顺便+上自己的一段思考
　　学习了很不错

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

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

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

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

建议修改~
　　2，分布式计数器
　　淘宝秒杀100件商品
　　思路是使用incr原子操作，
　　使用获取的返回值，判断是否超过范围，如果在范围内的话就开始做业务逻辑处理，如果不在范围内的话，就可以直接返回错误页面了。高并发没办法控制精确到哪一位，这样就控制50个进入范围，在这50个按照业务规则筛选出win的用户就可以了。