redis可以满足很多的应用场景，而且因为将所有数据都放到内存中，所以它的读写性能很好，很多公司都在使用redis。redis给我们带来便利的同时，使用过程中会存在什么问题呢，本文将简单加以总结。
阻塞问题
redis使用了单线程来处理请求，为什么单线程可以支持如此高的并发呢？主要有如下几点：- 纯内存访问：将所有数据都放到内存中,内存响应时间为100纳秒，是redis达到每秒万级别访问的重要基础
- 非阻塞IO：redis使用epoll作为I/O多路复用技术，redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多时间
单线程：避免了线程切换和竞态产生的消耗，简化了数据结构和算法的实现
因此如果某个命令执行时间过长，会造成其他命令阻塞，对redis来说是致命的产生阻塞的场景： A. API或数据结构使用不合理 a. 避免使用某些易造成阻塞的命令如：keys sort hgetall smembers 执行showlog get [n] 可以获取最近n条执行慢的记录，对于执行超过一定时间 (默认10ms，线上建议设置为1ms)的命令都会记录到一个定长队列(默认128，可调整)中。 b. 防止一次操作获取过多数据：缩减大对象或者把大对象拆分为多个小对象 发现大对象的命令：redis-cli -h{ip} -p{port} bigkeys 内部原理：采用分段进行scan操作，把历史扫描过的大对象统计出来 c. 防止大量key同时过期：如果有很多key在同一秒内过期，超过了所有key的25%，redis主线程就会阻塞直到过期key比例下降到25%以内， 因此要避免同一时间过期大量key，过期时间可做散列处理。 redis4.0引入的lazyfree机制可以避免del、flushdb、flushall、rename等命令引起的redis-server阻塞，提高服务稳定性。 B. CPU饱和 单线程的redis处理命令时只能使用一个CPU，CPU饱和是指redis把单核的CPU使用率跑到接近100%。 首先要确定redis的并发量是否达到极限，通过redis-cli-h{ip} -p{port}--stat 获取redis当前使用情况。 如果达到每秒6w+左右的qps，说明单台已跑到极限，需要水平扩展。 如果qps只有几百或者几千CPU就已经饱和，可能使用了高算法复杂度的命令或者是对内存的过度优化 (如放宽了ziplist的使用条件，虽然使用的内存会变少，但是更耗CPU)。 C. 持久化操作 持久化引起主线程的阻塞操作主要有：fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞 a. fork阻塞 发生在RDB和AOF重写时，redis主线程调用fork操作产生共享内存的子线程，由子线程完成持久化文件的重写工作，若fork操作耗时过长会引起阻塞。 避免使用内存过大的实例。 b. AOF刷盘阻塞 开启AOF持久化功能时，一般会采用1次/s的刷盘方式，后台线程每秒对AOF文件做fsync操作，当硬盘压力过大时fsync操作需要等待直到写入完成。 如果主线程距离上一次的fsync成功超过2s，为了数据安全会阻塞直到后台线程执行完fsync完成。这种阻塞是由于磁盘压力引起。 尽量独立部署 c. HugePage写操作阻塞 子进程在执行重写期间利用linux的copyonwrite机制，会拖慢写操作的执行时间，导致大量写操作慢查询。 优化linux配置
缓存穿透
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不命中，且不将空结果写到缓存中。
会导致后端存储负载变大，造成后端存储宕机等问题。可以在程序中分别统计总调用数、缓存命中数、存储命中数，若有大量存储层空命中，可能是出现了缓存穿透。
产生原因：1.自身代码或数据出现问题 2.恶意攻击，爬虫造成空命中
如何解决：- 缓存空对象
存储层不命中，扔将空对象保存到缓存层。
适用场景：数据频繁变化、实时性高
带来问题：
a.缓存了空值，会占用内存空间；可以设置较短过期时间，自动剔除。
b.数据不一致，若存储层添加了此数据，有短暂不一致；可主动清除掉缓存的空对象。 - 布隆过滤器
在访问缓存层和数据层之前将存在的key用布隆过滤器提前保存起来，做第一层拦截。
适用场景：大用户集，实时性要求较低的场景，如有几亿的数据集，每隔一段时间会新增用户进去，在更新之前新用户的访问会存在缓存穿透问题。
缺点：代码维护复杂
- 缓存空对象
