redis学习-经典使用场景分析-有图有真相

          提起redis，大家立马联想到缓存，是的，redis作用就是缓存，降低频繁查找数据库的IO操作，提升查询响应速度；接下来根据redis的五大数据类型，分别聊一下在实际工作场景中的应用：

          一、计数器：  

set  count 0  

incr count   //自动累加

         二、id生成器：

set   student   学生

127.0.0.1:6379> incr student:id:generate

(integer) 1

三、排行榜：

1、初始化一批数据
   zadd zstu 2   jerry
   zadd zstu 1   tony
   zadd zstu 5   jason
   zadd zstu 4   lili
   zadd zstu 20  jim
   zadd zstu 15  herry


2、查询排行数据：
 127.0.0.1:6379> zrange zstu 0 -1 withscores
 1) "tony"
 2) "1"
 3) "jerry"
 4) "2"
 5) "lili"
 6) "4"
 7) "jason"
 8) "5"
 9) "herry"
10) "15"
11) "jim"
12) "20"


3、更新某个排行信息：
//如果member存在，则直接更新score；如果不存在，则直接插入
127.0.0.1:6379> zadd zstu 21 tony
(integer) 0
127.0.0.1:6379> zrange zstu 0 -1 withscores
 1) "jerry"
 2) "2"
 3) "lili"
 4) "4"
 5) "jason"
 6) "5"
 7) "herry"
 8) "15"
 9) "jim"
10) "20"
11) "tony"
12) "21"




   

四、栈：

//栈的特征：先进后出

lpush  lpop

五、消息队列：

//队列的特征：先进先出

  lpush rpop


调优：在实际使用中，如果rpop消费队列中数据时，如果队列数据为空，需要通过休眠，频繁的检查是否有消息过来；也可以通过休眠来减少频繁检查的次数，但是会导致消费不及时。


这种情况下，我们引入brpop,当队列数据为空时，会阻塞；直到有消费到消息。

六、分布式锁：

      

七、分布式会话：

      通过hash解决分布式session共享问题；

八、社交网络：

        点赞、关注/被关注、共同好友

九、发布订阅：

      跟AMQ，kafka的发布订阅模式不同，

//订阅者一
127.0.0.1:6379> subscribe  author 
1) "message"
2) "author"
3) "new#message"

//订阅者二
127.0.0.1:6379> subscribe  author
1) "message"
2) "author"
3) "new#message"


//发布者：
127.0.0.1:6379> publish  author new#message
(integer) 2 //订阅数量

  注：redis、AMQ、kafka实现发布订阅的差异：

从数据可靠性分析：

1）redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。

2）redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是又太弱智，也并非完全可靠不会丢。

3）redis 发布订阅除了表示不同的 topic 外，并不支持分组，比如kafka中发布一个东西，多个订阅者可以分组，同一个组里只有一个订阅者会收到该消息，这样可以用作负载均衡。

比如，kafka 中发布：topic = "发布文章" data="文章1" 这个消息，后面有30台服务器每台服务器都是一个订阅者，都订阅了这个 topic，但是他们可能分为三组，A组10台，用来真的做发布文章，A组10台里所有 subscriber 都订阅了这个topic。

由于在同一组，这条消息 （topic="发布文章", data="文章1"）只会被A组里面一台当前空闲的机器收到。而B组5台服务器用于统计，C组5服务器用于存档备份，每组只有一台会收到。

用不同的组来决定每条消息要抄送出多少分去，用同组内哪些订阅者忙，哪些订阅者空闲来决定消息会被分到哪台服务器去处理，生产者消费者模型嘛

 

未完，待补充