PHP常見面試題

1.mvc是什麼?相互間有什麼關係?

答:mvc是一種開發模式,主要分爲三部分:m(model),也就是模型,負責數據的操做;v(view),也就是視圖,負責先後臺的顯示;c(controller),也就是控制器,負責業務邏輯

客戶端請求項目的控制器,若是執行過程當中須要用到數據,控制器就會到模型中獲取數據,再將獲取到的數據經過視圖顯示出來

2.oop是什麼?

答:oop是面向對象編程,面向對象編程是一種計算機編程架構,OOP 的一條基本原則是計算機程序是由單個可以起到子程序做用的單元或對象組合而成。

OOP具備三大特色

一、封裝性：也稱爲信息隱藏，就是將一個類的使用和實現分開，只保留部分接口和方法與外部聯繫，或者說只公開了一些供開發人員使用的方法。因而開發人員只 須要關注這個類如何使用，而不用去關心其具體的實現過程，這樣就能實現MVC分工合做，也能有效避免程序間相互依賴，實現代碼模塊間鬆藕合。

二、繼承性：就是子類自動繼承其父級類中的屬性和方法，並能夠添加新的屬性和方法或者對部分屬性和方法進行重寫。繼承增長了代碼的可重用性。PHP只支持單繼承，也就是說一個子類只能有一個父類。

三、多態性：子類繼承了來自父級類中的屬性和方法，並對其中部分方法進行重寫。因而多個子類中雖然都具備同一個方法，可是這些子類實例化的對象調用這些相同的方法後卻能夠得到徹底不一樣的結果，這種技術就是多態性。多態性加強了軟件的靈活性。

 

3.smarty是什麼,有什麼做用?

答:回答一:smarty是用php寫出來的模板引擎,也是目前業界最著名的php模板引擎之一

它分離了邏輯代碼和外在的顯示,提供了一種易於管理和使用的方法,用來將混雜的php邏輯代碼與html代碼進行分離

回答二:smarty是php中最著名的引擎框架之一,咱們公司使用的是TP框架,已經封裝好了smarty模板,因此沒有單獨使用過

回答三: smarty是個模板引擎，最顯著的地方就是有能夠把模板緩存起來。通常模板來講，都是作一個靜態頁面，而後在裏面把一些動態的部分用一切分隔符切開，而後在PHP裏打開這個模板文件，把分隔符裏面的值替換掉，而後輸出來，你能夠看下PHPLib裏面的template部分。

而smarty設定了緩存參數之後，第一次運行時候會把模板打開，在php替換裏面值的時候把讀取的html和php部分從新生成一個臨時的php文件，這樣就省去了每次打開都從新讀取html了。若是修改了模板，只要從新刷下就好了。

4.你在公司負責那些項目?

答:因爲咱們公司是一個外包公司,不可能只作一個項目,公司的項目都是交叉進行的,論壇,微信,商城我都作過?

5.你作過那些模塊?

答:登錄註冊,商品管理,購物車模塊,訂單管理

6.大家公司是使用什麼框架?

答:咱們公司採用的是TP框架,運用的mysql+apache+php進行開發,由於TP框架是一個免費開源的,輕量級的php開發框架,並且是咱們中國人本身開發的,也是國內用的比較多的,各類資料也比較齊全

7.laravel有那些特色?

答:回答一:

 1.強大的rest router:用簡單的回調函數就能夠調用,快速綁定controller和router

2.artisan:命令行工具,不少手動的工做都自動化

3.可繼承的模板,簡化view的開發和管理

4.blade模板:渲染速度更快

5.ORM操做數據庫

6.migration:管理數據庫和版本控制

7.測試功能也很強大

8.composer也是亮點

回答二: laravel框架引入了門面,依賴注入,Ioc模式,以及各類各樣的設計模式等

在設計時，可重用現有的，在之前的項目的領域中已被測試過的類使系統知足業務需求並具備較高的質量。

三、效率高

在軟件開發時，根據設計的須要對現實世界的事物進行抽象，產生類。使用這樣的方法解決問題，接近於平常生活和天然的思考方式，勢必提升軟件開發的效率和質量。

8.請簡述一下數據庫的優化?

答:數據庫的優化能夠從四個方面來優化:

1.從結構層: web服務器採用負載均衡服務器,mysql服務器採用主從複製,讀寫分離

2.從儲存層: 採用合適的存儲引擎,採用三範式

3.從設計層: 採用分區分表,索引,表的字段採用合適的字段屬性,適當的採用逆範式,開啓mysql緩存

4.sql語句層:結果同樣的狀況下,採用效率高,速度快節省資源的sql語句執行

9.如何解決異常處理?

答: 拋出異常:使用try...catch，異常的代碼放在try代碼塊內，若是沒有觸發異常，則代碼繼續執行，若是異常被觸發，就會 拋出一個異常。Catch代碼塊捕獲異常，並建立一個包含異常信息的對象。$e->getMessage()，輸出異常的錯誤信息。

解決異常:使用set_error_handler函數獲取異常(也可使用try()和catch()函數),而後使用set_exception_handler()函數設置默認的異常處理程序,register_shutdown_function()函數來執行,執行機制是,php要把調入的函數調入到內存,當頁面全部的php語句都執行完成時,再調用此函數

 

10.權限管理(RBAC)的實現?

答: 1.首先建立一張用戶表:id name auto(保存格式爲:控制器-方法)

2.而後在後臺中建立一個基類控制器,控制器裏封裝一個構造方法,當用戶登錄成功後,使用TP框架中封裝好的session函數獲取保存在服務器中的session id,而後實例化模型,經過用戶id獲取保存在數據表中的auth數據,使用explode函數分割獲取到的數據,並使用一個數組保存起來,而後使用TP框架中封裝好的常量獲取當前控制器和方法,而後把他們組裝成字符串,使用in_array函數進行判斷該數組中是否含有當前獲取到的控制器和方法,若是沒有,就提示該用戶沒有權限,若是有就進行下一步操做

11.TP框架有哪些優勢?

答:TP框架是咱們中國人本身開發的框架,各類資料比較齊全,國內用的比較多,比較簡單和方便,並且是免費開源的

12.TP的特性有哪些?

答: 1.多表查詢很是方便,在model中幾句代碼就能夠完成對多表的關聯操做

2.融合了smarty模板,使先後臺分離

3.支持多種緩存技術,尤爲對memcache技術支持很是好

4.命名規範,模型,視圖,控制器嚴格遵循命名規則,經過命名一一對應

5.支持多種url模式

6.內置ajax返回方法,包括xml,json,html等

7.支持應用擴展,類庫擴展,驅動擴展等

13.請介紹一下laravel框架?

答: laravel框架的設計思想比較先進,很是適合應用各類開發模式,做爲一個框架,它爲你準備好了一切,composer是php的將來,沒有composer,php確定要走向沒落

laravel框架最大的特色和優秀之處就是集合了php比較新的特色,以及各類各樣的設計模式,Ioc模式,依賴注入等

13.怎麼保證促銷商品不會超賣

答:這個問題是咱們當時開發時遇到的一個難點，超賣的緣由主要是下的訂單的數目和咱們要促銷的商品的數目不一致致使的，每次老是訂單的數比咱們的促銷商品的數目要多，當時咱們的小組討論了很久，給出了好幾個方案來實現：

第一種方案是：①在每次下訂單前咱們判斷促銷商品的數量夠不夠，不夠不容許下訂單，更改庫存量時加上一個條件，只更改商品庫存大於0的商品的庫存，當時咱們使用ab進行壓力測試，當併發超過500，訪問量超過2000時，仍是會出現超賣現象。因此被咱們否認了。

第二種方案是：②使用mysql的事務加排他鎖來解決，首先咱們選擇數據庫的存儲引擎爲innoDB，使用的是排他鎖實現的，剛開始的時候咱們測試了下共享鎖，發現仍是會出現超賣的現象。有個問題是，當咱們進行高併發測試時，對數據庫的性能影響很大，致使數據庫的壓力很大，最終也被咱們否認了。

第三種方案是：③使用文件鎖實現。當用戶搶到一件促銷商品後先觸發文件鎖，防止其餘用戶進入，該用戶搶到促銷品後再解開文件鎖，放其餘用戶進行操做。這樣能夠解決超賣的問題，可是會致使文件得I/O開銷很大。

最後咱們使用了redis的隊列來實現。將要促銷的商品數量以隊列的方式存入redis中，每當用戶搶到一件促銷商品則從隊列中刪除一個數據，確保商品不會超賣。這個操做起來很方便，並且效率極高，最終咱們採起這種方式來實現

競爭狀態下如何解決庫存的正確減小(」超賣」問題)

對於第一個問題，已經很容易想到用緩存來處理搶購，避免直接操做數據庫，例如使用Redis。第二個問題，咱們可使用redis隊列來完成，把要秒殺的商品放入到隊列中，由於pop操做是原子的，即便有不少用戶同時到達，也是依次執行，文件鎖和事務在高併發下性能降低很快，固然還要考慮其餘方面的東西，好比搶購頁面作成靜態的，經過ajax調用接口，其中也可能會出現一個用戶搶屢次的狀況，這時候須要再加上一個排隊隊列和搶購結果隊列及庫存隊列。高併發狀況下，將用戶進入排隊隊列，用一個線程循環處理從排隊隊列取出一個用戶，判斷用戶是否已在搶購結果隊列，若是在，則已搶購，不然未搶購，庫存減1，寫數據庫，將用戶入結果隊列。

14.購物車的原理

答:購物車至關於現實中超市的購物車，不一樣的是一個是實體車，一個是虛擬車而已。用戶能夠在購物網站的不一樣頁面之間跳轉，以選購本身喜好的商品，點擊購買時，該商品就自動保存到你的購物車中，重複選購後，最後將選中的全部商品放在購物車中統一到付款臺結帳，這也是儘可能讓客戶體驗到現實生活中購物的感受。服務器經過追蹤每一個用戶的行動，以保證在結帳時每件商品都物有其主。

主要涉及如下幾點:

一、把商品添加到購物車，即訂購

二、刪除購物車中已定購的商品

三、修改購物車中某一本圖書的訂購數量

四、清空購物車

五、顯示購物車中商品清單及數量、價格

實現購物車的關鍵在於服務器識別每個用戶並維持與他們的聯繫。可是HTTP協議是一種「無狀態(Stateless)」的協議，於是服務器不能記住是誰在購買商品，當把商品加入購物車時，服務器也不知道購物車裏原先有些什麼，使得用戶在不一樣頁面間跳轉時購物車沒法「隨身攜帶」，這都給購物車的實現形成了必定的困難。

目前購物車的實現主要是經過cookie、session或結合數據庫的方式。下面分析一下它們的機制及做用。

1五、cookie

cookie是由服務器產生，存儲在客戶端的一段信息。它定義了一種Web服務器在客戶端存儲和返回信息的機制，cookie文件它包含域、路徑、生存期、和由服務器設置的變量值等內容。當用戶之後訪問同一個Web服務器時，瀏覽器會把cookie原樣發送給服務器。經過讓服務器讀取原先保存到客戶端的信息，網站可以爲瀏覽者提供一系列的方便，例如在線交易過程當中標識用戶身份、安全要求不高的場合避免用戶重複輸入名字和密碼、門戶網站的主頁定製、有針對性地投放廣告等等。利用cookie的特性，大大擴展了WEB應用程序的功能，不只能夠創建服務器與客戶機的聯繫，由於cookie能夠由服務器定製，所以還能夠將購物信息生成cookie值存放在客戶端，從而實現購物車的功能。用基於cookie的方式實現服務器與瀏覽器之間的會話或購物車，有如下特色：

一、cookie存儲在客戶端，且佔用不多的資源，瀏覽器容許存放300個cookie，每一個cookie的大小爲4KB，足以知足購物車的要求，同時也減輕了服務器的負荷;

二、cookie爲瀏覽器所內置，使用方便。即便用戶不當心關閉了瀏覽器窗口，只要在cookie定義的有效期內，購物車中的信息也不會丟失;

三、cookie不是可執行文件，因此不會以任何方式執行，所以也不會帶來病毒或攻擊用戶的系統;

四、基於cookie的購物車要求用戶瀏覽器必須支持並設置爲啓用cookie，不然購物車則失效;

五、存在着關於cookie侵犯訪問者隱私權的爭論，所以有些用戶會禁止本機的cookie功能。

1六、session

session是實現購物車的另外一種方法。session提供了能夠保存和跟蹤用戶的狀態信息的功能，使當前用戶在session中定義的變量和對象能在頁面之間共享，可是不能爲應用中其餘用戶所訪問，它與cookie最重大的區別是，session將用戶在會話期間的私有信息存儲在服務器端，提升了安全性。在服務器生成session後，客戶端會生成一個sessionid識別號保存在客戶端，以保持和服務器的同步。這個sessionid是隻讀的，若是客戶端禁止cookie功能，session會經過在URL中附加參數，或隱含在表單中提交等其餘方式在頁面間傳送。所以利用session實施對用戶的管理則更爲安全、有效。

一樣，利用session也能實現購物車，這種方式的特色是：

一、session用新的機制保持與客戶端的同步，不依賴於客戶端設置;

二、與cookie相比，session是存儲在服務器端的信息，所以顯得更爲安全，所以可將身份標示，購物等信息存儲在session中;

三、session會佔用服務器資源，加大服務器端的負載，尤爲當併發用戶不少時，會生成大量的session，影響服務器的性能;

四、由於session存儲的信息更敏感，並且是以文件形式保存在服務器中，所以仍然存在着安全隱患。

結合數據庫的方式

這也是目前較廣泛的模式，在這種方式中，數據庫承擔着存儲購物信息的做用，session或cookie則用來跟蹤用戶。這種方式具備如下特色：

一、數據庫與cookie分別負責記錄數據和維持會話，能發揮各自的優點，使安全性和服務器性能都獲得了提升;

二、每個購物的行爲，都要直接創建與數據庫的鏈接，直至對錶的操做完成後，鏈接才釋放。當併發用戶不少時，會影響數據庫的性能，所以，這對數據庫的性能提出了更高的要求;

三、使cookie維持會話有賴客戶端的支持。

各類方式的選擇：

雖然cookie可用來實現購物車，但必須得到瀏覽器的支持，再加上它是存儲在客戶端的信息，極易被獲取，因此這也限制了它存儲更多，更重要的信息。因此通常cookie只用來維持與服務器的會話，例如國內最大的當當網絡書店就是用cookie保持與客戶的聯繫，可是這種方式最大的缺點是若是客戶端不支持cookie就會使購物車失效。

Session 能很好地與交易雙方保持會話，能夠忽視客戶端的設置。在購物車技術中獲得了普遍的應用。但session的文件屬性使其仍然留有安全隱患。

結合數據庫的方式雖然在必定程度上解決了上述的問題，但從上面的例子能夠看出：在這種購物流程中涉及到對數據庫表的頻繁操做，尤爲是用戶每選購一次商品，都要與數據庫進行鏈接，當用戶不少的時候就加大了服務器與數據庫的負荷。

17.redis消息隊列先進先出須要注意什麼

答:一般使用一個list來實現隊列操做，這樣有一個小限制，因此的任務統一都是先進先出，若是想優先處理某個任務就不太好處理了，這就須要讓隊列有優先級的概念，咱們就能夠優先處理高級別的任務，實現方式有如下幾種方式：

1)單一列表實現：隊列正常的操做是 左進右出(lpush,rpop)爲了先處理高優先級任務，在遇到高級別任務時，能夠直接插隊，直接放入隊列頭部(rpush)，這樣，從隊列頭部(右側)獲取任務時，取到的就是高優先級的任務(rpop)

2)使用兩個隊列，一個普通隊列，一個高級隊列，針對任務的級別放入不一樣的隊列，獲取任務時也很簡單，redis的BRPOP命令能夠按順序從多個隊列中取值，BRPOP會按照給出的 key 順序查看，並在找到的第一個非空 list 的尾部彈出一個元素，redis> BRPOP list1 list2 0

list1 作爲高優先級任務隊列

list2 作爲普通任務隊列

這樣就實現了先處理高優先級任務，當沒有高優先級任務時，就去獲取普通任務

方式1最簡單，但實際應用比較侷限，方式3能夠實現複雜優先級，但實現比較複雜，不利於維護

方式2是推薦用法，實際應用最爲合適

12.TP框架中的大字母函數?

答: U:對url的組裝

A:內部實例化控制器

S:緩存處理

R:調用某個控制器的操做方法

D:實例化自定義模型類

M:實例化基礎模型類

I:獲取參數

L:設置或者獲取當前語言

C:設置或獲取,保存配置

18.你負責的模塊有哪些難題

答:在我負責的B2B電商項目中，當時我負責的是訂單模塊，因爲客戶一次選擇了多家商戶的商品，最終生成了一個訂單，這樣咱們平臺在給商戶結算時出現了不知道這比費用應該給哪一個商戶，這時候咱們小組通過討論，須要涉及到訂單拆分，也就是說用戶點擊支付後,若是有多件商品,而且不是同一家店鋪那麼 就要用到訂單的拆分,好比若是有兩件商品,而且不是同一店鋪 就在原來的訂單號下 在生成兩個子訂單號 並修改訂單表中兩件商品的訂單號。最終實現了商品的分配管理，解決了咱們的難題。

我以爲在開發過程當中，遇到的難題無非是兩個，一個是技術層次的，我認爲，只要你有恆心，有熱心，沒有以爲不了的難題。另外一個就是溝通問題，在任何地方任什麼時候候溝通都是最重要的，尤爲是咱們作開發的，不溝通好，會影響整個項目的進度，我本人是個很是還溝通的人，因此這點上也沒多大問題。

19.用戶下單是怎麼處理的

答:判斷用戶有沒有登陸，在沒有登陸的狀況下，不容許下單。登錄後，可進行下單

並生成惟一的訂單號，此時訂單的狀態爲未支付。

20.電商的登陸是怎麼實現的

答:分爲普通登陸和第三方登陸 這邊主要說一下第三方登陸吧，第三方登錄主要使用的是author協議，我就以QQ的第三方登錄爲例來進行說明：當用戶在咱們的站點請求QQ的第三方登錄時，咱們站點會引導用戶跳轉到QQ的登錄受權界面， 當用戶輸入QQ和密碼成功登陸之後會自動跳回到咱們站點設置好的回調頁面，並附帶一個code參數，接着你使用code再次去請求QQ的受權頁面，就能夠從中獲取到一個access token(訪問令牌)，經過這個access_token，咱們能夠調用QQ提供給咱們的接口，好比獲取open_id，能夠獲取用戶的基本信息。獲取到以後，咱們須要拿用戶的受權信息和open_id和咱們平臺的普通用戶進行綁定。這樣無論是普通用戶登錄仍是第三方登錄用戶，均可以實現登錄。

21.接口安全方面是怎麼處理的

答:咱們當時是這麼作的，使用HTTP的POST方式,對固定參數+附加參數進行數字簽名,使用的是md5加密,好比:我想經過標題獲取一個信息,在客戶端使用 信息標題+日期+雙方約定好的一個key經過md5加密生成一個簽名(sign),而後做爲參數傳遞到服務器端,服務器端使用一樣的方法進行校驗,如何接受過來的sign和咱們經過算法算的值相同，證實是一個正常的接口請求，咱們纔會返回相應的接口數據。

22.作秒殺用什麼數據庫，怎麼實現的。

答:由於秒殺的一瞬間，併發很是大，若是同時請求數據庫，會致使數據庫的壓力很是大，致使數據庫的性能急劇降低，更嚴重的可能會致使數據庫服務器宕機。這時候通常採用內存高速緩存數據庫redis來實現的,redis是非關係型數據庫，redis是單線程的，經過redis的隊列能夠完成秒殺過程。

23.支付寶流程怎麼實現的

答:首先要有一個支付寶帳號，接下來向支付寶申請在線支付業務，簽署協議。協議生效後有支付寶一方會給網站方一個合做夥伴ID,和安全校驗碼，有了這兩樣東西就能夠按照支付寶接口文檔開發支付寶接口了，中間主要涉及到一個安全問題。整個流程是這樣的：咱們的網站經過post傳遞相應的參數(如訂單總金額，訂單號)到支付頁面，支付頁面把一系列的參數通過處理，以post的方式提交給支付寶服務器，支付寶服務器進行驗證，並對接收的數據進行處理，把處理後的結果返回給咱們網站設置的異步和同步回調地址，經過相應的返回參數，來處理相應的業務邏輯，好比返回的參數表明支付成功，更改訂單狀態。

24.什麼是單點登陸?

答:單點登陸SSO(Single Sign On)說得簡單點就是在一個多系統共存的環境下，用戶在一處登陸後，就不用在其餘系統中登陸，也就是用戶的一次登陸能獲得其餘全部系統的信任。

28.用的什麼技術實現短信發送，在哪調用

答:我主要用的第三方短信接口，在申請接口時進行相應信息的配置，而後在咱們站點須要用到短信驗證的地方進行調用，咱們一般在用戶註冊時使用到。

25.sku減庫存

答:SKU = Stock Keeping Unit (庫存量單位)

即庫存進出計量的單位，能夠是以件，盒，托盤等爲單位。SKU是庫存量單位，區分單品。

在服裝、鞋類商品中使用最多最廣泛。 例如紡織品中一個SKU一般表示：規格、顏色、款式。

在設計表時，不只僅只有商品表，商品表中有個總庫存，咱們還須要涉及一張SKU表，裏面有SKU庫存和單價字段，用戶每購買一件商品，實際上購買的都是SKU商品，這樣在下訂單成功後，應該根據所購買的商品的惟一的SKU號來進行相應的SKU庫存的減小，固然商品的總庫存保存在商品主表中，也須要減小總庫存中的庫存量。

26.在工做中遇到什麼困難?

答:整體來講：在工做我主要遇到這幾個問題比較難處理：

①我以前工做的時候發現常常會出現一些臨時需求打亂了個人計劃，搞得有時候這個任務還沒完成，又得去作其餘的任務，最後一天下來，大大小小的東西是不少，可是沒有完成得很是好的，後面我總結了一下，我會把這些都添加優先級，遇到臨時需求，按照優先級從新將已有任務和臨時任務進行排版，保證在規定時間內有效率的完成優先級高的任務。

②在作項目需求時候，遇到理解能力欠佳的人，溝通時容易被氣到，影響本身的情緒，最後反倒還不能到達須要的效果。後面，每次到這種時候，我通常會藉助一些紙質的、更加形象的東西，讓雙方都認同的、都能明白的一種方式來進行溝通，後面減小了不少沒必要須的麻煩。你們都知道，對於程序員來講，改需求是一件很痛苦的事情，因此前期的溝通工做很重要。

③還有一件事時，我之前的領導不太懂技術，因此每次出一個新的需求出來，老是要求咱們在很短的時間內完成，完不成咱們就會被懷疑能力有問題。固然，每一個領導都但願本身的員工可以儘快的完成任務，下降成本，提升效率。這時候我會把咱們的需求細化，把其中的重點、難點都列出來，作好時間規劃，耐心的跟領導溝通，項目每一個點的重要性和時間的花費比例，確保在這個規劃的時間點內保質保量的完成任務。慢慢的也獲得了領導的承認，其實領導也不是一味的不通情理，只要把東西計劃好了，以最小的代價換取最高的價值，每一個人都是很容易理解得

27.用戶不登陸，怎麼直接加入購物車的

答:用戶在不登陸的狀況下，能夠把要購買商品的信息(如商品的ID，商品的價格、商品的sku_id,購買數量等關鍵數據)存到COOKIE裏面，當登錄的狀況下。把COOKIE裏面的內容存到數據庫，並清除cookie中的數據。

28.庫存設置?

答:庫存分爲商品總庫存和SKU庫存，每每商品總庫存的爲SKU庫存的總和。通常在商城的後臺對貨品設置最高庫存及最低庫存後，當前庫存數量與最高、最低二者比較，超出庫存或者低於庫存的，則被統計成報表形式反映，便於用戶掌握貨品庫存超、短缺狀態及數量。

29.訂單、庫存兩個表 如何保證數據的一致性?

答:在一個電子商務系統中，正常的應該是訂單生成成功後，相應的庫存進行減小。必需要保證二者的一致性，但有時候由於某些緣由，好比程序邏輯問題，併發等問題，致使下單成功而庫存沒有減小的狀況。這種狀況咱們是不容許發生的，MySQL中的事務恰好能夠解決這一問題，首先得選擇數據庫的存儲引擎爲innoDB,事務規定了只有下訂單完成了，而且相應的庫存減小了才容許提交事務，不然就事務回滾，確保數據一致性。

30.O2O用戶下單,c端下單,如何保證b a端數據一致?

答:O2O爲線上和線下模式，O2O模式奉行的是「線上支付+實體店消費」的消費模式，即消費者在網上下單完成支付後，憑消費憑證到實體店消費。O2O模式是把商家信息和支付程序放在線上進行，而把商品和服務兌現放在線下，也就是說O2O模式適用於快遞沒法送達的有形產品。數據一致性的問題是O2O行業中最多見的問題，咱們能夠相似於數據庫的主從複製的思路來解決這個問題。O2O有個供應商系統，相似於主服務器，在C端(從服務器)下單時，數據同步更新到供應商系統端，b、a實時從供應商系統中拉取數據進行同步，好比利用定時任務，定時拉取數據進行同步。

31.Redis 如何防止高併發

答:其實redis是不會存在併發問題的，由於他是單進程的，再多的command都是one by one執行的。咱們使用的時候，可能會出現併發問題，好比get和set這一對。

redis爲何會有高併發問題

redis的出身決定

Redis是一種單線程機制的nosql數據庫，基於key-value，數據可持久化落盤。因爲單線程因此redis自己並無鎖的概念，多個客戶端鏈接並不存在競爭關係，可是利用jedis等客戶端對redis進行併發訪問時會出現問題。發生鏈接超時、數據轉換錯誤、阻塞、客戶端關閉鏈接等問題，這些問題均是因爲客戶端鏈接混亂形成。

同時，單線程的天性決定，高併發對同一個鍵的操做會排隊處理，若是併發量很大，可能形成後來的請求超時。

在遠程訪問redis的時候，由於網絡等緣由形成高併發訪問延遲返回的問題。

解決辦法

在客戶端將鏈接進行池化，同時對客戶端讀寫Redis操做採用內部鎖synchronized。

服務器角度，利用setnx變向實現鎖機制。

32.寫過接口嗎，怎麼定義接口的

答：寫過。接口分爲兩種：一種是數據型接口，一種是應用型接口。

數據型接口：是比抽象類更抽象的某種「結構」——它其實不是類，可是跟類同樣的某種語法結構，是一種結構規範，規範咱們類要以什麼格式進行定義，通常用於團隊比較大，分支比較多的狀況下使用。

應用型接口： API(application interface) 數據對外訪問的一個入口

我主要是參與的APP開發中接口的編寫，客戶端須要什麼樣的數據，咱們就給他們提供相應的數據，數據以json/xml的格式返回，而且配以相應的接口文檔。

33.秒殺當中的細節你是怎麼得出來的

答:經過性能測試及模擬秒殺場景。每一個問題都通過反覆測試，不斷的發現問題，不斷的解決。

34.接口和抽象類的區別是什麼？

答:抽象類是一種不能被實例化的類，只能做爲其餘類的父類來使用。抽象類是經過關鍵字abstract來聲明的。抽象類與普通類類似，都包含成員變量和成員方法，二者的區別在於，抽象類中至少要包含一個抽象方法，抽象方法沒有方法體，該方法天生就是要被子類重寫的。抽象方法的格式爲：abstract function abstractMethod(); 接口是經過 interface 關鍵字來聲明的，接口中的成員常量和方法都是 public 的，方法能夠不寫關鍵字public，接口中的方法也是沒有方法體。接口中的方法也天生就是要被子類實現的。抽象類和接口實現的功能十分類似，最大的不一樣是接口能實現多繼承。在應用中選擇抽象類仍是接口要看具體實現。子類繼承抽象類使用 extends，子類實現接口使用implements。

35.什麼是隊列？排它鎖，Myisam死鎖如何解決？

答:在默認狀況下MYisam是表級鎖，因此同時操做單張表的多個動做只能以隊列的方式進行； 排它鎖又名寫鎖，在SQL執行過程當中爲排除其它請求而寫鎖，在執行完畢後會自動釋放； 死鎖解決：先找到死鎖的線程號，而後殺掉線程ID