得物后端二面

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的扩容机制 单开