前言

??本文主要分兩部分，前半部分聊了聊這次找工作中我自己的一些想法和體會，因為是隨性而發(fā)，可能會寫得比較啰嗦，第二部分才是實際的面試題記錄和我的回答思路，如果只是想了解下面試題的小伙伴直接跳去第二部分開始看吧~
??另外面試題中我是有選擇性地記錄的，記錄的標(biāo)準(zhǔn)是，我個人認為問得比較有水平的，我感覺自己沒回答好的，或者說我覺得這部分還沒形成自己的知識積累，先記下來作為以后的學(xué)習(xí)參考的。所以里面所寫的回答的思路不一定對，而且記錄里也沒涉及到特別基礎(chǔ)的那部分知識，如果是想?yún)⒖蓟A(chǔ)部分的知識的話在下更推薦你去 https://github.com/CyC2018/CS-Notes/ 這里去整體過一遍。
??那么接下來開始第一部分~

一、對于找工作，個人的一些想法和體會

1. 關(guān)于個人的提升與學(xué)習(xí)，以及學(xué)習(xí)的針對性

?? 1）需要明確的第一點是，在軟件開發(fā)這一塊，無論想要學(xué)習(xí)什么，首先你得基礎(chǔ)足夠好。因為無論學(xué)習(xí)看起來多么炫酷，高大上的軟件技術(shù)，其本質(zhì)上還是離不開兩點：①它是以編程語言作為表達載體的；②它是以電子計算機作為運行載體的。明白這兩點之后會發(fā)現(xiàn)，其實很多東西萬變不離其宗，基礎(chǔ)足夠好的人，學(xué)習(xí)起來的效率也會比其他硬啃的人高很多。
?? 2）那么問題來了，所謂的基礎(chǔ)是指什么？①以一個程序員的角度上來說，首先得對馮·諾依曼提出的計算機體系結(jié)構(gòu)的工作原理（包括CPU，內(nèi)存，磁盤等，當(dāng)然也不用很深，畢竟又不是做硬件開發(fā)的）有一定的了解，其次要了解計算機網(wǎng)絡(luò)，包括TCP/IP，UDP，HTTP等知識；②進一步說，從一個JAVA程序員的角度出發(fā)，你當(dāng)然需要對JDK的語法，各項特性，原生提供的各種API都有一定程度的熟悉，同時對JVM內(nèi)存模型有所了解，然后就是對里面一些經(jīng)典的數(shù)據(jù)結(jié)構(gòu)有對其源碼有自己的理解和體會，例如最為大家廣泛流傳的HashMap，里面包含的hash一致性，散列表，鏈表，平衡二叉樹，以及其精妙絕倫的對于位運算的運用，能把它內(nèi)部學(xué)通一遍會有非常大的收獲；
?? 3）不少小伙伴會疑惑，這些東西是不是就是為了學(xué)來“面試造火箭”的？“上班擰螺絲”的時候真的能用上嗎？我想說，真的有用，但我這里不知道該怎么舉出例子來說服你，我只能說，當(dāng)你積累的知識足夠多的時候，回過頭去和自己曾經(jīng)的工作經(jīng)驗結(jié)合起來去細細體會，你會發(fā)現(xiàn)它們其實很有用，但是你積累不夠多之前沒法發(fā)現(xiàn)而已。
?? 4）除了基礎(chǔ)需要扎實外，學(xué)習(xí)還需要有針對性。我們常常說知識之海，你能把整個大海喝下去嗎？不能的，精力有限，時間有限。有一種說法叫做T字形的知識結(jié)構(gòu)，就是在學(xué)習(xí)上有一定的廣度，同時每一塊也有一定的深度，這個該如何平衡要看個人，也看你的目標(biāo)。例如有人想去阿里，阿里是做什么的啊？做支付，做金融，那么就要有針對性地了解有什么技術(shù)是互聯(lián)網(wǎng)通用的，同時關(guān)注金融，支付相關(guān)的特別適用的，契合度高的相關(guān)技術(shù)。

2. 裸辭還是騎牛找馬？

??關(guān)于這一點的話，每個人情況不一樣，我只能結(jié)合自己的情況給出一些想法，諸君想如何選擇還是看自己。
?? 1） 首先我個人的性格特征是，在某一個方面受到比較大的壓力時（這里特指工作）會消耗大量精力，進而導(dǎo)致其他方面的思考能力降低，容易鉆牛角尖。所以對我個人來說，每隔一個較長的周期之后，給自己一段相對比較放松的時間去好好整理自己的知識網(wǎng)絡(luò)，并且思考總結(jié)，想明白一些事情，是很必要的（我裸辭后那小半個月的時間想明白的問題比前面半年可能都多），所以對我來說，先辭職，自我整理，然后重新開始下一段工作，是一個比較好的過程。當(dāng)然這也與我個人的調(diào)整能力不高有一定關(guān)系，能自我調(diào)整壓力進行思考的小伙伴可能對于裸辭放松的必要性不大；
?? 2）裸辭之后的心理壓力，對于自己的經(jīng)濟儲備以及求職信心來說是負相關(guān)的。你的經(jīng)濟儲備越多，對于找工作的自信越強，你賦閑在家時的壓力就相對??；反過來說，經(jīng)濟儲備不足，而且對于求職信心不足，裸辭反而會讓你個人非常非常非常焦慮，壓力會把你壓得喘不過氣來，這樣的話反而得不到放松思考的效果了，還不如騎牛找馬，找到下家了再平滑過度；
?? 3） 對于我個人來說還有一點是我是跨城市從廣州跳槽上海，雖然現(xiàn)在大部分大公司都支持電話交流，但實際上我個人是覺得還是面對面聊天更靠譜一點，所以我這邊除了裸辭之外其實沒其他很好的選擇。至于跨城市求職的話，如果經(jīng)濟儲備還行，而且身上有貴重物品的，不妨找個1~2月的短租房，小豬短租，airbnb都是不錯的平臺，有個好的地方住也有助于你一邊求職一邊專心整理，學(xué)習(xí)。

3. 對于外包公司的一些看法

??大多數(shù)人不建議年輕人進外包公司，從我個人來說，包括人員外包和項目外包的公司我都做過，可以跟大家聊聊我的看法。
?? 1） 并不是所有的外包公司都是需要看甲方臉色的，這個跟自己同時也跟甲方公司文化有關(guān)系。不管是項目外包還是人員外包，作為乙方都需要和甲方對接這個毋庸置疑，有部分甲方公司會把乙方人員看做純粹是來干苦工的，甚至覺得自己身份比對方高，這種乙方過去了基本上就是受氣的，而且可能得不到任何提升，去了就是一片黑暗的未來；
??而另一種甲方，除了讓乙方干活之外，也會把乙方看做是人才儲備，在部門有HC且乙方表現(xiàn)出色的情況下會考慮引薦，至少在我上一家公司，領(lǐng)導(dǎo)（不管是我方還是甲方）其實都挺信任我，給了我很多嘗試實踐的機會（也因此犯了不少錯，讓他們幫我背了黑鍋，想想還是有點抱歉的），走的時候也是問過我要不要考慮加入他們。所以，雖然我也并不推薦做外包，但如果在出路不多的情況下，也沒必要鉆牛角尖寧愿餓死也不去外包，至少混口飯吃總是可以的；
?? 2）哪怕不用看臉色，在甲方的地盤上班還是會讓你明顯感覺出自己是個外人。雖然我上面說了有部分公司（包括大部分知名外企，互聯(lián)網(wǎng)企業(yè)，也包括一些文化相對開放的國企）甲方跟乙方的工作內(nèi)容和人員處于一個相對平等的地位，但實際上在組織編制上，員工福利上，提升機會上，以及部分核心的保密的工作內(nèi)容上，你還是會在里面處處感覺自己像個外人，時間久了會越做心里越委屈（真的就是覺得委屈，不是矯情），而且想要轉(zhuǎn)正也是需要等對方的HC，哪怕有了HC，人家也可能會更愿意拿來招211985的應(yīng)屆大學(xué)生而不是引薦你轉(zhuǎn)正。
??所以其實說句比較尖銳的話就是，公司之所以招乙方，其實更多的是因為乙方人員好打發(fā)，轉(zhuǎn)正不是完全沒機會，但其實有限。至少我個人目前是不想再去外包公司了，除非是已經(jīng)沒有出路的情況下。

4. 寫簡歷需要注意的事情

??簡歷上盡量要求真務(wù)實，有自知之明，并且自信，自己會什么就寫什么，對于自己擅長的點可以稍加筆墨詳細點去描述，而對于自己只懂點皮毛的點則慎用熟悉，精通等詞，更建議用了解這個詞（見過有人用會用XXX這種描述寫到簡歷上的，我只能說emmmm真睿智），因為你簡歷如果寫得太浮夸，自己明明只懂點皮毛偏要寫個精通上去，最后面試的時候答不出題會異常尷尬，而且面試官對你的印象也會很差，覺得你在造假。

5. 面試時的溝通技巧，怎么樣給面試官留下好印象

?? 1） 面試的時候其實也跟寫簡歷類似，需要你有自知之明，并且自信。①如果面試官提出了你不熟悉的問題，直白點說出自己知道的東西，剩下的就直接說不知道或者不清楚，然后也可以主動提出說其實你的精力集中在了某方面，所以對當(dāng)前問的這個問題理解不深，這樣來引導(dǎo)面試官去了解你擅長的方面；②如果面試官提出的問題剛好是你熟悉的，下過苦工去鉆研的，盡量多說點，保持邏輯清晰，思路清楚，并且加入自己的理解最好，就我目前發(fā)現(xiàn)來說，面試官對于能說清楚知識點之余同時加入自己的思考和理解的人會很欣賞；
?? 2） 說話的時候有禮貌，條理清晰就好，其他的什么技巧其實也是細枝末節(jié)。很多時候其實面試也講究一個相性的問題，你跟面試官的相性高，那很容易可以跟對方談笑風(fēng)生；但大多數(shù)情況下兩個陌生人見面聊天也就是一個你問我答的過程，有基本的禮貌，回答問題邏輯清晰，保持跟對方的交流而不是你自己自顧自地說就好，其他的什么亂七八糟的什么微表情什么心理學(xué)的技巧都是畫蛇添足了，你是去面試當(dāng)程序員而不是心理醫(yī)生；
?? 2） 面試的時候要心態(tài)好，不要覺得面試官身份比你高因而覺得緊張甚至害怕，面試官更愿意看到一個自信的，思維清晰的人。要知道面試是一個雙方互相選擇互相交流的過程，你跟面試官在這個過程中是平等的，大家都是人，面試官可能無非就是技術(shù)比你好，收入比你高，難道他因為比你強一點就不是人而是神了嗎？
?? 3） 面試除了你回答面試官的問題之外，其實也可以向他請教你的疑惑。前面已經(jīng)說了，面試是一個雙方互相平等交流，選擇的過程，有素質(zhì)的面試官，往往會在對你的提問結(jié)束后給你時間去提問，這個時候除了關(guān)于公司的問題之外，其實也可以提出你自己私人上一些疑惑和問題，實際上說不定還可以得到加分，因為，你會產(chǎn)生疑惑，說明你是真的下了不少心思去鉆研它，而前面也提過，部分面試官會非常欣賞有獨立思考能力的人。
??以我個人舉例子的話，提問環(huán)節(jié)我會喜歡先提問公司的營業(yè)模式，技術(shù)棧，開發(fā)時會遇到的一些挑戰(zhàn)和難題，最后提出自己最近的一些疑惑，例如這陣子的面試，我都會提出【對于學(xué)習(xí)的深度與廣度上的取舍與平衡，您個人有經(jīng)驗可以分享下嗎？】以及【如果自己學(xué)習(xí)到的新知識無法在公司的實際項目中得到實踐，如何自己創(chuàng)造機會去做實踐呢？】這兩個問題，前輩們也都很友善地給我分享了他們的想法，也不得不說每個人看問題的角度不一樣，綜合他們的經(jīng)驗下也讓我得到了不少收獲。


那么我個人的總結(jié)到這里結(jié)束了，下面就是我整理的印象比較深的面試題。

二、面試記錄

20190509 ebay初面：

一）開發(fā)計劃中的角色，職責(zé)，代碼主要寫的什么內(nèi)容，涉及到什么邏輯之類的

1. 參與業(yè)務(wù)分析與開發(fā)方案的設(shè)計，從業(yè)務(wù)需求轉(zhuǎn)換到具體的web api接口
2. 開發(fā)方面主要涉及到

1. 微服務(wù)接口開發(fā)，一般的邏輯包括：
   1.) 入?yún)⒌谋靥铐?，或者有條件的必填項
   2.) 貼合業(yè)務(wù)邏輯的代碼編寫，基本上就是CRUD，有可能根據(jù)需要外呼其他接口
   3.) 若發(fā)生異常（程序異常，業(yè)務(wù)異常）根據(jù)不同異常情況返回提示信息
   4.) 成功則根據(jù)消息格式返回
2. 定時任務(wù)的開發(fā)，一般邏輯為：
   1.) 檢查當(dāng)前異步程序的執(zhí)行要素是否齊全，不齊全則寫日志，直接退出
   2.) 根據(jù)執(zhí)行要素開始程序，任務(wù)多為IO密集型，會開多線程
   3.) 多線程，為了保證一致性，一般用
   ??i.生產(chǎn)者-消費者模式，在主線程將數(shù)據(jù)進行分割，避免沖突
   ??ii.無法避免沖突的情況下，使用鎖，鎖的粒度盡量小，以減少鎖占用時間

二）接口設(shè)計的個人體會和經(jīng)驗

1. 考慮接口的出參和入?yún)⒏袷?/li>
2. 考慮異常情況及異常發(fā)生時的提示
3. 接口的擴展性，業(yè)務(wù)變更可能性
4. 代碼追求簡潔高效，SQL同理

20190510 平安壹錢包

一）簡單算法：

??如何翻轉(zhuǎn)字符串:
??當(dāng)時的回答：轉(zhuǎn)成char數(shù)組，循環(huán)長度的一半，頭尾交換值；
??回答的算法是正確的，但可能說得太簡練，而且也是最常見的方法，對方反饋一般般，下次算法題考慮說詳細點

二）zookeeper的使用和理解，以及原理

??這里簡單地答了應(yīng)用，和服務(wù)發(fā)現(xiàn)，注冊，心跳，負載均衡，和ZAB一致性協(xié)議，但因為原理研究不深，應(yīng)用也沒答全（沒有說分布式鎖，也沒說到集群管理之類的），反饋一般
??考慮找時間詳細地補一下zookeeper的原理
??同理也應(yīng)該詳細補一下kafka的原理，甚至源碼
??redis只是簡單問了應(yīng)用，使用場景，但后續(xù)估計會問到工作原理，有時間也需要準(zhǔn)備一下
??spring原理現(xiàn)在感覺都問爛了，面試官都懶得問了，我還特地花了那么多心思去鉆呢（殘念臉

三）有部分回答可能會顯得有些啰嗦，例如問到溝通，問到團隊合作，之類的，應(yīng)盡量簡潔高效地回答對方自己的處事方式和工作溝通

四）說出自己比較做得比較好的項目和理解，這一塊前面答得略微簡單，可以考慮以下回答：

??簡單回答最近在CCB做的這個項目就是最有挑戰(zhàn)性的，因為前面都是單體式應(yīng)用，這是第一次接觸分布式，并發(fā)量可能高達幾千上萬，同時數(shù)據(jù)量也達到了千萬級甚至億級，對開發(fā)工作的要求嚴(yán)格很多。我對于這個項目的研究和學(xué)習(xí)里對與分布式與微服務(wù)得到了不少的理解，同時也在這個項目中學(xué)習(xí)到了各種比較流行的，包括kafka，redis等流行的中間件應(yīng)用，同時也會面對更復(fù)雜的業(yè)務(wù)場景，使我對于業(yè)務(wù)和技術(shù)結(jié)合有了更深的理解。
??我在這個項目中負責(zé)相關(guān)的業(yè)務(wù)分析和開發(fā)方案的設(shè)計，開發(fā)日程的討論，以及開發(fā)微服務(wù)接口和異步程序，除此之外也負責(zé)對新同事進行基礎(chǔ)的技術(shù)和業(yè)務(wù)培訓(xùn)，給他們的開發(fā)工作進行指導(dǎo)

20190513 eBay二面：

一） 第一個面試官，感覺考察的是架構(gòu)能力，問題的分析和追蹤能力，同時還順便考察了知識面的廣度

??一上來就先畫了一下他們某個電商微服務(wù)的架構(gòu)圖讓我分析問題，記錄如下：

簡單記錄的架構(gòu)圖

（我就隨便跟著印象瞎畫一下，我知道很糟糕，希望未來的我看到了不要回來打現(xiàn)在的我）

??當(dāng)時初步提供的信息里沒提到持久層MQ，后來我問出來的。
??提出的問題是：兩個請求A和B，A將value從F更新成T，B從T更新成F，執(zhí)行結(jié)束后在DB查到的結(jié)果是T，但是log console里可以查到有A和B完整執(zhí)行的記錄，請查找原因
??在一步步的詢問查找，包括對框架的分析中可以知道，由于在log console中可以找到執(zhí)行日志，且前面從前端到scheduler到worker集群都是保證順序的，所以通過log console的結(jié)果可以看出問題并不在前面的步驟。
??最后得出的結(jié)論是在持久層API內(nèi)的問題，因為MQ并不是直接操作到持久層的，而是發(fā)送請求到持久層，由持久層API進行操作，我一開始沒問清楚，以為持久層是直接操作。
??至于為什么會出問題，因為持久層的API也是集群（很雞賊，我前面問的時候告訴我持久層可以看做是一個單體API，但是后來挑明之后又告訴我看做是單體API是從外部的角度來看，只向外部暴露了API，外部不需要知道內(nèi)部細節(jié)，但內(nèi)部實際上是一套持久層API的集群），在集群中，可能A和B被分配到了不同的持久層節(jié)點，雖然MQ內(nèi)是有順序的，但是可能A在執(zhí)行過程中節(jié)點被阻塞，導(dǎo)致B的操作先完成了，最后導(dǎo)致A后更新。
??解決方法：一開始考慮了在持久層內(nèi)部使用raft算法或者別的選舉算法來定位一個Leader，由leader來保證順序，但是這樣對吞吐量不利，實際上更多地應(yīng)該考慮使用樂觀鎖可以解決問題。

二） 第二個面試官，感覺側(cè)重在對以前項目的理解深度，包括業(yè)務(wù)，架構(gòu)和開發(fā)模式等等，順便也考察了面試者有沒有主動去對框架和架構(gòu)進行了解學(xué)習(xí)的積極性？另一方面就是重點考察基礎(chǔ)知識，特別是多線程

1. 寫一個死鎖程序：
   ??媽蛋當(dāng)時太緊張忘了，后來面試完在路上突然間又想起來了，但是也是因為對死鎖理解不夠深，多線程還要繼續(xù)補補，而且記住以后面試千萬不要緊張

2. kafka（MQ）的分區(qū)，擴展怎么擴，根據(jù)什么來擴容？
   一開始以為這里問的是業(yè)務(wù)場景，但是回頭想想應(yīng)該問的是kafka的分區(qū)原理

3. 說一下線程同步，如何保證？
   對于線程同步的理解不夠清晰沒答好，后續(xù)補
   
   回來查了一些資料之后我認為相對靠譜的答案：線程同步，從內(nèi)存的角度上來說，在多線程環(huán)境下，對同一個內(nèi)存地址進行操作，同一時間內(nèi)只能有一個線程進行操作，其他線程必須要等待；從程序的角度上看的話，就是多線程環(huán)境下，多個線程對同一個公共資源進行操作時，這個資源的狀態(tài)的變化在所有線程角度上觀察是一致且有序的。
   要保證線程同步，那就要保證每次對公共資源進行寫操作的時候，只能有一個線程參與，其他線程只能等待。想要做到這一點，可以通過synchronized關(guān)鍵字或者lock接口對資源進行加鎖
   除了對資源進行加鎖之外還可以對方法，或者片面的代碼塊進行加鎖，如此在執(zhí)行相關(guān)的代碼時就只能是單個線程參與。

4. JVM如果發(fā)生OOM如何查問題
   基本思路是對的，查看最近的接口是否有長時間存活的大對象，是否對大文件讀寫沒注意，查看是否集合類被一直引用；
   跟蹤GC情況，用jstat –gcutil
   生成堆快照，jmap
   分析堆快照，jhat
   還可以用包括eclipse等ide進行分析

5. 問到了項目間用什么協(xié)議通訊
   因為緊張把網(wǎng)絡(luò)協(xié)議的知識都忘了，沒答好，說了TCP（扶額），實際上應(yīng)該是HTTP，內(nèi)部用流進行傳輸

三） 第三個面試官跟第二個差不多，也是重點考察基礎(chǔ)，基礎(chǔ)進階，包括多線程和JVM等，同時還考察了方案設(shè)計能力

1. 聊聊JVM的內(nèi)存結(jié)構(gòu)，順便說說GC
   當(dāng)時把VM棧和本地方法棧的作用忘了，其他答得還行
   JVM棧記錄的是JAVA方法執(zhí)行的內(nèi)存模型，存儲了包括局部變量表，操作數(shù)棧，方法出口等等信息，
   本地方法棧同理，不過記錄的是native方法的信息

2. 講講簡歷中提到的，開發(fā)的定時任務(wù)，異步任務(wù)之類的思路
   當(dāng)時常規(guī)地講到了大部分是IO密集型的數(shù)據(jù)處理任務(wù)，然后跟他聊了聊常用的生產(chǎn)者-消費者模式
   詳細地問完，反問我，如果生產(chǎn)者對于數(shù)據(jù)的生產(chǎn)速度較慢，需要也用多線程生產(chǎn)怎么辦
   生產(chǎn)者線程組跟消費者生產(chǎn)組分隔開，中間建立一個調(diào)度線程，調(diào)度線程負責(zé)對生產(chǎn)者的發(fā)送的數(shù)據(jù)作為一個緩沖，緩沖池有個最大值，當(dāng)生產(chǎn)者檢查到緩沖池滿了，則休眠，調(diào)度線程會喚醒消費線程；同理，消費線程不運作的時候會休眠

3. 索引

20190513 螞蟻金服初面，電面

一） 分布式事務(wù)

分布式事務(wù)，首先可以圍繞著CAP定理開始聊
聊完之后考慮實現(xiàn)方式，包括2PC（二階段提交）和TCC（補償事務(wù)）
也可以異步MQ記賬，最后通過日終核算以及人工補償達到最終一致性

二）問了排序算法，回答了冒泡排序和快速排序

后來被追問時間復(fù)雜度，忘記怎么算了，撲街

20190515 花旗銀行

一）關(guān)于線程池，JDK原生提供的幾種線程池，自己創(chuàng)建線程池的話對于參數(shù)設(shè)置的心得

例如說某塊功能需要用線程池做處理，有峰值低估，該怎么設(shè)置？
原生提供的線程池包括single（單線程），fixed（固定長度），cache（可緩存可回收利用），scheduled（定長，支持周期性或定時任務(wù)，用schedule方法而不是execute來執(zhí)行）
corePoolSize核心線程數(shù)（當(dāng)忙碌線程數(shù)小于核心線程數(shù)時，會將已有的空閑線程回收再用，節(jié)省資源），maximumPoolSize最大線程數(shù)，線程池中允許線程數(shù)最大值
keepAliveTime 空閑線程的最大存活時間
workQueue 提供存放待運行的任務(wù)隊列的隊列類型，有多種策略
RejectedExecutionHandler 拒絕策略接口

二）關(guān)于synchronized

部分基礎(chǔ)細節(jié)記不清楚，回答的時候很模糊，記錄如下：

1. 將synchronized加到方法定義上，起什么作用，分兩種情況，
   1. 如果是一般方法，則相當(dāng)于將當(dāng)前對象加鎖，例如對象A，有method1和method2加了synchronized，那么當(dāng)線程T1調(diào)用A.method1，線程T2調(diào)用method2，由于是對A對象實例加鎖，所以會根據(jù)加鎖順序，先執(zhí)行T1，再執(zhí)行T2
   2. 但是如果T1和T2調(diào)用的是不一樣的對象，例如T1調(diào)用A.method1，T2調(diào)用B.method2，那么兩個線程之間加鎖對象不一樣，沒有順序，但有一種情況，如果method1和method2調(diào)用了靜態(tài)變量，那么會產(chǎn)生對靜態(tài)變量的競爭，會自動對靜態(tài)變量加鎖，所以也會有順序
2. 如果是synchronized加到靜態(tài)方法上的話，就是對類進行加鎖，而不是對對象實例進行加鎖，或者說是對類A的class對象加鎖

三）算法題問到的是一個動態(tài)規(guī)劃的應(yīng)用場景，但是相對簡單，用普通的遞歸也可以做

??這里回答得不太好，沒有一開始想到用動態(tài)規(guī)劃，稍微需要對算法也補一下

20190517 壹沓科技（爬蟲，大數(shù)據(jù)，機器學(xué)習(xí)）

一）問到項目內(nèi)相關(guān)技術(shù)選型的經(jīng)驗，判斷標(biāo)準(zhǔn)，并舉出具體例子

1. 選型，根據(jù)場景考慮需要用什么，然后對這個工具進行初步的了解，學(xué)會它是怎么用的，怎么樣可以解決目前的問題，最后將其與其他類似或相同功能的東西進行對比，判斷我為什么要用它，同時也參考網(wǎng)絡(luò)上其他人的使用經(jīng)驗等，最后自己進行參考，并且進行實際的測試
2. 例如說kafka，我個人目前對它理解里比較看重的兩點是，
   1. 它配合zk一起使用，可以對分區(qū)進行靈活的擴展，有助于提高吞吐量，而且使用簡單；這一塊是對應(yīng)我們的業(yè)務(wù)場景之余也是考慮到我們公司的背景，我們那邊其實也是為了這塊的功能，第一次引入使用MQ，當(dāng)時考慮的是，選一款簡單易上手的MQ進行使用，甚至可能組內(nèi)別的功能會直接用我這邊搭建完成的現(xiàn)成的東西，也想選一個對于分區(qū)上方便擴展的東西來用，所以同時也是剛好我個人在學(xué)習(xí)kafka mq，我就自告奮勇的接下來了來做這個東西；
   2. 關(guān)于第二點的話，我這邊了解到kafka對比其他的MQ，在實時性上的性能是比較遜色的，但是它有一個很好的特性就是它會使用到硬盤的log文件進行一個消息的持久化，我們其實也是看重了這一點，我們那邊是銀行機構(gòu)嘛，可能更傾向于使用容災(zāi)性強的，并且恢復(fù)簡單的工具，同時也想選用一個使用簡單方便培訓(xùn)的工具，后續(xù)擴展，推廣可以開箱即用，kafka在這一點上也很符合我們的期望；
   3. 至于第三點就會比較簡單了，就是我個人在過程中也根據(jù)我們的業(yè)務(wù)場景去進行了嘗試，當(dāng)時上游接口告訴我們說會有每秒5~7千，峰值可能會到達上萬的消息傳輸量，而我這邊進行過自己的實測，kafka哪怕是單分區(qū)情況下，每秒鐘進行2w的生產(chǎn)和消費是完全沒有性能瓶頸的，這里已經(jīng)是達到了我們業(yè)務(wù)預(yù)測值的兩倍了，所以也會認為它是符合我們的期望

就經(jīng)過上述幾點的考慮的話，我們這邊引入了kafka作為我們對于MQ的第一次嘗試

20190521 拉卡拉（支付）

一）分布式架構(gòu)中該如何拆分微服務(wù)？可以按些什么標(biāo)準(zhǔn)，有些什么方法論？

當(dāng)時回答的是可以按業(yè)務(wù)拆分（這也是最常見的一種方式），至于如何確定拆分粒度，當(dāng)時提出了一些《聊聊架構(gòu)》中的一些思想，包括核心生命周期與非核心生命周期。但因為這兩塊學(xué)得還不夠透徹，沒有形成足夠的知識積累，后面再深入學(xué)習(xí)架構(gòu)方面的知識。

二）還是問到了分布式事務(wù)的基礎(chǔ)。同時問，如果一個分布式事務(wù)，涉及到一個很長的調(diào)用鏈，而且橫跨多個模塊，該如何設(shè)計它來盡量提高容錯率和正確率？直接設(shè)計一個可行的方案。

這里其實用不著什么2PC和TCC了，根本不實用，其實大型的分布式事務(wù)可以考慮使用異步MQ進行調(diào)用鏈的合并，最后用日終對賬/核算來處理異常情況。

三）還是談到了中間件的選型，談到了kafka看中了它什么特性，回答說了前面提出過的回答，被追問，其他MQ也有持久化的策略，而且也有入門難度低且速度快的，有沒有仔細對比過？

這一塊沒答出來，后續(xù)考慮對技術(shù)選型方面的考慮和知識考慮更深點。