Java p2p項目面試題

P2P項目專題

● 具體的你在P2P項目中都干什么了，你負責哪一塊，每一塊實現的時候用到了哪些技術？

● 你們項目的并發量設計了多少？

● P2P項目上線了嗎？

● 你項目中的事務是怎么處理的？

● 在秒殺項目中使用消息隊列ActiveMQ進行流量削峰，如果ActiveMQ接收消息失敗了，怎么辦？

消息在接收后會被服務器刪除，為了避免接收消息失敗而消息又被服務器刪除，此時我們可以關閉自動確認機制AUTO_ACKNOWLEDGE，采用手動消息確認機制，由程序進行消息的確認，接收消息發生異常，則不確認消息，以便于下次可以再次接收。

● 在秒殺項目中使用消息隊列ActiveMQ進行流量削峰，如果ActiveMQ掛掉怎么辦？

第一點，首先消息需要使用持久化消息，服務掛掉，重啟服務后消息依然可以消費，不會丟失；

第二點，ActiveMQ采用主從模式搭建集群，比如搭建3臺主從模式的ActiveMQ集群，提高服務的可用性；

● 在交易中，如何控制超賣問題（賣出去的商品大于數據庫實際商品庫存）？

解決超賣問題，一個是借助于鎖機制實現，這里面有線程鎖、數據庫鎖、分布式鎖等，另一個是借助于某些中間件產品實現，比如Redis；

如果我們的服務只是部署了一臺服務器，我們通過線程鎖即可控制并發問題，控制了并發問題，也就不會產生減庫存的沖突，即不會產生超賣問題，這種實現，效率不高，而且只能是單機部署，實際項目不會采用；

如果我們的服務是集群部署，線程鎖就不行了，此時可以使用數據庫鎖或分布式鎖控制并發問題，從而控制減庫存的沖突，避免超賣問題，數據庫鎖可以采用樂觀鎖、悲觀鎖，其中樂觀鎖比悲觀鎖效率稍高，在實際項目中使用多一些，悲觀鎖使用較少，但由于數據庫本身的性能和并發處理能力并不理想，在高并發項目中，使用數據庫鎖也是不合適的；

使用分布式鎖解決超賣問題，在實際項目中有相關真實的案例，主要采用zookeeper實現分布式鎖，分布式鎖是將我們的線程鎖擴展為多個jvm的鎖，代碼在多個jvm上執行時，分布式鎖也能進行鎖定，因為能鎖定就能控制并發，控制了并發即能控制減庫存的沖突，即可解決超賣問題；

使用一些中間件產品解決超賣問題被經常使用，最被常用的是Redis，在實際項目中被大量使用，由于Redis是單線程的，不管有多少個并發請求，Redis會將請求排隊進行處理，即一個一個地有先后順序地處理，這樣即不會有并發問題，即不會產生減庫存的沖突，從而解決減庫存的超賣問題；

● 在實際項目中，是否使用過多線程？

在P2P項目中，比如在用戶投資到期后需要給用戶回款，此處我們使用了多線程，加快整個回款的速度，我們先從數據庫獲取所有待回款的數據，然后創建一個線程池，每個回款是一個線程，將這些回款線程提交到線程池中執行，從而充分利用服務器的CPU資源快速為用戶回款；

再比如當每個投資用戶生日時，我們會在用戶生日當天給用戶送一個生日紅包，由于同一天有大量用戶生日，我們也是通過多線程為用戶送紅包，先從數據庫獲取當天生日的用戶，然后創建一個線程池，給每個用戶發紅包是一個線程，將這些發紅包線程提交到線程池中執行，從而加速生日紅包的發送任務；

● P2P中的投資及收益金額采用Java中的什么數據類型進行存儲？

由于涉及到精度問題，我們項目中都采用BigDecimal類型，以避免在計算收益時，導致金額精確的損失。

● 你們這個P2P項目上線后采用的是什么訪問協議？

為了數據傳輸的安全性，我們的p2p項目訪問的時候，全部都https協議，https協議會將數據加密傳輸，提高安全性，我們當時公司的運維部門采購了https的安全證書，在服務器上搭建了https協議的訪問方式，如果用戶采用http訪問，我們會自動跳轉到https協議打開網頁；

● 你們P2P項目對金錢是怎么處理的？

項目中涉及到的資金問題，有幾處處理，一個是我們有一個后臺對賬系統，每天會根據第三方支付系統的結算清單，與我們這邊的充值數據進行對賬，保證我們與第三方的數據一致；

對于用戶投資到期后，提現自己的本金和收益，我們后臺系統有專門的提現審核功能，通過系統審核該投資用戶的資金流是否有異常，無異常方可通過提現審核。

● 你們使用定時任務是干什么的？

我們使用定時任務主要是處理一些定時或延遲的工作，這些工作不需要馬上處理，就配置好時間，讓程序在指定的時間或者指定的頻率去執行，比如我們在理財產品投資滿標后，會生成收益計劃，投資到期后給用戶返回收益等，我們都是采用定時任務來完成的，Spring框架集成支持定時任務，我們采用的就是spring框架下的spring-task來實現定時任務；

● 請你描述一下整個P2P的支付流程？

支付模塊，我們當時對接了兩家，一家快錢支付，一家豐付支付，當時是由我開發的，我們的商務和對方談好后并簽訂了支付協議，對方的技術給我們提供了相關的支付接口文檔及demo，我主要是根據對方的接口文檔進行開發，首先是調用對方提供的支付下單接口，把我這邊準備好的參數傳給對方，然后調用對方接口，根據對方的返回信息進行處理，如果對方返回成功，然后調用對方的獲取短信驗證碼接口，此時將給用戶的手機號發送一個支付驗證碼，用戶輸入支付短信驗證碼后，點擊確定支付，然后我們提交支付請求，對方將返回支付的結果，支付結果對方會通過兩種方式返回，一個是同步返回，一個是異步返回，我們接收對方的這兩個返回結果，更新我們的數據庫狀態，完成整個支付流程；

● 請介紹一下這個P2P項目的整體架構及你做了什么？

整個P2P項目第一個版本，我們是采用普通的ssm框架進行開發的，是一種集中式的開發方式，上線一年之后，隨著公司發展和業務需要，我們原來的ssm架構的項目，代碼非常龐大和混亂，一個方法可能出現好幾百行，里面很多邏輯，要新增一個功能，開發特別慢，由于修改這個功能，可能又導致另一個功能出現問題或者bug，后來我們對整個p2p項目進行了重構，采用分布式開發方式，當時選擇了非常流行的Dubbo分布式開發框架，主要架構是spring mvc + spring + dubbo +mybatis的架構，另外還有一些中間件，dubbo注冊中心zookeeper，緩存Redis、隊列ActiveMQ、文件存儲FastDFS，Session同步Sprign Session等；

在這個項目中，我參與了整個過程的開發，當時公司處于快速發展中，工作分工并不明確，前后臺基本都會參與開發，我先是開發了p2p前端網站部分的理財產品展示、用戶投資、用戶充值三大功能模塊，同時開發這些模塊對應的Dubbo服務，其中的支付模塊，是單獨一個項目，主要對接第三方支付接口，快錢和豐付，這個項目全部是我完成的，對此我也比較熟悉。

● 你們這個P2P項目的并發量大概多少，部署了幾臺tomcat？

我們P2P項目有三端，一個是PC端，一個是H5端，一個的App端，其中H5端的流量比較小，并發量也很低，PC端和App端并發量高一些，其中App端并發量最大，因為App端的用戶最多，App端的后端接口部署了5臺tomcat，最大的并發是3500左右，這個3500是同時處理請求的能力，而不是一段時間或者多少秒的處理能力，QPS大約是30萬左右，整個平臺大約有200萬左右的用戶；

● 你們P2P項目中分布式事務怎么解決和處理的？

我們這個P2P項目，后端的服務，沒有再拆分，就是一個dubbo服務，所以一個事務請求會提交到一個項目單元上執行，這樣我們是避免了分布式事務的問題，因為對于一般的中小型項目，也建議不涉及到分布式事務的問題，也就是說能避免盡量避免，而在一些大型項目中無法避免需要分布式事務時，目前常用的解決方案是：

1、兩階段提交；

2、三階段提交；

3、TCC補償；

4、異步確保；

5、最大努力通知；

● 為什么充值會發生掉單問題？怎么解決的？

充值時候與第三方接口對接的過程中，涉及到多個系統，每個系統都無法保證整個充值過程中都是100%的高可用，還有網絡等原因，就不可避免會出現某個系統成功了，另一個系統沒有成功的問題，當出現這種情況的時候，這筆充值就會出現數據狀態的不一致，也就是掉單，為了解決該問題，我們采用的是一種補償機制，在發生掉單后，進行自動補償，系統開啟一個定時任務，對出現掉單的訂單進行再次補償，我們會先檢索出掉單的訂單，然后通過第三方支付系統的接口，查詢該訂單的充值狀態，如果第三方已經成功了，我們這邊系統就需要更新相關的數據；

● 你們的P2P項目使用Redis主要做什么？

在該項目中，最初沒有使用Redis，是邊運營邊迭代升級的，在沒有使用Redis的時候，我們的前端業務系統上的所有數據都是直接到達數據庫獲取，導致我們后端的數據庫經常出現cpu及io壓力很大，后續我們將前端業務系統上一些不需要實時更新的數據，一些頻繁查詢的熱點數據，進行了Redis緩存存儲，來提升系統的能力。

● 生產環境（線上環境）中出現的問題，你們是怎么解決的？

生產中的問題，發現后由該系統的技術負責人全力協調解決，如果是緊急影響較大的bug，會暫時下線該功能，快速對該問題進行修復，然后由測試團隊進行嚴格測試，再上線，再次上線前將之前由于bug產生的數據問題進行修復。處理線上問題的步驟是先判斷問題的嚴重程序、波及范圍等，優先快速恢復服務，讓用戶可以繼續使用，然后再解決bug，排查bug主要是根據線上日志、數據庫數據等；

● 你們P2P項目的利息是怎么計算的?

利息的計算，公司的產品經理提供了計算公式，我們技術人員根據計算公式進行計算，由于涉及到精度問題，所有計算都是采用BigDecimal類型進行加減乘除；

● 用戶在你的P2P充值，如何防止你的請求被黑客攔截，給你返回一個假的充值成功結果？實際用戶未支付，但你系統給用戶充了值？

這個問題，我們有簽名驗簽機制就保證了，我們的請求中都有一個簽名串，簽名串黑客無法偽造，如果簽名串驗證無法通過，我們將不會給用戶充值，提示簽名失敗；

● 如何防止用戶重復點擊、重復提交充值？

用戶點擊后我們會將用戶的提交在redis中存放一個標志，如果用戶重復提交，我們會檢查redis的標志，來拒絕用戶的第二次提交，值處理第一次提交請求；

● 用戶的錢的整個流轉過程是怎么樣的？

用戶通過第三方充值渠道，將用戶銀行卡的資金劃入到P2P平臺在第三方支付公司開通的賬戶中，然后我們會把用戶的充值金額記錄在我們的數據庫用戶資金記錄表中，當用戶投資某個產品，比如100元，我們會將用戶資金記錄表中的資金凍結掉投資金額100元，當投資到期后，會產生收益，比如收益是1元，那么我們就會將之前凍結的100元，再加上收益1元返回到用戶的資金記錄表中，最后用戶提現101元，我們的后臺結算系統審核用戶的提現金額，審核通過后，通過第三方支付公司，從我們P2P平臺在第三支付公司開通的賬戶中扣除101元，將101元打入用戶提交的銀行賬號中；

● 請介紹一下你做的這個P2P項目？

該項目是一個基于互聯網金融的網貸平臺，有理財端和借款端，我主要是參與做的理財端，該項目主要包括PC站、M站、APP客戶端（Android、iOS），由多個項目系統構成，包括前端業務系統PC端和H5端、數據接口系統、核心系統、結算系統、支付系統、定時任務系統、營銷活動系統，紅包系統，合同簽章系統、實名認證接口系統、輪播圖系統等。

整個項目采用分布式開發模式，Tomcat集群部署，采用Nginx實現負載均衡和動靜分離，MySQL主從復制模式，Redis集群模式，ActiveMQ的異步處理、Zookeeper做為注冊中心，Spring session共享，Redis集群緩存熱點數據提升系統吞吐量，整個項目采用的技術架構主要是：Spring mvc + Spring + Dubbo +MyBatis, 采用Dubbo實現項目間的RPC調用，采用分布式文件系統FastDFS存儲投資借款合同。

我在這個平臺中參與過前端業務系統，Dubbo數據接口系統，支付接口系統、合同簽章系統的開發，對這幾個系統比較熟悉，通過這個項目，遇到過一些問題，也學到很多東西。比如最早的時候，對Dubbo開發框架不是很了解，通過該項目，現在比較得心應手。

互聯網分布式專題

● 你都知道哪些技術可以完成異構系統整合？

httpclient、webservices

HR專題

● 自我介紹？

面試官您好，我叫XX，非常高興認識您。到目前為止我從事Java軟件編碼工作已經3年了，之前一直在石家莊的XX公司工作，他是一家外包公司，在這期間我接觸了有六七個項目，其中包括政府部門的項目、銀行相關的項目、還有互聯網公司相關的項目，最近做的是一個P2P互聯網金融項目。北京這邊畢竟軟件環境好一些，有一些朋友也來到北京發展情況挺好的，所以前兩天把石家莊的工作辭掉了，想在北京闖一闖。這就是我的個人情況，謝謝。

說明：這只是一個參考的模板，自行修改，并且在進行自我介紹的時候不要死記硬背。要用描述性的語言說出來。

● 說一個我們留下你的理由？

首先，我個人非常喜歡熱愛Java軟件開發這份工作，我喜歡耐心的做一件事，實現一個一個客戶的需求。

其次，我的技術能力完全可以勝任咱們這份工作，技術這塊您放心，肯定不掉鏈子，按時按點完成領導交辦的任務。

另外，我也喜歡咱們公司的企業文化以及工作氛圍。希望貴公司能給一次機會。

● 你還有什么要問的嗎？

基本上也沒什么問題了，我就是想知道一下咱們團隊開發使用的是哪些技術，如果可以的話，我回去抓緊時間熟悉一下。比如用的哪些框架，后臺使用的什么技術，前端使用的什么框架等。

● 你的期望薪資是多少？

多種回答方式：第一種是直接說一個薪資值，例如：10K左右是可以接受的（帶個左右，不要說區間值，千萬別說10~15）。第二種方式可以這樣說：我來之前也對北京這塊的薪資結構有了一定的了解，3年工作經驗在北京這塊大概在12K以上，所以12K左右都可以接受，當然，薪資這塊不是硬性要求，能夠遇到一個好的團隊，優秀的企業這是最主要的。

● 說一下職業規劃？

其實具體的職業規劃目前也沒有刻意的去制定過，目前來說我還是希望能夠把技術底層再好好的研究一下，比如像數據結構、算法、框架底層源代碼等。我還是比較喜歡鉆研技術。

● 你平時除了開發還干什么？

平時除了編碼之外，主要還是為公司產品解決一些線上的問題，調一些bug。另外還會寫日報周報、參與各種會議、和產品溝通、和測試溝通等等，閑暇時間會學習一些新的技術。

● 項目經理通過什么方式分配任務？

這個問題的答案不是固定的，因為每個團隊的管理方式不同。比較正規的大的公司一般會使用專業的工具，例如project、Planisware工具，但這些工具使用復雜。對于一些規模比較小的公司來說一般excel就搞定了，在excel表格中描述任務并自動生成甘特圖來跟蹤任務的進展。（建議這樣回答：我們項目組使用的excel進行任務分配的，在excel中標上一些特殊的顏色，來表示不同的進度。）

● 項目經理怎么監控項目進度的？

每一天我們都要按時提交日報，每一周都要按時提交周報，項目經理通過日報周報等形式監控項目進度。

● 項目經理怎么監控代碼質量的？

不定期的進行代碼走查（代碼review），項目經理、組長、程序員一起到會議室，打開投影儀，把最近幾天的代碼一行一行的看一看，主要看看代碼的注釋、代碼的格式、代碼的命名規范、代碼的冗余度等。

● 怎么和測試溝通的？

● 你平時和誰溝通較多？

通過上圖可以看出，開發通常和產品、測試溝通較多。

● 你們小組是怎么溝通的？

● 你們平時都什么時候開會，都開什么會？

一般都會有晨會（小組會議）。

每日晨會是敏捷開發過程中最為重要的一個環節。核心團隊成員每天早上開一個非常短的碰頭會，每人平均2到3分鐘，介紹昨天做了什么，今天要做什么，有什么困難沒有。 

主要目的是便于項目管理人員了解任務開發狀態，發現潛在的隱患，督促團隊成員勤勉工作，幫助解決困難。

一般采用站立式非正規會議，集中在一個小會議室或者是在稍微偏僻一點的走廊。 

當項目管理人員發現某個團隊成員工作不力或者是遇到困難的時候，除在會議上作簡短確認以及詢問其它團隊成員能否幫助外，還應在會后與當事人進行詳細溝通。

有一些公司會有夕會，下班時候的一個碰頭會（小組會議）。

每周都會有周例會（公司的所有成員會議）。

● 為什么從上家公司離職？

北京這邊的軟件環境好一些，趁年輕想來大城市闖一闖。

● 你上家公司在哪，哪條路，哪個大廈？

這個題目就需要隨機應變了，比如：上家公司在北京大興區，經濟技術開發區，涼水河二街，大族企業灣，11號樓A座三層。

● 你上家公司是做哪個行業的？

這個題目需要大家查一下“之前工作的公司”，了解一下該公司主要做哪一方面的。如果上一家工作的公司是外包公司那是不錯的。因為被外派出去的人員可能會接觸不同行業的項目。

● 對你上家公司進行一個評價？

我相信面試官您也看到了，自從我大學畢業到現在一直在上家公司工作，這也充分證明了我對上家公司的認可。上家公司擁有良好的企業文化，為我們提供了良好的工作環境，我們團隊也構建了一個良好的工作氛圍，大家工作都很積極努力，團隊成員也都很照顧我，如果還有機會回到石家莊工作的話，我希望能再回到這家公司。

● 說一下你的離職流程？

我離職的前1個月提出了申請，然后我們老大就開始招人，招到后，我就開始和新人進行工作交接，直到新人能夠上手，我就離開了。

● 你們多少人開發這個項目？

● 說一下你們項目組的組織架構/人員分配？

● 你們分組了嗎，都是什么組，你在哪一組？

● 你和領導在一些想法上產生了分歧，你怎么做？

在工作中，和領導打交道是一個技術活，讓領導開心很重要，但也不能委屈了自己，當和領導產生分歧后，好盡量的去挽救雙方之間的關系，畢竟自己使下屬，在該讓步的時候還是要學會讓步。

第一：積極的溝通。也許是領導不了你的實際情況，沒看到你的付出和努力，對你產生了誤解，所以適當的溝通就很重要了。

第二：保持不卑不亢的態度。在產生分歧的時候，不要一味的退讓或者太過于強勢，凡是都是可以溝通的，讓領導看到自己的工作態度很重要。

第三：顯示出自己對領導的尊重。也許你的工作能力是比較出眾的，但是一定要給足領導面子，讓領導看出自己的態度，免得給領導留下了不好的態度。

第四：選擇求同存異的處理手法。特別是解決工作上的問題，手段是有很多的，你考慮的方向和領導考慮的方向可能會有所出入，可以選擇一種大家都認同的方法來處理。

第五：領導布置的任務要好好的完成。就算是和領導有分歧，但是領導布置的任務還是要好好的完成，這樣可以顯示出自己對工作一絲不茍的態度，也會的到領導的贊賞。

第六：在不改變自己原則的前提下妥協。先要表明自己的立場，讓自己不做違背自己本心的事情，然后考慮妥協，對方是領導，很有可能是你處于被動的地步，所以適當的妥協是有必要的。

● 你們項目組使用的是哪個項目管理軟件？

禪道。

● 你們項目組使用的是哪個版本控制工具？

最近兩年的開發一直在使用Git，感覺Git比SVN好用。Git是基于分布式的。

● 你之前交過社保嗎？

之前沒有繳納過社保，公司每個月有800元補助。（之前在北京工作過，并且在北京交過社保的同學，可以回答：交過社保。如果社保不是連續的，可以告訴面試官，社保中間斷了，不想交社保了，公司每個月有800元補助。）

● 程序員苦逼的一天？

其它

● 你們的測試環境是怎樣的？

我們的測試環境模擬的就是生產環境，只不過生產環境中服務器硬件要多一些，在測試環境中一個機器上會安裝多個軟件。

● AJAX跨域你是怎么實現的？

首先我先給您解釋一下我理解的跨域，為什么會有跨域呢？這是因為瀏覽器的同源策略導致的，同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，則瀏覽器的正常功能可能都會受到影響。可以說 Web 是構建在同源策略基礎之上的，瀏覽器只是針對同源策略的一種實現。它的核心就在于它認為來自任何站點裝載的信賴內容是不安全的。當被瀏覽器半信半疑的腳本運行在沙箱時，它們應該只被允許訪問來自同一站點的資源，而不是那些來自其它站點可能懷有惡意的資源。所謂同源是指：域名、協議、端口相同。所以跨域限制主要的目的就是為了用戶的上網安全。不過在實際的開發中有很多情況下需要我們實現跨域訪問，因為同一個項目的不同服務可能部署在不同的服務器當中，服務器A調用服務器B當中的資源時，就涉及到了跨域問題，那么怎么解決AJAX跨域呢？

第一種方式：JSONP方式解決跨域問題。

jsonp解決跨域問題是一個比較古老的方案（實際中不推薦使用），實際項目中如果要使用JSONP，一般會使用jQuery對JSONP進行了封裝的類庫來進行ajax請求。