面试阿里知识点总结

9月份-11月中旬，前后面了阿里四个部门，百度监控部门（被放鸽子）。最终进了成都��。下面贡献下当时自己的简单总结。
（感想：好好准备，前面先面些其他公司，增加把握，我都是被动接到面试通知的，好在这个部门GG下个部门电话又来了。。简历要简单粗暴突出重点优势，另外失败了不少一根毛，不要怕，我当时第一次失败自己的QQ签名就是来年再战！）

---

——————————————————————————————————JAVA基础 JVM———————————————————————————————————————
1.线程安全volatile

JAVA内存区域: 1.JVM栈、JVM堆、直接内存、本地方法栈、本地方法区、程序计数器、运行时常量池

2.JAVA内存模型

3.类加载机制

4.分代收集算法
GC回收 serial（年轻代串行 复制算法） serialOld（年老代串行 标记整理） paralNew
ParalScavage（paralNew 但是更关注吞吐量） paralOld
CMS（缺点：浮动垃圾、内存碎片、占CPU） 初始标记、并发标记、重新标记、并发清除
G1 初始标记、并发标记、最终标记、筛选回收 内存不再是连续 而是region 年轻、年老、永久、T（大对象）四种

对象不可达：1.引用计数 2、可达性分析

垃圾收集：标记 清除
复制算法
标记 整理

—————————————————————————————————————JAVA基础 并发——————————————————————————————————————
1. final域：
2.volatile： 禁止指令重排序 立即更新到主内存并使其他工作内存的副本失效
3.工作窃取算法：（双端队列） 任务多个线程执行 一个线程执行完了 去另外一个线程的队里尾端取数据执行 （本线程从顶端取数据）
4. 闭锁
5.FutureTask
6.信号量
7.CountDownLauntch和栅栏
8. CompletionService
9. ConcurrentHashMap： volatile + CAS
10.线程饥饿：
死锁

1. ReentrantLock与synchronize的区别
   。

———————————————————————————————————————JAVA基础 IO、NIO、数据结构—————————————————————————————
1.HashMap实现原理： 数组 + 链表
2.TreeMap有序：就是一颗红黑树。 get和put都要logN （Map是因为存放的Entry有key val）
3.ConccurrentHashMap实现原理 ： 数据 + 链表 + 红黑树 （链表长度过长则转为TreeBin 由TreeBin构建红黑树）
4.IO的设计模式： 装饰者模式 适配器模式
5.NIO ： selector的职责
6.netty：》事件驱动的、异步非阻塞消息通信框架
》一个 Reactor 线程聚合一个多路复用器 Selector，它可以同时注册、监听和轮询成百上千个 Channel，一个 IO 线程可以同时并发处理N个客户端连接
》零拷贝原理: 1.使用了directBuffer 直接操作内存，无需字节缓冲区的拷贝
2.使用了组合buffer对象。 操作组合对象其实还是操作单独的buffer，并不是真正合并成一个新对象
3.使用了JAVA提供的transferTo直接发送文件 避免了传统的while{}循环导致的内存拷贝问题
可以通过NETTY构建高效RPC框架

7.Reactor模式： 先注册一个事件，并指定回调函数，当事件触发的时候，Reactor调用对应事件的回调函数 用于IO多路复用
proactor模式 ： 依赖操作系统的异步回调
10.写快排的实现

1. 同步、异步、阻塞、非阻塞
   同步非阻塞： 烧开水，然后去切菜，切完了回来看烧开没
   异步非阻塞： 拜托老妈烧开水， 我去切菜， 老妈烧好了会告诉我， 我不用管

———————————————————————————————————————微信电视项目————————————————————————————————————————————

———————————————————————————————————————容器云平台项目 & 微服务框架项目———————————————————————————————
k8s、docker、etcd、CI\CC\CD\AG

galileo、newton、maxwell、planck、

服务注册与发现、流控、限速限额、监控（健康检查、服务质量、JVM、链路追踪）、权限、持续交付、通信、配置、监控

————————————————————————————————————————监控————————————————————————————————————
1.api、alert、jobmgr、notify、gatherer、client模块
2.docker log收到宿主机、每台宿主机都有flume实例，flume采集log数据到kafka，
kafka gatherer消费数据。 读取收集到opentsdb（hbase）
alert消费数据。 做实时告警。（先匹配，再丢入kafka，再消费event数据根据时间窗口判定是否触发告警）

jobmgr模块请求opentsdb读取hbase数据，做周期告警、日报

其他服务需要import我们的client jar。 1.client会采集服务质量数据 2.用户打metric数据 （自定义指标）

————————————————————————————————————opentsdb、Hbase、kafka、zk、elk—————————————————————————————————————————
大数据的基本上都是依赖wal同步写入日志 ， 然后异步刷盘，因为是顺序写磁盘，所以速度能够媲美写内存。
kafka也是顺序写磁盘。并且数据永久保存，定期清理（30天前）

HBase： 使用LSM树（牺牲了部分读性能，大幅度提高写性能）log structure merge归并树，先存储数据，然后数据够了就归并排序成有序的写入磁盘
面向列存储： column不固定，可以动态增加。顺序写，不是随机写，
划为多个region，然后每个hbase节点通通过zookeeper管理部分region。通过zookeeper实现高可用，leader选举

    map、reduce

opentsdb优化： 1.减少rowkey长度 通过uid映射（三个字节 1600W+ 可以通过修改源码改为4字节）
2.多行合并单行 一个小时的数据存为一行， 每一列即是1s的数据（秒偏移）
3.多列合并为一列 定时compact合并 把3600列的数据合并到一列
4.热点问题： 通过预分配桶编号 加到前缀

———————————————————————————————————————————————kafka——————————————————————————————————————————————
1.多副本实现高可用 每个broker会存其他partition的几份副本
2.顺序写磁盘实现高吞吐量
3.多partition实现消息分发

———————————————————————————————————————————————redis————————————————————————————————————————
1.单线程 无线程切换
2.操作合并为串行执行 无并发冲突
3.

———————————————————————————————————————————————分布式链路追踪———————————————————————————————————————
traceId和spanId全局透传
利用ElasticSearch实现索引 rowkey找到原始数据

——————————————————————————————————一致性哈希———————————————————————————————————————
普通哈希存在的问题： 节点删除、增加 导致整个hash99%错误。无法动态扩展、删除
一致性哈希解决的问题： 能够最大程度的减少 节点删除、增加带来的 哈希映射失败
原理： 一个环形结构（2^32个节点） 机器节点hash到这些节点上， 然后数据hash出来的顺序取到其后的节点上，如果没有，则取firstkey。
还存在一个问题：热点问题。 引入虚拟节点，一个节点有多份副本，均匀分散在整个环。
1 2 3 变成 1.1 2.1 3.1 1.2 2.2 3.2 3.1 3.2 3.3 ，之前如果全是3的 那么现在也就分散到1.2.3了 则避免了热点问题
具体做法 10.2.1.1#1 10.2.1.1#2 10.2.1.1#3

__________________________分布式锁_______________________

————————————————————————————————————分布式事务——————————————————————————————
目前基本都是通过消息队列解耦 从而实现最终一致性：
两阶段提交
三阶段提交
补偿式
可靠事件模式（消息队列）

—————————————————————————————————————分布式系统数据一致性——————————————————————————————————
leader分发数据、日志。通过raft协议实现选主 （zookeeper是ZAB协议 类paxos） paxos协议

—————————————————————————————————————海量数据处理————————————————————————————————
bitmap 2bitmap 处理重复整数
bloom filter 查看是否存在
主要思路为顺序读取数据 hash 然后写入到不同的小文件，最后对小文件进行内存运算

---

1.spring事务、事务嵌套、bean的proptertype和生命周期、spring的几个重要功能、aop实现、动态代理的几种实现方式及区别
2.数据库表行锁、乐观锁、悲观锁、写sql用到乐观锁和悲观锁、秒杀系统（mysql实现）如何保证销量不会减到-1、事务的一些特性
3.rpc的几个特性：序列化、通信 和http有什么区别（详细） netty的client过多会有问题吗？
4.服务注册与发现的实现流程
5.微服务框架 流程、功能、主要内容、每个模块具体的功能及实现 （需要深入 细讲）
6.java的数据结构 Map Array（分配连续空间 扩容的时候重新分配 把原来的拷贝） List Set
如何判断两个对象相等，hash冲突的时候会怎么样
7.JVM内存区域、垃圾收集
8.分布式事务 分布式一致性（需要仔细）
9.当一个服务很多次FULL GC，该怎么排查
10.怎么实现的监控JVM及监控哪些方面
11.spring boot了解吗
怎么获取springContext
13.如果消息丢失了怎么办？ 和对方对账

不能模棱两可。