導讀：紀錄面試的經過，成功有經驗，失敗則有教訓。目前已找到工作，做Java大數據，月base45k，整理總結，希望對你也有幫助。

自我介紹

• 公司介紹，近期的三家公司，在線教育獨角獸、暴風影音、創維數字

• 負責的項目

面向業務的需求開發，親子系統、支付系統、秒殺抽獎等

面向基礎組件封裝，springboot二次封裝、分布式鏈路追蹤系統apm、分布式任務系統等

面向推薦系統開發

面向團隊建設，內部技術分享，包括java并發、基礎組件應用、企業開發規范、推薦技術

為什么離職找工作

• 現有系統已經很穩定了

• 希望自己能進行更好的發展，不要讓自己的技術停滯

• 個人原因

秒殺系統介紹

• 抽獎服務，注意獎品內存扣減

• 抽獎服務，注意獎品池設計

秒殺系統

如何避免緩存雪崩

緩存雪崩分為兩種：

• 自然雪崩(緩存服務器宕機)

• 非自然雪崩(緩存的key在同一時間過期)

解決方案：

• 數據預熱

• 緩存高可用，異地多活

• 限流降級

• 在沒有緩存的情況下加鎖

redis版本

• 阿里云版本2.8

redis應用，不僅僅是做一個kv緩存去用吧(介紹的時候千萬不要拘泥于項目，一定要把redis的功能全部闡述出來)

• 普通的緩存

• 排行榜單

• 分布式鎖

• 地圖坐標，附近的人

• 布隆過濾器(bitmap)

• 網站uv統計(hyperloglog)

• 訂閱發布，可以做簡易的聊天室(消息隊列可以替代)

• 實現分布式的樂觀鎖(watch+multi)

• 支持事務操作(不支持原子性)

• 計數器(incrby)

redis使用的客戶端

• jedis

• redisTemplate

• lettuce，通過大名鼎鼎的netty進行的實現，需要熟悉一下

redis的IO模型

• NIO，異步IO

• 底層是select+epoll做的實現

jvm

jvm參數配置

• 場景1，測試環境一臺機器帶很多個微服務

出現過內存溢出的情況嗎？怎么解決的？

• 同事寫的一個服務，在壓測的時候出現了，開始的時候變慢，到最后出現oom的現象

spring

談一下IOC和DI

• 依賴反轉(開發原則中的

  依賴導致原則

  )

• 自己之前搞過非IOC的項目

• 所有的對象都是自己手動管理

• 如果有一個對象跨模塊使用，則需要在上層進行對象傳遞

• 過程相當痛苦

• 有了Spring的IOC，對象管理全部托管給spring

spring的bean被放在什么地方？

• spring容器

• spring容器是什么？？？

spring boot的啟動過程

• 初始化過程由SpringApplication類在承接

• 推斷應用類型，非web？web tomcat？或者web netty？

• 啟動所有初始化處理器Initializers，

• 啟動所有的監聽器，監聽器基本都是同步監聽

• 啟動context

• 啟動環境相關

• 使用所有的環境變量，這個其實不經常用

• 啟動SpringFactories的實例，都是利用AutoConfiguration的實例，也就是Springboot自動配置和零xml配置的核心，這里模仿了java的SPI機制，很多框架里面都有所使用。

• 主要涉及的文件，resources/META-INF的spring.factories

需要強調

• springboot設置了不同的事件監聽器(例如Listener的starting、環境準備好、上下文準備好等事件)，利用了觀察者模式。

• 啟動過程最重要的是SpringFactoriesLoader進行自動配置的過程(此過程類似于java的spi機制，可以進行適度的發散)

微服務

你使用過的微服務架構

• 主要使用springboot+dubbo

• 需要了解spring cloud的架構

• 需要了解grpc的架構

• 對比微服務優缺點

服務治理是怎么實現的？

• 基礎的遠程調用rpc

• 通過實現負載均衡來實現高可用

• 有容錯機制，

  超時、重試、提供mock數據功能

• 服務自動發現(只需要按照接口注冊)

• 性能日志監控(這里可以通過pinpoint去實現)

• 服務治理中心，實現某節點的禁用(dubbo-admin)

dubbo的服務治理并優秀，主要還是使用的dubbo的高速rpc功能

在分布式系統中，你們的id是怎么處理的？(再次問，雪花算法怎么避免重復)

• 雪花算法

參考：https://www.bilibili.com/video/BV1xK411W7zy?from=search&seid=5732540532182464777發散回答：雪花算法+分表鍵選擇了id+分表數量選擇不規范，導致了數據集中的問題。

1.由于雪花算法中生成的id大多數都是0結尾，這和雪花算法本身有關系，“在同一個毫秒內，如果只生成一個id的話，那么sequence必然是0，最后的id生成也就是固定的0”。
2.在進行分庫分表的時候，如果選擇的不是質數，而是2的n次冪，更有甚者，選擇“10”的話，那么數據將非常的集中，導致了分表后的數據傾斜。

消息隊列

使用過哪些消息隊列？

• activateMq

• rabitMq

• rocketMq

• kafka

說一下優劣

如何實現發現定時消息

自動集成

Jenkins

發散問題

你在公司偶爾做培訓，那么你最近的一次培訓是什么？

• mapStruct插件的相關原理與應用

• 分布式事務seta的簡易實現

• 阿里云機器學習pai簡介

• 簡易爬蟲的實現，實戰爬取股票數據

• 深度學習之人臉識別

---

歡迎點贊+收藏+轉發朋友圈素質三連

看完本文有收獲？請轉發分享給更多人

大數據愛好者社區

文章不錯？點個【在看】吧！??

總結

以上是生活随笔為你收集整理的java opencv4.5 人脸对比_2020大数据Java面试总结（未完待续）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。