reids类型：string、set、zset、hash、list
string:统计点赞数
set：无序，值不重复
zset：有序集合，适合做排行榜
hash：
list：队列、查看点赞列表
redis与memcached区别：reids支持更丰富的类型，memcached仅支持string，redis比memcached更快，redis支持持久化
redis解决并发请求：redis利用队列把并发访问变成串行访问，消除了传统的数据库的开销
reids6的淘汰策略：noeviction：不删除策略，达到内存限制时，如果需要更多内存，直接返回请求错误信息，大多数会新加内存，极少数会例外。
LRU算法：allkeys-lru删除最近最少使用的key，volatile-lru:只限设置exprie的部分，删除最近最少使用的key。
随机淘汰：allkeys-randm、；所有key通用，随机删除一部分key，volatile-randm：只限于设置了exprie的部分，随机删除一分部key，volatile-ttl：只限制于设置exprie的部分，有限删除剩余时间短的key
redis持久化流程:1.客户端向服务器发送写操作（数据在客户端内存中）2.数据库服务接收到服务器的写操作（数据在服务器内存中）3.服务器调用write这个调用将数据网磁盘离去写（数据在系统内存的缓存区）4.操作系统将缓存区的数据转移到磁盘控制器上（数据在磁盘缓存里）5.磁盘控制器将数据写到磁盘的物理介质中（数据真正的写到磁盘上）
RDB持久化：是把当前内存的数据集快照以二进制写入磁盘，也就是snapshot快照,默认dump.rdb,用这个文件代替上次的文件达到数据持久化的目的。
RDB的三种机制:1.save：会阻塞reids，执行save期间redis不执行其他操作，只有当RDB过程执行完成为止 ，执行完成后把旧的文件替换掉。2.bgsave：执行命令时，redis会在后台进行异步快照操作，快照同时还可以响应客户端请求（步骤：redis执行fork创建子程序，redis持久化过程有子过程完成，阻塞只发生在fork阶段）。3.自动化：在redis.conf中配置
RDB的优点：1.文件紧凑，全量备份，非常适合备份和灾难恢复。2.生成RDB文件的时候，主进程会fork一个子进程来处理所有的保存工作，主进程不需要进行任何的磁盘IO操作。3.RDB恢复大数据比AOF快
RDB的缺点：RDB快照是一个全量备份，存储的是内存二进制序列化形式，存储上非常紧凑，当快照持久化时，会开启一个子进程专门来负责快照持久化，子进程会拥有父进程的数据，当父进程被修改内存子进程反应不过来时，快照持久化期间被修改的数据不会被保存，可能丢失数据。
AOF机制：redis收到一个命令都通过write函数追加到文件中，俗称日志记录
AOF重新原理：AOF持久化带来的问题是文件越来越大，为了压缩AOF文件，redis提供了bgrewriteaof命令，将内存中的数据已命令的形式保存临时文件中，同时会fork一个子进程来重写文件。重写aof文件，并没有读取就得aof文件，而是将整个内存中的数据库内容用命令的形式重新aof文件。
AOF的三种触发机制：1.每修改同步always：每次持久化都会立即同步到磁盘，性能较差，但数据保存完好，2.每秒同步everysec：异步操作，如果一秒内有宕机，有数据会丢失。3.不同no：从不同步
AOF的优点：1.可以更好的保护数据的不丢失，一般AOF会每隔一秒通过后台线程执行一次fsync操作，最多丢失一秒数据。2.AOF没有任何磁盘寻址的开销，写入性能非常高，文件不容易破碎。3.AOF即使过大的时候，出现重写操作，也不会影响客户端的读写4.AOF日志文件的命令，通过非常可读的方式进行记录，这个特性非常适合做灾难误删除的紧急恢复。比如不小心flushall命令清楚了所有数据，只要后台rewrite还没发生，那么久拷贝AOF文件，将最后一条flushall命令给删除，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
AOF的缺点：1.对于同一个文件来说AOF通常不RDB数据快照文件大。2.AOF开启，支持的QPS写会比RDB支持的QPS写低，因为AOF一般配置成每秒fsync一次日志文件。3.AOF发生bug，就是通过AOF日志进行恢复，没有恢复一模一样的数据。
redis内存划分：1.数据：作为数据库，数据是最主要的部分，这部分占用的内存会统计在used_memory。2.进程本身运行需要的内存：代码和常量池，这部分大约有几兆，可以忽略不计，这部分不是由jemalloc分配，所以不会统计在used_memory中，AOF和RDB创建的子进程不属于redis进程，不统计在used_memory和used_memory_rss中。3.缓存内存：包括客户端缓冲区、复制积压缓冲区、AOF缓冲区，有jemalloc分配，统计在used_memory中。4.内存碎片：是redis内存分配，回收物理内存过程产生的，频繁改变数据可能导致物理内存没有释放，这部分内存不统计在used_memory中。
redis主从复制：复制是redis高可用的基础，哨兵和集群都是在复制的基础上实现的高可用，复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复，缺陷在于:恢复故障无法自动化，写操作无法负载均衡，存储能力受到单机限制
reids哨兵：在复制的基础上，哨兵实现了自动化的故障恢复，缺陷：写操作无法负载均衡，存储能力受单机限制
redis缓存被击穿处理机制：使用mutex，缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功的返回值操作（例如reids的SETNX或者memcache的add）去set一个mutex key，当返回成功时，在进行load db操作并回设缓存，否则就重试整个get缓存方法。
缓存和数据库之间的数据一致性问题：分布式环境下非常容易出现缓存和数据库之间的一致问题，如果项目对数据是强一致性，那就不要用缓存，只能采用合适的策略来降低缓存和数据库不一致性的概率，而无法保证数据的强一致性，合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存，缓存更新失败后增加重试机制，例如MQ消息队列
redis缓存雪崩问题：1.像缓存穿透一样加锁排列。2.建立备份缓存，设置A的过期时间，不设置B的过期时间，当缓存A失效的时候，读取缓存B，并且更新A的缓存和B的缓存。
redis分布式：redis支持主从模式，master会同步数据到slave，而slave不会同步master，slave启动时会连接master，同步数据，这是一个典型的读写分离没事，利用master来插入数据，slave提供检索服务，这样可以有效减少单个计算机的并发数量
redis读写分离模式：通过增加slave db数量，读的性能会成线性增加，为了避免Master db的单店故障，集群一般采用两台Master db做双机热备，是整个几群的读写性都非常高。
redis读写分离的缺点：主机从机都要不存完整的数据，如果在数据量很大的情况下，集群的扩展还是受制于单个节点的存储能力，对于write-intersive类型的应用，读写分离并不适用。
数据库分片模型：为了解决读写分离的缺陷，可以将数据分片模型应用进来可以将每个节点看成独立的master，然后通过业务进行分片，可以设计成一个master和多个slave的模式。
redis分布式锁的实现：先拿setnx来抢锁，抢到之后，再用exprie给锁加一个过期时间，防止锁忘记释放，如果在setnx执行后exprie之前进程意外crash或者重启维护了，那会怎么样？set指令有非常复杂的参数，这个应该可以同时把setnx和exprie合成一个指令来用
redis做异步队列：一般使用list做队列，lpush生产消息，lpop消费消息，当lpop没有消息的时候，要适当的sleep一下，缺点：在线下消费的时候，生产消息会丢失，得使用创业的消息队列rabbitmq等，能不能产生一次消费多次？使用pub/sub主题订阅者模式，实现1：N的消息队列。
redis中海量数据的正确方式：利用scan系列命令（SCAN、SSCAN、HCAN、ZCAN）完成数据迭代。
redis集群：Redis Sentinal着眼于高可用，在Master宕机时会自动将Slave提升为Master，继续提供服务。Redis Cluster着眼于扩展，在单个redis不够时，使用Cluster进行分片存储。
redis集群什么情况下会导致集群不可用：A、B、C三个节点集群，当B节点失败，那么整个集群会因为缺失B节点范围的槽而不可用。
redis哈希槽的概念：redis集群没有一致性hash，而是引入hash槽的概念，redis集群有16384个哈希槽，每个key通过CRC16效验后对16384取模来决定防止那个槽，集群的内个节点负责一部分槽。
redis并不能保障强一致性，这就意味着实际集群在特点环境下可能会丢失写操作。
redis事务：事务是单独的隔离操作，事务中的所有命令都会序列化、按顺序执行，事务在执行时，不会被其他客户端的请求打断，事务的原子性，事务要么全部执行，要不全部不执行。
redis如何做内存优化：尽可能使用散列表，散列表使用的内存非常少，所以尽可能的将数据抽象到三列表里。
redis回收进程机制如何工作：一个客户端运行了新的命令，添加了新的数据，redis检查内存的使用清理，如果大于maxmemory的限制，则根据设定好的策略进行回收，所以就是内存不断的达到限制边界，不断的会受到边界以内，如果一个内存导致内存被大量占用，不用多久，内存很快就会被超越。
redis如何保证都是热数据：redis内存数据集大小升到一定的大小后，就会实行数据淘汰策略。
如何查找一亿数据中的10W个key：使用keys扫描出所有指定模式的key列表，如果这个redis正在为线上提供服务，这会造成阻塞卡顿，因为redis是单线程的，keys指令会导致线程阻塞一段时间，线上服务停顿，直到指令执行完毕，服务才能恢复，scan命令可以无阻塞提取指定模式的key列表，但可能给会有重复的概率，在客户端去重一次就好，整个执行时间比keys长。
redis设置过期时间一致：如果大量的过期时间过于集中，到过期时间时redis会出现卡顿，一般在时间上加一个随机值，是过去时间分散一点。
redis连接connect和pconnect区别：connect结束后连接断开，pconnect结束后连接不断开，保持在php-fpm进程中。
redis有哪些结构时间复杂度较高的list（redis hsah实现）：哈希的实现编号可以是ziplist或者hashtable，ziplist编号的哈希对象采用压缩列表作为底层实现，每当有新的键值对要加入到hash对象的时候，程序会先将保存了键的压缩列表节点推入到压缩列表结尾，然后再将保存了值的压缩列表节点推入到压缩列表结尾，因此保存了同一键值对的两个节点总是紧挨在一起，保存的节点在前，保存值得节点在后，先添加到哈希对象的键值对会被放在压缩列表表头，后添加到哈希对象的键值对会被放在压缩列表的结尾。
https://editor.csdn.net/md?articleId=106455902
本文是个人总结，如果那里有问题请指出，谢谢