1、redis 执行流程
1.1、redis为什么这么快
1.2、redis线程模型(什么时候使用多线程)
2、redis持久化
2.1、redis datebase(rdb)
2.2、AOF Append Only File
2.3、混合持久化
3、数据类型
3.1、字符串(str): simple dynamic Strings，内部还是一个char数组，只不过支持动态扩容，我感觉可以理解成StringBuilder
3.2、列表(list)
3.3、哈希(hash)
3.4、set
3.5、order set
>字符串:可以理解为字符串本身就是一个特殊的数据对象 (包含了真实数据的一个容器. 容器本身就是一个数据结构了). 其中内置的属性调用可以以O(1)的复杂度返回.
其次，字符串本身又是其他数据类型的基石，一个足够灵活/安全的字符串对象在后期支撑更多的数据结构的时候都非常舒服。
操作函数:
1、get k
2、set k v [ex 100、px 10000]
3、ttl
4、setnx k v
>哈希: 同比Java中的HashMap,pyhon中的字典. 一个典型的数据容器，一般的实现都是基于数组+链表实现的.
操作函数
1、hget hashObj key
2、hset hashObj key value
3、hsetnx hashObj key value
1、hash冲突，链式冲突法，如果数据量变大，那么就需要添加数组来减少hash冲突. 分散进行散列
2、如何进行rehash(redis中的渐进式hash): 同时保留2个hash表，然后逐渐迁移数据，最终一个hash表的数据清空

  1.     我好像没有使用这个场景，一般情况下我们都是使用字符串的。 直接使用hash来进行存储的场景比较少。<br />    >列表: 同步Java中的LinkedList. 新增和删除是o(1), 遍历是o(n), 按照插入顺序存储，没有权重顺序排列。<br />        1、数据结构<br />            1.1、3.2以后是quicklist(双向列表)<br />            1.2、3.2以前是压缩列表和双向列表组成<br />    >集合: 同比Java中的Set，对比列表，他是无序的，且不支持重复元素，集合类型支持集合之间的交集 && 错集 && 并集<br />    >有序集合: 对比集合，额外增加了一个score，利用score即可完成这个排序的过程，redission的公平锁就利用了redis的有序集合. 使用当前系统的时间戳作为score进行排列，使用跳跃表进行实现的。<br />4、redis删除策略<br />    4.1、定时删除: 每次到时候都删除一点，触发过期时间。<br />    4.2、惰性删除: 等get到的时候，发现过期了就删除了。<br />    4.3、定期删除: 过期字典取出20个，过期的干掉，如果干掉的超过25%，再来一次。<br />5、内存淘汰策略: 当超过redis设定的最大内存触发，怎么清理数据，如果自己去写内存的也需要设计这里(例如最大只有1000个，如果超过1000个也需要数据淘汰)<br />    5.1、noeviction：不淘汰任何数据，当内存不足时，新增操作会报错，Redis 默认内存淘汰策略；<br />    5.2、allkeys-lru：淘汰整个键值中最久未使用的键值；<br />    5.3、allkeys-random：随机淘汰任意键值;<br />    5.4、volatile-random：随机淘汰设置了过期时间的任意键值；<br />    5.6、volatile-ttl：优先淘汰更早过期的键值。<br />    5.7、volatile-lfu：淘汰所有设置了过期时间的键值中，最少使用的键值；<br />    5.8、allkeys-lfu：淘汰整个键值中最少使用的键值<br />    算法: LRU + LFU<br />        LRU 全称是 Least Recently Used 译为最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。<br />        LFU 全称是 Least Frequently Used 翻译为最不常用的，最不常用的算法是根据总访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。<br />6、主从同步<br />7、哨兵、集群: 基于主从同步的哨兵和集群<br />8、缓存存在的问题<br />8.1、缓存失效: key随机失效时间<br />8.2、缓存穿透: key没有数据，一直整DB，
  • 设置过期时间短的无效数据.
  • 布隆过滤器，数据量太大则无法则不好处理

8.3、缓存雪崩: A蹦了，然后引发了B蹦了，降级关系搞好
8.4、数据不一致(缓存操作出问题了，缓存机器上下线引发了问题)

  • 缓存更新
    • 多次重试
    • 队列重试
  • 降低缓存时间，趁早国

8.5、缓存失效并发竞争

  • 全局锁
  • 缓存备份(多份缓存)

8.6、热key(高QPS的请求导致网卡打爆，带宽打满，CPU极限的问题)

  • 如何预防热key的出现
  • 如何拆分热key
    • 热key后缀拆分到多台机器
    • 多级缓存(JVM缓存)

8.7、大key(高QPS的请求导致网卡打爆，带宽打满，CPU极限的问题)

  • 数据是否是必须的，是否可以减少
  • 压缩数据
  • 拆分大key

其他

  1. redis的hash结构跟java的什么区别
    2.扩容的时候各自的流程
    3.各自的长度/容量的限制
    4.各自的冲突解决方法
    5.让你实现一个简单的hashmap
    6.hash函数/hashcode如何计算的？

redis真的的有被问到过rehash过程中，来了命令后如何处理。
再扩展一下：
1.redis的rehash的方案的优点。
2.为什么要这样做
3.如果用java的思路会有什么问题。