Redis知识点

数据存入磁盘的简要步骤
1. 客户端发送数据给到服务器（数据在客户端的内存中）
2. 服务器中的数据库接收到请求（可以对应这里的redis），（此时数据在服务端的内存中）
3. 数据库调用操作系统的api，将数据写到磁盘（数据在内核缓冲区）
4. 操作系统将写缓冲区传输到磁盘控制器（数据在磁盘缓冲区）
5. 操作系统的磁盘控制器将数据写入实际的物理媒介中
注意点
1. 上述第四步写到磁盘缓冲区：把数据写入磁盘，是系统来操作硬件，我们是无法直接操作硬件的，那么为了防止过慢的IO操作拖慢整个系统的运行，操作系统不会将写操作立即写入磁盘，而是先到一个磁盘缓冲区，然后每隔30秒，进行实际的提交写入
2. 对于redis而言，肯定是承受不了30s的，所以PROSIX API提供了fsync，该命令会强制内核将缓冲区写入磁盘，但是这是一个非常耗性能的操作，每次调用都会阻塞等待直到报告设备IO完成，所以redis中一般是每秒执行下fsync命令
常见问题
1. redis使用的是非阻塞的io多路复用机制，那具体是怎样的呢？
2. redis快照：在某个时间点，将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，可恢复数据，快照优缺点
  1. 只有一个dump.rdb,恢复操作简单，容灾性好
  2. fork子进程进行写操作，主进程继续处理命令，性能高
  3. 大数据集比aof的恢复效率高
  4. 缺点：数据安全性低，rdb是每隔一段时间进行持久化，在中间这段时间redis发生故障了，那么数据就丢失了
3. aof:将增删改的命令保存在aof文件中，恢复数据时，把aof中的命令重新执行一遍，优缺点：
  1. 数据安全，aof持久化配置appendfsync属性为always，就可以同步每一个改动redis的命令到aof文件中，通过append模式写文件，如果中redis挂了，那么可以通过redis-check-aof工具恢复数据
  2. 缺点就是如果时时刻刻同步的话，那么aof的文件比较大，恢复速度慢

分布式锁

实现思路及问题

为什么需要分布式锁
1. 在单个服务中面对的是多线程并发，如果某些资源（比如商品库存）需要保证数据的安全性，那么可以通过synchronized来实现加锁，保证资源的安全
2. 如果是分布式集群项目，比如有多个下单服务是个集群，那么多个服务器操作库存就不是多线程并发，而是多进程并发，synchronized就不起作用了
思路
1. redis中setnx（mykey，value）命令，只有redis中mykey不存在时，才会设置成功，这就为我们做分布式锁提供了可能性
2. 假设我们集群项目的每个服务都是用的同一个单体redis，那么通过setnx这个命令如果可以拿到值，就证明当前的这个服务拿到锁了，可以操作资源了，此时其他的服务设置setnx是无法成功的，而我们当前的服务执行完任务后删除setnx（mykey，value）中的mykey，也就达到释放锁的目的了，可以供其他服务使用了
问题及解决思路
1. 服务a获得锁后挂掉了，那么该锁不会显示删除，资源就永远不会释放了；解决思路：设置一个过期时间，即使a服务挂掉了，到了设置的过期时间，redis会自己把mykey删除
2. 给锁设置了超时时间（比如为10秒），但是服务中执行任务需要很长的时间（比如15秒），那么过了10秒，服务a中还没有主动显示的释放锁，但是redis的过期时间到了，主动把mykey删除了，此时假设服务b获得了锁，当到15秒后，服务a显示的去释放锁，那释放的就是服务b的锁了，而不是自己的；解决思路：setnx（mykey，value）中的value设置的时候用一个全局唯一的值，当任务执行完成后，拿本地的value和redis中对应mykey的value做对比，如果一致就证明是自己的锁，可以释放，否则不能释放
3. 上述2中判断锁，释放锁不是原子性操作，不能保证准确性，所以要用Lua脚本来实现（Lua脚本是原子性的）
4. 综上可以看出redis做分布式锁是不适合执行很长时间的任务的，假如我的过期时间是10秒，但是任务执行要15秒，就无法保证任务数据的安全性，我们也不知道该如何设置我们的过期时间，因为无法知道任务执行到底需要多久；解决思路：就是让获得锁的线程（准确来讲应该是某个服务的某个线程）开启一个守护线程，当任务还没执行完，但是过期时间到了第9秒的时候，守护线程用expire指令延长下过期时间，保证任务的顺利执行，当任务执行完后显示的释放锁
5. 同时在执行任务的过程中我们还可以使用try finally，一旦我们的任务挂掉了，就可以马上释放锁，不一定非得等到过期时间来释放

常见问题

Redis如何做内存优化
1. 缩减键值对象：满足业务要求下key越短越好；value值进行适当压缩
2. 尽可能使用hash散列表
3. 编码优化，控制编码类型
4. 控制key的数量
5. 共享对象池：redis内部维护了[0~9999]的整数对象池，开发中在满足需求的前提下，尽量使用整数对象以节省内存，比如set age 29后执行object refcount age 时得到值2，然后在执行set age1 29后执行object refcount ag1 时得到值3，如果设置set age2 20那么执行object refcount age2还是得到值2，就是当你的key值不一样，但是value都为相同的整数时，refcount的计数就加一，value不相同时不会加，value相同时，此时不同的key就会共享这个对象，对应的value值的应用计数就加1
Redis 的默认回收策略是 noenviction，当内存用完之后，写数据会报错。
单个redis实例能存放多少个key:官方理论是2的32次方个，实际使用中单个redis实例最多存储2.5亿个key
如何保证redis中存储的都是热点数据：当redis存储在内存的中的数据达到配置大小时，就进行数据淘汰，使用allkeys-lru策略,从所有的数据中删除最近最少使用的
redis中如何找出已知前缀的key：可以使用keys指令，但是如果在线上使用，keys指令会导致线程阻塞，直到执行结束，可以使用scan指令，非阻塞的提取key列表，但是会有一定的重复率需要在客户端做一次去重，整体耗时比直接使用keys指令长；scan提供3个参数：第一个是 cursor 整数值，第二个是 key 的正则模式，第三个是遍历的 limit hint，例如：scan 0 match key99* count 1000 解释：从0开始遍历，匹配key99*，总数是1000 ，1000不是结果数量，是redis单次遍历字典槽位数量(约等于）
大量的key同一时间过期有什么问题：大量key同一时间过期，redis可能会出现短暂的卡顿现象，如果访问量过大时还可能出现雪崩，所以可以在过期时间上加一个随机值，分散过期时间点
redis如何实现消息一次产生，多次消费：利用pub/sub发布订阅模式，我们可以订阅多个主题的消息，也可以给多个主题发布消息，如果一个主题（频道）被多个客户端订阅，那么就可以一次生产多次消费了
redis如何实现消息延迟：利用zset存储，zadd添加消息时，用时间戳作为score，消息内容作为key,zrangbysocre指令获取指定区间的元素，调整指定区间的参数（比如0到最近七天）就可以实现消息延迟