一轮电话面试，一个半小时，昨天晚上面试的，今早面试官打电话约了二面（为啥是一面面试官:） 

1. 自我介绍
   1. 工作经历，项目经历
2. 项目挑两个介绍一下
   1. 这里介绍了一个偏技术的基于Mysql搭建的olap系统，数据量大概十几亿，但是业务逻辑比较简单，olap逻辑主要体现在SQL上，重点说了一下分表和主从的搭建和原因；分表方便备份和管理；因为数据只是顺序写入和增量读取，大表本质上不影响事务性能；
   2. 另外一个toB的业务系统，这里核心业务逻辑是TOB场景下的复杂权限管理，讲了一下利用状态机模式实现的思路，状态机利用Mysql的自生成列加状态位图来实现；
3. 第一个项目，数据库主从备份的原理
   1. 三种模式，我使用的是异步+statement，为什么使用statement模式，其他两种有什么优劣性，这里理解三种备份原理，就很容易明白怎么使用为什么使用--olap定时做批处理，对从库的实时一致性要求不高，所以采用异步，事务只涉及到单行insert，且不包含SQL函数，所以使用statement，性能高；
   2. 分表--
      1. 我分表使用mycat主键范围分片，一千万一张表；主键在应用层自生成，服务重启需要阻塞回查--mycat中间件压测下自生成id有BUG；
      2. 如果多实例自增id怎么实现--雪花算法，redis原子自增命令，分布式锁；
      3. 如果是业务数据库怎么分表--冷热分表，数据散列--数据散列的时候要注意数据配合查询路由策略；
4. 第二个项目
   1. 状态机怎么实现的--自生成列，使用位图，权限结果四字节，每个字节存储的是状态机中不同的业务对象的状态，计算出来的就是权限结果
   2. 状态机为什么用Mysql的自生成列，如果业务代码中实现会怎么样--回答避免了多次查询，性能比较高
   3. 其实这里面试官想说的是强依赖与Mysql的功能，扩展性不够好，另外Mysql的版本支持性，这里没有意识到，面试官提了Mysql是否所有版本都支持自生成列才意识到，避免多次查询来计算状态结果可以用查询时计算，这样也可以保证状态改变时为了计算出权限状态而导致的多次查询，但是这里其实有一个问题，就是查询时计算如果查询之后状态被其他事务修改，也必须加锁才能保证一致性，另外就是每次查询都要计算权限值，所以性能开销还是很大的，所以这个取舍还是有必要的--当时回答的是只考虑了性能；没有考虑扩展性；
   4. 关于状态机模型是否还在其他项目中使用过--工作过程中没有，最近想做的分布式异步任务处理组件设计考虑到了状态机模式，这种类似于zk，新建节点处于同步模式，数据同步完才进入worker模式，由于这个项目实际未在简历中体现，就大概提了一下，面试官也没多问；
5. 技术问题
6. 是否使用过RPC，RPC的原理
   1. 回答，RPC其实后来因为公司单体架构加上vertx本身的eventbus单机部署用不上RPC，这点如实回答，大概有了解过fegin，回答http协议实现+集成ribbon负载均衡，原理就是对象的序列化+非代码入侵式的接口调用；
7. 如果自己设计实现一个RPC框架，怎么做--基于RPC的原理，服务发现，负载均衡，对象序列化和反序列化--当时只考虑到这么多，（后续还是要看一下springcloud的几个核心组件的设计以及微服务架构中的一些核心架构思想；）
8. 服务发现怎么实现--说了利用zk的watcher机制和注册中心eurake，核心就是分布式+发布订阅，分布式保证注册中心不会出现单节点问题，发布订阅就是服务发现的核心功能；
9. 常用的LB算法--核心就是分流，之前配置过nginx的lb，先说了一下基于nginx的lb怎么配置的，很简单，两个业务服务器2:1 的流量分配，面试官问2:1是什么意思--答主服务器百分之七十的流量，从服务器百分之三十的流量；
10. 然后问数据库怎么主从设计的，面试官其实就想问数据一致性的问题了这里，回答了数据库还是主库单实例模式，主库负责所有事务读写，发生故障转移之后流量才转发到到从库上，之前的lb只是基于服务的lb；继续回答LB算法，简单轮训，IP散列，这里说了LB对于数据一致性的影响，如果水平分库分表的时候要保证同一用户的多次请求最终转发到同一服务实例上，最终保证了访问到同一数据库实例；
11. Spring和Springboot的区别--
    1. 答Spring核心是Bean管理工厂，springboot核心是对spring开发配置优化，提供了很多组件的starter，实现了组件之间的版本依赖问题，另外springboot集成了Tomcat，可以直接部署war包一键运行，而Spring需要单独部署，但是springboot的核心还是spring的bean管理---这里因为springboot很久没有接触了，回答的比较简单，但是核心没啥问题，springboot就是为了方便spring开发，在配置和部署方面做了优化，要具体说我感觉也没啥好展开讲的
12. 如果实现一个限流框架怎么做--
    1. 先说了下限流实现--流量转发或者服务降级
    2. 核心关注了怎么做流量统计，提到了服务自反馈和网关层代理，服务自反馈的时候监控JVM运行状态，服务自己决定是否接受新的请求，提了下对JVM性能监控本身会影响到服务性能，所以时间会长一些，一般不考虑；核心还是网关层的限流
    3. 网关层的话做流量统计监控就可以，针对某个服务实例粒度的流量统计，一般需要更细粒度的实例的接口层面的流量统计；然后提到了怎么做到流量控制，这里首先想到的点是如何发现需要限流，就说了一下可以先做统计记录某个实例的平均TPS，如果TPS变大的话就限流；
    4. 继续问流量统计具体怎么实现，比如配置好某个实例的某个接口限流QPS小于100----回答了一个简单的算法，每秒重置的计时器，对某个接口每秒接受的请求做计数，小于一百就发给该实例，大于一百就做限流--转发或者降级；然后问计数器并发问题怎么实现--其实这里问流量统计的时候好像核心就是想问多线程并发问题，但是我下意识都是觉得既然使用了计数器，肯定是要保证线程安全的，emm，于是说了cas就可以实现了，
    5. 然后说了单节点问题，所以限流框架本身要做分布式集群，所以还需要集群协议来做集群管理，简单的可以用zk来做集群管理；
13. 问怎么实现分布式链路追踪
    1. 答设计一个请求的全局标识来记录请求链路；
    2. 问具体怎么实现全局标识，怎么实现服务间传递--可以在网关层维护一个全局唯一ID放在http请求头里，然后服务内方法间传递使用ThreadLocal，服务间传递根据具体的调用方式，可以继续放在请求头里或者显示传参都行
    3. 问线程池里的ThreadLocal传递全局ID会有问题吗--emmm，当时没有意识到线程池使用ThreadLocal的一个坑，因为使用ThreadLocal本来代码标准就是要使用完之后remove，我以为要问的是线程调用线程池能不能直接把ThreadLocal传过去，或者线程被回收会不会丢失ID，就大概说了下ThreadLocal的原理，因为每个线程实例维护自己的ThreadLocalMap，所以传递给线程池里的线程的时候必须显式set；面试完才看了一下线程池使用ThreadLocal的雷---线程池里的线程可能不会被回收，ThreadLocal可能存放的上一个请求的ID，但是显式set是没有问题的，面试官主要是想看能否考虑到数据安全性这一点~
14. 问JVMGC
    1. 先说了判断对象存活的算法--根搜索和引用计数
    2. 然后说了经典的GC算法--标记复制，标记清除，标记整理，分代，
    3. 然后说了CMS和G1的实现核心原理，详细说了CMS的GC过程--这里面试好像没注意听了，因为一个多小时了已经，也是八股文，我就一直讲；
15. 然后问currenthashmap----我大概说了下JDK七之前使用分段锁来提高并发度，JDK八以后取消的分段锁，我记得是用cas做了优化，但是没看过具体实现，就老实说没看具体怎么实现的，大概使用Synchronized做了get和set的同步控制，然后数据结构和hashmap基本一致，然后面试官就没怎么问了，直接开启下一题------emmm这道题真的是，八股文背了七股-一股没背，送分题让我给丢了：），因为想的是后边系统看一下juc下的源码，就没想为了应付面试看currenthashmap，说实话最近三四场面试都问到了currenthashmap，但是我都没答上来hhhhh
16. 问类加载机制----老重八问题了

最后：面试官说今天的面试也一个多小时了，就到这里先，也没有反问环节就直接结束了，面完一个半多小时了，经历的单次最长的面试，乘着热乎记录一下，可能不完全，但是大差不差；

总体来说面试内容比较多但是比较简单，微服务架构尤其springcloud那一套都没怎么详细看过，最近一直在研究偏底层的技术细节，但是之前了解到的一些核心思想都可以讲明白，前年大概看过eurake的代码，但是看的不细，重要的是最近在分布式任务调度组件中设计中对线程并发，分布式一致性，分布式集群管理有了一些比较深刻的认识，虽然没有去get太多的新技术点，但是就已经很够了，另外看netty源码，虽然没有问到过，但是也学习到了很多，计算机技术很多都是相通的---因为最近才开始系统性的学一些底层的东西，所以自己没啥把握完全通过面试，慢慢来吧；