面試問題總結二（技術能力-PHP）----Ⅱ

時間 2019-11-11

標籤面試問題總結技術能力 php 欄目快樂工作简体版

原文原文鏈接

20、支付功能的實現？php

答：在線支付通常來講有兩種實現方式，一種是調用各個銀行提供的接口，另外一種是使用第三方集成好的支付功能，兩種方式各有優劣。對於第三方支付來講會須要提交企業5證來驗證，還會有部分手續費，可是實現起來就很是方便了。對於直接使用銀聯接口的話就是使用起來必來麻煩，要爲各個銀行寫接口實現，可是相比起來就更加安全了。html

案例參考：https://blog.csdn.net/qq_38869854/article/details/79204792mysql

2一、如何保證促銷產品不會超賣？程序員

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

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

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

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

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

2二、商城秒殺的實現？json

答:搶購、秒殺是現在很常見的一個應用場景，主要須要解決的問題有兩個：

1 高併發對數據庫產生的壓力

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

對於第一個問題，用緩存來處理搶購，避免直接操做數據庫，例如使用 Redis。

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

2三、購物車原理？

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

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

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

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

四、清空購物車；

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

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

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

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

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

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

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

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

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

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 的文件屬性使其仍然留有安全隱患。結合數據庫的方式雖然在必定程度上解決了上述的問題，但從上面的例子能夠看出：在這種購物流程中涉及到對數據庫表的頻繁操做，尤爲是用戶每選購一次商品，都要與數據庫進行鏈接，當用戶不少的時候就加大了服務器與數據庫的負荷。

2四、redis 消息隊列先進先出須要注意什麼？

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

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

二、使用兩個隊列，一個普通隊列，一個高級隊列，針對任務的級別放入不一樣的隊列，獲取任務時也很簡單。

三、redis 的 BRPOP 命令能夠按順序從多個隊列中取值，BRPOP 會按照給出的 key 順序查看，並在找到的第一個非空 list 的尾部彈出一個元素，redis> BRPOP list1 list2 0 。

list1作爲高優先級任務隊列list2 作爲普通任務隊列這樣就實現了先處理高優先級任務，當沒有高優先級任務時，就去獲取普通任務方式 1 最簡單，但實際應用比較侷限，方式 3 能夠實現複雜優先級，但實現比較複雜，不利於維護，方式 2 是推薦用法，實際應用最爲合適

2五、簡述一下對redis 的認識？

答：Redis(REmote DIctionary Server) 是一個由Salvatore Sanfilippo寫的key-value存儲系統。

Redis是一個開源的使用ANSI C語言編寫、遵照BSD協議、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。

它一般被稱爲數據結構服務器，由於值（value）能夠是字符串(String), 哈希(Map), 列表(list), 集合(sets) 和有序集合(sorted sets)等類型。

Redis 與其餘 key - value 緩存產品有如下三個特色：

Redis支持數據的持久化，能夠將內存中的數據保存在磁盤中，重啓的時候能夠再次加載進行使用。
Redis不只僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
Redis支持數據的備份，即master-slave模式的數據備份。

Redis 優點

性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操做。
原子 – Redis的全部操做都是原子性的，意思就是要麼成功執行要麼失敗徹底不執行。單個操做是原子性的。多個操做也支持事務，即原子性，經過MULTI和EXEC指令包起來。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過時等等特性。

Redis與其餘key-value存儲的不一樣之處

Redis有着更爲複雜的數據結構而且提供對他們的原子性操做，這是一個不一樣於其餘數據庫的進化路徑。
Redis運行在內存中可是能夠持久化到磁盤，因此在對不一樣數據集進行高速讀寫時須要權衡內存，由於數據量不能大於硬件內存。
在內存數據庫方面的另外一個優勢是，相比在磁盤上相同的複雜的數據結構，在內存中操做起來很是簡單，這樣Redis能夠作不少內部複雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產生的，由於他們並不須要進行隨機訪問。

2六、你工做中遇到哪些難題？如何解決？

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

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

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

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

④以前工做中遇到過不少不懂的知識技能，但在公司發展規劃中須要用到這些知識，由於才畢業沒多久而且是在創業公司，也沒有人能夠帶領去學習相關的知識。前期確實有點手忙腳亂的感受，後來經過與領導交流和加入一些技術羣與羣裏的技術大咖們進行探討學習，以後在工做之餘梳理了下公司的發展計劃，羅列了一系列的知識技能點，按需求時間順序去查找相關的資料和在網上聽取相關知識的公開課，並結合實踐進行練習。經過實戰練習發現問題並記錄下來，能經過網上查詢找到解決的方法的就先解決，實在沒辦法了纔去詢問技術羣裏的前輩或諮詢講解公開課的老師。堅持自學和與他人溝通很是重要，只要天天學一點，堅持下去總會有所收穫的。

2七、用戶下單如何處理？

答:下單前判斷用戶有沒有登陸，在沒有登陸的狀況下，不容許下單。登錄後，可進行下單，並生成惟一的訂單號，此時訂單的狀態爲未支付。

2八、電商的登陸是怎麼實現的？

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

2九、接口數據安全是如何處理的？

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

30、短信發送如何實現？通常什麼狀況下會用到？

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

3一、用戶不登陸如何把商品加入購物車？

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

可是若用戶禁用了cookie，則須要提示用戶開啓cookie 才能生效。

3二、如何定義接口？

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

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

應用型接口： API（application interface）數據對外訪問的一個入口。客戶端須要什麼樣的數據，咱們就給他們提供相應的數據。

我主要是參與的 APP 開發中接口API的編寫，數據以 json 的格式返回，而且配以相應的接口文檔。

3三、SKU 減庫存？

答:SKU = Stock Keeping Unit (庫存量單位) 即庫存進出計量的單位，能夠是以件，盒，托盤等爲單位。SKU 是庫存量單位，區分單品。在服裝、鞋類商品中使用最多最廣泛。例如紡織品中一個 SKU 一般表示：規格、顏色、款式。在設計表時，不只僅只有商品表，商品表中有個總庫存，咱們還須要涉及一張 SKU 表，裏面有 SKU 庫存和單價字段，用戶每購買一件商品，實際上購買的都是 SKU 商品，這樣在下訂單成功後，應該根據所購買的商品的惟一的 SKU 號來進行相應的 SKU 庫存的減小，固然商品的總庫存保存在商品主表中，也須要減小總庫存中的庫存量。

3四、庫存的設置？

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

3五、訂單和庫存2張表如何保證數據的一致性？

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

3六、O2O 用戶下單,c 端下單,如何保證 b a 端數據一致?

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

3七、Redis 如何防止高併發？

答:其實 redis 是不會存在併發問題的，由於他是單進程的，再多的 command 都是 one by one 執行的。咱們使用的時候，可能會出現併發問題，好比 get 和 set 這一對。redis 爲何會有高併發問題redis 的出身決定 Redis 是一種單線程機制的 nosql 數據庫，基於 key-value，數據可持久化落盤。因爲單線程因此 redis 自己並無鎖的概念，多個客戶端鏈接並不存在競爭關係，可是利用 jedis 等客戶端對 redis 進行併發訪問時會出現問題。發生鏈接超時、數據轉換錯誤、阻塞、客戶端關閉鏈接等問題，這些問題均是因爲客戶端鏈接混亂形成。同時，單線程的天性決定，高併發對同一個鍵的操做會排隊處理，若是併發量很大，可能形成後來的請求超時。在遠程訪問 redis 的時候，由於網絡等緣由形成高併發訪問延遲返回的問題。解決辦法在客戶端將鏈接進行持久化，同時對客戶端讀寫 Redis 操做採用內部鎖 synchronized。服務器角度，利用 setnx 變向實現鎖機制。

3八、作秒殺通常用什麼數據庫？怎麼實現？

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

3九、支付寶流程如何實現？

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

40、微信支付流程如何實現？

官方文檔：

https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=8_3

答：業務流程說明：
一、商戶後臺系統根據用戶選購的商品生成訂單。
二、用戶確認支付後調用微信支付【統一下單API】生成預支付交易；
三、微信支付系統收到請求後生成預支付交易單，並返回交易會話的二維碼連接code_url。
四、商戶後臺系統根據返回的code_url生成二維碼。
五、用戶打開微信「掃一掃」掃描二維碼，微信客戶端將掃碼內容發送到微信支付系統。
六、微信支付系統收到客戶端請求，驗證連接有效性後發起用戶支付，要求用戶受權。
七、用戶在微信客戶端輸入密碼，確認支付後，微信客戶端提交受權。
八、微信支付系統根據用戶受權完成支付交易。
九、微信支付系統完成支付交易後給微信客戶端返回交易結果，並將交易結果經過短信、微信消息提示用戶。微信客戶端展現支付交易結果頁面。
十、微信支付系統經過發送異步消息通知商戶後臺系統支付結果。商戶後臺系統需回覆接收狀況，通知微信後臺系統再也不發送該單的支付通知。
十一、未收到支付通知的狀況，商戶後臺系統調用【查詢訂單API】。
十二、商戶確認訂單已支付後給用戶發貨。