针对网上Redis常见问题的思考
实际情况中 面试者不会这么提问。
如有错误 欢迎私信交流
1.redis为什么是key，value的，为什么不是支持SQL的？
Redis 本身设计思想就是 key-value
底层数据结构，数据持久化只是支持 key-value
Redis 本身方向是共享内存数据，SQL 语句更多是查找硬盘的数据。
个人理解：
Redis是这个名字本就是是Remote Dictionary Server的缩写。
Redis的作者是antirez，最早创建Redis的目的就是用作缓存，加速他的一个实时网页日志分析器项目的启动速度，因为他发现从传统数据库里加载大量数据太慢了。
Redis的原型使用Tcl实现，后来使用C语言重写，第一个实现的数据结构是List。后来在内部试用中发现效果不错，于是antirez决定将它开源，并在HackNews上做了推广。
问这种问题要么是一定高度 考察面试者对Redis整体理解，要么是对Redis 不熟悉，随口问下。
2.redis是多线程还是单线程？
从整个服务角度上看 是多进程 多线程
但是主服务是单线程
多线程，但是主要的数据读取、保存服务还是单线程
单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
Redis 为什么是单线程，作者自己表达避免复杂锁机制，单线程服务 不需要锁
单线程依靠 nio 一样高并发
一般来说 Redis 的瓶颈并不在 CPU，而在内存和网络。如果要使用 CPU 多核，可以搭建多个 Redis 实例来解决。其实，Redis 4.0 开始就有多线程的概念了，比如 Redis 通过多线程方式在后台删除对象、以及通过 Redis 模块实现的阻塞命令等。
3.redis的持久化开启了RDB和AOF下重启服务是如何加载的？
先看AOF 如果有aof 文件 在加载aof
如果没有再看RDB 加载db文件
4.redis如果做集群该如何规划？AKF/CAP如何实现和设计？
开方式问题，根据需求场景和机器配置分析
看对方公司大小，服务器小于50台的公司基本上不舍得上集群，
或者三台机器的集群，
或者哨兵模式
一个哨兵、一台主 、一台从
控制成本情况下保证了服务稳定，主、从配置根据数据量定，大内存，2核心即可
哨兵配置能跑起来就行。
大公司：
个人推荐使用Redis cluster
服务端的分片方案，主从备份，或者一主多从，哨兵机制，
哨兵可以认为是一台特殊的Redis 服务，Redis 源码理解
也可以使用代理 Twitter 开源
或者客户端的分片策略
如果对方继续深入问：
三种策略：
1，客户端分片
2.中间件分片
3.服务端分片
以上三种是17年左右的
发展成熟的
集群、哨兵 主从模式
都是在服务端做逻辑
主从复制模式
主从复制的优缺点
优点：
master能自动将数据同步到slave，可以进行读写分离，分担master的读压力
master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求
缺点：
不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复
master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题
难以支持在线扩容，Redis的容量受限于单机配置
Sentinel（哨兵）模式
优点：
哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有
哨兵模式下，master挂掉可以自动进行切换，系统可用性更高
缺点：
同样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置
需要额外的资源来启动sentinel进程，实现相对复杂一点，同时slave节点作为备份节点不提供服务
Cluster模式
优点：
无中心架构，数据按照slot分布在多个节点。
集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
可线性扩展到1000多个节点，节点可动态添加或删除
能够实现自动故障转移，节点之间通过gossip协议交换状态信息，用投票机制完成slave到master的角色转换
缺点：
客户端实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度。目前仅JedisCluster相对成熟，异常处理还不完善，比如常见的“max redirect exception”
节点会因为某些原因发生阻塞（阻塞时间大于 cluster-node-timeout）被判断下线，这种failover是没有必要的
数据通过异步复制，不保证数据的强一致性
slave充当“冷备”，不能缓解读压力
批量操作限制，目前只支持具有相同slot值的key执行批量操作，对mset、mget、sunion等操作支持不友好
key事务操作支持有线，只支持多key在同一节点的事务操作，多key分布不同节点时无法使用事务功能
不支持多数据库空间，单机redis可以支持16个db，集群模式下只能使用一个，即db 0 Redis Cluster模式不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。
5. 10万用户一年365天的登录情况如何用redis存储，并快速检索任意时间窗内的活跃用户？
10万用户量并不大，简单的存储每个员工一个List 记录365天的登录情况，这样存储不能快速检索
那么可以每天作为key
当天登录的用户放在这个List 里
可以方便的查出任意时间段的人数登录情况
登录员工的数据可以只存id 减少内存占用
这个时间段精确到天，如果精确到秒呢
这个数据量有点庞大了，就要在mysql里设计逻辑，每次登录记录一次
6. 100万并发4G数据，10万并发400G数据，如何设计Redis存储方式？
100万 并发，按照10小时计算 平均每小时10万
每分钟1600 每秒30个请求
数据全部放在Redis 内存中就可以
完全可以满足
如果是400G 数据
全部放在内存不太现实，使用Redis 也不现实，建议使用mysql
如果一定要使用Redis 选择内存占用最小的存储方式
本文地址：https://blog.csdn.net/keep_learn/article/details/110533813