NOSQL(not only sql)；
泛指非关系型数据库，优点是易扩展、大数据量高性能、多样灵活的数据模型。
传统的ACID是什么?
Atomicity原子性：事务里面的操作要么全执行，要么都不执行；
Consistency一致性：事务开始前和结束时，数据库的完整性约束不被破坏。比如A向B转账，不可能A扣了钱，但是B没有收到；
Isolation隔离性：并发执行的事务对彼此的中间状态不可见；
Durability持久性：事务一旦提交，对数据库的修改就是永久了;
事务的四种隔离级别
读未提交（Read UnCommited）:会脏读、不可重复读、幻读问题；
【脏读：指的是一个事务读取了另一个事务未提交的数据】
【不可重复读：指的是在一个事务内，多次读取某一行数据，结果不一致】
【幻读：指的是一个事务读取了另一个事务插入的数据，导致前后读取不一致】
读已提交（Read Commited）:一个事务当等另一个事务提交后才能读取数据，会出现不可重复读和幻读问题；（Oracle的默认隔离级别）
可重复读（Repeatable Read）：一个事务开启时，不允许其他事务修改该事务的数据，会出现幻读问题；（MySQL的默认隔离级别）
串行化（serializable）:最高的隔离级别，事务串行化执行;
CAP理论？
Consistency：一致性
Availability: 高可用
partition tolerance:分区容错
redis保证的是CP
redis是单线程，非阻塞IO多路复用模型，默认16个库；
单线程：避免了不必要的上下文切换和竞争条件消耗cpu；
IO多路复用：采用轮询的方式依次处理准备好的流，避免了大量无用的操作；
redis常用数据结构？
1. String: 简单的k-v键值对；
2. Hash：是一个String类型的field和value的映射表，hash特别适合用于存储对象；
3. list:底层实现是双向链表；
4. set：功能与list类似，特殊之处set可以排重；
5. sorted set: 和set相比，增加了一个score参数，使得集合中的元素能够按照score进行有序排列，并且是插入有序的，即自动排序；
redis的持久化？
1.RDB:
在指定的时间间隔内，把内存中的数据集快照写入磁盘，恢复的时候直接将磁盘的数据集写入内存
默认是15分钟1次，5分钟100次，1分钟10000次写操作触发
保存的是dump.rdb文件
优点：适合大规模的数据恢复
缺点：
1.会丢失最后一些快照后的所有修改；
2.fork子线程时，内存中的数据被克隆的一份，2倍空间的膨胀性需要考虑；
2.AOF(append only file):
以日志的形式记录每个写操作，只需追加文件不许改写文件，redis启动之初会读取文件来重新执行命令来构建数据
生成是appendonly.aof文件; 默认是关闭的，开启时 appendonly no 改成yes
重写机制：当aof文件超过某个设定的阀值时，redis就会启动文件的压缩，只保留恢复数据的最小指令集，可以使用命令gbrewirteaof执行。
重写原理: fork一个新线程来重写，先写临时文件再rename，重写时不会读取旧的aof文件，而是把内存中的数据用命令的形式重写一个新的aof文件；
重写触发条件：redis会记录上次重写aof文件的大小，默认配置当aof文件是上次重写的一倍且文件大于64M；
同时开启rdb和aof时，redis会优先载入aof文件来恢复原始的数据。
比较：
1.aof文件比red文件更新频繁，优先使用aof还原数据；
2.aof比rdb更安全，更大；
3.aof性能比rdb差；
4.如果两个都配了，优先加载aof
redis的事务？
一个队列中一次性、顺序性、排他性的执行一系列命令，不保证原子性，同一个事务内如果有一条命令执行失败，其他的命令仍然会被执行，没有回滚；
事务相关命令：
1.discard：取消事务，放弃执行事务内的所有命令；
2.exec: 执行事务内的所有命令；
3.mutil：标记一个事务的开启；
4.watch key[key …]: 监视一个（或多个）key，如果在事务执行之前，这个key被其他命令所改动，那么事务将被打断；
5.unwatch: 取消watch命令对key的监视；
watch命令类似于乐观锁，乐观锁策略：提交版本必须大于记录当前版本才能被执行；
redis集群？
**redis主从复制：**读写分离、容灾恢复；
一类是主数据库（master）、一类是从服务器（slave）
1.主数据库可以进行读写操作，当发生写操作的时候自动将数据指令集通道到从数据库；
2.从服务器一般是只读的，一个主库可以有多个从库，一个从库只能有一个主库；
配置：配从不配主；
从库配置命令：slaveof 主库Ip 主库端口,查看命令 info replication
原理：
1.slave启动成功后会给master发送一个sync命令；
2.master收到sync命令个启动后台存盘程序，同时收集所有接收到的用于修改数据的指令集，在后台程序执行完成后，传送整个文件给slave完成一次全量同步；
3.全量复制：slave接收到数据文件时，将其存盘，并加载到内存；
4.增量复制：master继续将收集到的新指令集发送给slave；
5.slave只要重连master，一次全量复制自动执行；
哨兵模式（sentinel）：
后台监控主机是否故障，如果故障根据投票数，将slave转换成master；
redis-cluster集群：
redis3.0之后版本支持redis-cluster集群，采用的是无中心结构，每个节点保存数据和整个集群状态，每个节点和其他所有节点连接。
结构特点：
1.所有的redis彼此互连（ping-pong），内部使用二进制协议优化传输数据和带宽；
2.节点的fail是通过集群中超过半数的节点检测失效才生效;
3.客户端与redis节点直连，连接集群中任何一个可用节点即可;
4.redis集群预分配好16384个slot(槽)所有的节点（不一定平均分配），添加k-v时，对key使用crc16算法得到一个hash，取模16384决定将key放入哪个slot;
多个命令并发执行redis怎么保证原子性？
1.使用redis事务；
2.使用redis+lua脚本；
如何保证缓存和数据库双写一致性问题？
1.先更新数据库再更新缓存；
2.如果对数据有强一致性要求，不建议放缓存；
MaxMemory:最大缓存配置。
默认为0，没有指定最大缓存，如果有新数据添加，操作最大内存，redis就会崩溃，所以一定要设置。
redis内存数据集上升到一定程度时，就会实行数据淘汰策略。
redis的过期策略和内存淘汰策略：
redis过期策略采用的是定期删除+惰性删除
定期清除：redis每隔100ms随机抽样检查，是否有过期的key,有则删除，但是会导致很多过期的key没有删除;
惰性删除：在获取某个key的时候redis会检查一下key是否过期，过期则删除;
内存淘汰策略有六种：
1.volatile-lru: 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰；
2.volatile-ttl: 从已设置过期时间的数据集中挑选将要过期的数据淘汰；
3.volatile-random：从已设置过期时间的数据集中随机挑选数据淘汰；
4.allkeys-lru: 当内存不足以容纳新写入数据时，在键空间中移除最近最少使用的key（这个是最常用的）；
5.allkeys-random: 当内存空间不足以容纳新写入的数据时，随机淘汰数据；
6.no-eviction: 禁止驱逐数据，当内存不足以容纳新写入的数据时报错。
redis常见性能问题？
master最好不要做任何持久化工作，如rdb内存快照和aof日志文件，如果数据比较重要，某个slave开启aof备份数据，策略设置为每秒同步一次;master和slave最好在同一个局域网；尽量避免压力很大的主库上增加从库，不要用图状结构，用单向链表结构更为稳定。即： Master <- Slave1 <- Slave2 <-Slave3…
秒杀系统如何设置？高并发会出现什么问题？
架构设计：
1.将请求拦截在系统上游，降低下游压力。
秒杀系统特点是高并发，但实际秒杀成功的请求数量却很少，所以不在前端拦截可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
2.充分利用缓存：利用缓存可以极大的提高系统读写速度。
3.使用消息中间件：消息队列可以削峰，拦截大量并发请求。
前端设计方案：
1.页面静态化：将活动页面上的所有可静态元素全部静态化；
2.禁止重复提交：用户提交之后按钮置灰；
3.用户限流：在某一时间段内，只允许用户提交一次请求；
后端设计方案：
1.网关限制uid访问频率；
2.服务层：采用消息队列缓存请求和利用缓存应对请求;
3.把减库存和生成订单逻辑使用mysql存储过程实现，减少事务锁持有时间，避免GC和IO的延迟;
