Silence-wen

java基于Redis Zset实现排行榜功能前言做之前要思考的问题？Zset怎么存储需要的多个字段？话不多说先上效果图数据存储格式核心代码源码下载闲暇之余，整理了一下之前利用Redis Zset数据类型实现的排行榜功能。前言排行榜功能之所以选用redis是因为，参加的用户数据量较大，有将近20万人，如果前100名排行从数据库中查的话也不是不可以，但相对于redis来说，还是不够看的，所以当时就把排行榜的功能做在了redis里。做之前要思考的问题？Redis数据类型那么多，到底用哪个数据类型呢？

Redis缓存穿透和缓存雪崩什么是缓存穿透？当用户想要查找一个数据的时候，发现在Redis中没有查询到（没有命中缓存），于是就会向持久层数据库去查询数据。结果在持久层也没有查询到该数据。当很多用户都查询数据的时候，由于在Redis缓存中不存在该数据，所以都指向了持久层数据库去查询，这就给持久层数据库造成了非常大的压力，这种情况我们就叫做缓存穿透。（是指在缓存和数据库中都查询不到）注意：区别于缓存击穿。缓存击穿是指一个热点key，大并发集中对这个key进行访问，当这个key在失效的瞬间，仍然有大批量

Redis哨兵模式(Sentinel)以及场景实践根据我们上篇中所用到的模型是一个Master两个Salve节点，那么当Master宕机时，两个从节点是无法进行写操作的，那势必会影响我们程序的正常使用，有没有什么办法可以在Master宕机时能有一个Salve节点变成Master继续提供写操作呢？答案是肯定的，我们的哨兵就是为解决这个问题而生的！什么是哨兵模式？在Redis2.8版本以前，当Master节点出现宕机情况时，我们是手动配置从Salve节点变为Master节点（或者恢复Master节点的服务

Redis主从复制的配置并进行场景测试为什么要使用主从复制？Redis虽然读写的速度相对于传统的关系型数据库较快，但是也会出现读取压力比较大的情况，为了避免出现这种情况的发生，以免给用户造成不好的体验，这时候就要考虑Redis的主从复制了。所谓主从复制，就是一个master下有多个slave节点。用户对于数据的操作，都是读远远大于写的，所以我们只在master节点下进行写的操作，而读就交给slave节点，这样就很好的分摊压力，保证Redis的读写性能。在Redis中，数据的复制都是单向的，只能从Mas

Redis持久化RDB和AOF为什么Redis需要持久化？因为Redis属于内存型数据库，数据是储存在内存当中的，当遇到不可抗力因素，比如断电，那么储存在内存中的数据就会丢失。所以为了保证数据的完整性，我们需要做持久化操作，来保证数据的完整性。Redis中都有哪些持久化机制？Redis早就考虑到了这一点，所以在Redis中，为我们准备了两种持久化的机制，RDB和AOF。既然Redis为我们提供了两种持久化的机制，那我们到底该选用哪个呢？其实啊，在Redis配置文件中RDB这种机制是默认开启的，而A

再此之前可以复习一下一些Redis的基本命令：Redis八大类型常用命令大全（五大常用类型+三个特殊类型）：https://blog.youkuaiyun.com/nxw_tsp/article/details/107897580Redis事务常用命令以及通过watch命令实现乐观锁示例：https://blog.youkuaiyun.com/nxw_tsp/article/details/107922864Redis配置文件中配置信息详解：在实际工作当中，使用redis的默认配置是远远不够的，我们需要做一些配置来应对我

事务：Redis的单条命令是支持事务的，但是事务不保证原子性。Redis没有隔离级别的概念，所有的命令在事务中并没有直接去执行，只有发起执行命令的时候才执行。Redis事务：开启事务（multi）命令入队（…）执行事务（exec）**Redis事务特点：**一致性，顺序性，排他性。执行事务命令：127.0.0.1:6379> multi #开启事务OK127.0.0.1:6379> set myset v1 #命令入队QUEUED127.0

绝对手敲验证完成的一篇博客，多敲几遍才能记得牢！String类型：**应用场景：**缓存、分布式ID、分布式锁、计数器举例说明：实现分布式ID功能，通过incr自动增长或者incrby实现固定步长增长常用命令： * 清空数据库：flushdb * 清空全部数据库：flushall * 当前数据库的使用大小：dbsize * 查看当前数据库有多少key：keys * * 切换数据库：select 0 -- redis默认有16个数据库，select 0 就是切换到0数据库 *