前言:

最近在面試找工作,整理一下遇到的面試題.大公司更傾向于基礎(chǔ),小公司更偏向于業(yè)務(wù)處理,但整體上遇到的面試問題大部分都會圍繞于你簡歷中寫了哪些技術(shù).
寫下這些面試題,權(quán)且當(dāng)做對用到的技術(shù)做概念上的梳理.當(dāng)然其中一些答案有的是我摘自別人的,可能存在不嚴(yán)謹(jǐn)?shù)那闆r,建議自行驗證

Django

講一下Django的生命周期

瀏覽器發(fā)起請求>>WSGI創(chuàng)建socket服務(wù)端，接收請求（Httprequest）>>中間件處理請求>>url路由，根據(jù)當(dāng)前請求的URL找到視圖函數(shù)>>view視圖，進(jìn)行業(yè)務(wù)處理>>中間件處理響應(yīng)>>WSGI返回響應(yīng)（HttpResponse）>>瀏覽器渲染

說一下用過哪些中間件

• 緩存中間件： django.middleware.cache.UpdateCacheMiddleware django.middleware.cache.FetchFromCacheMiddleware 開啟全站范圍的緩存。 如果開啟了這些緩存，任何一個由Django提供的頁面將會被緩存，緩存時長在CACHE_MIDDLEWARE_SECONDS中配置定義。

• 會話中間件 django.contrib.sessions.middleware.SessionMiddleware 開啟會話支持，session支持中間件，加入這個中間件，會在數(shù)據(jù)庫中生成一個django_session的表。

• 通用中間件： django.middleware.common.CommonMiddleware 通用中間件，會處理一些URL，比如baidu.com會自動的處理成www.baidu.com。比如/blog/111會處理成/blog/111/自動加上反斜杠。

• CSRF保護(hù)中間件 django.middleware.csrf.CsrfViewMiddleware 跨域請求偽造中間件。加入這個中間件，在提交表單的時候會必須加入csrf_token，cookie中也會生成一個名叫csrftoken的值，也會在header中加入一個HTTP_X_CSRFTOKEN的值來放置CSRF攻擊。

• 用戶授權(quán)中間件: django.contrib.auth.middleware.AuthenticationMiddleware 他會在每個HttpRequest對象到達(dá)view之前添加當(dāng)前登錄用戶的user屬性，也就是你可以在view中通過request訪問user。

• 消息中間件 django.contrib.messages.middleware.MessageMiddleware 展示一些后臺信息給前端頁面。如果需要用到消息，還需要在INSTALLED_APPS中添加django.contrib.message才能有效。如果不需要，可以把這兩個都刪除。

• XFrameOptionsMiddleware中間件 django.middleware.clickjacking.XFrameOptionsMiddleware 防止通過瀏覽器頁面跨Frame出現(xiàn)clickjacking（欺騙點擊）攻擊出現(xiàn)。

Python

python中倆個列表如何取交集

獲取兩個list 的交集

• 方法一:

a=[2,3,4,5]
b=[2,5,8]
tmp = [j for j in a if j in b] #列表推導(dǎo)式求的兩個列表的交集
print(tmp)

• 方法二:

print(list(set(a).intersection(set(b)))) # #列用集合的取交集方法

• 方法三:

lst = []
for i in a:
if i in b :
lst.append(i)
print(lst)

拓展:
獲取兩個 list 的差集
方法一:
ret = list(set(a)-set(b))
print(ret)
方法二:
print(list(set(b).difference(set(a)))) # b中有而a中沒有的
獲取兩個 list 的并集
方法一:
ret = list(set(a)-set(b))
print(ret)
方法二:
print(list(set(b).difference(set(a)))) # b中有而a中沒有的

python全局變量應(yīng)用場景

Python 允許在所有函數(shù)的外部定義變量，這樣的變量稱為全局變量（Global Variable）
全局變量的默認(rèn)作用域是整個程序，即全局變量既可以在各個函數(shù)的外部使用，也可以在各函數(shù)內(nèi)部使用
globals() 函數(shù)為 Python 的內(nèi)置函數(shù)，它可以返回一個包含全局范圍內(nèi)所有變量的字典，該字典中的每個鍵值對，鍵為變量名，值為該變量的值
locals() 函數(shù)也是 Python 內(nèi)置函數(shù)之一，通過調(diào)用該函數(shù)，我們可以得到一個包含當(dāng)前作用域內(nèi)所有變量的字典。這里所謂的“當(dāng)前作用域”指的是，在函數(shù)內(nèi)部調(diào)用 locals() 函數(shù)，會獲得包含所有局部變量的字典；而在全局范文內(nèi)調(diào)用 locals() 函數(shù)，其功能和 globals() 函數(shù)相同

python可變數(shù)據(jù)類型有哪些

• 可變數(shù)據(jù)類型：list（列表）、dict（字典）、set（集合，不常用）

• 不可變數(shù)據(jù)類型：數(shù)值類型（int、float、bool）、string（字符串）、tuple（元組）

可變數(shù)據(jù)類型：當(dāng)該數(shù)據(jù)類型對應(yīng)的變量的值發(fā)生了變化時，如果它對應(yīng)的內(nèi)存地址不發(fā)生改變，那么這個數(shù)據(jù)類型就是 可變數(shù)據(jù)類型。

不可變數(shù)據(jù)類型：當(dāng)該數(shù)據(jù)類型對應(yīng)的變量的值發(fā)生了變化時，如果它對應(yīng)的內(nèi)存地址發(fā)生了改變，那么這個數(shù)據(jù)類型就是 不可變數(shù)據(jù)類型。

總結(jié)：可變數(shù)據(jù)類型更改值后，內(nèi)存地址不發(fā)生改變。不可變數(shù)據(jù)類型更改值后，內(nèi)存地址發(fā)生改變。

裝飾器用過嗎,寫一個簡單的裝飾器

用自己的話總結(jié)一下
裝飾器可完成對原函數(shù)的擴(kuò)展,可傳遞函數(shù)做為參數(shù)

# 一個簡單的裝飾器
def wsm(f):
    def wzj(*args,**kwargs):
        s = time.time()
        res = f(*args,**kwargs)
        e = time.time()
        h = (e -s)
        print(f'當(dāng)前耗時{h}秒')
        return res
    return wzj

@wsm
def func():
    time.sleep(2)
    list1 = [1,2,2,3]
    list2 =  list(set(list1))

    print(list2)
func()

Docker

Dockerfile中ENTRYPOINT和CMD的區(qū)別:

• CMD命令設(shè)置容器啟動后默認(rèn)執(zhí)行的命令及其參數(shù)，但CMD設(shè)置的命令能夠被docker run命令后面的命令行參數(shù)替換
• ENTRYPOINT配置容器啟動時的執(zhí)行命令（不會被忽略，一定會被執(zhí)行，即使運(yùn)行 docker run時指定了其他命令）

總結(jié):CMD和ENTRYPOINT可指定容器啟動運(yùn)行的參數(shù),但是真實啟動時如果RUN后面修改了啟動參數(shù),那以RUN修改的參數(shù)優(yōu)先,而ENTRYPOINT比較倔,就不改

ADD和COPY的區(qū)別:

• ADD支持從遠(yuǎn)程URL獲取資源
• COPY只能從本地獲取

docker的幾種網(wǎng)絡(luò)模型

• host模式:net=host 容器和宿主機(jī)共享network namespace
• container模式:net=container:NAME_or_ID 容器之間共享Network namespace,k8s中的pod就是多個容器共享一個Network namespace
• none模式:net=none 容器有獨立的Network namespace,但并沒有對其進(jìn)行熱河網(wǎng)絡(luò)設(shè)置,如分配veth pair和網(wǎng)橋連接配置ip等
• bridge模式:net=bridge 默認(rèn)為該模式

K8S

k8s的工作原理

用戶創(chuàng)建pod請求信息>>存到etcd中>>scheduler查詢分配未使用的node創(chuàng)建pod>>kubelet接收創(chuàng)建指令,實時匯報pod信息>>contrller-manager通過apiserver監(jiān)控集群狀態(tài),確保集群處于預(yù)期工作中
用戶通過kubectl或者APIserver的rest api接口提交需要運(yùn)行的docker容器(創(chuàng)建pod請求)
api server將創(chuàng)建pod相關(guān)請求數(shù)據(jù)存儲至etcd中
scheduler監(jiān)聽API server,查詢還未分配的Node的pod,然后根據(jù)調(diào)度策略為這些pod分配節(jié)點
kubelet負(fù)責(zé)在所在的node節(jié)點上接收主節(jié)點發(fā)來的指令,管理pod及pod中的容器,并定時向master主節(jié)點匯報節(jié)點資源的使用情況及容器的情況
controller-manager則通過api-server監(jiān)控整個集群的狀態(tài),并確保集群處于預(yù)期的工作

k8s中的常用組件

• etcd：提供數(shù)據(jù)庫服務(wù)保存了整個集群的狀態(tài)
• kube-apiserver：提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機(jī)制
• kube-controller-manager：負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測、自動擴(kuò)展、滾動更新等
• cloud-controller-manager：是與底層云計算服務(wù)商交互的控制器
• kub-scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上
• kubelet：負(fù)責(zé)維護(hù)容器的生命周期，同時也負(fù)責(zé)Volume和網(wǎng)絡(luò)的管理
• kube-proxy：負(fù)責(zé)為Service提供內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡，并維護(hù)網(wǎng)絡(luò)規(guī)則
• container-runtime：是負(fù)責(zé)管理運(yùn)行容器的軟件，比如docker

k8s的網(wǎng)絡(luò)模式

k8s 網(wǎng)絡(luò)模型要符合四個基礎(chǔ)原則、三個網(wǎng)絡(luò)要求原則、一個架構(gòu)原則、一個 IP 原則。
每個 Pod 都擁有一個獨立的 IP 地址，而且假定所有 Pod 都在一個可以直接連通的、扁平的網(wǎng)絡(luò)空間中，不管是否運(yùn)行在同一 Node 上都可以通過 Pod 的 IP 來訪問。
k8s 中的 Pod 的 IP 是最小粒度 IP。同一個 Pod 內(nèi)所有的容器共享一個網(wǎng)絡(luò)堆棧，該模型稱為 IP-per-Pod 模型。

• Pod 由 docker0 實際分配的 IP。
• Pod 內(nèi)部看到的 IP 地址和端口與外部保持一致。
• 同一個 Pod 內(nèi)的不同容器共享網(wǎng)絡(luò)，可以通過localhost來訪問對方的端口，類似同一個虛擬機(jī)內(nèi)不同的進(jìn)程。
  IP-per-Pod 模型從端口分配、域名解析、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、應(yīng)用配置等角度看，Pod 可以看做是一臺獨立的虛擬機(jī)或物理機(jī)。
• 所有容器都可以不用 NAT 的方式同別的容器通信。
• 所有節(jié)點都可以在不同 NAT 方式下同所有容器通信，反之亦然。
• 容器的地址和別人看到的地址是同一個地址。

pod有幾種狀態(tài)

• Pending：Pod創(chuàng)建已經(jīng)提交給k8s，但是因為某種原因不能順利創(chuàng)建，例如下載鏡像慢，調(diào)度不成功等
• Running：Pod已經(jīng)綁定到一個節(jié)點上了，并且已經(jīng)創(chuàng)建了所有容器。只是有一個容器正在運(yùn)行，或者在啟動中。
• Secceeded：Pod中的所有容器都已經(jīng)成功終止，不能重新啟動。
• Failed： Pod中所有的容器均已經(jīng)終止，且至少有一個容器已經(jīng)在故障中終止。
• Unkown：由于某中原因apiserver無法獲取到Pod的狀態(tài)。通常是由于Master與pod所在的主機(jī)失去連接了

pod服務(wù)啟動失敗有哪些原因及排查:

# 獲取信息
kubectl describe pod 資源id
# 查看日志
kubectl logs 資源id
# 進(jìn)入資源中
kubectl exec -it 資源id bash

常見故障

• Pod狀態(tài) 一直處于Pending

  Pending狀態(tài)意味著Pod的YAML文件已經(jīng)提交給Kubernetes，API對象已經(jīng)被創(chuàng)建并保存在Etcd當(dāng)中。但是，這個Pod里有些容器因為某種原因而不能被順利創(chuàng)建。比如，調(diào)度不成功（可以通過kubectl describe pod 命令查看到當(dāng)前Pod的事件，進(jìn)而判斷為什么沒有調(diào)度）。可能原因：資源不足（集群內(nèi)所有的Node都不滿足該P(yáng)od請求的CPU、內(nèi)存、GPU等資源）；HostPort已被占用（通常推薦使用Service對外開放服務(wù)端口

• Pod狀態(tài) 一直處于Waiting

  首先還是通過kubectl describe pod 命令查看當(dāng)前Pod的事件?？赡艿脑蛴校?/p>

  1、鏡像拉取失敗，比如鏡像地址配置錯誤、拉取不了國外鏡像源（gcr.io）、私有鏡像密鑰配置錯誤、鏡像太大導(dǎo)致拉取超時（可以適當(dāng)調(diào)整kubelet的-image-pull-progress-deadline和-runtime-request-timeout選項）等。

  2、CNI網(wǎng)絡(luò)錯誤，一般需要檢查CNI網(wǎng)絡(luò)插件的配置，比如：無法配置Pod網(wǎng)絡(luò)、無法分配IP地址。

  3、容器無法啟動，需要檢查是否打包了正確的鏡像或者是否配置了正確的容器參數(shù)

  4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盤壞道（input/output error）

• Pod狀態(tài) 一直處于ContainerCreating

  處理方法同Waiting

• Pod狀態(tài) 處于ImagePullBackOff

  通常是鏡像名稱配置錯誤或者私有鏡像的密鑰配置錯誤導(dǎo)致。這種情況可以使用docker pull來驗證鏡像是否可以正常拉取

• Pod狀態(tài) 處于CrashLoopBackOff

  此狀態(tài)說明容器曾經(jīng)啟動了，但又異常退出。這時可以先查看一下容器的日志

• Pod狀態(tài) 處于Error

  通常處于Error狀態(tài)說明Pod啟動過程中發(fā)生了錯誤。常見的原因：依賴的ConfigMap、Secret或PV等不存在；請求的資源超過了管理員設(shè)置的限制，比如超過了LimitRange等；違反集群的安全策略，比如違反了PodSecurityPolicy等；容器無法操作集群內(nèi)的資源，比如開啟RDAC后，需要為ServiceAccount配置角色綁定

• Pod狀態(tài) 一直處于Terminating

  從v1.5開始，Kubernetes不會因為Node失聯(lián)而刪除其上正在運(yùn)行的Pod，而是將其標(biāo)記為Terminating 或 Unknown 狀態(tài)。想要刪除這些狀態(tài)的Pod有三種方法：

  1、從集群中刪除Node。使用公有云時，kube-controller-manager會在VM刪除后自動刪除對應(yīng)的Node。而在物理機(jī)部署的集群中，需要管理員手動刪除Node（kubectl delete node）。

  2、Node恢復(fù)正常。kubelet會重新跟kube-apiserver通信確認(rèn)這些Pod的期待狀態(tài)，進(jìn)而再決定刪除或者繼續(xù)運(yùn)行這些Pod。用戶強(qiáng)制刪除，用戶可以執(zhí)行（kubectl delete pods pod-name --grace-period=0 --force）強(qiáng)制刪除Pod。除非明確知道Pod的確處于停止?fàn)顟B(tài)（比如Node所在VM或物理機(jī)已經(jīng)關(guān)機(jī)），否則不建議使用該方法。特別是StatefulSet 管理的Pod，強(qiáng)制刪除容易導(dǎo)致腦裂或數(shù)據(jù)丟失等問題。

  3、Pod行為異常，這里所說的行為異常是指Pod沒有按預(yù)期的行為執(zhí)行，比如沒有運(yùn)行podSpec 里面設(shè)置的命令行參數(shù)。這一般是podSpec yaml文件內(nèi)容有誤，可以嘗試使用 --validate 參數(shù)重建容器，比如（kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml）；也可以查看創(chuàng)建后的podSpec是否是對的，比如（kubectl get pod mypod -o yaml）；修改靜態(tài)Pod的Manifest后未自動重建，kubelet 使用inotify 機(jī)制檢測 /etc/kubernetes/manifests 目錄（可通過 kubelet 的 -pod-manifest-path 選項指定）中靜態(tài)Pod的變化，并在文件發(fā)生變化后重新創(chuàng)建相應(yīng)的 Pod。但有時也會發(fā)現(xiàn)修改靜態(tài)Pod的 Manifest后未自動創(chuàng)建新 Pod的情景，此時已過簡單的修復(fù)方法是重啟 Kubelet

• Pod狀態(tài) 處于Unknown

  這個異常狀態(tài)意味著Pod的狀態(tài)不能持續(xù)地被 kubelet匯報給 kube-apiserver，這很有可能是主從節(jié)點（Master 和 Kubelet）間的通信出現(xiàn)了問題

VUE

vue中組件間怎么傳遞數(shù)據(jù):

• 父組件向子組件傳遞數(shù)據(jù)，使用props屬性；子組件向父組件中傳遞數(shù)據(jù)，在子組件中使用$emit派發(fā)事件，父組件中使用v-on
  監(jiān)聽事件；缺點：組件嵌套層次多的話，傳遞數(shù)據(jù)比較麻煩。

• 祖先組件通過依賴注入(inject / provide)的方式，向其所有子孫后代傳遞數(shù)據(jù)；缺點：無法監(jiān)聽數(shù)據(jù)修改的來源，不支持響應(yīng)式。

• 通過屬性parent / $children /
  ref，訪問根組件、父級組件、子組件中的數(shù)據(jù)；缺點：要求組件之間要有傳遞性。

• 通過事件總線(event
  bus)的方式，可以實現(xiàn)任意兩個組件間進(jìn)行數(shù)據(jù)傳遞；缺點：不支持響應(yīng)式，這個概念是vue1.0版本中的，現(xiàn)在已經(jīng)廢棄。

• 通過 VueJs 的狀態(tài)管理模式 Vuex，實現(xiàn)多個組件進(jìn)行數(shù)據(jù)共享，推薦使用這種方式進(jìn)行項目中各組件間的數(shù)據(jù)傳遞。
  下面詳細(xì)介紹數(shù)據(jù)傳遞的幾種方式

vue中data內(nèi)要return為什么:

• 組件是一個可復(fù)用的實例，當(dāng)你引用一個組件的時候，組件里的data是一個對象，所有用到這個組件的都引用的同一個對象，就會造成數(shù)據(jù)污染
• 將data封裝成函數(shù)后，在引用組件的時候，我們只是調(diào)用了data函數(shù)生成的數(shù)據(jù)副本，是一個新對象，避免了數(shù)據(jù)污染

vue組件的生命周期:

組件的生命周期就是一個組件創(chuàng)建、數(shù)據(jù)初始化、掛載、更新、銷毀的整個過程,其中具體方法:

beforeCreate
// 在實例初始化之后，數(shù)據(jù)觀測和event/watcher時間配置之前被調(diào)用
created
// 實例已經(jīng)創(chuàng)建完成之后被調(diào)用。在這一步，實例已經(jīng)完成以下的配置：數(shù)據(jù)觀測，屬性和方法的運(yùn)算，watch/event事件回調(diào)。然而，掛載階段還沒開始，$el屬性目前不可見
beforeMount
// 在掛載開始之前被調(diào)用：相關(guān)的render函數(shù)首次被調(diào)用。
// 該鉤子在服務(wù)器端渲染期間不被調(diào)用
mounted (
// el被新創(chuàng)建的vm.$el替換，并掛在到實例上去之后調(diào)用該鉤子函數(shù)。如果root實例掛載了一個文檔內(nèi)元素，當(dāng)mounted被調(diào)用時vm.$el也在文檔內(nèi)。
// 該鉤子在服務(wù)端渲染期間不被調(diào)用。
    beforeUpdate
   // 數(shù)據(jù)更新時調(diào)用，發(fā)生在虛擬DOM重新渲染和打補(bǔ)丁之前。
　　// 你可以在這個鉤子中進(jìn)一步第更改狀態(tài)，這不會觸發(fā)附加的重渲染過程。
　　// 該鉤子在服務(wù)端渲染期間不被調(diào)用。
    updated
    // 由于數(shù)據(jù)更改導(dǎo)致的虛擬DOM重新渲染和打補(bǔ)丁，在這之后會調(diào)用該鉤子。
　　 // 當(dāng)這個鉤子被調(diào)用時，組件DOM已經(jīng)更新，所以你現(xiàn)在可以執(zhí)行依賴于DOM的操作。然而在大多數(shù)情況下，你應(yīng)該避免在此期間更改狀態(tài)，因為這可能會導(dǎo)致更新無限循環(huán)。
　　 //該鉤子在服務(wù)端渲染期間不被調(diào)用
)

beforeDestroy
// 實例銷毀之間調(diào)用。在這一步，實例仍然完全可用。
// 該鉤子在服務(wù)端渲染期間不被調(diào)用。
destroyed
// Vue實例銷毀后調(diào)用。調(diào)用后，Vue實例指示的所有東西都會解綁定，所有的事件監(jiān)聽器會被移除，所有的子實例也會被銷毀。
// 該鉤子在服務(wù)端渲染不會被調(diào)用

DevOps

jenkins的流程,怎么構(gòu)建的

1. 開發(fā)者開發(fā)代碼
2. 提交至git倉庫
3. jenkins從倉庫拉取代碼
4. jenkins通過maven（ant，gradle等）構(gòu)建項目推到docker倉庫
5. 生成一個在tomcat運(yùn)行的項目的docker容器
6. 測試人員測試

jenkins的webhook怎么配置

shell

使用腳本取公網(wǎng)ip和內(nèi)網(wǎng)ip

• 使用curl 獲取本機(jī)公網(wǎng)ip

  curl cip.cc
  curl v4.ident.me
  curl myip.ipip.net
  

• 使用正則匹配

  ip a|grep 'inet'|grep -v 'inet6'|awk '{print $2}'|cut -d '/' -f 1
  

• 使用路由獲取

  ip route show
  

• 使用hostname獲取

  題目有限制要求取所有內(nèi)網(wǎng)ip,可以在取出所有ip后,使用grep過濾出內(nèi)網(wǎng)IP

  hostname -I
  

還有很多其他方法....

strace命令可以獲取一個程序調(diào)用哪些函數(shù)的整個過程,貌似是這個命令

使用腳本寫出多塊4T盤,格式化后分區(qū)掛載并添加自啟動

for V in $(ls /dev/sd[b-z])
do
  echo -e "n\np\n\n\n\nw\n" |parted $V
  mkfs.xfs -i size=512 ${V}1 &>/dev/null
  sleep 1
  M=$(echo "$V" |awk -F "/" '{print $3}')
  mkdir -p /data/${M}1 &>/dev/null
  echo -e "${V}1 /data/${M}1 xfs defaults 0 0\n" >>/etc/fstab
  mount -a &>/dev/null
done

使用腳本監(jiān)測一個程序每15秒的狀態(tài),如果15秒中未監(jiān)測到進(jìn)程,則視為程序退出了(還有其他需求,大致記得這么多)

一個簡單思路,未做驗證,還有語法可能不通

c = 1
while true
do
# 獲取此程序pid
A = ps -ef|grep '程序'
    if '$A' == '';then
        sleep 3
        c += 1
        if [ $c -eq 5 ];then
            break
        fi
    else
        continue
    fi
done

其他

Linux開機(jī)啟動順序

我覺得不準(zhǔn)確,再查一查

1、加載BIOS（包含了CPU的相關(guān)信息、設(shè)備啟動順序信息、硬盤信息、內(nèi)存信息、時鐘信息、PnP特性等）
2、讀取MBR（硬盤上第0磁道第一個扇區(qū)）
3、Boot Loader（初始化硬件設(shè)備、建立內(nèi)存空間的映射圖）
4、加載內(nèi)核
5、設(shè)定運(yùn)行等級（init0-init6）
6、執(zhí)行rc.sysinit
7、啟動內(nèi)核模塊
8、執(zhí)行不同運(yùn)行級別的腳本
9、執(zhí)行rc.local
10、執(zhí)行/bin/login 進(jìn)入登陸狀態(tài)

Redis持久化

• 默認(rèn)為RDB(redis database),定時快照至硬盤,對應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb
• AOF 持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫命令記錄到單獨的日志文件中，當(dāng)重啟Redis會重新將持久化的日志中文件恢復(fù)數(shù)據(jù)

Zabbix自動發(fā)現(xiàn)及分布式

• 自動發(fā)現(xiàn)（server端輪詢網(wǎng)段掃描發(fā)現(xiàn)agent）

• 自動發(fā)現(xiàn)：server-->輪詢掃描-->ip地址段

• 自動發(fā)現(xiàn)：ip、ftp、ssh、web、pop3、imap、tcp

  • ip范文自動發(fā)現(xiàn)（兩個階段：發(fā)現(xiàn)-->動作）
    • zabbix-web自動發(fā)現(xiàn)定義自動監(jiān)控的網(wǎng)段中的zabixx-agent（配置文件中server已經(jīng)定義zabbix-server地址）

• 自動發(fā)現(xiàn)所執(zhí)行的動作

  • 發(fā)送消息
  • 添加/刪除主機(jī)
  • 啟用/禁用主機(jī)
  • 添加主機(jī)到組
  • 從組中刪除主機(jī)
  • 將主機(jī)鏈接到模板/從模板中取消鏈接
  • 執(zhí)行遠(yuǎn)程腳本命令

• 主動注冊（agent端主動告訴server端請求加入）

• zabbix-server必須開啟自動注冊-->操作-->（通知|加入監(jiān)控|套用模板）

軟連接與硬鏈接的區(qū)別:

• 軟連接原文件與連接文件擁有不同的inode號,是倆個不同的文件,而硬鏈接是和鏈接文件共一個inode,是同一個文件
• 軟鏈接支持跨文件系統(tǒng)建立,硬鏈接不支持
• 軟鏈接的鏈接數(shù)目不會增加,文件大小是不一樣的,硬鏈接顯示的大小是和源文件一樣的

僵尸進(jìn)程和孤兒進(jìn)程的區(qū)別:

• 孤兒進(jìn)程：一個父進(jìn)程退出，而它的一個或多個子進(jìn)程還在運(yùn)行，那么那些子進(jìn)程將成為孤兒進(jìn)程。孤兒進(jìn)程將被init進(jìn)程(進(jìn)程號為1)所收養(yǎng)，并由init進(jìn)程對它們完成狀態(tài)收集工作。
• 僵尸進(jìn)程：一個進(jìn)程使用fork創(chuàng)建子進(jìn)程，如果子進(jìn)程退出，而父進(jìn)程并沒有調(diào)用wait或waitpid獲取子進(jìn)程的狀態(tài)信息，那么子進(jìn)程的進(jìn)程描述符仍然保存在系統(tǒng)中。這種進(jìn)程稱之為僵死進(jìn)程。
• 僵尸進(jìn)程危害場景：
  例如有個進(jìn)程，它定期的產(chǎn) 生一個子進(jìn)程，這個子進(jìn)程需要做的事情很少，做完它該做的事情之后就退出了，因此這個子進(jìn)程的生命周期很短，但是，父進(jìn)程只管生成新的子進(jìn)程，至于子進(jìn)程 退出之后的事情，則一概不聞不問，這樣，系統(tǒng)運(yùn)行上一段時間之后，系統(tǒng)中就會存在很多的僵死進(jìn)程，倘若用ps命令查看的話，就會看到很多狀態(tài)為Z的進(jìn)程。 嚴(yán)格地來說，僵死進(jìn)程并不是問題的根源，罪魁禍?zhǔn)资钱a(chǎn)生出大量僵死進(jìn)程的那個父進(jìn)程。因此，當(dāng)我們尋求如何消滅系統(tǒng)中大量的僵死進(jìn)程時，答案就是把產(chǎn)生大 量僵死進(jìn)程的那個元兇槍斃掉（也就是通過kill發(fā)送SIGTERM或者SIGKILL信號啦）。槍斃了元兇進(jìn)程之后，它產(chǎn)生的僵死進(jìn)程就變成了孤兒進(jìn) 程，這些孤兒進(jìn)程會被init進(jìn)程接管，init進(jìn)程會wait()這些孤兒進(jìn)程，釋放它們占用的系統(tǒng)進(jìn)程表中的資源，這樣，這些已經(jīng)僵死的孤兒進(jìn)程 就能瞑目而去了

怎么查看僵尸進(jìn)程:

• 使用Top命令查找，當(dāng)zombie前的數(shù)量不為0時，即系統(tǒng)內(nèi)存在相應(yīng)數(shù)量的僵尸進(jìn)程
• 使用命令ps -A -ostat,ppid,pid,cmd |grep -e '^[Zz]'定位僵尸進(jìn)程以及該僵尸進(jìn)程的父進(jìn)程
• 使用Kill -HUP僵尸進(jìn)程ID來殺死僵尸進(jìn)程，往往此種情況無法殺死僵尸進(jìn)程，此時就需要殺死僵尸進(jìn)程的父進(jìn)程
  kill -HUP 僵尸進(jìn)程父ID

Nginx中l(wèi)ocation的匹配規(guī)則:

「=」 修飾符：要求路徑完全匹配
「~」修飾符：區(qū)分大小寫的正則匹配
「~*」不區(qū)分大小寫的正則匹配
「^~」修飾符：前綴匹配 如果該 location 是最佳的匹配，那么對于匹配這個 location 的字符串， 該修飾符不再進(jìn)行正則表達(dá)式檢測。注意，這不是一個正則表達(dá)式匹配，它的目的是優(yōu)先于正則表達(dá)式的匹配

• 精確匹配 =
• 前綴匹配 ^~（立刻停止后續(xù)的正則搜索）
• 按文件中順序的正則匹配 ~或~*
• 匹配不帶任何修飾的前綴匹配。

Nginx日志中出現(xiàn)499報錯是怎么回事

后端處理請求時間過長,客戶端等的不耐煩了,提前關(guān)閉了http連接.常見于后臺接口處理時間比較長，而前端請求又自帶有超時時間
排查方法:

• 1、cpu（top）與內(nèi)存（free -h）的使用
• 2、后臺程序
• 3、 MySQL慢查詢

Apche與Nginx的區(qū)別

簡單來說apache是同步多進(jìn)程處理業(yè)務(wù),更穩(wěn)定,nginx異步處理業(yè)務(wù),面對高并發(fā)更快性能更好.
nginx適合靜態(tài)服務(wù)

• apache 的 rewrite 比 nginx 強(qiáng)大，在 rewrite 頻繁的情況下，用 apache
• apache 發(fā)展到現(xiàn)在，模塊超多，基本想到的都可以找到
• apache 更為成熟，少 bug ，nginx 的 bug 相對較多
• apache 超穩(wěn)定
• apache 對 PHP 支持比較簡單，nginx 需要配合其他后端用
• apache 在處理動態(tài)請求有優(yōu)勢，nginx 在這方面是雞肋，一般動態(tài)請求要 apache 去做，nginx 適合靜態(tài)和反向。
• apache 仍然是目前的主流，擁有豐富的特性，成熟的技術(shù)和開發(fā)社區(qū)

TCP連接的幾種狀態(tài):

LISTEN：偵聽來自遠(yuǎn)方的TCP端口的連接請求
SYN-SENT：再發(fā)送連接請求后等待匹配的連接請求（客戶端）
SYN-RECEIVED：再收到和發(fā)送一個連接請求后等待對方對連接請求的確認(rèn)（服務(wù)器）
ESTABLISHED：代表一個打開的連接
FIN-WAIT-1：等待遠(yuǎn)程TCP連接中斷請求，或先前的連接中斷請求的確認(rèn)
FIN-WAIT-2：從遠(yuǎn)程TCP等待連接中斷請求
CLOSE-WAIT：等待從本地用戶發(fā)來的連接中斷請求
CLOSING：等待遠(yuǎn)程TCP對連接中斷的確認(rèn)
LAST-ACK：等待原來的發(fā)向遠(yuǎn)程TCP的連接中斷請求的確認(rèn)
TIME-WAIT：等待足夠的時間以確保遠(yuǎn)程TCP接收到連接中斷請求的確認(rèn)
CLOSED：沒有任何連接狀態(tài)

常見狀態(tài)碼:

• 400 客戶端請求的語法錯誤，服務(wù)器無法理解
• 401 請求要求用戶的身份認(rèn)證
• 403 服務(wù)器理解請求客戶端的請求，但是拒絕執(zhí)行此請求
• 404 服務(wù)器無法根據(jù)客戶端的請求找到資源（網(wǎng)頁）。通過此代碼，網(wǎng)站設(shè)計人員可設(shè)置"您所請求的資源無法找到"的個性頁面
• 405 客戶端請求中的方法被禁止
• 500 服務(wù)器內(nèi)部錯誤，無法完成請求
• 501 服務(wù)器不支持請求的功能，無法完成請求
• 502是報錯類型代碼 bad gate way 錯誤的網(wǎng)關(guān)。產(chǎn)生錯誤的原因是連接超時，我們向服務(wù)器發(fā)送請求，由于服務(wù)器當(dāng)前 鏈接 太多，導(dǎo)致服務(wù)器方面無法給于正常的響應(yīng)，產(chǎn)生此類報錯
• 504錯誤代表網(wǎng)關(guān)超時 （Gateway timeout），是指 服務(wù)器 作為網(wǎng)關(guān)或代理，但是沒有及時從上游服務(wù)器收到請求。. 服務(wù)器（不一定是 Web 服務(wù)器）正在作為一個網(wǎng)關(guān)或代理來完成客戶（如您的 瀏覽器 或我們的 CheckUpDown 機(jī)器人）訪問所需網(wǎng)址的請求。. 為了完成您的 HTTP 請求， 該服務(wù)器訪問一個上游服務(wù)器， 但沒得到及時的響應(yīng)。. 這通常意味著上游服務(wù)器已關(guān)閉（不響應(yīng) 網(wǎng)關(guān) / 代理），而不是上游服務(wù)器和網(wǎng)關(guān)/代理在交換數(shù)據(jù)的協(xié)議上不一致。. 正常情況下，是由于被請求服務(wù)器發(fā)送超時引起。

Ansible的使用:

ansible testservers -m copy -a 'src=/root/install.log dest=/tmp/install.log owner=testuser group=testgroup'
# 先進(jìn)入somedir/ ，再在somedir/目錄下讓所有節(jié)點運(yùn)行somescript.sh并把log輸出到somelog.txt

ansible -i hosts all -m shell -a "somescript.sh >> somelog.txt" chdir=somedir/

LVS模式的幾種及使用場景:

LVS工作模式分為NAT模式、TUN模式、以及DR模式

• 常用DR模式:
  直接路由模式,數(shù)據(jù)環(huán)形傳輸,用戶請求>>LVS>>分配請求給節(jié)點>>節(jié)點返回報文給用戶
  DR模式修改目標(biāo)MAC地址來完成負(fù)載分發(fā)實現(xiàn)
  場景:支持大并發(fā),但不能修改端口,要求調(diào)度器與后端服務(wù)器必須在同一個局域網(wǎng)內(nèi),節(jié)點要綁定VIP,抑制ARP
• TUN模式:
  與DR相似,也是環(huán)形傳輸數(shù)據(jù),但是是以添加數(shù)據(jù)包頭的實現(xiàn)完成數(shù)據(jù)傳輸分發(fā)到節(jié)點,對請求報文重新封裝
  場景:請求報文不能太大
• NAT模式:
  數(shù)據(jù)為往返式傳輸,LVS在中間完成網(wǎng)絡(luò)地址轉(zhuǎn)換的工作
  用戶請求>>LVS>>節(jié)點>>LVS>>用戶

災(zāi)備是如何做的(其實就是數(shù)據(jù)庫備份)

列出服務(wù)器備份恢復(fù)策略

• 全網(wǎng)備份服務(wù)器
• 數(shù)據(jù)庫完全備份
• 數(shù)據(jù)庫增量備份
• 差異備份
• 冷數(shù)據(jù)歸檔
• 定時任務(wù)備份站點目錄，配置文件等。 恢復(fù)策略
• 數(shù)據(jù)庫增量恢復(fù)，全量恢復(fù)
• 站點目錄，配置文件等故障后隨時調(diào)取備份來備份
  mysql 主從備份,每日做一次增量備份
  每周一次完整備份異地備份
• 增量備份
  rsync是Linux系統(tǒng)下的數(shù)據(jù)鏡像備份工具，使用快速增量備份工具Remote Sync可以遠(yuǎn)程同步，支持本地復(fù)制，或者與其他SSH、rsync主機(jī)同步

Rsync 三種模式

• 本地模式,類似于cp
• 隧道模式:類似scp
• 守護(hù)進(jìn)程模式:以守護(hù)進(jìn)程socket 的方式傳輸數(shù)據(jù)
  在使用 rsync首次全量同步后，結(jié)合 inotify對源目錄進(jìn)行實時監(jiān)控，只要有文件變動或新文件產(chǎn)生，就會立刻同步到目標(biāo)目錄下，非常高效實用。

linux系統(tǒng)做過內(nèi)核優(yōu)化嗎?

沒有,但是知道是修改sysctl.conf文件其中存在比較多的參數(shù)可供優(yōu)化,但是做過nginx等中間件的優(yōu)化....

最大并發(fā)連接數(shù)
允許系統(tǒng)打開的端口范圍
發(fā)送緩存區(qū)的最大值
發(fā)送緩存區(qū)的默認(rèn)值
socket保持FN-WAIT-2狀態(tài)的最大時間 
.......

并發(fā)翻倍,系統(tǒng)正在擴(kuò)容中,但是擴(kuò)容需要7分鐘才可以完成,怎么用現(xiàn)有服務(wù)器抗住7分鐘內(nèi)的翻倍并發(fā)

我不知道
面試官答:是在代碼中做了埋點,當(dāng)并發(fā)大于某一閾值,會觸發(fā)開關(guān),此時業(yè)務(wù)上存在的部分功能不可用,比如微博上傳視頻此時不做轉(zhuǎn)碼等等,以犧牲部分功能延緩到擴(kuò)容完成后(簡單的講就是業(yè)務(wù)降級)

系統(tǒng)出現(xiàn)504需要怎么排查

客戶訪問時,代理不能及時地從遠(yuǎn)程服務(wù)器獲得應(yīng)答給客戶,此時要檢查后端數(shù)據(jù)服務(wù)是否出現(xiàn)問題,為什么未及時返還數(shù)據(jù)

寫一下你們現(xiàn)有的架構(gòu)

自己寫