1. Redis基础
-
Redis有哪些数据结构
-
如果有大量的key需要设置同一时间过期，一般需要注意什么
-
Redis分布式锁（set unlock SEC NX）
-
找出所有以某个固定的前缀开头的key（KEYS，SCAN）
-
Redis做异步队列（list。pub/sub主题订阅者模式）
-
持久化？机器突然断电丢失？（RDB做镜像全量持久化，AOF做增量持久化）
-
主从同步？（也是用到RDB，AOF。BGSAVE）
-
RDB的原理？（fork，cow）
-
RDB和AOF各自优缺点
-
pipeline
2.Redis-避免缓存穿透BloomFilter
BloomFilter是一个很长的二进制向量和一系列随机映射函数，用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难
- 原理
- 优缺点
- 用处（防止缓存击穿）
- 如何删除？Counting Bloom Filter
- redis 有布隆过滤器的功能？Redisson
3.Redis-缓存雪崩、击穿、穿透
-
雪崩（同一时间key大面积失效）和避免措施（随机时间失效）
-
穿透（不断发起请求缓存和数据库中都没有的数据）和避免措施（参数校验，BloomFilter，对应Key的Value对写为null并设置短过期时间）
-
击穿（热key失效）避免措施（热点数据永远不过期）
-
大key和热key问题
4.Redis哨兵、持久化、主从、手撕LRU
-
redis为什么快？（100000+的QPS。单线程+内存+io多路复用）
-
持久化（RDB，AOF）
-
高可用（哨兵+主从不保证数据不丢失，但保证集群的高可用；三实例）
-
主从同步（master写，数据同步给slave读，分发掉读请求；RDB，AOF；同步同时缓存区处理写请求）
-
内存淘汰机制（定期删除+惰性删除；LRU、随机和是否过期正交，外加TTL，五种策略）
-
Redis 3.0 LRU算法优化
5.-Redis双写一致性、并发竞争、线程模型
- redis不同数据类型的适用场景（string；map；list通过 lrange 命令做分页查询，做mq；set交集、并集、差集；sortedlist排行榜）redis适用用作存储吗？
- 缓存与数据库双存储双写（ Cache Aside Pattern先更新数据库，然后再删除缓存）为什么是删除缓存，而不是更新缓存？为什么建议先操作数据库，再操作缓存？Cache Aside Pattern存在什么问题www.pianshen.com/article/315…
6.消息队列基础
- 异步、削峰、解耦
7.分布式事务、重复消费、顺序消费
- 重复消费（接口幂等）www.jianshu.com/p/475589f5c…
- 顺序消费（Hash取模法，让同一个订单发送到同一个队列中，再使用同步发送）
- 分布式事务（2pc，最终一致性，tcc，tb）
8.Rocket MQ
-
四大核心组成部分：NameServer、Broker、Producer、Consumer
-
NameServer：心跳、注册、broker-topic关系
-
producer发送消息方式：同步、异步和单向
-
consumer消费消息方式：PUSH和PULL
-
broker消息存储（Topic为纬度的队列）
-
message模型：topic，tag，queue
-
Clustering（集群消费）和Broadcasting（广播消费）；group
-
Orderly（顺序消费）和Concurrently（并行消费）；一个topic下同一个queue时保证
-
**消息去重（**at least once）（消费者做幂等）
-
顺序消息。可使用Hash取模法，让同一个订单发送到同一个队列中，再使用同步发送
-
分布式事务的支持： Half Message(半消息)
-
持久化
9.zk实现分布式锁
-
线程进程同步的机制（互斥；临界值；事件通知；共享资源信号量）
-
分布式锁实现主要以Zookeeper（以下简称zk）、Redis、MySQL这三种
-
zk（数据库，文件存储系统，并且有监听通知机制（观察者模式））
-
节点
10.redis实现分布式锁
- set key value nx px millionseconds
11.乐观锁悲观锁
12.Volatile
可见性问题和顺序性问题
-
现代计算机的内存模型（每个cpu有自己的cache，cache和主内存memory之间的一致性问题）
-
Java内存模型(局部变量在cache有副本。线程对局部变量都必须在cache完成，不能直接读写主内存中的变量。 不同线程之间也不能直接访问对方cache)由此带来可见性问题
-
可见性问题解决方案（加锁synchronized；volatile）
-
synchronized解决可见性问题
-
volatile解决可见性问题（每次从主内存读；每次写回主内存时，其他线程cache副本失效立即看到最新的值）
-
volatile原理（MESI（缓存一致性协议）；嗅探；总线风暴）
-
指令重排编译优化（as-if-serial单线程下的执行结果不能被改变）由此带来多线程下顺序性问题
-
volatile解决顺序性问题，禁止指令重排（内存屏障）
-
happens-before：对一个volatile域的写操作，happens-before于任意线程后续对这个volatile域的读
-
volatile无法保证原子性 不保证线程安全
-
单例模式利用volatile
-
volatile与synchronized的区别（volatile保证数据的可见性，但是不保证原子性(多线程进行写操作，不保证线程安全);而synchronized是一种排他(互斥)的机制。volatile可以看做是轻量版的synchronized）
13.synchronized
14.数据库基础
无
15.索引
-
有序数组、哈希、二叉树作为索引的不足
-
B+树的节点多大合适
-
**页的结构（槽、记录）**页和页之间双向链表；根据主键、二分法定位槽；槽内部记录是单向链表
-
覆盖索引；回表
-
最左前缀匹配原则
16.数据库调优
-
explain字段分别有什么含义
-
覆盖索引、联合索引、最左匹配原则 、索引下推
-
唯一索引普通索引选择（change buffer）
-
优化字符串字段的索引（前缀索引、hash、substring、reverse函数）邮箱？身份证号？手机号？
-
对索引字段做函数操作，可能优化器放弃走树搜索功能
17.sql调优
-
内联子查询 禁用
-
**不建议使用Left Join，**即使ON过滤条件列索引，可能也不会走索引
-
不建议使用子查询，可以改写成Inner Join
-
索引列被运算、类型转换、字符集转换可能导致索引失败
-
group by、order by后面的列有索引，索引可以消除排序带来的CPU开销，如果是前缀索引，是不能消除排序的
-
like %xxx% 或者 like %xx即使列上有索引，也不会被使用
-
order by排序字段顺序，asc/desc升降要跟索引保持一致，充分利用索引的有序性
-
limit m, n分页查询m很大时，先取出主键id，然后通过主键id跟原表进行Join关联查询
-
列值存储了大量的NULL，会影响索引的稳定性
-
or， in走索引吗？
18.Text类型
-
四种类型：TINYTEXT, TEXT, MEDIUMTEXT,LONGTEXT
-
InnoDB，面向ROW存储，每个page(16KB)存储16K/2 - 200 = 7992行
-
row四种格式
19.模糊匹配like的SQL
-
like %xxx% 或者 like %xx即使列上有索引，也不会被使用
-
索引条件下推
-
辅助索引idx_nickname(nickname)内部是包含主键id的，等价于(id，nickname)的复合索引
-
like %xxx% 或者 like %xx通过索引条件下推合辅助索引，达到减少回表的优化
-
Extra显示的索引扫描方式
-
reverse函数将like '%风云'反转为like '云风%'，基于此函数添加虚拟生成列
-
**like的多种优化方式：索引下推、全文索引、生成列
**
20.不建议delete删除数据
-
InnoDB存储结构：表空间tablespace —> 段segmen —> 区Extent ——>数据页Page，Innodb逻辑管理单位是segment，空间分配的最小单位是extent
-
MySQL内部不会真正删除空间，而且做标记删除
-
碎片
-
对普通的大表，想要通过delete数据来对表进行瘦身是不现实的
-
优化建议（在create_time列要创建索引，标记删除（ 做唯一索引的时候带上is_deleted），原表和归档表）
21.innodb是如何一步步插入一条数据的
-
不用uuid做主键
-
表空间/Tablespace： 系统表空间，用户表空间，Undo表空间
-
系统表空间 存储change buffer, doublewrite buffer以及与innodb相关的所有对象的元数据。系统表空间information_schema库
-
段，如：B+对中的非叶子节点或B+树中的叶子节点。常见的段有数据段、索引段、回滚段
-
区/簇/Extent 一个区/簇，默认由64个连续的页（Page）组成，每个页默认大小为16K 当page size为4、8、16KB时，对应一个extent的page数量同步变化，以保证extent(区/簇)大小保持1M不变
-
如何一步步存储一条数据（
-
CREATE TABLE
-
系统表空间的information_schema库的tables和columns中存入表结构信息；
-
创建表空间 同时创建独立表空间world/user以及对应的数据文件world/user.ibd；
-
创建聚集索引 为索引创建两个段：索引段（非叶子节点）和数据段（叶子节点），并把段信息存储到表空间封面页的段链表中，并存储到information_schema.innodb_indexes
-
插入数据
-
从sql中提取数据库名和表名，从information_schema.innodb_tables中查出表id 根据表id，从information_schema.innodb_indexes中查出表对应的聚集索引的Root Page No 为4。 通过Root Page No 4计算出Root Page的物理地址。根据Root Page中指定的段信息，向Root Page中插入索引数据
-
）
