簡歷準備
簡歷答疑準備專業技能答疑：1、orm框架2、restful接口規範3、Django restframework框架4、django框架5、分佈式系統：6、緩存系統7、Mysql查詢優化1、從索引上優化2、sql語句上優化8、分庫分表，讀寫分離9、redis10、mongdb11、高併發負載均衡的處理1 什麼是負載均衡？2、處理負載均衡的四種方式1、HTTP重定向實現負載均衡過程描述調度策略優缺點分析2、 DNS負載均衡DNS是什麼具體做法調度策略優缺點分析動態DNS綜上所述3、 反向代理負載均衡什麼是反向代理負載均衡？優缺點粘滯會話4、負載均衡組件12、vim13、docker14、集羣與分佈式15、設計者模式1、單例模式單例模式的優點單例模式的應用舉例單例模式的缺點2、工廠類相關模式16、基本算法17、CMDB系統20、go介紹21、
專業技能答疑：
1、orm框架
對象關係映射，方便開發
手擼orm框架，仿django，不帶創建數據庫功能，但是可以建表，對數據進行增刪改查
主要思路是封裝SQL語句，
先創建表的元類，在裏面判斷主鍵，拼接建表語句
建工具類，單獨建增刪改查函數 負責增刪改查，
建連接類，負責連接，在init中寫，調用類自動連接
複雜的寫不了就用原生的django，
2、restful接口規範
根據請求，進行相應的操作，儘量用名詞表示資源
1、API與通訊協議，總是使用https協議，比http安全
2、域名：儘量將API部署在專用域名後（跨域問題）
3、版本：每個接口都應該有版本
https://127.0.0.1/api/v2/books(推薦用這種)
4、路徑：網絡上任何東西都是資源，均使用名詞表示（可以是複數）
5、method
6、過濾：通過在url上傳參的形式傳遞搜索路徑
7、狀態碼：請求回去,需要有狀態碼
8、錯誤信息，應該返回錯誤信息，error當做key
9、返回結果，針對不同操作，服務器向用戶返回的結果應該符合以下規範。
10、Hypermedia API，RESTful API最好做到Hypermedia，即返回結果中提供鏈接，連向其他API方法，使得用戶不查文檔，也知道下一步應該做什麼。
3、Django restframework框架
序列化組件：最重要的是序列化，把字符串轉換爲json，需要返回一個當前表不存在的字段，用method，序列化中返回，
認證組件，可以返回值，返回url，付給request，
登錄認證
權限認證
頻率認證
解析器
視圖：用viewset沒有集成view，必須手動集成，APIview繼承了，不需要手動寫，
響應器
分頁器
版本控制
4、django框架
靜態文件配置：
orm框架：
路由層：
視圖層：
模版層：
模型層：
inclusion_tag：代碼片段：
choice：
事物操作：
defer 和only數據庫優化：只查需要的數據，
組件：
django與ajax：
分頁器：
forms組件
cookie組件
session組件
中間件
auth組件
5、分佈式系統：
1、python操作Elasticsearch（分佈式全文檢索引擎）
2、
6、緩存系統
將頁面緩存到文件，或者緩存到內存數據可中，一般放到redis中，然後訪問時直接到內存數據庫中直接拿數據，避免了資源的浪費，但是不具備實時更新的效果，
7、Mysql查詢優化
1、從索引上優化
1、建立合適的索引
建表時一定得有主鍵
2、主鍵索引和唯一鍵索引查詢效率最高（聯合索引可避免重複性高的情況）
3、爲需要經常排序、分組、聯合操作的字段建立索引，可避免排序
4、常作爲where的字段建立索引
5、列值長度較長的索引列,我們建議使用前綴索引.
6、 降低索引條目,一方面不要創建沒用索引,不常使用的索引清理,percona toolkit 7、索引維護要避開業務繁忙期
開發者對於索引：
查詢儘量有條件，儘量有索引（業務允許的情況下）
索引不能有運算，函數，子查詢
2、sql語句上優化
1、儘量不要連表查詢
2、儘量不要有外聯，
改業務邏輯採用實務操作單表
8、分庫分表，讀寫分離
建主庫和從庫，主從複製，讀數據和寫數據分別對不同的數據庫進行
9、redis
單線程的工作模式
純內存操作
單線程操作，避免了頻繁的上下文切換
採用了非阻塞I/O多路複用
10、mongdb
11、高併發負載均衡的處理
1 什麼是負載均衡？
當一臺服務器的性能達到極限時，我們可以使用服務器集羣來提高網站的整體性能。那麼，在服務器集羣中，需要有一臺服務器充當調度者的角色，用戶的所有請求都會首先由它接收，調度者再根據每臺服務器的負載情況將請求分配給某一臺後端服務器去處理。
那麼在這個過程中，調度者如何合理分配任務，保證所有後端服務器都將性能充分發揮，從而保持服務器集羣的整體性能最優，這就是負載均衡問題。
2、處理負載均衡的四種方式
1、HTTP重定向實現負載均衡
過程描述
當用戶向服務器發起請求時，請求首先被集羣調度者截獲；調度者根據某種分配策略，選擇一臺服務器，並將選中的服務器的IP地址封裝在HTTP響應消息頭部的Location字段中，並將響應消息的狀態碼設爲302，最後將這個響應消息返回給瀏覽器。
當瀏覽器收到響應消息後，解析Location字段，並向該URL發起請求，然後指定的服務器處理該用戶的請求，最後將結果返回給用戶。
在使用HTTP重定向來實現服務器集羣負載均衡的過程中，需要一臺服務器作爲請求調度者。用戶的一項操作需要發起兩次HTTP請求，一次向調度服務器發送請求，獲取後端服務器的IP，第二次向後端服務器發送請求，獲取處理結果。
調度策略
調度服務器收到用戶的請求後，究竟選擇哪臺後端服務器處理請求，這由調度服務器所使用的調度策略決定。
隨機分配策略
當調度服務器收到用戶請求後，可以隨機決定使用哪臺後端服務器，然後將該服務器的IP封裝在HTTP響應消息的Location屬性中，返回給瀏覽器即可。
輪詢策略(RR)
調度服務器需要維護一個值，用於記錄上次分配的後端服務器的IP。那麼當新的請求到來時，調度者將請求依次分配給下一臺服務器。
由於輪詢策略需要調度者維護一個值用於記錄上次分配的服務器IP，因此需要額外的開銷；此外，由於這個值屬於互斥資源，那麼當多個請求同時到來時，爲了避免線程的安全問題，因此需要鎖定互斥資源，從而降低了性能。而隨機分配策略不需要維護額外的值，也就不存在線程安全問題，因此性能比輪詢要高。
優缺點分析
採用HTTP重定向來實現服務器集羣的負載均衡實現起來較爲容易，邏輯比較簡單，但缺點也較爲明顯。
在HTTP重定向方法中，調度服務器只在客戶端第一次向網站發起請求的時候起作用。當調度服務器向瀏覽器返回響應信息後，客戶端此後的操作都基於新的URL進行的(也就是後端服務器)，此後瀏覽器就不會與調度服務器產生關係，進而會產生如下幾個問題：
由於不同用戶的訪問時間、訪問頁面深度有所不同，從而每個用戶對各自的後端服務器所造成的壓力也不同。而調度服務器在調度時，無法知道當前用戶將會對服務器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每臺服務器罷了。
若分配給該用戶的後端服務器出現故障，並且如果頁面被瀏覽器緩存，那麼當用戶再次訪問網站時，請求都會發給出現故障的服務器，從而導致訪問失敗
2、 DNS負載均衡
DNS是什麼
在瞭解DNS負載均衡之前，我們首先需要了解DNS域名解析的過程。
我們知道，數據包採用IP地址在網絡中傳播，而爲了方便用戶記憶，我們使用域名來訪問網站。那麼，我們通過域名訪問網站之前，首先需要將域名解析成IP地址，這個工作是由DNS完成的。也就是域名服務器。
我們提交的請求不會直接發送給想要訪問的網站，而是首先發給域名服務器，它會幫我們把域名解析成IP地址並返回給我們。我們收到IP之後纔會向該IP發起請求。
那麼，DNS服務器有一個天然的優勢，如果一個域名指向了多個IP地址，那麼每次進行域名解析時，DNS只要選一個IP返回給用戶，就能夠實現服務器集羣的負載均衡。
具體做法
首先需要將我們的域名指向多個後端服務器(將一個域名解析到多個IP上)，再設置一下調度策略，那麼我們的準備工作就完成了，接下來的負載均衡就完全由DNS服務器來實現。
當用戶向我們的域名發起請求時，DNS服務器會自動地根據我們事先設定好的調度策略選一個合適的IP返回給用戶，用戶再向該IP發起請求。
調度策略
一般DNS提供商會提供一些調度策略供我們選擇，如隨機分配、輪詢、根據請求者的地域分配離他最近的服務器。
優缺點分析
DNS負載均衡最大的優點就是配置簡單。服務器集羣的調度工作完全由DNS服務器承擔，那麼我們就可以把精力放在後端服務器上，保證他們的穩定性與吞吐量。而且完全不用擔心DNS服務器的性能，即便是使用了輪詢策略，它的吞吐率依然卓越。
此外，DNS負載均衡具有較強了擴展性，你完全可以爲一個域名解析較多的IP，而且不用擔心性能問題。
但是，由於把集羣調度權交給了DNS服務器，從而我們沒辦法隨心所欲地控制調度者，沒辦法定製調度策略。
DNS服務器也沒辦法瞭解每臺服務器的負載情況，因此沒辦法實現真正意義上的負載均衡。它和HTTP重定向一樣，只不過把所有請求平均分配給後端服務器罷了。
此外，當我們發現某一臺後端服務器發生故障時，即使我們立即將該服務器從域名解析中去除，但由於DNS服務器會有緩存，該IP仍然會在DNS中保留一段時間，那麼就會導致一部分用戶無法正常訪問網站。這是一個致命的問題！好在這個問題可以用動態DNS來解決。
動態DNS
動態DNS能夠讓我們通過程序動態修改DNS服務器中的域名解析。從而當我們的監控程序發現某臺服務器掛了之後，能立即通知DNS將其刪掉。
綜上所述
DNS負載均衡是一種粗獷的負載均衡方法，這裏只做介紹，不推薦使用。
3、 反向代理負載均衡
什麼是反向代理負載均衡？
反向代理服務器是一個位於實際服務器之前的服務器，所有向我們網站發來的請求都首先要經過反向代理服務器，服務器根據用戶的請求要麼直接將結果返回給用戶，要麼將請求交給後端服務器處理，再返回給用戶。
之前我們介紹了用反向代理服務器實現靜態頁面和常用的動態頁面的緩存。接下來我們介紹反向代理服務器更常用的功能——實現負載均衡。
我們知道，所有發送給我們網站的請求都首先經過反向代理服務器。那麼，反向代理服務器就可以充當服務器集羣的調度者，它可以根據當前後端服務器的負載情況，將請求轉發給一臺合適的服務器，並將處理結果返回給用戶。
優缺點
優點
隱藏後端服務器。
與HTTP重定向相比，反向代理能夠隱藏後端服務器，所有瀏覽器都不會與後端服務器直接交互，從而能夠確保調度者的控制權，提升集羣的整體性能。
故障轉移
與DNS負載均衡相比，反向代理能夠更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時，能夠及時通知反向代理服務器，並立即將其刪除。
合理分配任務
HTTP重定向和DNS負載均衡都無法實現真正意義上的負載均衡，也就是調度服務器無法根據後端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺後端服務器的權重。我們可以根據服務器的配置設置不同的權重，權重的不同會導致被調度者選中的概率的不同。
缺點
調度者壓力過大
由於所有的請求都先由反向代理服務器處理，那麼當請求量超過調度服務器的最大負載時，調度服務器的吞吐率降低會直接降低集羣的整體性能。
制約擴展
當後端服務器也無法滿足巨大的吞吐量時，就需要增加後端服務器的數量，可沒辦法無限量地增加，因爲會受到調度服務器的最大吞吐量的制約。
粘滯會話
反向代理服務器會引起一個問題。若某臺後端服務器處理了用戶的請求，並保存了該用戶的session或存儲了緩存，那麼當該用戶再次發送請求時，無法保證該請求仍然由保存了其Session或緩存的服務器處理，若由其他服務器處理，先前的Session或緩存就找不到了。
解決辦法1：
可以修改反向代理服務器的任務分配策略，以用戶IP作爲標識較爲合適。相同的用戶IP會交由同一臺後端服務器處理，從而就避免了粘滯會話的問題。
解決辦法2：
可以在Cookie中標註請求的服務器ID，當再次提交請求時，調度者將該請求分配給Cookie中標註的服務器處理即可。
4、負載均衡組件
1.1、apache
—— 它是Apache軟件基金會的一個開放源代碼的跨平臺的網頁服務器，屬於老牌的web服務器了，支持基於Ip或者域名的虛擬主機，支持代理服務器，支持安全Socket層(SSL)等等，目前互聯網主要使用它做靜態資源服務器，也可以做代理服務器轉發請求(如：圖片鏈等)，結合tomcat等servlet容器處理jsp。
1.2、ngnix
—— 俄羅斯人開發的一個高性能的 HTTP和反向代理服務器。由於Nginx 超越 Apache 的高性能和穩定性，使得國內使用 Nginx 作爲 Web 服務器的網站也越來越多，其中包括新浪博客、新浪播客、網易新聞、騰訊網、搜狐博客等門戶網站頻道等，在3w以上的高併發環境下，ngnix處理能力相當於apache的10倍。
參考：apache和tomcat的性能分析和對比(Nginx 0.8.x + PHP 5.2.13（FastCGI）搭建勝過Apache十倍的Web服務器（第6版）[原創])
1.3、lvs
—— Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。由畢業於國防科技大學的章文嵩博士於1998年5月創立，可以實現LINUX平臺下的簡單負載均衡。瞭解更多，訪問官網：http://zh.linuxvirtualserver.org/。
1.4、HAProxy
—— HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點， 這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬件上，完全可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上.
1.5、keepalived
—— 這裏說的keepalived不是apache或者tomcat等某個組件上的屬性字段，它也是一個組件，可以實現web服務器的高可用(HA high availably)。它可以檢測web服務器的工作狀態，如果該服務器出現故障被檢測到，將其剔除服務器羣中，直至正常工作後，keepalive會自動檢測到並加入到服務器羣裏面。實現主備服務器發生故障時ip瞬時無縫交接。它是LVS集羣節點健康檢測的一個用戶空間守護進程，也是LVS的引導故障轉移模塊（director failover）。Keepalived守護進程可以檢查LVS池的狀態。如果LVS服務器池當中的某一個服務器宕機了。keepalived會通過一 個setsockopt呼叫通知內核將這個節點從LVS拓撲圖中移除。
1.6、memcached
—— 它是一個高性能分佈式內存對象緩存系統。當初是Danga Interactive爲了LiveJournal快速發展開發的系統，用於對業務查詢數據緩存，減輕數據庫的負載。其守護進程(daemon)是用C寫的，但是客戶端支持幾乎所有語言(客戶端基本上有3種版本[memcache client for Java;spymemcached;xMecache])，服務端和客戶端通過簡單的協議通信；在memcached裏面緩存的數據必須序列化。
1.7、terracotta
—— 是一款由美國Terracotta公司開發的著名開源Java集羣平臺。它在JVM與Java應用之間實現了一個專門處理集羣功能的抽象層，允許用戶在不改變系統代碼的情況下實現java應用的集羣。支持數據的持久化、session的複製以及高可用(HA)。
12、vim
一種編輯器
13、docker
容器技術,
14、集羣與分佈式
15、設計者模式
設計模式是面對各種問題進行提煉和抽象而形成的解決方案。這些設計方案是前人不斷試驗，考慮了封裝性、複用性、效率、可修改、可移植等各種因素的高度總結。它不限於一種特定的語言，它是一種解決問題的思想和方法
二十三種設計者模式
1、單例模式
單例模式的優點
1、由於單例模式要求在全局內只有一個實例，因而可以節省比較多的內存空間； 2、全局只有一個接入點，可以更好地進行數據同步控制，避免多重佔用； 3、單例可長駐內存，減少系統開銷。
單例模式的應用舉例
1、生成全局惟一的序列號； 2、訪問全局複用的惟一資源，如磁盤、總線等； 3、單個對象佔用的資源過多，如數據庫等； 4、系統全局統一管理，如Windows下的Task Manager； 5、網站計數器。
單例模式的缺點
1、單例模式的擴展是比較困難的； 2、賦於了單例以太多的職責，某種程度上違反單一職責原則（六大原則後面會講到）; 3、單例模式是併發協作軟件模塊中需要最先完成的，因而其不利於測試； 4、單例模式在某種情況下會導致“資源瓶頸”。
2、工廠類相關模式
3、建造者模式
建造者模式的定義如下：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。 建造者模式的作用，就是將“構建”和“表示”分離，以達到解耦的作用。
4、原型模式
5、代理模式
6、裝飾器模式
裝飾器模式定義如下：動態地給一個對象添加一些額外的職責。在增加功能方面，裝飾器模式比生成子類更爲靈活。
7、適配器模式
8、門面模式
9、組合模式
10、享元模式
11、橋樑模式
12、策略模式
13、責任鏈模式
14、命令模式
15、中介者模式
16、模板模式
17、迭代器模式
迭代器模式的定義如下：它提供一種方法，訪問一個容器對象中各個元素，而又不需要暴露對象的內部細節。
18、訪問者模式
19、觀察者模式
20、解釋器模式
21、備忘錄模式
22、狀態模式:
23、設計原則:
16、基本算法
冒泡排序:
直接排序:
插入排序:
快速排序:
迴歸排序:
17、CMDB系統
20、go介紹