前言:

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

Django

講一下Django的生命周期

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

說一下用過哪些中間件

• 緩存中間件： django.middleware.cache.UpdateCacheMiddleware django.middleware.cache.FetchFromCacheMiddleware 開啟全站范圍的緩存哼凯。 如果開啟了這些緩存拭抬，任何一個(gè)由Django提供的頁面將會(huì)被緩存遇八，緩存時(shí)長(zhǎng)在CACHE_MIDDLEWARE_SECONDS中配置定義。

• 會(huì)話中間件 django.contrib.sessions.middleware.SessionMiddleware 開啟會(huì)話支持辰晕，session支持中間件梁肿，加入這個(gè)中間件飘千，會(huì)在數(shù)據(jù)庫中生成一個(gè)django_session的表。

• 通用中間件： django.middleware.common.CommonMiddleware 通用中間件栈雳，會(huì)處理一些URL，比如baidu.com會(huì)自動(dòng)的處理成www.baidu.com缔莲。比如/blog/111會(huì)處理成/blog/111/自動(dòng)加上反斜杠哥纫。

• CSRF保護(hù)中間件 django.middleware.csrf.CsrfViewMiddleware 跨域請(qǐng)求偽造中間件。加入這個(gè)中間件痴奏，在提交表單的時(shí)候會(huì)必須加入csrf_token蛀骇，cookie中也會(huì)生成一個(gè)名叫csrftoken的值，也會(huì)在header中加入一個(gè)HTTP_X_CSRFTOKEN的值來放置CSRF攻擊读拆。

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

• 消息中間件 django.contrib.messages.middleware.MessageMiddleware 展示一些后臺(tái)信息給前端頁面檐晕。如果需要用到消息暑诸，還需要在INSTALLED_APPS中添加django.contrib.message才能有效蚌讼。如果不需要，可以把這兩個(gè)都刪除个榕。

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

Python

python中倆個(gè)列表如何取交集

獲取兩個(gè)list 的交集

• 方法一:

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

• 方法二:

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

• 方法三:

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

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

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

Python 允許在所有函數(shù)的外部定義變量，這樣的變量稱為全局變量（Global Variable）
全局變量的默認(rèn)作用域是整個(gè)程序西采，即全局變量既可以在各個(gè)函數(shù)的外部使用凰萨，也可以在各函數(shù)內(nèi)部使用
globals() 函數(shù)為 Python 的內(nèi)置函數(shù)，它可以返回一個(gè)包含全局范圍內(nèi)所有變量的字典械馆，該字典中的每個(gè)鍵值對(duì)胖眷，鍵為變量名，值為該變量的值
locals() 函數(shù)也是 Python 內(nèi)置函數(shù)之一霹崎，通過調(diào)用該函數(shù)珊搀，我們可以得到一個(gè)包含當(dāng)前作用域內(nèi)所有變量的字典。這里所謂的“當(dāng)前作用域”指的是仿畸，在函數(shù)內(nèi)部調(diào)用 locals() 函數(shù)食棕，會(huì)獲得包含所有局部變量的字典；而在全局范文內(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ù)類型對(duì)應(yīng)的變量的值發(fā)生了變化時(shí)，如果它對(duì)應(yīng)的內(nèi)存地址不發(fā)生改變耀里，那么這個(gè)數(shù)據(jù)類型就是 可變數(shù)據(jù)類型蜈缤。

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

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

裝飾器用過嗎,寫一個(gè)簡(jiǎn)單的裝飾器

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

# 一個(gè)簡(jiǎn)單的裝飾器
def wsm(f):
    def wzj(*args,**kwargs):
        s = time.time()
        res = f(*args,**kwargs)
        e = time.time()
        h = (e -s)
        print(f'當(dāng)前耗時(shí){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è)置容器啟動(dòng)后默認(rèn)執(zhí)行的命令及其參數(shù)翰守，但CMD設(shè)置的命令能夠被docker run命令后面的命令行參數(shù)替換
• ENTRYPOINT配置容器啟動(dòng)時(shí)的執(zhí)行命令（不會(huì)被忽略孵奶，一定會(huì)被執(zhí)行，即使運(yùn)行 docker run時(shí)指定了其他命令）

總結(jié):CMD和ENTRYPOINT可指定容器啟動(dòng)運(yùn)行的參數(shù),但是真實(shí)啟動(dòng)時(shí)如果RUN后面修改了啟動(dòng)參數(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就是多個(gè)容器共享一個(gè)Network namespace
• none模式:net=none 容器有獨(dú)立的Network namespace,但并沒有對(duì)其進(jìn)行熱河網(wǎng)絡(luò)設(shè)置,如分配veth pair和網(wǎng)橋連接配置ip等
• bridge模式:net=bridge 默認(rèn)為該模式

K8S

k8s的工作原理

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

k8s中的常用組件

• etcd：提供數(shù)據(jù)庫服務(wù)保存了整個(gè)集群的狀態(tài)
• kube-apiserver：提供了資源操作的唯一入口蜡峰，并提供認(rèn)證了袁、授權(quán)朗恳、訪問控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制
• kube-controller-manager：負(fù)責(zé)維護(hù)集群的狀態(tài)早像，比如故障檢測(cè)僻肖、自動(dòng)擴(kuò)展、滾動(dòng)更新等
• cloud-controller-manager：是與底層云計(jì)算服務(wù)商交互的控制器
• kub-scheduler：負(fù)責(zé)資源的調(diào)度卢鹦，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上
• kubelet：負(fù)責(zé)維護(hù)容器的生命周期臀脏，同時(shí)也負(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ò)模型要符合四個(gè)基礎(chǔ)原則揉稚、三個(gè)網(wǎng)絡(luò)要求原則、一個(gè)架構(gòu)原則熬粗、一個(gè) IP 原則搀玖。
每個(gè) Pod 都擁有一個(gè)獨(dú)立的 IP 地址，而且假定所有 Pod 都在一個(gè)可以直接連通的驻呐、扁平的網(wǎng)絡(luò)空間中灌诅，不管是否運(yùn)行在同一 Node 上都可以通過 Pod 的 IP 來訪問。
k8s 中的 Pod 的 IP 是最小粒度 IP含末。同一個(gè) Pod 內(nèi)所有的容器共享一個(gè)網(wǎng)絡(luò)堆棧猜拾，該模型稱為 IP-per-Pod 模型。

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

pod有幾種狀態(tài)

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

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

# 獲取信息
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對(duì)象已經(jīng)被創(chuàng)建并保存在Etcd當(dāng)中忆肾。但是，這個(gè)Pod里有些容器因?yàn)槟撤N原因而不能被順利創(chuàng)建菱肖。比如客冈，調(diào)度不成功（可以通過kubectl describe pod 命令查看到當(dāng)前Pod的事件，進(jìn)而判斷為什么沒有調(diào)度）稳强〕≈伲可能原因：資源不足（集群內(nèi)所有的Node都不滿足該P(yáng)od請(qǐng)求的CPU、內(nèi)存退疫、GPU等資源）渠缕；HostPort已被占用（通常推薦使用Service對(duì)外開放服務(wù)端口

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

  首先還是通過kubectl describe pod 命令查看當(dāng)前Pod的事件√憧В可能的原因有：

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

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

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

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

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

  處理方法同Waiting

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

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

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

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

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

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

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

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

  1叹坦、從集群中刪除Node。使用公有云時(shí)卑雁，kube-controller-manager會(huì)在VM刪除后自動(dòng)刪除對(duì)應(yīng)的Node募书。而在物理機(jī)部署的集群中，需要管理員手動(dòng)刪除Node（kubectl delete node）测蹲。

  2莹捡、Node恢復(fù)正常。kubelet會(huì)重新跟kube-apiserver通信確認(rèn)這些Pod的期待狀態(tài)扣甲，進(jìn)而再?zèng)Q定刪除或者繼續(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是否是對(duì)的甩牺，比如（kubectl get pod mypod -o yaml）蘑志；修改靜態(tài)Pod的Manifest后未自動(dòng)重建匈棘，kubelet 使用inotify 機(jī)制檢測(cè) /etc/kubernetes/manifests 目錄（可通過 kubelet 的 -pod-manifest-path 選項(xiàng)指定）中靜態(tài)Pod的變化九秀，并在文件發(fā)生變化后重新創(chuàng)建相應(yīng)的 Pod绞呈。但有時(shí)也會(huì)發(fā)現(xiàn)修改靜態(tài)Pod的 Manifest后未自動(dòng)創(chuàng)建新 Pod的情景呀打，此時(shí)已過簡(jiǎn)單的修復(fù)方法是重啟 Kubelet

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

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

VUE

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

• 父組件向子組件傳遞數(shù)據(jù)泼各，使用props屬性谱俭；子組件向父組件中傳遞數(shù)據(jù)笙纤，在子組件中使用$emit派發(fā)事件查描，父組件中使用v-on
  監(jiān)聽事件突委；缺點(diǎn)：組件嵌套層次多的話，傳遞數(shù)據(jù)比較麻煩冬三。

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

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

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

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

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

• 組件是一個(gè)可復(fù)用的實(shí)例泣特，當(dāng)你引用一個(gè)組件的時(shí)候浩姥，組件里的data是一個(gè)對(duì)象，所有用到這個(gè)組件的都引用的同一個(gè)對(duì)象状您，就會(huì)造成數(shù)據(jù)污染
• 將data封裝成函數(shù)后勒叠，在引用組件的時(shí)候，我們只是調(diào)用了data函數(shù)生成的數(shù)據(jù)副本膏孟，是一個(gè)新對(duì)象眯分，避免了數(shù)據(jù)污染

vue組件的生命周期:

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

beforeCreate
// 在實(shí)例初始化之后，數(shù)據(jù)觀測(cè)和event/watcher時(shí)間配置之前被調(diào)用
created
// 實(shí)例已經(jīng)創(chuàng)建完成之后被調(diào)用飘诗。在這一步与倡，實(shí)例已經(jīng)完成以下的配置：數(shù)據(jù)觀測(cè)，屬性和方法的運(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替換，并掛在到實(shí)例上去之后調(diào)用該鉤子函數(shù)喳瓣。如果root實(shí)例掛載了一個(gè)文檔內(nèi)元素馋贤，當(dāng)mounted被調(diào)用時(shí)vm.$el也在文檔內(nèi)。
// 該鉤子在服務(wù)端渲染期間不被調(diào)用畏陕。
    beforeUpdate
   // 數(shù)據(jù)更新時(shí)調(diào)用配乓，發(fā)生在虛擬DOM重新渲染和打補(bǔ)丁之前。
　　// 你可以在這個(gè)鉤子中進(jìn)一步第更改狀態(tài)惠毁，這不會(huì)觸發(fā)附加的重渲染過程扰付。
　　// 該鉤子在服務(wù)端渲染期間不被調(diào)用。
    updated
    // 由于數(shù)據(jù)更改導(dǎo)致的虛擬DOM重新渲染和打補(bǔ)丁仁讨，在這之后會(huì)調(diào)用該鉤子羽莺。
　　 // 當(dāng)這個(gè)鉤子被調(diào)用時(shí)，組件DOM已經(jīng)更新洞豁，所以你現(xiàn)在可以執(zhí)行依賴于DOM的操作盐固。然而在大多數(shù)情況下，你應(yīng)該避免在此期間更改狀態(tài)丈挟，因?yàn)檫@可能會(huì)導(dǎo)致更新無限循環(huán)刁卜。
　　 //該鉤子在服務(wù)端渲染期間不被調(diào)用
)

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

DevOps

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

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

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命令可以獲取一個(gè)程序調(diào)用哪些函數(shù)的整個(gè)過程,貌似是這個(gè)命令

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

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)測(cè)一個(gè)程序每15秒的狀態(tài),如果15秒中未監(jiān)測(cè)到進(jìn)程,則視為程序退出了(還有其他需求,大致記得這么多)

一個(gè)簡(jiǎn)單思路,未做驗(yà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ī)啟動(dòng)順序

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

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

Redis持久化

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

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

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

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

• 自動(dòng)發(fā)現(xiàn)：ip闲延、ftp痊剖、ssh、web垒玲、pop3陆馁、imap、tcp

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

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

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

• 主動(dòng)注冊(cè)（agent端主動(dòng)告訴server端請(qǐng)求加入）

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

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

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

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

• 孤兒進(jìn)程：一個(gè)父進(jìn)程退出合愈，而它的一個(gè)或多個(gè)子進(jìn)程還在運(yùn)行叮贩，那么那些子進(jìn)程將成為孤兒進(jìn)程。孤兒進(jìn)程將被init進(jìn)程(進(jìn)程號(hào)為1)所收養(yǎng)佛析，并由init進(jìn)程對(duì)它們完成狀態(tài)收集工作益老。
• 僵尸進(jìn)程：一個(gè)進(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)程危害場(chǎng)景：
  例如有個(gè)進(jìn)程桃纯，它定期的產(chǎn) 生一個(gè)子進(jìn)程，這個(gè)子進(jìn)程需要做的事情很少披坏，做完它該做的事情之后就退出了慈参，因此這個(gè)子進(jìn)程的生命周期很短，但是刮萌，父進(jìn)程只管生成新的子進(jìn)程驮配，至于子進(jìn)程 退出之后的事情，則一概不聞不問，這樣壮锻，系統(tǒng)運(yùn)行上一段時(shí)間之后琐旁，系統(tǒng)中就會(huì)存在很多的僵死進(jìn)程，倘若用ps命令查看的話猜绣，就會(huì)看到很多狀態(tài)為Z的進(jìn)程灰殴。 嚴(yán)格地來說，僵死進(jìn)程并不是問題的根源掰邢，罪魁禍?zhǔn)资钱a(chǎn)生出大量僵死進(jìn)程的那個(gè)父進(jìn)程牺陶。因此，當(dāng)我們尋求如何消滅系統(tǒng)中大量的僵死進(jìn)程時(shí)辣之，答案就是把產(chǎn)生大 量僵死進(jìn)程的那個(gè)元兇槍斃掉（也就是通過kill發(fā)送SIGTERM或者SIGKILL信號(hào)啦）掰伸。槍斃了元兇進(jìn)程之后，它產(chǎn)生的僵死進(jìn)程就變成了孤兒進(jìn) 程怀估，這些孤兒進(jìn)程會(huì)被init進(jìn)程接管狮鸭，init進(jìn)程會(huì)wait()這些孤兒進(jìn)程，釋放它們占用的系統(tǒng)進(jìn)程表中的資源多搀，這樣歧蕉，這些已經(jīng)僵死的孤兒進(jìn)程 就能瞑目而去了

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

• 使用Top命令查找，當(dāng)zombie前的數(shù)量不為0時(shí)康铭，即系統(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)程，此時(shí)就需要?dú)⑺澜┦M(jìn)程的父進(jìn)程
  kill -HUP 僵尸進(jìn)程父ID

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

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

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

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

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

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

Apche與Nginx的區(qū)別

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

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

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

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

常見狀態(tài)碼:

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

Ansible的使用:

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

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

LVS模式的幾種及使用場(chǎng)景:

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

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

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

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

• 全網(wǎng)備份服務(wù)器
• 數(shù)據(jù)庫完全備份
• 數(shù)據(jù)庫增量備份
• 差異備份
• 冷數(shù)據(jù)歸檔
• 定時(shí)任務(wù)備份站點(diǎn)目錄箕慧，配置文件等。 恢復(fù)策略
• 數(shù)據(jù)庫增量恢復(fù)茴恰，全量恢復(fù)
• 站點(diǎn)目錄颠焦，配置文件等故障后隨時(shí)調(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對(duì)源目錄進(jìn)行實(shí)時(shí)監(jiān)控似忧，只要有文件變動(dòng)或新文件產(chǎn)生渣叛，就會(huì)立刻同步到目標(biāo)目錄下，非常高效實(shí)用盯捌。

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)的最大時(shí)間 
.......

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

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

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

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

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

自己寫