公司：安硕信息
薪资：11k-20k *13
面试时间：40min
主营业务：信贷管理系统，分控产品，主要客户是各大银行
面试方式：腾讯会议
面试人数：4人（产品经理和同事，hr旁听）
注意点：斟酌简历中的每一句话
特点：感觉技术面没有深挖，回答一个问题基本回答就结束，不会根据回答深挖，另外建议在职找工作，在职可以给hr安全感
二面心得：研发总经理面，问过往史？过往确实很烂，也没什么光彩的历史，但是找工作是一个我选择你大于你选择我的过程，面试过程不必卑微，勇敢提出质疑，反驳，建议。
介绍一下自己负责的模块，代办，kpi，审批？
微服务是怎么拆分的？
需求评审是怎么做的？怎么进行可行性分析？
每天需要进行汇报工作吗？是怎么汇报工作的？模拟一下？
为什么来这边工作？
期望薪资？
每天的学习方式？和学习时间？
加班的强度？
有没有女朋友？我：what？
有两个项目：一个是优化sql，底层封装；另一个是综合技术和业务你更倾向于哪一个项目？
你比较喜欢新技术，但是我这边有的项目很老，你愿意维护吗？（老技术学原理！）
除了看书业余时间用来干嘛？
平时喝不喝酒，去不去ktv唱歌？
缓存穿透：指的是数据库和缓存中都没有，用户请求直接打到服务器，使缓存不可用
解决方案：1、接收参数时过滤不合法的值，如空值，负值，例如过滤掉查询id为-1的请求
2、布隆过滤器：类似于hash表的一种算法，将所有可能的查询条件生成一个bitmap，查询时使用bitmap过滤请求，从而减轻数据库的压力
3、空值缓存：在第一次查询完不存在的数据后，将该key与对应的空值也放入缓存中，只不过设定为较短的失效时间，例如几分钟，这样则可以应对短时间的大量的该key攻击，设置为较短的失效时间是因为该值可能业务无关，存在意义不大，且该次的查询也未必是攻击者发起，无过久存储的必要，故可以早点失效
缓存雪崩：缓存服务器挂掉或者热点key集中过期，所有的请求打到数据库中，从而导致数据库连接不够，或者数据库处理不过来，从而导致整个数据库挂掉。
解决方案：1、加锁排队，使线程互斥，但是降低了QPS
2、交错key的失效时间，避免同一时间key全部失效
缓存击穿：缓存击穿实际上是缓存雪崩的一个特例，缓存中没有，数据库中有，热点key过期导致请求直接打到服务器上，导致服务器不可用。
解决方案：1、缓存设置不过期
上次面试问到，不做赘述
上次面试问到，不做赘述
事务：事务可以看成是由多个小事件一起组成的一个大事件，这些小事件要么全部成功，则整个事件成功；如果有任意一个事件失败，则所有事件均宣告失败，并恢复成事件执行之前的样子
ACID：原子性，一致性（正确性），隔离性（数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务的运行过程的中间状态。通过配置事务隔离级别可以比避免脏读、重复读问题。），持久性（数据持久化到数据库中）
分布式事务：分布式系统把一个单体应用系统拆分成可独立部署的多个微服务，很多场景下需要服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务
产生场景：跨服务，或者数据库
CAP： 是 Consistency、Availability、Partition tolerance 三个单词的缩写，分别表示一致性、可用性和分区容忍性。一个分布式系统最多只能同时满足一致性、可用性和分区容错性这三项中的两项。
以jar包发布springboot项目时，默认会先使用jar包同级目录下的application.properties来作为项目配置文件。但使用–spring.config.location指定了配置文件，则读取指定的配置文件。
如果在不同的目录中存在多个配置文件，它的读取顺序是：
config/application.properties（项目同级目录中config目录下）
config/application.yml
application.properties（项目同级目录下）
application.yml
resources/config/application.properties（项目resources目录中config目录下）
resources/config/application.yml
resources/application.properties（项目的resources目录下）
resources/application.yml
我：
薪资是在什么环节谈？（复试）
项目周期？和项目人数？（看项目大小，几人至上百人，几个月至几年）
入职有没有业务培训？
公司旁边好租房吗？租金大概多少？通勤时间如何？（1000Y，20min）
薪酬制度？出差怎么算工资？
高考分数？
考研没考上为什么直接选择工作？
大学的成绩？
职业发展规划？（我的发展规划是没想在第二家公司长久干下去。第二家公司应该是个公司和个人互相成长的平台，完成公司任务，学习技术与业务，这个平台也是一个跳板，对于这个问题怎么回答欢迎在评论区讨论）
如何做需求评审？如何拆解需求和任务？（这是个开发人员参与且必须要思考的地方，专门去查询了相关的资料，反思了公司流程的不足）
1、需求评审过程中作为开发应该搞清楚，需求的背景目的和意义（确定需求是否偏离了用户的原视需求）。
2、需求文档的错别字，文字和图案不符造成整个过程的正式性和权威性，需求文档是测试和开发依据，不应该存在错误点。
2、需求评审需要有正式健全的文档和资料，形式越正式，参会人员才会更加重视这次会议。
3、产品喜欢直接找切入点，把新人说懵，新人并不知道设计逻辑，产品应该从源头介绍详细把听众当作小白用户，然后参会人员才能给出合理的建议。需求评审是一个产品自我复习和反省（逻辑能否理清楚）的过程，所以产品能否表意清晰很重要。需求评审主要是为了补全产品的设计细节，所以有必要说细节。
4、需求评审要形成会议纪要确定优化点和有争议的地方，确定是否需要二次评审。
5、需求评审的周期要尽量的长逐个字段，逐个功能点分析，有关联模块要去了解关联模块的前因后果，保证开发排期和设计的合理性。
6、开发需求评审过后需要给出具体的排期时间，落实到每一个功能点。
7、测试按照需求文档测试，明确职责，不能直接向开发提出优化点，可以向需求方提出优化点，提出优化点需要全程协同开发。
8、产品交付质量低，重复返工。开发完后，要增加产品的试错成本，例如需求文档以外的内容需要产品全程协同开发（一起加班），不然产品老是中途提出优化点，还会咄咄逼人的说今天必须上线，最后开发不仅付出了大量的时间，并且落下重复返工，效率低下的罪名。
9、验收方不是需求设计方，老板验收，随老板怎么讲，老板应该全程参与需求评审的，或者最终需求文档交由老板验收，老板验收结果为开发依据和产品的验收依据。
10、需求5大评审点：正确性（需求文档图文正确，功能目的正确）；明确性（保证项目干系人都能看懂，且理解一致）；完整性（完成用户的所有功能，和交互点）；限制性（输入输出的条件限制）；一致性（需求文档前后一致，不冲突），只要不满足其中任意一个评审点就需要二次评审。
11、优化点是否执行需要考虑他的难度和耗时，性价比。比如用户量不大的系统要求多级审批没有必要，要考虑发展的话后期迭代更新，现在也需要人力成本。内部系统没必要保证实时性，你又不做实时的数据分析，并制定处理策略，你只需要在固定的时间能看到信息就行。
12、商业化的功能和内部功能解耦合。
13、老板是土皇帝，权力太大无法制衡，说什么就是什么，没有什么君主立宪制，三权分立啥的。
为什么需要排期？
当产品经理提出一个需求后，作为需求方，例如市场部、运营部或客户，都是希望这个需求能尽快上线，并且期望能知道预期可以上线的时间节点，以便安排下一步工作计划。
评估开发工时为什么这么难？
对于产品可能觉得只是加一个小功能，改几行代码，不知道实现细节和关联点；对于老板不懂技术，可能觉得开发工时排期过高；此外，作为技术人员本身而言，评估工时也是一件很有挑战的事情。
工时评估的决定性因素：
1、不确定性：无法考虑到所关联的模块，改了此模块会影响其他模块（产品也无法考虑到），或者增加此功能需要修改其他模块的功能。
2、任务场景：a.同一个任务交给实习生和高级开发工程师是不同的，实习生会有更多的学习和试错成本。b.交给老员工和新职员也是不同的，新职员不了解业务，具有历史包袱。c.如果是新系统需要搭建基础架构。d.确定是否需要和第三方对接，第三发的开发进度是不可控的，需要熟悉对接流程，开发文档，需要沟通和调试成本。e.负责开发的技术人员是否有其他的任务在身。
需求如何排期？
1、需求11个耗时点：框架搭建，数据库设计，编写代码，反复沟通和确认，编写文档和任务，联调，自测，改bug，技术和产品调研，梳理老业务和功能，codereview和代码小步重构。
1、注意三个时间点：联调时间，提测时间，上线时间。
2、从接口数量，交互点，实现细节和难度，是否关联其他模块等因素作出对应的排期。
1、薪资构成
2、社保公积金缴纳比例和基数，到手工资
3、如何调薪，调级，频率
4、年终奖
5、餐补，住房补贴
6、工作时长，加班频率