SSM相關

講下 springmvc 框架的工作流程?

1、用戶向服務器發(fā)送請求，請求被 SpringMVC 的前端控制器 DispatcherServlet 截獲。?

2、DispatcherServlet 對請求的 URL（統(tǒng)一資源定位符）進行解析，得到 URI(請求資源標識符)，然后根據(jù)該 URI，調(diào)用 HandlerMapping 獲得該 Handler 配置的所有相關的對象，包括 Handler 對象以及 Handler 對象對應的攔截器，這些對象都會被封裝到一個 HandlerExecutionChain 對象當中返回。?

3、DispatcherServlet 根據(jù)獲得的 Handler，選擇一個合適的 HandlerAdapter。HandlerAdapter 的設計符合面向?qū)ο笾械膯我宦氊熢瓌t，代碼結(jié)構清晰，便于維護，最為重要的是，代碼的可復制性高。HandlerAdapter 會被用于處理多種 Handler，調(diào)用 Handler 實際處理請求的方法。

4、提取請求中的模型數(shù)據(jù)，開始執(zhí)行 Handler(Controller)。在填充 Handler 的入?yún)⑦^程中，根據(jù)配置，spring 將幫助做一些額外的工作

消息轉(zhuǎn)換：將請求的消息，如 json、xml 等數(shù)據(jù)轉(zhuǎn)換成一個對象，將對象轉(zhuǎn)換為指定的響應信息。數(shù)據(jù)轉(zhuǎn)換：對請求消息進行數(shù)據(jù)轉(zhuǎn)換，如 String 轉(zhuǎn)換成 Integer、Double 等。

數(shù)據(jù)格式化：對請求的消息進行數(shù)據(jù)格式化，如將字符串轉(zhuǎn)換為格式化數(shù)字或格式化日期等。

數(shù)據(jù)驗證：驗證數(shù)據(jù)的有效性如長度、格式等，驗證結(jié)果存儲到 BindingResult 或 Error 中。

5、Handler 執(zhí)行完成后，向 DispatcherServlet 返回一個 ModelAndView 對象，ModelAndView 對象中應該包含視圖名或視圖模型。

6 、 根 據(jù) 返 回 的 ModelAndView 對 象 ， 選 擇 一 個 合 適 的 ViewResolver( 視 圖 解 析 器 ) 返 回 給DispatcherServlet。

7、ViewResolver 結(jié)合 Model 和 View 來渲染視圖。

8、將視圖渲染結(jié)果返回給客戶端。

以上 8 個步驟，DispatcherServlet、HandlerMapping、HandlerAdapter 和 ViewResolver 等對象協(xié)同工作，完成 SpringMVC 請求—>響應的整個工作流程，這些對象完成的工作對于開發(fā)者來說都是不可見的，開發(fā)者并不需要關心這些對象是如何工作的，開發(fā)者，只需要在 Handler(Controller)當中完成對請求的業(yè)務處理。

圖片怎么上傳

前端使用 angularJS 異步上傳，后端使用 springmvc 的 MultipartFile 類型來接收，放

到分布式圖片服務器中，服務器返回圖片路徑把路徑返回頁面回顯圖片

微服務和 SOA 有什么區(qū)別？

如果一句話來談 SOA 和微服務的區(qū)別，即微服務不再強調(diào)傳統(tǒng) SOA 架構里面比較重的 ESB企業(yè)服務總線，同時 SOA 的思想進入到單個業(yè)務系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。

說的更直白一點就是微服務被拆分的粒度更小

spring 框架 AOP 執(zhí)行原理簡單說下？還有就是 AOP 在事務管理方面是怎么實現(xiàn)的？

Spring AOP 使用的動態(tài)代理，所謂的動態(tài)代理就是說 AOP 框架不會去修改字節(jié)碼，而是在內(nèi)存中臨時為方法生成一個 AOP 對象，這個 AOP 對象包含了目標對象的全部方法，并且在特定的切點做了增強處理，并回調(diào)原對象的方法。

Spring? AOP 中的動態(tài)代理主要有兩種方式，JDK 動態(tài)代理和 CGLIB 動態(tài)代理。JDK 動態(tài)代理通過反 射來接 收被代 理的類， 并且要 求被代 理的類 必須實 現(xiàn)一個 接口。 JDK 動態(tài) 代理的 核心 是InvocationHandler 接口和 Proxy 類。如果目標類沒有實現(xiàn)接口，那么 Spring AOP 會選擇使用 CGLIB來動態(tài)代理目標類。CGLIB（Code Generation Library），是一個代碼生成的類庫，可以在運行時動態(tài)的生成某個類的子類，注意，CGLIB 是通過繼承的方式做的動態(tài)代理，因此如果某個類被標記為final，那么它是無法使用 CGLIB 做動態(tài)代理的。

AOP 在事務管理方面，Spring 使用 AOP 來完成聲明式的事務管理有 annotation 和 xml 兩種形式。開發(fā)中，方便代碼編寫，很多時候都是在 spring 配置文件中配置事務管理器并開啟事務控制注解。在業(yè)務類或業(yè)務類方法中添加@Transactional 實現(xiàn)事務控制。

Spring 分布式事務如何處理的

回答：

第一種方案：可靠消息最終一致性，需要業(yè)務系統(tǒng)結(jié)合 MQ 消息中間件實現(xiàn)，在實現(xiàn)過程中需要保證消息的成功發(fā)送及成功消費。即需要通過業(yè)務系統(tǒng)控制 MQ 的消息狀態(tài)

第二種方案：TCC 補償性，分為三個階段 TRYING-CONFIRMING-CANCELING。每個階段做不同的處理。

TRYING 階段主要是對業(yè)務系統(tǒng)進行檢測及資源預留CONFIRMING 階段是做業(yè)務提交，通過 TRYING 階段執(zhí)行成功后，再執(zhí)行該階段。默認如果 TRYING階段執(zhí)行成功，CONFIRMING 就一定能成功。

CANCELING 階段是回對業(yè)務做回滾，在 TRYING 階段中，如果存在分支事務 TRYING 失敗，則需要調(diào)用 CANCELING 將已預留的資源進行釋放。

Springboot 用過沒，跟我說說，他的特點？

Springboot 是從無數(shù)企業(yè)實戰(zhàn)開發(fā)中總結(jié)出來的一個更加精煉的框架，使得開發(fā)更加簡單，能使用寥寥數(shù)行代碼，完成一系列任務。

1） Springboot 解決那些問題

a) 編碼更簡單

????????i. Spring 框架由于超重量級的 XML，annotation 配置，使得系統(tǒng)變得很笨重，難以維護

????????ii. Springboot 采用約點大于配置的方法，直接引入依賴，即可實現(xiàn)代碼的開發(fā)

b) 配置更簡單

Xml 文件使用 javaConfig 代替，XML 中 bean 的創(chuàng)建，使用@bean 代替后可以直接注入。配置文件變少很多，就是 application.yml

????c) 部署更簡單

d) 監(jiān)控更簡單

????????Spring-boot-start-actuator:

????????可以查看屬性配置

????????線程工作狀態(tài)

????????環(huán)境變量

????????JVM 性能監(jiān)控

支付部分

支付接口是怎么做的？

調(diào)用微信的支付接口，參考微信提供的 api

使用了微信的統(tǒng)一下單接口和查詢支付狀態(tài)接口

每個接口需要的參數(shù)放入到 map 中使用微信提供的 sdk 轉(zhuǎn)成 XML 字符串，httpClient遠程提交參數(shù)和接收結(jié)果。

項目業(yè)務面試問題

哪些情況用到 activeMq

商品上架后更新 solr 索引庫、更新靜態(tài)頁、發(fā)送短信

秒殺的時候，只有最后一件物品，該怎么去搶或者分配？

? 秒殺商品的庫存都會放到 redis 中，在客戶下單時就減庫存，減完庫存會判斷庫存是否為大于 0，如果小于 0,表示庫存不足，剛才減去的數(shù)量再恢復，整個過程使用 redis的 watch 鎖

solr 和 lucene 的區(qū)別

? solr 是 Apache 的用于實現(xiàn)全文檢索的開源項目，是一個 war 包，直接可以放入tomcat 服務器中配置一下就可以使用，而 Lucene 是全文檢索的底層技術，solr 是在Lucene 的基礎上開發(fā)的 solr

solr 怎么設置搜索結(jié)果排名靠前（得分）？

設置 boots 值

你項目對于訂單是怎么處理的，假如一個客戶在下訂單的時候沒有購買怎么辦，對于顧客在購買商品的時候你們怎么處理你們的庫存？

訂單表中設置了一個過期時間，每天會有定時任務來掃描訂單表數(shù)據(jù)，如果到達預訂的

過期時間沒有付款就會取消此訂單交易。

關于庫存的設計是這樣的：

普通商品在發(fā)貨時才去更新庫存，如果庫存不足商家會馬上補貨

秒殺的商品會在客戶下單時就減庫存，如果在規(guī)定時間（半個小時）沒有付款，會取消

此訂單把庫存還原

插入商品的話，要求級聯(lián)插入幾張表，你們當時是怎么實現(xiàn)的？

三張表 商品表、商品描述表、sku 表，他們的關系是一對一對多，三張表使用了組合類 表現(xiàn)他們的關系，在頁面使用 angularjs 雙向綁定了組合類

redis 存儲格式的選擇

redis 支持的數(shù)據(jù)結(jié)構總共有 5 種：hash、value、list、set、zset，其中項目中用到最多是 hash

商品表中的數(shù)據(jù)是哪里來的不知道

商品表的數(shù)據(jù)是在商家管理后臺中由商家錄入的。數(shù)據(jù)分別錄入到商品表、商品描述表和商品項表

當初設計項目時預計的訪問量計劃是多少

訪問量計劃是 3000 至 5000

店主申請開店是從哪里申請的，所需要的信息都有哪些

? 商家申請開店在商家管理后臺申請入駐的。在運營商管理后臺審核通過后，方可登陸系統(tǒng)完成后續(xù)操作，例如：錄入商品信息等。所需要的信息可以參考：注冊頁面學習。需要信息有：商家登錄名、密碼、店鋪名稱、公司名稱、公司電話、聯(lián)系人、聯(lián)系人電話、營業(yè)執(zhí)照號、稅務登記號、組織機構代碼證、法人代表信息、開戶行信息等。

模板表的設計思想

模板表設計主要是為了商品表與品牌表、規(guī)格表進行數(shù)據(jù)關聯(lián)。方便商品錄入時，選擇對應的品牌和規(guī)格數(shù)據(jù)。

簡單介紹一下你的這個項目以及項目中涉及到的技術框架以及使用場景以及你主要負責項目中的哪一塊？

項目介紹時，先整體介紹是什么項目，項目主要是做啥的。例如：XXX 電商項目，是一個 B2B2C 綜合電商平臺。由三個系統(tǒng)組成，包含：運營商管理后臺、商家管理后臺、網(wǎng)站前臺。運營商平臺主要負責基礎數(shù)據(jù)維護、商家審核、商品審核等。商家管理后臺主要負責商家入駐、商品錄入/修改、商品上下架等。網(wǎng)站前臺主要負責商品銷售。包含：網(wǎng)站首頁、商品搜索、商品詳情展示、購物車、訂單、支付、用戶中心等模塊。

? 再介紹自己在項目中做的功能模塊。例如：運營商管理后臺的品牌、規(guī)格數(shù)據(jù)錄入，已經(jīng)商品管理后臺商品錄入功能。同時，實現(xiàn)了網(wǎng)站前臺系統(tǒng)中的商品搜索、購物車等功能模塊。

然后介紹里面使用的技術：例如：dubbo 分布式框架、ssm、angularjs、solr、redis、freemarker、activeMQ、微信掃碼支付等等。最好是結(jié)合技術講解項目功能點如何實現(xiàn)。

秒殺系統(tǒng)中如何防止超售？如何避免腳本進行惡意刷單？

防止超售解決方案：將存庫從 MySQL 前移到 Redis 中，所有的寫操作放到內(nèi)存中，由于 Redis 中不存在鎖故不會出現(xiàn)互相等待，并且由于 Redis 的寫性能和讀性能都遠高于 MySQL，這就解決了高并發(fā)下的性能問題。然后通過隊列等異步手段，將變化的數(shù)據(jù)異步寫入到 DB 中。當達到庫存閥值的時候就不在消費隊列，并關閉購買功能。

避免腳本惡意刷單：采用 IP 級別的限流，即針對某一個 IP，限制單位時間內(nèi)發(fā)起請求數(shù)量。

單點登錄你們是自己編寫的還是使用通用的 CAS？

項目使用通用的 CAS 框架。

如果一個用戶的 token 被其他用戶劫持了，怎樣解決這個安全問題。

a、在存儲的時候把 token 進行對稱加密存儲，用時解開。

b、將請求 URL、時間戳、token 三者進行合并加鹽簽名，服務端校驗有效性。

c.HTTPS 對 URL 進行加密

項目部署上線后，運營商管理，商品審核等后臺流量問題？

回答：

先詢問流量是指哪方面？流量分為三種，一種是商家流量，另一種是用戶流量，第三種運營商流量。

解決方案：

? 這三種流量對系統(tǒng)運行造成很大壓力，隨著項目上線時間增長，壓力會越來越大，因此我們要減輕系統(tǒng)訪問壓力 ，就需要做一系列優(yōu)化措施。

具體優(yōu)化如下：

數(shù)據(jù)層面的優(yōu)化：

從數(shù)據(jù)庫層面做優(yōu)化，比如:索引，緩存，集群，讀寫分離，主從復制，分表，分庫。

從數(shù)據(jù)庫設計層面的優(yōu)化：比如減少表關聯(lián)，加入冗余字段

從緩存方面優(yōu)化：比如 redis 實現(xiàn)數(shù)據(jù)緩存，減輕數(shù)據(jù)庫壓力

從搜索上進行優(yōu)化：比如查找索引庫

項目層面的優(yōu)化：

采用面向服務的分布式架構：分擔服務器壓力 ，提高項目并發(fā)量

比如 dubbox+zookeeper 分布式架構

采用分布式文件系統(tǒng)實現(xiàn)海量文件存儲：如采用 fastdfs 實現(xiàn)海量圖片存儲，提高文件的訪問速度。

采用 mq 使用服務進一步解藕：同步索引庫，同步靜態(tài)資源，短信發(fā)送服務器層面的優(yōu)化

集群思想的使用：tomcat,zookeeper,redis,mysql 等

Tomcat 異步通信的使用，tomcat 連接池配置

秒殺和團購業(yè)務實現(xiàn)思路

回答：

將商品數(shù)量查詢出存入到 redis 中，所有用戶下單后，減掉 redis 中的數(shù)量

如果并發(fā)量很大時，還要考慮高并發(fā)問題，所以可以加入 mq 消息中間件處理搶單問題，再結(jié)合 redis

實現(xiàn)庫存減少操作。高并發(fā)方面還可以考慮 CDN，Nginx 負載均衡等

你們項目中使用的安全框架是什么？

使用 springSecurity，校驗用戶登錄和用戶權限！

項目中使用到的應用服務器是什么？

Tomcat+nginx

講一下每臺服務器的集群數(shù)量：

? 項目中一共 15 臺項目服務，那么為了每一臺高可用一主一備，但首頁項目高并發(fā)設為四臺服務器，則一共 32 臺項目服務器，再加 redis 集群用了 3 臺，為了每一臺高可用一主一備一共 6 臺，fastdfs 一個 trackerServer 一個 storageServer 搭建集群一共 6 臺，solr 集群 7 臺服務器，nginx 為了高可用一主一備一共 2 臺，mysql 數(shù)據(jù)庫集群 3 臺！activemq 消息中間件高可用 2 臺；

共計：58 臺服務器！

1：你在項目開發(fā)中碰到過哪些重大且棘手的問題

場景一：需求不明確困境

在項目開發(fā)中，項目采用迭代開發(fā)，開發(fā)需求不是很明確，對于項目開發(fā)初期來說非常困難，進度非常慢，有時開發(fā)的出的產(chǎn)品結(jié)果往往不能令老板滿意，或者是甲方滿意，項目還需要不停的迭代，修改。

比如說：

在開發(fā)品優(yōu)購項目的時候，客戶定位是一個綜合性的商務平臺，可以實現(xiàn)在線第三方商家對接，實現(xiàn)商品的銷售但是并沒有明確的需求，因此開發(fā)全憑借電商的項目經(jīng)驗來實現(xiàn)里面的相關的業(yè)務，后期慢慢迭代。

場景二：使用 cas 單獨登錄不能很好實現(xiàn)想要的效果

場景三： solr 高亮不能顯示的問題

前臺使用 angularJS 加載搜索結(jié)果，但是發(fā)現(xiàn)高亮不能展示。

問題原因：

angularJS 底層使用 ajax，異步加載高亮信息返回給頁面后，頁面沒有刷新，就直接顯示返回的數(shù)據(jù)。此時會把所有的數(shù)據(jù)作為普通的文本數(shù)據(jù)進行加載。因此就沒有高亮的效果。

解決方案：

使用 angularJS 過濾器過濾文本數(shù)據(jù)，此時 angularJS 過濾器把 html 文本數(shù)據(jù)解析為瀏覽器能識別的 html 標簽。高亮就能展示了。

場景四：Nginx 靜態(tài)頁面服務跳轉(zhuǎn)到購物車跨域問題

在 Nginx 中部署了靜態(tài)頁面，添加購物車時必須從靜態(tài)頁面跳轉(zhuǎn)到購物車系統(tǒng),實現(xiàn)購物車添加操作。

由于在靜態(tài)頁面中使用 angularJS 實現(xiàn)的跳轉(zhuǎn)，發(fā)現(xiàn)跳轉(zhuǎn)到購物車系統(tǒng)完全沒有問題，但是并不能跳轉(zhuǎn)回到購物車系統(tǒng)頁面。

問題分析：

從靜態(tài)詳情系統(tǒng)跳轉(zhuǎn)到購物車系統(tǒng)，會存在跨域問題，因此不能進行回調(diào)函數(shù)的數(shù)據(jù)傳遞。所以在回調(diào)函數(shù)中的頁面跳轉(zhuǎn)就不能實現(xiàn)。

解決方案：

使用 angularJS 跨域調(diào)用及 springmvc 跨域配置，解決問題。

場景五：activeMQ 存在運行時間長了以后，收不到消息的現(xiàn)象時間長了就會出現(xiàn)，卡死，新的數(shù)據(jù)不能從隊列接聽到。只能重啟程序。

解決方案：

1）不要頻繁的建立和關閉連接

? ?JMS 使用長連接方式，一個程序，只要和 JMS 服務器保持一個連接就可以了，不要頻繁的建立和關閉連接。頻繁的建立和關閉連接，對程序的性能影響還是很大的。這一點和 jdbc 還是不太一樣的。

2）Connection 的 start()和 stop()方法代價很高

? ?JMS 的 Connection 的 start()和 stop()方法代價很高，不能經(jīng)常調(diào)用。我們試用的時候，寫了個 jms 的 connection pool，每次將 connection 取出 pool 時調(diào)用 start()方法，歸還時調(diào)用 stop()方法，然而后來用 jprofiler發(fā)現(xiàn)，一般的 cpu 時間都耗在了這兩個方法上。

3）start()后才能收消息

? ?Connection 的 start()方法調(diào)用后，才能收到 jms 消息。如果不調(diào)用這個方法，能發(fā)出消息，但是一直收不到消息。不知道其它的 jms 服務器也是這樣。

4）顯式關閉 Session

? ?如果忘記了最后關閉 Connection 或 Session 對象，都會導致內(nèi)存泄漏。這個在我測試的時候也發(fā)現(xiàn)了。本來以為關閉了 Connection，由這個Connection 生成的 Session 也會被自動關閉，結(jié)果并非如此，Session 并沒有關閉，導致內(nèi)存泄漏。所以一定要顯式的關閉 Connection 和 Session。

5）對 Session 做對象池

? ?對 Session 做對象池，而不是 Connection。Session 也是昂貴的對象，每次使用都新建和關閉，代價也非常高。而且后來我們發(fā)現(xiàn)，原來 Connection是線程安全的，而 Session 不是，所以后來改成了對 Session 做對象池，而只保留一個Connection。

6） 集群

ActiveMQ 有強大而靈活的集群功能，但是使用起來還是會有很多陷阱

場景六：activeMQ 存在發(fā)生消息太大，造成消息接收不成功

多個線程從 activeMQ 中取消息，隨著業(yè)務的擴大，該機器占用的網(wǎng)絡帶寬越來越高。

仔細分析發(fā)現(xiàn)，mq 入隊時并沒有異常高的網(wǎng)絡流量，僅僅在出隊時會產(chǎn)生很高的網(wǎng)絡流量。

最終發(fā)現(xiàn)是 spring 的 jmsTemplate 與 activemq 的 prefetch 機制配合導致的問題。

研究源碼發(fā)現(xiàn) jmsTemplate 實現(xiàn)機制是：每次調(diào)用 receive()時都會創(chuàng)建一個新的 consumer 對象，用完即銷毀。

正常情況下僅僅會浪費重復創(chuàng)建 consumer 的資源代價，并不至于產(chǎn)生正常情況十倍百倍的網(wǎng)絡流量。但是 activeMQ 有一個提高性能的機制 prefetch，此時就會有嚴重的問題。

prefetch 機制：

每次 consumer 連接至 MQ 時，MQ 預先存放許多 message 到消費者（前提是 MQ 中存在大量消息），預先存 放 message 的數(shù)量取決于 prefetchSize（默認為 1000）。此機制的目的很顯然，是想讓客戶端代碼用一個 consumer 反復進行 receive 操作，這樣能夠大量提高出隊性能。此機制與 jmsTemplate 配合時就會產(chǎn)生嚴重的問題，每次 jmsTemplate.receive()，都會產(chǎn)生 1000個消息的網(wǎng)絡流量， 但是因為 jmsTemplae 并不會重用 consumer，導致后面 999 個消息都被廢棄。反復 jmsTemplate.receive()時，表面上看 不出任何問題，其實網(wǎng)絡帶寬會造成大量的浪費。

解決方案：

1、若堅持使用 jmsTemplate，需要設置 prefetch 值為 1，相當于禁用了 activeMQ 的 prefetch 機制，此時感覺最健壯， 就算多線程，反復調(diào)用 jmsTemplate.receive()也不會有任何問題。但是會有資源浪費，因為要反復創(chuàng)建 consumer 并頻繁與服務器進 行數(shù)據(jù)通信，但在性能要求不高的應用中也不算什么問題。

2、不使用 jmsTemplate，手工創(chuàng)建一個 consumer，并單線程反復使用它來 receive()，此時可以充分利用 prefetch 機制。配合多線程的方式每個線程擁有自己的一個 consumer，此時能夠充分發(fā)揮 MQ在大吞吐量時的速度優(yōu)勢。

切記避免多線程使用一個 consumer 造成的消息混亂。大吞吐量的應用推薦使用方案 2，能夠充分利用prefetch 機制提高系 MQ 的吞吐性能。

商品的價格變化后，如何同步 redis 中數(shù)以百萬計的購物車數(shù)據(jù)。

解決方案：

購物車只存儲商品 id,到購物車結(jié)算頁面將會從新查詢購物車數(shù)據(jù)，因此就不會涉及購物車商品價格同步的問題。

系統(tǒng)中的錢是如何保證安全的。

在當前互聯(lián)網(wǎng)系統(tǒng)中錢的安全是頭等大事，如何保證錢的安全可以從以下 2 個方面來思考：

1）錢計算方面

在系統(tǒng)中必須是浮點數(shù)計算類型存儲錢的額度，否則計算機在計算時可能會損失精度。

2）事務處理方面

在當前環(huán)境下，高并發(fā)訪問，多線程，多核心處理下，很容易出現(xiàn)數(shù)據(jù)一致性問題，此時必須使用事務進行控制，訪問交易出現(xiàn)安全性的問題，那么在分布式系統(tǒng)中，存在分布式事務問題，可以有很多解決方案：

使用 jpa 可以解決

使用 tcc 框架可以解決等等。

訂單中的事物是如何保證一致性的。

使用分布式事務來進行控制，保證數(shù)據(jù)最終結(jié)果的一致性。

當商品庫存數(shù)量不足時，如何保證不會超賣。

當庫存數(shù)量不足時，必須保證庫存不能被減為負數(shù)，如果不加以控制，庫存被減為小于等于 0 的數(shù)，那么這就叫做超賣。

那么如何防止超賣的現(xiàn)象發(fā)生呢？

場景一： 如果系統(tǒng)并發(fā)要求不是很高

那么此時庫存就可以存儲在數(shù)據(jù)庫中，數(shù)據(jù)庫中加鎖控制庫存的超賣現(xiàn)象。

場景二：系統(tǒng)的并發(fā)量很大

如果系統(tǒng)并發(fā)量很大，那么就不能再使用數(shù)據(jù)庫來進行減庫存操作了，因為數(shù)據(jù)庫加鎖操作本身是以損失數(shù)據(jù)庫的性能來進行控制數(shù)據(jù)庫數(shù)據(jù)的一致性的。

但是當并發(fā)量很大的時候，將會導致數(shù)據(jù)庫排隊，發(fā)生阻塞。因此必須使用一個高效的 nosql 數(shù)據(jù)庫服務器來進行減庫存。

此時可以使用 redis 服務器來存儲庫存，redis 是一個內(nèi)存版的數(shù)據(jù)庫，查詢效率相當?shù)母?，可以使用watch 來監(jiān)控減庫存的操作，一旦發(fā)現(xiàn)庫存被減為 0，立馬停止售賣操作。

你們系統(tǒng)的商品模塊和訂單模塊的數(shù)據(jù)庫是怎么設計的

商品模塊設計：

商品模塊一共 8 張表，整個核心就是模板表。采用模板表為核心的設計方法，來構造商品數(shù)據(jù)。訂單設計：

訂單涉及的表有：

1） 收貨人地址

2） 訂單信息

3） 訂單明細訂單關系描述：

系統(tǒng)中商家活動策劃以及上報相關業(yè)務流程。

品優(yōu)購系統(tǒng)中有以下活動：

1） 秒殺活動

a) 后臺設置秒殺商品

b) 設置秒殺開啟時間，定時任務，開啟秒殺

c) 秒殺減庫存（秒殺時間結(jié)束，庫存賣完，活動結(jié)束）

2）?促銷活動

3）?團購活動

4）?今日推薦

以上活動銷售記錄，統(tǒng)計，使用圖形化報表進行統(tǒng)計，可以查看銷售情況。

11，涉及到積分積累和兌換商品等業(yè)務是怎么設計的

積分累計有 2 大塊：

積分累計：

根據(jù)用戶購買的商品的價格不同，沒有購買一定價格的商品，獲取一定的積分。積分商城：

積分商城是用戶可以使用積分商品換取商品的區(qū)域。

介紹下電商項目，你覺得那些是亮點？

這個項目是為 xxx 開發(fā)的 b2b2c 類型綜合購物平臺，主要以銷售家用電器，電子產(chǎn)品為主要的電子商城網(wǎng)站。

項目的亮點是：

1） 項目采用面向服務分布式架構（使用 dubbo,zookeeper）

a) 解耦

????????b) 提高項目并發(fā)能力

? ? ? ? c) 分擔服務器壓力

2） 項目中使用 activeMQ 對項目進一步解耦

????????a) 提高項目并發(fā)能力

????????b) 提高任務處理速度

3）?使用微信支付，支付寶支付（自己總結(jié)）

4）?使用阿里大于發(fā)生短信

5）?使用第三方分布式文件系統(tǒng)存儲海量文件

6）?Nginx 部署靜態(tài)頁面實現(xiàn)動靜分離

購物車功能做了嗎，實現(xiàn)原理說一下？

購物車設計示意圖：

你們的項目上線了嗎？這么大的項目怎么沒上線？

項目上線問題回答：

1） 項目沒有上線

????????可以是項目沒有上線之前，你離職了，這個一個創(chuàng)業(yè)型的公司，或者此項目是給甲方做的項目，你沒有參與上線。以此來回避這個問題

2） 項目上線

????項目已經(jīng)上線了

上線環(huán)境：

????????????a) Centos7

????????????b) Mysql

????????????c) Jdk8

????????????d) Tomcat8

關于上線，那么面試官一定會問您，上線遇到什么問題沒有？因此必須把項目中遇到的問題準備 2 個。

訂單怎么實現(xiàn)的，你們這個功能怎么這么簡單？

訂單實現(xiàn)：

????????從購物車系統(tǒng)跳轉(zhuǎn)到訂單頁面，選擇默認收貨地址

????????選擇支付方式

????????購物清單展示

????????提交訂單

訂單業(yè)務處理：

一個商家一個訂單，不同的倉庫發(fā)送的貨品也是屬于不同的訂單。因此會產(chǎn)出不同的訂單號。

訂單處理：根據(jù)支付的狀態(tài)進行不同的處理

????????1） 在線支付

????????????????a) 支付未成功—從新發(fā)起支付

????????????????b) 支付超時---訂單關閉

????????2) 貨到付款