redis有⽤Sorted-Set应⽤场景
1.1.1Set数据类型的使⽤场景
1、可以使⽤Redis的Set数据类型跟踪⼀些唯⼀性数据，⽐如访问某⼀博客的唯⼀IP地址信息。对于此场景，我们仅需在每次访问该博客时将访问者的IP存⼊Redis中，Set数据类型会⾃动保证IP地址的唯⼀性。
2、充分利⽤Set类型的服务端聚合操作⽅便、⾼效的特性，可以⽤于维护数据对象之间的关联关系。⽐如所有购买某⼀电⼦设备的客
户ID被存储在⼀个指定的Set中，⽽购买另外⼀种电⼦产品的客户ID被存储在另外⼀个Set中，如果此时我们想获取有哪些客户同时购买了这两种商品时，Set的intersections交集命令就可以充分发挥它的⽅便和效率的优势了。
1.1 存储sortedset
1.1.1 概述
Sorted-Set和Set类型极为相似，它们都是字符串的集合，都不允许重复的成员出现在⼀个Set中。它们
之间的主要差别是Sorted-Set中的每⼀个成员都会有⼀个分数(score)与之关联，Redis正是通过分数来为集合中的成员进⾏从⼩到⼤的排序。然⽽需要额外指出的是，尽
管Sorted-Set中的成员必须是唯⼀的，但是分数(score)却是可以重复的。
在Sorted-Set中添加、删除或更新⼀个成员都是⾮常快速的操作，其时间复杂度为集合中成员数量的对数。由于Sorted-Set中的成员在集合中的位置是有序的，因此，即便是访问位于集合中部的成员也仍然是⾮常⾼效的。事实上，Redis所具有的这⼀特征在很多其它类型的数据库中是很难实现的，换句话说，在该点上要想达到和Redis同样的⾼效，在其它数据库中进⾏建模是⾮常困难的。
例如：游戏排名、微博热点话题等使⽤场景。
1.1.1 扩展命令（了解）
l zrangebyscore key min max [withscores] [limit offset count]：返回分数在[min,max]的成员并按照分数从低到⾼排序。[withscores]：显⽰分数；[limit offset count]：offset，表明从脚标为offset的元素开始并返回count个成员。  分页排名
l zincrby key increment member：设置指定成员的增加的分数。返回值是更改后的分数。
l zcount key min max：获取分数在[min,max]之间的成员
l zrank key member：返回成员在集合中的排名。（从⼩到⼤）
l zrevrank key member：返回成员在集合中的排名。（从⼤到⼩）
1.1.1 使⽤场景
1、可以⽤于⼀个⼤型在线游戏的积分排⾏榜。每当玩家的分数发⽣变化时，可以执⾏ZADD命令更新玩家的分数，此后再通过ZRANGE命令获取积分TOPTEN的⽤户信息。当然我们也可以利⽤ZRANK命令通过username来获取玩家的排⾏信息。最后我们将组合使
⽤ZRANGE和ZRANK命令快速的获取和某个玩家积分相近的其他⽤户的信息。
2、Sorted-Set类型还可⽤于构建索引数据。
消息订阅与发布
1.1 消息
l subscribe channel：订阅频道，例：subscribe mychat，订阅mychat这个频道
l psubscribe channel*：批量订阅频道，例：psubscribe s*，订阅以”s”开头的频道
l publish channel content：在指定的频道中发布消息，如 publish mychat ‘today is a newday’l 步骤1：在第⼀个连接中，订阅mychat频道。此时如果没有⼈“发布”消息，当前窗⼝处于等待状态。
l 步骤2：在另⼀个窗⼝中，在mychat频道中，发布消息。
l 步骤3：再第三个窗⼝，批量订阅以my开头所有频道。
l 步骤4：在第⼆个窗⼝，分别在“mychat”和“mychat2”发布消息
特征
redis支持的数据结构
1.1.1 redis事务特征
1、 在事务中的所有命令都将会被串⾏化的顺序执⾏，事务执⾏期间，Redis不会再为其它客户端的请求提供任何服务，从⽽保证了事物中的所有命令被原⼦的执⾏
2、 和关系型数据库中的事务相⽐，在Redis事务中如果有某⼀条命令执⾏失败，其后的命令仍然会被继续执⾏。
3、 我们可以通过MULTI命令开启⼀个事务，有关系型数据库开发经验的⼈可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执⾏的命令都将被视为事务之内的操作，最后我们可以通过执⾏EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
4、 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致⽹络断开，其后所有待执⾏的语句都将不会被服务器执⾏。然⽽如果⽹络中断事件是发⽣在客户端执⾏EXEC命令之后，那么该事务中的所有命令都会被服务器执⾏。
1.1.1 优势
1、 该机制可以带来更⾼的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、
每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是⾮常⾼的，所差的是⼀旦系统出现宕机现象，那么这⼀秒钟之内修改的数据将会丢失。⽽每修改同步，我们可以将其视为同步持久化，即每次发⽣的数据变化都会被⽴即记录到磁盘中。可以预见，这种⽅式在效率上是最低的。⾄于⽆同步，⽆需多⾔，我想⼤家都能正确的理解它。
2、 由于该机制对⽇志⽂件的写⼊操作采⽤的是append模式，因此在写⼊过程中即使出现宕机现象，也不会破坏⽇志⽂件中已经存在的内容。然⽽如果我们本次操作只是写⼊了⼀半数据就出现了系统崩溃问题，不⽤担⼼，在Redis下⼀次启动之前，我们可以通过redis-check-aof⼯具来帮助我们解决数据⼀致性的问题。
3、 如果⽇志过⼤，Redis可以⾃动启⽤rewrite机制。即Redis以append模式不断的将修改数据写⼊到⽼的磁盘⽂件中，同时Redis还会创建⼀个新的⽂件⽤于记录此期间有哪些修改命令被执⾏。因此在进⾏rewrite切换时可以更好的保证数据安全性。
4、 AOF包含⼀个格式清晰、易于理解的⽇志⽂件⽤于记录所有的修改操作。事实上，我们也可以通过该⽂件完成数据的重建。
1.1.2 劣势
1、 对于相同数量的数据集⽽⾔，AOF⽂件通常要⼤于RDB⽂件
2、 根据同步策略的不同，AOF在运⾏效率上往往会慢于RDB。总之，每秒同步策略的效率是⽐较⾼的，同步禁⽤策略的效率和RDB⼀样⾼效。
第1章 redis使⽤场景（了解）
1、 取最新N个数据的操作

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。