版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/njys1/article/details/82795882
- 常见场景
- 存储优化
- 其它
常见场景
1. 会话存储. web server负载均衡之后、可以使用redis统一进行会话存储
2. 数据统计. eg. 有多少人查看xx
3. 排行榜. 可以使用sorted set实现
4. 队列. 不支持持久化
5. 最新的N个记录. 可以使用list实现
6. 通常使用的缓存服务器
存储优化
1. 可以先做一个最基本的设计、简单的讲每个属性映射到key中
2. 可以使用减少key的方式来探测、比如 使用hash、此时注意hash-max-ziplist-entries的配置值、确保使用的是ziplist的编码方式节省内存
3. 还可以使用压缩键的值的长度来减少内存、eg. 使用cmsgpack库压缩数据
4. 压缩键的长度. eg. 使用缩写
redis本身是一个单线程的数据存储服务、在选择命令时一定要谨慎、不要获取过大的数据、导致其它命令的执行延时、键过多时、要记得scan系列的命令
其它
1. redis分布式锁
setnx来进行锁的竞争、抢到锁之后、使用expire给锁加上过期时间、防止锁忘记释放
如果在setnx之后、执行expire之前、进程意外crash掉、会产生什么样的后果 ？
set指令可以将setnx和expire合成一条指令来执行
2. redis里有1亿个key、其中10w个key是以固定的已知前缀开头、如何找出 ？
使用keys指令
但redis是单线程的、keys指令会导致线程阻塞、线上服务卡顿、直到指令执行完毕
可以使用scan、但是会有一定概率的重复、需要在客户端执行去重、整个执行时间也会比keys要多一些
3. redis做消息队列
rpush产生消息、lpop消费消息、无消息时、lpop会sleep一会儿再试
blpop在没有消息时、会阻塞、直到有消息产生
pub/sub的方式实现消息订阅、在消费者下线时消息会丢失、且不可持久化、所以如果对数据可靠性要求比较高、最好还是使用专业的消息队列、eg. activeMq等
redis实现延时队列：
使用sortedset、拿时间戳作为score、消息内容作为key调用zadd来生产消息、
消费者使用zrangebyscore来获取N秒之前的数据轮询进行处理
4. 若同一时间有大量key过期、应该注意什么
若大量key过期时间过于集中、那一时刻、redis可能会出现短暂的卡顿、一般可以在时间上加一个随机值、使得过期时间分散一点儿
5. redis持久化、
bgsave执行全量持久化、aof做增量持久化、bgsave会耗费比较长的时间、不够实时、在停机时可能会造成大量的数据丢失、需要配合aof使用
redis实例重启时、会先使用aof来恢复内存的状态、若如aof日志、则使用rdb来恢复
aof的问题是、可能文件过大、导致恢复时间过长、此时redis提供了aof重写机制来压缩aof文件的大小
redis4.0之后的版本提供了混合持久化的功能、将bgsave的全量和aof的增量做了融合处理、可以保证效率又兼顾数据安全性
突然断电？？？
取决于aof的sync属性配置
若不要求性能、可以每条指令写一次磁盘、不会丢失数据
一般会1s写1次、这样最多丢失1s之内的数据
bgsave是fork一个子进程来进行操作、子进程创建后、父子进程共享数据段、父进程继续提供读写服务、写脏的页面数据会逐渐和子进程分离
5. pipeline
可以将多次IO的时间缩减为1次、
6. 同步机制
可以使用主从或者从从同步、第一次同步、主节点做bgsave、并同时将后续修改操作记录buffer、等待完成后将rdb文件全量同步到复制节点、复制节点接收完成后将rdb文件加载到内存、
加载完成后再通知主节点将期间修改的操作同步到节点重放
7. redis集群
redis sentinal着眼于高可用、在master宕机时会自动将slave提升为master、继续提供服务
redis cluster着眼于扩展性、在单个redis内存不足时、使用cluster进行分片存储
8. redis是单线程的、会不会出现并发问题 ？
redis的单线程实现保证了单个key是不会出现并发问题的
但若应用使用了多线程处理、在使用i++等操作时、可能会出现
eg. i++操作分为单个步骤：1、val = get i；2、val=val+1；3、set i。假设 i=1，如果多个连接同时执行第一步，那么在操作执行结束时，i并不是期望的3，很有可能是2。对于这种情况单纯采用Multi，Exec无法得到期望的结果