Java-面试-数据库-3-Redis
Redis基础
Redis 是基于C语言开发的开源NoSQL数据库。
- 基于内存
- 时间处理模型：单线程事件循环、IO多路复用
- 多种优化后的数据结构
- 通信协议简单、解析高效
为什么
为什么不直接用Redis？因为内存成本太高且Redis的持久化有数据丢失的风险。
为什么使用Redis？ 1. 访问速度快 2. 高并发，一般4核8G的数据上能够达到4k，使用Redis之后能够达到5w+，这还只是单机，集群会更高。
缓存读写策略
旁路缓存模式 Cache Aside
适合读请求比较多的情况。
写：
- 先更新db
- 然后直接删除 cache
读：
- 从 cache中读数据，返回
- cache中读不到数据，从db中读取数据返回
- 再把数据放回到缓存里面
问题：为什么不先删除cache，然后更新db？因为如果反过来，那么先删除后读会出现数据不一致。再问：现有策略不会吗？会，但是概率小，因为cache比数据库快得多。
缺陷：
- 首次请求数据没有在cache中。解决：热点数据提前存入
- 写操作比较频繁时影响缓存命中率。分情况，是否短暂允许数据库与缓存数据不一致。
读写穿透 写直达 Read/Write Through Pattern
把 cache 作为主要数据存储。cache 服务负责将数据读取与写入db，比较少见，因为Redis 没有提供将cache 写入db 的功能。
异步缓存写入 Write Behind Pattern
Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 db 的读写。
但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 db，而 Write Behind 则是只更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db。
很明显，这种方式对数据一致性带来了更大的挑战，比如 cache 数据可能还没异步更新 db 的话，cache 服务可能就就挂掉了。
这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 Innodb Buffer Pool 机制都用到了这种策略。
Write Behind Pattern 下 db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。
应用
- 缓存
- 分布式锁
- 限流
- 消息队列 不建议
- 延时队列
- 分布式 Session
- 复杂业务场景
还有很多，主要是对上面应用场景的详细解释
Redis 数据类型
5 种基本数据类型：String、List、Set、Hash、Zset（有序集合）
3 种特殊类型：HyperLogLog（基数统计）、Bitmap（位图）、Geospatial（地理位置）
还有一些比如布隆过滤器，位域
如果是完整的对象，存储建议使用哈希，整个的读写操作多的。
如果对于部分信息需要经常变动，建议使用Hash