[PHP]面試問題探討2

此次主要是討論技術的廣度，對問題廣度進行深刻的分析和討論。

2. 知識的廣度

2.1 大家架構是怎麼樣的？

答： 咱們的架構整體來講分爲4塊，分別是業務架構，應用架構，數據架構還有技術架構。 能夠分開來講下咱們的架構體系：

1. 業務架構。咱們是廣告業務，主要是針對大流量平臺的架構。 因此，咱們根據不一樣的業務場景分爲不一樣的架構，如廣告投放/管理，數據報表等做爲核心項目，基於核心項目咱們拆分了，廣告接口項目

2. 應用架構。 咱們對應用進行垂直化進行拆分。主要是對業務解耦和提升系統的穩定性。應用架構分層的，包括表現層，如廣告投放頁面，業務層，服務層，資源層。 其中業務層包括業務系統，如投放系統，圖片存儲系統，業務監控系統等。 服務層，主要是提供一些基礎的服務功能，如用戶的管理，權限的校驗等。

3. 數據架構。 數據架構咱們作了數據和應用服務器分離，避免出現數據和應用的負載/資源影響應用服務器相互影響。 同時咱們採用了部分讀寫分離。 減小主庫的壓力。 對於一些大表，咱們進行表拆分。如小時數據統計表。對於一些常常須要查詢或者須要計算的數據，咱們採用redis緩存來處理。

4. 技術架構。咱們的前期是本身在AWS ec2搭建相關的服務，如redis, mysql等。 後期咱們測試aws服務，同時也調研了其餘的團隊的aws使用狀況，從服務的穩定和咱們須要的服務都有相應的解決方案。 使用的服務包括，ELB解決負載均衡的問題，使用了RDS處理數據庫問題， 使用了Redis 作緩存和消息隊列的工做。 同時還使用s3作對象處理的服務。 解決素材本地化的問題。 在技術架構的時候咱們考慮到aws的可監控，可回滾，可在線擴容等都提供解決方案。 咱們就技術整體架構是構建在aws服務上。

2.2 對CodeIgniter框架作了什麼深度優化?

答：CodeIgniter 是一個很是老的框架了。 採用了還比較老的5.3之前的下劃線的命名方式。 咱們使用了版本是2.2，咱們在此作的優化包括：

1. 增長了composer 加載類的機制。 這個跟CI的類加載機制仍是不同的。
2. 爲了更好開發項目，咱們擴展了Service層。Service層主要應用/控制器更好的提供服務。
3. 對於CI裏面一些特性或者遇到的問題作了擴展。 寫死的超時機制，xss機制等作了一些擴展
4. 其餘的增長了一些擴展的組件和工具等。

2.3 JS的原理是是什麼？ 查看

2.3.1 javascript 是怎麼個東西？ @todo

答： javascript 是前端的執行腳本語言。譯式腳本語言，是一種動態類型、弱類型、基於原型的語言，內置支持類型。
這二者的區別用一句話來歸納就是：編譯器是將源代碼編譯爲另一種代碼（好比機器碼，或者字節碼），而解釋器是直接解析並將代碼運行結果輸出。javascript 採用的是單線程的方式進行處理

2.3.2 javascript 爲何是單線程的？

答：javascript 的單線程，主要是考慮js執行過程當中多線程保持同步帶來的複雜度， 如在執行事件的時候，一個事件對建立一個element，而另一個刪除了element,主要避免多線程的同步問題的複雜度。

2.3.3 javascript 事件回調函數和機制是什麼？

答：js把function 做爲一個對象的類型，這樣經過參數類型的轉換從而實現方法的回調操做。 而這種機制能夠異步處理的方式，避免同步等待的過程。 尤爲在xhttpRequest使用的場景不少。

2.3.4 javascript prototype是怎麼樣的？

答：咱們都知道js基本上都是函數的表達式，就比如面向過程編程同樣，經過函數的調用。可是這樣隨着項目的負載，使用的js代碼愈來愈複雜在必定的程度上就很差處理了。這樣js其實也有面向對象的一些特性，而原型就是能夠設置本身的對象，而且能夠包含其方法和屬性信息。這樣在必定的程度上解決了js對象的擴展問題。

2.4 ajax的機制和原理是什麼？ @todo

答：Ajax 是javascript 的異步回調的機制，主要是使用xmlHttpRequest 請求的方式。 Ajax的工做原理至關於在用戶和服務器之間加了—箇中間層(AJAX引擎),使用戶操做與服務器響應異步化。 ajax核心就在於對客戶端和服務之間的數據通訊進行了一層封裝，支持的服務有：實時驗證，實時刷新，實時更新用戶，做者和標題，從而能夠快速的獲取服務端的數據，並動態的使用javascript填充區域的數據。

2.5 Redis

2.5.1 Redis的機制和原理是什麼？

答：Redis 是一個高效的分佈式緩存存儲和管理機制。 它的實現原理，首先採用客戶端和服務端c/s模式。 客戶端請求redis服務端，服務端採用多路事件模型libevent 其次， 線程對事件的處理包括建立，更新，刪除等操做，也內存分配和管理策略。 使用的分配算法包括slab ，申請塊內存的方法，管理內存算法主要使用LRU算法機制。 保證Redis的高速緩存特性。 最好，處理的結果返回。

2.5.2 Redis 訂閱和發佈機制

答： Redis 訂閱和發佈機制,主要是消息的生產者把消息放入channel中，其中channel能夠多個。 而消費者若是關注/訂閱了這個Channel消息類型，就會廣播給相應的消費者。 從而達到訂閱和發佈的效果。

2.5.3 Redis 大家的吞吐量是多少？

答： 咱們現有使用Redis不是很充分，主要是使用場景仍是廣告數據的計算和平常的緩存處理。 咱們測試的吞吐量大概5k。 咱們Redis配置，採用兩臺16GRedis做爲集羣處理。

2.5.4 Redis 的事務機制是怎麼處理的？

答： Redis 爲了支持事務的操做也增長了事務的回滾機制。 在redis操做的時候，能夠redis 會把開啓事務的操做加入到隊列中，而後一塊兒提交。 若是中間有事務的異常全部提交的都將失敗。 具體的命令：Redis事務的實現須要用到 MULTI 和 EXEC 兩個命令。若是客戶端在發送EXEC命令以前斷線了，則服務器會清空事務隊列，事務中的全部命令都不會被執行。

2.5.5 若是達到每秒1w/s或者10w/s你打算怎麼來處理？

答：redis單機的話處理2w其實就很容易產生數據包問題。咱們算下，若是平均一條記錄是0.1k，那麼2w 就是 2M/s 若是1G內存能夠處理500s，大概預估10分鐘。 16G能夠存儲的內存是3個小時熱數據。而對於一些須要技術28天歸因的redis數據失效時間比較長，因此redis仍是比較難知足10w這樣大的體量的緩存機制。 能夠採用業界比較成熟的的kafka，可是具體這項技術的引進須要各類指標的測試還要調用具體的坑有哪些。

2.5.6 Redis 使用遇到的坑有哪些？

答：如今體量還不是很大，暫時沒有遇到大的坑。 有些坑是開發同窗在設置redis失效時間比較長產生的，影響redis擠壓的內存比較多

2.5.7 Redis 的集羣和分佈式原理 @todo

答: Redis集羣主備，主要是Redis aof文件的同步處理。 AOF 相似mysql 的binlog， 同步的機制主要是主開一個線程寫aof文件，具體根據aof配置策略，而後從開啓兩個線程，一個讀取aof文件，而且把aof寫入中繼器文件。 從而實現主從能夠同步。 而Redis 分佈式主要解決的時候數據的一致性，事務和數據的分片。 Redis 跟memcache 一致性hash算法不太同樣，使用了鍵和槽的hash桶算法。 經常使用了hash算法如crc32, 把不一樣的鍵放到不一樣的hash桶中。 而保證不一樣節點均可以真正的數據同步使用。

redis hash槽通常有16384個槽點，而對節點的存儲採用地址拉鍊法，不斷的把在節點的數據節點延伸。這樣能夠知足redis的節點的分佈。redis解決分佈式一方面支持了分佈式事務，另外一份方面對服務器槽點服務器進行邏輯映射。因此節點仍是存在一些問題的。

2.6 Elasticsearch機制和原理是什麼？ @todo

答： 在咱們項目中使用es的技術主要仍是探索階段。咱們是想用來解決報表數據查詢比較慢的問題，如今對es瞭解主要是方案的探討。我能夠簡單聊下咱們對es調研的方案和一些簡單的理解。從對es的瞭解，es的主要是解決搜索和分佈式問題。 而搜索這一塊仍是使用lucence 框架，對lucence框架基礎上增長索引分片，分佈式等解決方案。 提升了搜索的效率。 爲了更加方便和使用es,es挺比較restful的簡單清晰的請求方式。 elasticsearch 具體的原理，能夠分兩塊來探討。 一塊是lucence 搜索的機制，另一個是lucence 分佈氏技術。 lucence是使用java開發的全文搜索引擎的框架。爲何它可以這樣有效的做爲關鍵詞進行搜索呢？這個搜索引擎的設計思路是模擬咱們搜索的過程來構建的。 咱們輸入關鍵詞而後但願可以顯示關鍵詞在不一樣的文檔匹配的狀況。

1. 對文檔的全部內容進行關鍵詞切詞。切詞的算法整體歸位三類，基於字符串的匹配，基於單詞的語法的，還有基於統計的。具體能夠查找相關算法。
2. 採用到排序的方式記錄關鍵詞的在文檔的位置。並對關鍵詞進行構建索引。
3. 怎麼樣來構建很是好的索引是搜索引擎的關鍵。咱們的指望，查詢要快，內存要佔用的少，磁盤浪費少等咱們常見的方式可使用hashmap做爲索引可是這種方式太佔用內存了。咱們也會想到關係數據庫的b樹索引。b樹能夠做爲索引，可是b樹的索引更新的時候效率很低，不適合頻繁的採集和更新操做。後面有人提出對hashmap基礎上增長了字典和前綴的方式來提升索引的效率。這就是比較著名的fst算法。它的本質就是對索引的關鍵詞前綴下不斷創建關聯節點。對於重複的詞來講能夠省去重複詞佔用的空間，大大的提升使用的效率。
4. 最後是文檔內容的輸出，能夠對查詢命中的關鍵詞進行壓縮輸出，提升使用的效率。

另外一個就是es支持分佈式理念把其整合系統中去。要知足分佈式的處理通常須要解決這樣一些場景的問題：

1. 進行數據的分片，這樣才能夠把一個大的問題拆分紅更小塊，保證處理起來更加高效。同時還須要對分片的數據進行replication,創建副本集。
2. 要均衡的分配到不一樣的節點中，這樣避免節點分配不均產生的問題。常見的算法有一致性hash分配算法，還有redishash槽的算法。
3. 對於節點的管理，包括增長和刪除節點均可以保證其有效性，而且可以從新均衡分配。
4. 支持分佈式事務的原則。通常參考cap原則，通常高可用和分區均可以知足，強一致性比較難知足。主要仍是異步的事件同步機制會出現同步失敗重試和延遲的狀況，因此，咱們支持最終一致性的方式。 對於es基本知足前面說的幾點，除了知足這幾點和增長了，節點發現的方式。對於實效的節點可以檢測替換和恢復等操做。 還有更多細節的其特性須要根據實際的場景再進行其利用。

2.7. Supervisor 主要用來作什麼？ 它的機制和原理是什麼？

答：Supervisor 技術選擇主要是考慮到一些定時任務會出現中斷的狀況。 supervisor就是用Python開發的一套通用的進程管理程序，能將一個普通的命令行進程變爲後臺daemon，並監控進程狀態，異常退出時能自動重啓。因此咱們選擇了Supervisor. 使用Supervisor，把全部的守護進程都配置到它的配置裏面。而後啓動的Supervisor 就會對全部的進程去檢測，若是存在中斷的狀況，會自動重啓一個新的進程進行處理。

2.8 你所瞭解的TCP/IP協議 @todo

2.8.1 tcp的理解

答： TCP是傳輸層的協議，而且是可靠的數據傳輸協議。 咱們都知道OSI 有7層協議， 在tcp IP協議中，其中會話層，展現層， 應用層合併爲應用層。 因此咱們常常討論TCP/IP 4層模型。 如今就成了，應用發送數據包->TCP->IP->數據鏈路層，最後物理層。 TCP從這個分層結構來看，TCP首先要解決跟應用層的交互，也就是常常的3次握手協議和4次關閉鏈接協議，這裏會涉及三個概念，一個是syn同步序列號，ack確認碼，fin完成標識。來保證數據可靠性。 TCP層主要是解決傳輸層的問題，那解決了什麼問題？

1. 數據包標準化的問題。 若是數據包的大小沒有規範，這樣不一樣的路由器，不一樣的網絡對數據包的解析都沒有規範。 基於此，有挺多概念的如ack，window，syn 等都是TCP數據包大小。 tcp規劃了20個字節對於數據包頭進行規定2個字節源端口，2字節目標端口，4個字節放syn，4個字節放ack，2個字節放window，最後2個字節放偏移量，flag等內容。校驗碼2個，還有緊急指針2個。總共20個字節
2. 數據包丟包重傳的優化。 TCP是可靠的協議這樣就須要解決數據包的重傳問題，常見了算法有RTT算法。主要是跟進丟包時間差來決定是否須要重傳。

---

3. 數據包的重複包的問題。 如d-slab 算法，主要對確認的塊進行驗證。
4. 數據包傳輸的調度問題，如網絡阻塞，網絡。 這裏主要是根據window來調度。window 對數據包分爲4類，1類，數據包已發送已接受，2類，數據包已發送尚未接受，3 數據包已經發送，等待確認 ， 4. 數據未發送，也未確認。 解決的方式有，1）慢啓動，2）擁塞避免，3）擁塞發現，4）快速恢復。

2.8.2 IP協議的理解

答：IP表示網絡協議層，主要是根據傳輸層和數據鏈層制定報文結構，IP頭也是20個字節。主要內容包括，IP地址，目標地址，協議版本，協議的ttl，協議的校驗，和協議的的標識。主要是支持arp地址的解析。

2.9 你所瞭解的HTTP協議

2.9.1 HTTP 的版本狀況是怎麼樣？ @todo

答：HTTP 有3個版本， 0.9版本這個版本只支持get請求，已經中止了使用了。1.0版本支持get，post,put,delete等常見的http的方法。 1.1 版本在1.0版本增長了一些特性，如重複請求的緩存機制

2.9.2 HTTP的原理和機制

答：HTTP是無狀態的超文本的協議，主要解決的是客戶端和服務端的通訊。 咱們試想下若是沒有HTTP協議，咱們會怎麼來進行客戶端和服務端的通信。 咱們的通信的基本需求，創建鏈接，而後進行增刪改查的操做。 而若是沒有協議的話，就比如一條馬路大量的來往車輛沒有本身的規則和標準。咱們就須要，不一樣的區域有不一樣的協議來協商數據的傳輸。而HTTP協議就是這規則和標準，統一全部的傳輸方式，雖然不可以說是最好的，但必定是最普遍的傳輸協議。其實本身也能夠在開發制定本身的傳輸協議。 HTTP 是在應用層跟傳輸層創建的協議標準。首先創建鏈接採用TCP/IP 三層握手協議創建鏈接。 採用請求和相應的機制進行通訊。 在通訊過程當中採用了GET, POST, PUT,DELTE 方法,來知足交互。 除了解決基本的客戶端和服務端的通訊也解決其餘的問題。 包括HTTP無狀態怎麼來作區分和標識，採用了cookie或者session的技術。 而對於常常的重複請求和重複的相應，引進了Cache機制。 若是Cache-Control

1. HTTP 的通訊規則是基於URI，統一資源標識符，來定位資源。 而全部的服務端提供的服務均可以經過統一標識符來處理。解決鏈接的問題。
2. HTTP在解決通訊鏈接的問題，而後解決數據的傳遞問題。 對於數據的請求採用了各類請求數據的傳遞參數，如json參數，字符串傳輸等。 而相應也有一樣的指定。解決數據格式的問題
3. 解決權限控制的問題，cors跨域的控制
4. 在1.1版本更是對鏈接的效率和重複鏈接作了大的優化。包括採用了長鏈接機制，減小創建和啓動的成本，還有優化了緩存控制機制，有緩存的年齡，過時的時間，還有采用etag的緩存檢測機制等。

2.9.3 HTTPS 是怎麼樣的？

答： HTTPS 是在HTTP加上了一個s，這個主要是讓http更加的安全可靠的傳輸數據。 那HTTPS是怎麼來解決安全這件事情的呢？ 通常來講計算機解決安全主要從兩方面着手，一方面是權限控制，如只有知足某些條件你纔可以訪問這個資源或者服務，另外一方面就是經過加密的手段。 咱們試想一下，使用HTTP在使用過程當中的不安全的地方。 首先HTTP是無狀態的，這樣任何的代理均可以」假傳聖旨「，這樣就容易出現不可以識別真實的狀況。 而這種狀況呀在http其實已經能夠經過session驗證和客戶端加密和服務端解密來解決。 可是在客戶端加密和服務端解密的過程當中有一個重要的隱患：客戶端和服務端通常信息不怎麼加密，針對重要的信息才進行加密，而客戶端的代碼通常是暴露的，若是對客戶端的加密代碼進行研究是瞭解服務端發送的信息怎麼解密的。

針對這個狀況，能夠對於客戶端每次請求的全部數據都進行加密傳輸，而後服務端進行解密處理。可是涉及到客戶端和服務端的祕鑰怎麼傳輸的狀況。若是是寫死在客戶端，那麼就很容易被客戶端反編譯查看到，若是是經過http創建鏈接來傳遞祕鑰的話，天然會被中間的代理劫持。 針對http帶來的不安全，就出現了HTTPS的設計。

HTTPS 設計首先須要解決的是客端戶和服務端數據都須要加密，而且祕鑰最好是可逆和不可逆混合加密的方式來處理。 最後經過第三方的CA證書認證，過濾掉代理的劫持，保證數據的正常安全的通訊。

具體的設計流程以下：

1. 客戶端請求服務器，首先會驗證服務器CA認證的證書是否合法。具體主要是瀏覽器根認證裏面會根據關聯的CA認證機構進行查看是否合法/存在。
2. 客戶端瀏覽器驗證CA正常後，會把本身的私鑰以非對稱算法進行加密，如RSA算法(基於公因數分解)加密傳輸後，服務端就知道客戶端的祕鑰了。
3. 服務端採用對稱加密服務端祕鑰，如dea，aes而且以md5（基於hash分佈），sha散列算法加密。這樣客戶端也知道解除服務端數據。而後客戶端和服務端均可以正常的數據加密操做。而中間人會被過濾了。

2.10 你說下負載均衡（ELB）的原理？ ->done

答：負載均衡要知足的作到流量的分發，均衡的分發到不一樣的節點。而咱們http請求通常經過域名來請求，這樣咱們須要作好基於域名流量的策略。常見的策略有，dns輪詢，負載均衡器裏面內置dsn管理和對dns的反向服務器的代理或者服務器流量的分發。除了dns輪詢，還有流量的比例和比重,把流量均衡到不一樣的服務器節點上。而不一樣的策略能夠根據業務的場景來知足需求。處理流量的分發，還有流量的檢測和負載均衡的主歷來保證負載均衡的穩定，並對存在問題的節點檢測問題，均衡處理。除了分發流量，還能夠基於流量的內容過濾，如過濾色情,暴力等內容的信息。

2.10.1 怎麼來搭建現有的架構體系，而不是使用aws的服務？

答：在使用aws服務前，全部的服務都是咱們能夠搭建的，後面是從服務器的成本和其餘團隊的使用穩定性和高可用等多因素考慮。重新搭建架構體系，能夠把一步步的替換。如elb，咱們能夠本身經過搭建lvs，規劃好服務器的地址和管理的dns，進行節點的配置，最後經過數據庫的配置進行處理。知足elb中使用到的特性，而且對其進行基準測試，評估成本看是否方案是否可行。同理其餘的服務和組件也是一樣的思路和解決方法。

2.11 怎麼來作到自動伸縮的？->done

答：自動伸縮主要是要解決不一樣的服務器的各項指標的檢測，更重要的是知足服務器要大流量的增加的同時也須要考慮服務器閒置產生的浪費的狀況。從這個角度來看，要作一些必要的事情：

1. 服務器的監控，
2. 對服務器監控設置規則，能夠按照機會或者規則進行觸發，如CPU使用超過70%自動添加機器。
3. 對於歷史的流量時段或者特別的節假日，咱們要考慮提早啓動服務器來知足其流量的狀況。
4. 容錯的處理，自動檢查存在異常的實例，把這些實例進行替換保證系統正常完成執行操做。

2.12 S3對象存儲的原理是什麼？->done

答：S3的對象存儲。主要是用於管理一些文件還有一些日誌信息。在沒有使用s3的時候，咱們採用了更多的是寫入本地磁盤或者本身搭建簡單的文件系統。s3不但知足了平常的文件系統的需求，更重要的提供了高可用的服務，同時也能夠專一於場景開發。 簡單說下：

1. 支持了各類文件對象的存儲，存儲性能比較快
2. 有安全的驗證，而且對象進行主備消除了單點等。

2.13 說下自動伸縮的機制是什麼？->done

詳見：2.11

2.14 你所瞭解的Mysql集羣 ->done

2.14.1 Mysql 查詢過程是怎麼樣？

答：mysql是關係數據庫，它是c/s架構模式。客戶端和服務端採用半雙公的方式，客戶端請求後，須要等服務端的返回，一樣,服務端的返回，客戶端須要接收完成。 整體的查詢過程有這樣幾步：

1. mysql客戶端發送請求，而請求協議通常仍是基於http的協議方式
2. 服務端接收到請求後會查看緩存中是否存在結果命中，有就直接返回
3. 對於未命中，把sql構建成查詢樹，並對語法進行驗證，而且進行預處理權限的驗證，驗證OK後。根據查詢樹進行查詢任務的優化器中，而後檢查是否存在查詢的緩存的task，存在直接使用查詢的數據。而後把沒有緩存的sql。優化器根據查詢優化的最小成本去優化。
4. 放到優化器引擎去調用選擇的存儲引擎，而後根據存儲引擎返回的結果進行數據的返回。而後優化器統一計算計算結果，而後進行輸出。 這樣就是mysql的簡單的查詢過程了。

2.14.2 Mysql集羣的機制

答：mysql的集羣，主要是避免數據庫的執行單點狀況。mysql集羣是對mysql的水平擴展，常見的方式有，主從的同步的實現，也能夠一主多從的操做。 集羣構建後，須要對主從庫進行檢測，若是主庫掛掉了，能夠根據最新的sql時間從庫做爲主庫，而後起來寫bin log文件。主庫負責寫，從庫負責讀的操做。

2.14.3 Mysql 主從同步的機制

答：做爲主服務器須要開啓一個線程主要dump sql任務， 而從庫須要把線程主庫的dump sql寫入到從庫的中繼器文件中，而後開啓一個sql 線程，把中繼器文件寫入從庫中。從而實現主從的同步。

2.15.4 說下你瞭解的Mysql的索引機制是什麼樣的？

2.15 Mysql 事務

2.15.1 Mysql的事務狀況是怎麼樣?

2.16 說下用戶從打開你網站的技術過程？ ->done

2.17 代碼工具的路徑是什麼？ ->done

2.18 文檔化工具實現邏輯是什麼？ ->done

2.19 PHP

2.19.1 解析機制是什麼樣的？ ->done

解析機制主要是分爲4層，zend引擎，PHP層級，SAPI服務應用調用，最後是應用調用

zend引擎：是php的核心，這個是純C語言編寫包括，詞法，opcode,也支持對底層的數據結構的處理，如hashtable, 並進行內存的管理，使其更加方便使用。 Extension: 這個是PHP的擴展，包括增長一些PHP的驅動，裏面經常使用的mysql，redis的擴展；對於經常使用的函數，可擴展的性能的工具的處理

SAPI : 服務的外圍的編程接口， 經過sapi，應用能夠直接調用服務公共的接口，也能夠對Sapi經過一系列鉤子函數，使得PHP能夠和外圍交互數據，這是PHP很是優雅和成功的一個設計，經過sapi成功的將PHP自己和上層應用解耦隔離，PHP能夠再也不考慮如何針對不一樣應用進行兼容，而應用自己也能夠針對本身的特色實現不一樣的處理方式。SAPI也負責對cgi進行解析和命令行的調用，

Application : 應用層，這就是咱們的應用程序，能夠經過webserver 來實現web的服務操做和開發工做

2.19.2 PHP 解析器的opcache的是何時引進php版本，具體的實現機制是什麼？ ->done

2.19.3 PHP Hash table的數據結構邏輯

Hash table 實現了簡單的hash結構， 而且支持了增長附加的雙向列表， 提供正向和反向的遍歷數組的信息。

這裏涉及到的數據結構包括， Hash的數據結構， 雙向鏈表，PHP關聯數組，PHP索引數組信息。 這裏的雙向鏈表主要是爲了快速的遍歷和快速的刪除操做。 PHP索引數組對於數組的Key進行歸一化的處理。

2.20 大家系統的加密算法是什麼？ 爲何要使用這個？ ->done

常見的加密算法分紅3類 對稱加密算法： DES， AES,3DES DES 分組式加密算法，以64位爲分組對數據加密，加解密使用同一個算法。 而3DES對DES進行加密進行3次，使其更加安全和高效。

非對稱加密： RSA,DSA（數字簽名） hash加密算法：Hash算法特別的地方在於它是一種單向算法，用戶能夠經過Hash算法對目標信息生成一段特定長度的惟一的Hash值，卻不能經過這個Hash值從新得到目標信息。（hash加密算法）高級加密標準算法，是美國聯邦政府採用的一種區塊加密標準，用於替代原先的 常見的包括MD5,SHA, SHA-1, HMAC

DES：對稱加密， 指加密和解密使用相同密鑰的加密算法。

2.21 有了解過度布式嗎？ 簡單說下你的理解

2.21.1 分佈式的機制是什麼？

答：分佈式的方式主要是考慮任務的拆分，把一個大的事情不斷的拆分紅不一樣的小的塊。 從使得各個拆分的點能夠組織在一塊兒進行處理。 分佈式須要解決了的問題包括任務的拆分，還有任務的聚合處理，保證任務處理結果的一致性。 那具體怎麼來達到分佈式的效果呢？

1. 須要解決分佈式拆分的問題。 把一個大的服務拆分紅小的服務，進行服務的註冊和管理。（拆分的服務直接是能夠保持通訊和資源的共享）
2. 須要解決分佈式的事務的狀況，保證事務處理的一致性，通常是數據的最終一致性的要求。 而須要保證事務的一致性通常採用的是主服務收到從服務的一致性的確認以後進行判斷是否的執行仍是停止/回滾。
3. 分佈式還有解決的是高可用性的問題。 怎麼保證分佈在不一樣的節點的服務是高可用的？ 這個須要對不一樣節點進行單點容錯，而且檢測，保證數據的高可用性。 這就是咱們常見的副本集。

現有的一些框架如dubbo，spring clond在必定的程度上提供了對分佈式服務解決方案。

2.21.1 分佈式和集羣的區別

答：分佈式主要是解決垂直的任務的拆解問題，而集羣是解決水平的擴展問題。 分佈式更多的是須要解決業務和服務的拆解，保證每一個服務是高可用的。 而且各個服務是獨立可用相互使用的。 而且須要保證各個節點是正常運轉的。 而集羣更多的是水平的擴展，消除單點的狀況，而且增長總體的處理能力。

2.21.2 CAP原則

答：CAP原則又稱CAP定理，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

三種原則： CA without P : 若是不要求P（不容許分區），則C（強一致性）和A（可用性）是能夠保證的。

CP : 犧牲可用性 AP : 保持高可用性

但若是以算法劃分，到能分出幾類： 1.以Leader選舉爲主的一類算法，好比paxos、viewstamp，就是如今zookeeper、Chuby等工具的主體 2.以分佈式事務爲主的一類主要是二段提交，這些分佈式數據庫管理器及數據庫都支持 3.以若一致性爲主的，主要表明是Cassandra的W、R、N可調節的一致性 4.以租賃機制爲主的，主要是一些分佈式鎖的概念，目前尚未看到純粹「分佈式」鎖的實現 5.以失敗探測爲主的，主要是Gossip和phi失敗探測算法，固然也包括簡單的心跳 6.以弱一致性、因果一致性、順序一致性爲主的，開源尚很少，但大都應用在Linkedin、Twitter、Facebook等公司內部 7固然以異步解耦爲主的，還有各種Queue

2.22 能夠說下你理解的protobuf協議嗎？

答：protobuf 是google 開發出來的二進制協議，主要是解決數據的傳輸帶來的問題。 咱們常見的傳輸協議主要使用json的方式，而json優勢固然很清晰明瞭，結構也比較簡單。 也使用使用xml，解析和可讀性比較差，可是對於返回的數據比較好定義，包括數據的格式等都很是明顯。 它們有個很是大的問題就是返回的結果數據比較大，消耗網絡的傳輸和處理。 而protobuf就很是聰明的方式來解決協議上的問題了。 protobuf主要採用的協議方式是二進制對象的方式，全部的key多使用序號來生成，這個樣4個字節基本上能夠知足全部的key的填充，而內容也對字符,對象進行壓縮生成二進制碼，在必定的程度是減小了數據的傳輸成本，提升的數據的交互效率。

protobuf很是優秀的點：

1. 代碼生成機制，數據解析類自動生成。這樣值須要配置proto文件就能夠生成必要的信息
2. 支持向後兼容和向前兼容
3. 支持多種語言的方式

2.23 簡單說下你在項目中使用到的CI和TP框架

答：CI是框架比較簡單。主要是採用MVC模式，能夠很是方便的代碼進行封裝處理。 而路由也是很是簡單的方式，採用類和方法的路由方式。 而這些方式在必定的程度上開發只須要重點關注於項目的具體處理而不須要考慮具體的邏輯場景。 TP框架是國內的一款框架，第一次接觸的是TP框架，也對MVC進行封裝，特別是提供了簡單的M方法，能夠很是方便的進行SQL的查詢和處理，可是若是都把sql放到M方法體裏面，很容易產生代碼和模板的混亂，特別而是如今不少進行業務場景的拆分，這套機制是很難知足業務的需求。 隨着TP的改進，由以前的基於數據挖掘的內容改變成

2.24 技術功底

2.24.1 簡單說下網絡I/O模型是怎麼樣？

答：網絡的I/O主要分爲兩種，一種是同步等待的I/O，另一種是異步等待的I/O模型。 同步機制就是咱們常見的socket io， server不斷的監聽client是否對數據進行發送數據的請求，而後把數據請求進行處理。 而另一種是基於異步的I/O模型，這種模型主要解決的問題是異步的處理機制。 這樣增長了一個I/O緩存去和I/O的事件註冊機制，採用的模型能夠是epoll異步機制。 多路複用的I/O事件模型，更多的是解決等待的處理狀況，客戶端的狀況會優先放到註冊事件列表/隊列中，而後服務端會有事件回調，處理好的服務端會優先查看下是否還有時間服務沒有處理，若是存在，則進行接口的調用。 從而實現數據的接口調用操做。 整體來講有5中I/O模型：

1. 阻塞IO :讀必需要在寫以後纔可以讀
2. 非阻塞IO：每次輪詢檢測用戶有沒有執行好（主要是看文件描述符的緩衝區是否就緒），當書記報準備好的時候，就進行拷貝的工做。當數據包沒有準備好的時候也不阻塞程序，直接返回未準備好，等待下一吃用戶的輪詢。
3. 信號驅動IO：這個就是告訴系統內核，你準備就緒了就發送一個信號告訴我來調用事件的處理機制。
4. IO複用：對了一個select 對文件描述符號進行輪詢，當發現某個文件描述符就詢後就進行處理。這個是對阻塞I/O的支持多個文件的操做
5. 異步IO: 就是信號驅動IO和IO複用結合在一塊兒，一方面是告訴內核我有事件信號就直接通知我調用進程，另外一方面能夠註冊多個文件，對多個文件描述符進行監聽處理。

2.24.2 進程調度的機制是怎麼樣？

答：對於操做系統而言，進程就是一個Task，而不一樣的進程調度就是任務的調度。你任務的調度能夠分爲搶佔式的仍是非搶佔是的進程調度的方式。
而常見的任務調度都是基於時間片切換的方式，如每一個10ms進程進行切換調用。 一樣的也能夠進程採用優先級的方式進行進程的調度。 都有一些剛啓動的進程的優先級 linux能夠經過nice值來調整優先級，從而使得優先級更好的進行出來。

而搶佔式的方式常見的方式是FIFO,當前獲得的進程要所有使用完以後纔會退出，這樣對資源的消耗是很是的巨大的。

2.24.3 說下內存的模型是怎麼樣？

答：內存是存儲器中很是快速的方式。存儲器分爲主存和輔助存儲，輔助存儲主要是硬盤，磁盤等，而主存包括內存和高速緩存，通常而言高速緩存的空間很是的小，可操做的空間很是小，通常是操做系統內核進行調度。 因此咱們更多的是關注於內存的處理。 內存的主要數據和地址主要是從輔助存儲加載進來處理的。 那咱們具體說下java語言的內存模型： java的代碼主要是經過類加載器，加載到JVM虛擬機裏面。

1. java的內存數據區域對於java 代碼進行分類。 類裏面的方法放到方法區，變量和引用對象的變量放到棧區，而新建的對象和數組放到堆區，java裏面的線程放到線程池區，而對於程序的加載都有程序計數器記錄，記錄當前線程執行的內存地址。方便線程以前的切換，還可以還原到初始狀態。
2. Jvm 虛擬機編譯java的代碼，而後經過java的代碼執行生成class文件 。
3. Jvm 執行器（JIT）把class 文件加載到內存中，對於須要釋放的空間有java GC進行內存的回收處理。
4. JVM 編譯後連接c語言的本地接口的調用和數據的返回處理。

2.25 CSS

2.25.1 css的機制是什麼

答：css 是層疊樣式文件。 css主要是對Dom進行加載後的查找和渲染。 css會定製它的框架的基本樣式，而在框架的樣式風格下能夠本身定義樣式的風格。 css 須要解決兩件事情：

1. 怎麼進行DOM 的查找，這個常見的是使用class名稱或ID進行查找。除了這些查找有大量的方式是使用過濾的方式，經過節點通配符來獲取查找的節點。 如根據p段落來查找
2. 怎麼對查找的節點進行渲染，渲染須要考慮的是客戶端的大小和兼容性問題。 對於選擇的區域能夠採用相對大小也能夠採用以爲的大小的方式來保證節點渲染精確性。

2.25.2 CSS盒模型

答：CSS的盒模型盒子裏面有盒子內的座標和外部的座標。 咱們常說的內間距和外間距。 而間距包括上下左右的間距大小。 經過間距大小能夠控制盒子的位置

2.26 對hashMap的深度理解，是怎麼實現get和put

答：HashMap 是對Map接口的實現，裏面有兩個必要的方法，一個是hashcode，來定位hash存放的位置，兩個是equals方法來判斷對象是否匹配。 這個是使用層面的，而真正的hashMap可使用方式是hash桶，而hash桶的的算法能夠是多種如crc32效驗法。你hash的桶可使用拉鍊法，不斷的地址須要延伸。 這樣就能夠真正的實現hash的在桶的基礎上不斷的擴展。

2.27 分區分服，查看

答：遊戲有個特色，很是的依賴於網速。若是網速的性能差，常常出現掉線，那麼通常遊戲基本上是無法玩的。 通常的分區的考慮是跟進不一樣的網絡服務商和不一樣的大平臺來劃分，如電信網絡一區，網通一區。或者QQGame和QQ空間 不一樣的區支持的網絡信號是存在差別的。 在分區以後，會發現一些大的區在遊戲體量很是集中的時候會出現很是多人的狀況。 這時候須要在區的基礎上進一步花費，採用邏輯分服。

而分區分服務的實現：

1. 根據用戶量進行預估來判斷大概須要開啓多少個區和多少的個服知足前期的用戶的進入，加上有100w用戶。 咱們可能會分爲2個電信區，2個網通區。
2. 在具體的架構上來看，不一樣服務的DB是不一樣的。通常不互通。 從運營的架構機制來，用戶羣會集羣進行分發到不一樣的服務，而不一樣的服務下面有不一樣的服務器節點進行處理。 而後進行遊戲的服務請求。

2.28 加密技術

2.28.1 RSA加密

2.28.2 DES加密

2.28.3 AES加密

2.28.4 md5加密

2.28.5 sha加密

2.29 Kafka技術

3. 彈力設計

3.1 冪等性做用和應用場景是什麼？

3.2 隔離設計做用和應用場景？

3.3 異步通訊設計做用和應用場景？