1.技术选型的原因 说了选kafka的原因
2.kafka怎么保证顺序性
3.kafka为什么吞吐量那么大
4.redsi常用的数据结构
5.redis分布式锁的实现
6.除了redis 还有什么方法能实现分布式锁
7.innoDB 索引的存储
8.给了条sql语句问要怎么建立索引
select A from table where B='xxx ’ order by C
如果B和C都是独立索引 会用到吗
9.g1垃圾回收器的特点
10.concurrentHashMap怎么保证线程安全
11.concurrentHashMap的扩容机制
答案
3.kafka为什么吞吐量这么大?
1)日志追加写是顺序写 读是顺序读
2）页缓存机制：写数据并不会直接刷盘到io，而是先缓存到页缓存中，由操作系统刷盘，若此时要读数据直接从缓存度，不需要经过磁盘io
kafka数据可靠性的保障
1.使用flush.messages和flush.ms(不推荐)
会极大降低性能，且没必要
2.使用副本机制!(推荐)
副本+ack机制 至少设置ack为1 即lead副本在收到数据后再让数据可读
这样即使当前broker宕机，也可以从其他broker的副本里恢复数据
3) 零拷贝:数据不用再从内核态拷贝到用户态，再从用户态拷贝到内核socket缓冲区再发给网卡
直接在内核态通过mmap+sendfile把数据拷贝到网卡(DMA)要快很多
4）批处理:无论是生产数据还是消费数据都做了批处理缓存，缓存一定量数据后再发送给broker或客户端 减少了网络io
5)分区并行:一个topic可以分多个分区，生产者并行写，消费者并行消费
6)数据压缩:用gzip对数据进行压缩后再发给broker 消费者拿到数据解压后再使用
7)拉取模型:消费者拉取模式，按照自己的处理能力拉取消息，防止被压垮
5.6.分布式锁:单开文章
8.若要建立联合索引 则按照(B,C,A）的顺序
因为过滤(Where)优先 排序优化(Oredr) 要先过滤再排序 所以B要在最前面
如果B和C都是独立索引，大概率只会用到B索引，因为过滤优先，若是按B索引排序后，C字段实际上就无序了，所以没法用索引
mysql语句执行的顺序
1.From Join 确定要从哪些表拿数据是起点
2.where 过滤优先 先减少要处理的行数
3.group by +Having
4.select 选择最终输出的列
5.order by
6.limit
10. jdk1.8之前是分段锁(默认16个)，用的是ReentrantLock
1.8之后是cas+synchronized节点锁
读都不加锁 写才加锁 用volitile保证可见性
11.concurrentHashMap的扩容机制 单开