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