
1、請簡述OSI七層網絡模型有哪些層及各自的含義?
物理層:底層數據傳輸,比如網線、網卡標準數據鏈路層:定義數據的基本格式,如何傳輸,如何標識。比如網卡MAC地址網絡層:定義IP編碼,定義路由功能,比如不同設備的數據轉發傳輸層:端到端傳輸數據的基本功能,比如TCP、UDP會話層:控制應用程序之間會話能力,比如不同軟件數據分發給不停軟件表示層:數據格式標識,基本壓縮加密功能。應用層:各種應用軟件,包括 Web 應用。這個分3種
【資料圖】
第一種方法:
growpart /dev/vda 1resize2fs /dev/vda1
第二種方法:
partpeobe /dev/sdaresize2fs /dev/vda1
第三種方法:
fdisk /dev/sdb # n p 1 1 回車 回車 t 8e wpvcreate /dev/sdb1vgextend datavg /dev/sdb1lvextend -r -L +100%free /dev/mapper/datavg-lv01
迭代查詢(返回最優結果)、遞歸查詢(本地找DNS)用戶要訪問 www.baidu.com,會先找本機的host文件,再找本地設置的DNS服務器,如果也沒有找到,就去網絡中找根服務器,根服務器反饋結果,說只能提供一級域名服務器.cn,就去找一級域名服務器,一級域名服務器說只能提供二級域名服務器.com.cn,就去找二級域名服務器,二級域服務器只能提供三級域名服務器.baidu.com.cn,就去找三級域名服務器,三級域名服務器正好有這個網站www.baidu.com,然后發給請求的服務器,保存一份之后,再發給客戶端。
在一個虛擬路由器中,只有作為MASTER的VRRP(虛擬路由冗余協議)路由器會一直發送VRRP通告信息,BACKUP不會搶占MASTER,除非它的優先級更高。當MASTER不可用時(BACKUP收不到通告信息)多臺BACKUP中優先級最高的這臺會被搶占為MASTER。這種搶占是非常快速的(<1s),以保證服務的連續性由于安全性考慮,VRRP包使用了加密協議進行加密。BACKUP不會發送通告信息,只會接收通告信息。
LVS:
抗負載能力強、工作在第4層僅作分發之用,沒有流量的產生,這個特點也決定了它在負載均衡軟件里的性能最強的;無流量,同時保證了均衡器IO的性能不會受到大流量的影響;工作穩定,自身有完整的雙機熱備方案,如LVS+Keepalived和LVS+Heartbeat;應用范圍比較廣,可以對所有應用做負載均衡;配置簡單,因為沒有可太多配置的東西,所以并不需要太多接觸,大大減少了人為出錯的幾率;LVS的缺點:
軟件本身不支持正則處理,不能做動靜分離,這就凸顯了Nginx/HAProxy+Keepalived的優勢。如果網站應用比較龐大,LVS/DR+Keepalived就比較復雜了,特別是后面有Windows Server應用的機器,實施及配置還有維護過程就比較麻煩,相對而言,Nginx/HAProxy+Keepalived就簡單多了。Nginx:
工作在第7層,應用層,可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活;Nginx對網絡的依賴非常小,理論上能ping通就就能進行負載功能Nginx安裝和配置簡單可以承擔高的負載壓力且穩定,一般能支撐超過幾萬次的并發量;Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件,它同時也是功能強大的Web應用服務器。Nginx在處理靜態頁面、特別是抗高并發方面相對apache有優勢;Nginx作為Web反向代理加速緩存越來越成熟,速度比傳統的Squid服務器更快Nginx的缺點:
Nginx不支持url來檢測。Nginx僅能支持http、https和Email協議Nginx的Session的保持,Cookie的引導能力相對欠缺。HAProxy:
HAProxy是支持虛擬主機的,可以工作在4、7層(支持多網段);能夠補充Nginx的一些缺點比如Session的保持,Cookie的引導等工作;支持url檢測后端的服務器;它跟LVS一樣,本身僅僅就只是一款負載均衡軟件;單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度,在并發處理上也是優于Nginx的;HAProxy可以對Mysql讀進行負載均衡,對后端的MySQL節點進行檢測和負載均衡,不過在后端的MySQL slaves數量超過10臺時性能不如LVS;HAProxy的算法較多,達到8種;工作選擇:
HAproxy和Nginx由于可以做七層的轉發,所以URL和目錄的轉發都可以做在很大并發量的時候我們就要選擇LVS,像中小型公司的話并發量沒那么大選擇HAproxy或者Nginx足已,由于HAproxy由是專業的代理服務器配置簡單,所以中小型企業推薦使用HAproxy。
docker是一個Client-Server結構的系統,docker守護進程運行在宿主機上,守護進程從客戶端接受命令并管理運行在主機上的容器,容器是一個運行時環境,這就是我們說的集裝箱。
一個完整的docker有以下幾個部分組成:
docker client,客戶端,為用戶提供一系列可執行命令,用戶用這些命令實現跟 docker daemon 交互;docker daemon,守護進程,一般在宿主主機后臺運行,等待接收來自客戶端的請求消息;docker image,鏡像,鏡像run之后就生成為docker容器;docker container,容器,一個系統級別的服務,擁有自己的ip和系統目錄結構;運行容器前需要本地存在對應的鏡像,如果本地不存在該鏡像則就去鏡像倉庫下載。docker 使用客戶端-服務器 (C/S) 架構模式,使用遠程api來管理和創建docker容器。docker 容器通過 docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。
一個完整的Linux操作系統包含Linux內核和rootfs根文件系統,即我們熟悉的/dev、/proc/、/bin等目錄。我們平時看到的centOS除了rootfs,還會選裝很多軟件,服務,圖形桌面等,所以centOS鏡像有好幾個G也不足為奇。
而對于容器鏡像而言,所有容器都是共享宿主機的Linux 內核的,而對于docker鏡像而言,docker鏡像只需要提供一個很小的rootfs即可,只需要包含最基本的命令,工具,程序庫即可,所有docker鏡像才會這么小。
一個新的鏡像其實是從 base 鏡像一層一層疊加生成的。每安裝一個軟件,dockerfile中使用RUM命令,就會在現有鏡像的基礎上增加一層,這樣一層一層的疊加最后構成整個鏡像。所以我們docker pull拉取一個鏡像的時候會看到docker是一層層拉去的。
分層機構最大的一個好處就是 :共享資源。比如:有多個鏡像都從相同的 base 鏡像構建而來,那么 Docker Host 只需在磁盤上保存一份 base 鏡像;同時內存中也只需加載一份 base 鏡像,就可以為所有容器服務了。而且鏡像的每一層都可以被共享。
我們知道,鏡像是分層的,鏡像的每一層都可以被共享,同時,鏡像是只讀的。當一個容器啟動時,一個新的可寫層被加載到鏡像的頂部,這一層通常被稱作“容器層”,“容器層”之下的都叫“鏡像層”。
所有對容器的改動 - 無論添加、刪除、還是修改文件,都只會發生在容器層中,因為只有容器層是可寫的,容器層下面的所有鏡像層都是只讀的。鏡像層數量可能會很多,所有鏡像層會聯合在一起組成一個統一的文件系統。如果不同層中有一個相同路徑的文件,比如 /a,上層的 /a 會覆蓋下層的 /a,也就是說用戶只能訪問到上層中的文件 /a。在容器層中,用戶看到的是一個疊加之后的文件系統。
添加文件:在容器中創建文件時,新文件被添加到容器層中。讀取文件:在容器中讀取某個文件時,Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到,立即將其復制到容器層,然后打開并讀入內存。修改文件:在容器中修改已存在的文件時,Docker 會從上往下依次在各鏡像層中查找此文件。一旦找到,立即將其復制到容器層,然后修改之。??刪除文件??:在容器中刪除文件時,Docker 也是從上往下依次在鏡像層中查找此文件。找到后,會在容器層中記錄下此刪除操作。只有當需要修改時才復制一份數據,這種特性被稱作 Copy-on-Write。可見,容器層保存的是鏡像變化的部分,不會對鏡像本身進行任何修改。
首先,Dockerfile是一層一層的構建鏡像,期間會產生一個或多個臨時容器,構建過程中其實就是在臨時容器里面安裝應用,如果因為臨時容器安裝應用出現異常導致鏡像構建失敗,這時容器雖然被清理掉了,但是期間構建的中間鏡像還在,那么我們可以根據異常時上一層已經構建好的臨時鏡像,將臨時鏡像運行為容器,然后在容器里面運行安裝命令來定位具體的異常。
進入容器有兩種方法:??docker attach?
?、??docker exec?
?。
K8s是kubernetes的簡稱,其本質是一個開源的容器編排系統,主要用于管理容器化的應用,其目標是讓部署容器化的應用簡單并且高效(powerful),Kubernetes提供了應用部署,規劃,更新,維護的一種機制。
說簡單點:k8s就是一個編排容器的系統,一個可以管理容器應用全生命周期的工具,從創建應用,應用的部署,應用提供服務,擴容縮容應用,應用更新,都非常的方便,而且還可以做到故障自愈,所以,k8s是一個非常強大的容器編排系統。
k8s主要由master節點和node節點構成。master節點負責管理集群,node節點是容器應用真正運行的地方。
master節點包含的組件有:kube-api-server、kube-controller-manager、kube-scheduler、etcd。node節點包含的組件有:kubelet、kube-proxy、container-runtime。kube-api-server:以下簡稱api-server,api-server是k8s最重要的核心組件之一,它是k8s集群管理的統一訪問入口,提供了RESTful API接口, 實現了認證、授權和準入控制等安全功能;api-server還是其他組件之間的數據交互和通信的樞紐,其他組件彼此之間并不會直接通信,其他組件對資源對象的增、刪、改、查和監聽操作都是交由api-server處理后,api-server再提交給etcd數據庫做持久化存儲,只有api-server才能直接操作etcd數據庫,其他組件都不能直接操作etcd數據庫,其他組件都是通過api-server間接的讀取,寫入數據到etcd。
kube-controller-manager:以下簡稱controller-manager,controller-manager是k8s中各種控制器的的管理者,是k8s集群內部的管理控制中心,也是k8s自動化功能的核心;controller-manager內部包含replication controller、node controller、deployment controller、endpoint controller等各種資源對象的控制器,每種控制器都負責一種特定資源的控制流程,而controller-manager正是這些controller的核心管理者。
kube-scheduler:以下簡稱scheduler,scheduler負責集群資源調度,其作用是將待調度的pod通過一系列復雜的調度算法計算出最合適的node節點,然后將pod綁定到目標節點上。shceduler會根據pod的信息(關注微信公眾號:網絡技術聯盟站),全部節點信息列表,過濾掉不符合要求的節點,過濾出一批候選節點,然后給候選節點打分,選分最高的就是最佳節點,scheduler就會把目標pod安置到該節點。
Etcd:etcd是一個分布式的鍵值對存儲數據庫,主要是用于保存k8s集群狀態數據,比如,pod,service等資源對象的信息;etcd可以是單個也可以有多個,多個就是etcd數據庫集群,etcd通常部署奇數個實例,在大規模集群中,etcd有5個或7個節點就足夠了;另外說明一點,etcd本質上可以不與master節點部署在一起,只要master節點能通過網絡連接etcd數據庫即可。
kubelet:每個node節點上都有一個kubelet服務進程,kubelet作為連接master和各node之間的橋梁,負責維護pod和容器的生命周期,當監聽到master下發到本節點的任務時,比如創建、更新、終止pod等任務,kubelet 即通過控制docker來創建、更新、銷毀容器;每個kubelet進程都會在api-server上注冊本節點自身的信息,用于定期向master匯報本節點資源的使用情況。
kube-proxy:kube-proxy運行在node節點上,在Node節點上實現Pod網絡代理,維護網絡規則和四層負載均衡工作,kube-proxy會監聽api-server中從而獲取service和endpoint的變化情況,創建并維護路由規則以提供服務IP和負載均衡功能。簡單理解此進程是Service的透明代理兼負載均衡器,其核心功能是將到某個Service的訪問請求轉發到后端的多個Pod實例上。
container-runtime:容器運行時環境,即運行容器所需要的一系列程序,目前k8s支持的容器運行時有很多,如docker、rkt或其他,比較受歡迎的是docker,但是新版的k8s已經宣布棄用docker。
kubelet部署在每個node節點上的,它主要有4個功能:
節點管理。kubelet啟動時會向api-server進行注冊,然后會定時的向api-server匯報本節點信息狀態,資源使用狀態等,這樣master就能夠知道node節點的資源剩余,節點是否失聯等等相關的信息了。master知道了整個集群所有節點的資源情況,這對于 pod 的調度和正常運行至關重要。pod管理。kubelet負責維護node節點上pod的生命周期,當kubelet監聽到master的下發到自己節點的任務時,比如要創建、更新、刪除一個pod,kubelet 就會通過CRI(容器運行時接口)插件來調用不同的容器運行時來創建、更新、刪除容器;常見的容器運行時有docker、containerd、rkt等等這些容器運行時,我們最熟悉的就是docker了,但在新版本的k8s已經棄用docker了,k8s1.24版本中已經使用containerd作為容器運行時了。容器健康檢查。pod中可以定義啟動探針、存活探針、就緒探針等3種,我們最常用的就是存活探針、就緒探針,kubelet 會定期調用容器中的探針來檢測容器是否存活,是否就緒,如果是存活探針,則會根據探測結果對檢查失敗的容器進行相應的重啟策略;??Metrics Server資源監控??。在node節點上部署Metrics Server用于監控node節點、pod的CPU、內存、文件系統、網絡使用等資源使用情況,而kubelet則通過Metrics Server獲取所在節點及容器的上的數據。kube-api-server的端口是8080和6443,前者是http的端口,后者是https的端口,以我本機使用kubeadm安裝的k8s為例:
在命名空間的kube-system命名空間里,有一個名稱為kube-api-master的pod,這個pod就是運行著kube-api-server進程,它綁定了master主機的ip地址和6443端口,但是在default命名空間下,存在一個叫kubernetes的服務,該服務對外暴露端口為443,目標端口6443,這個服務的ip地址是clusterip地址池里面的第一個地址,同時這個服務的yaml定義里面并沒有指定標簽選擇器,也就是說這個kubernetes服務所對應的endpoint是手動創建的,該endpoint也是名稱叫做kubernetes,該endpoint的yaml定義里面代理到master節點的6443端口,也就是kube-api-server的IP和端口。這樣一來,其他pod訪問kube-api-server的整個流程就是:pod創建后嵌入了環境變量,pod獲取到了kubernetes這個服務的ip和443端口,請求到kubernetes這個服務其實就是轉發到了master節點上的6443端口的kube-api-server這個pod里面。
amespace是kubernetes系統中的一種非常重要的資源,namespace的主要作用是用來實現多套環境的資源隔離,或者說是多租戶的資源隔離。
k8s通過將集群內部的資源分配到不同的namespace中,可以形成邏輯上的隔離,以方便不同的資源進行隔離使用和管理。不同的命名空間可以存在同名的資源,命名空間為資源提供了一個作用域。
可以通過k8s的授權機制,將不同的namespace交給不同的租戶進行管理,這樣就實現了多租戶的資源隔離,還可以結合k8s的資源配額機制,限定不同的租戶能占用的資源,例如CPU使用量、內存使用量等等來實現租戶可用資源的管理。
輪詢(默認)
加權輪詢(輪詢+weight)
ip_hash
每一個請求的訪問IP,都會映射成一個hash,再通過hash算法(hash值%node_count),分配到不同的后端服務器,訪問ip相同的請求會固定訪問同一個后端服務器,這樣可以做到會話保持,解決session同步問題。
least_conn(最少連接)
使用最少連接的負載平衡,nginx將嘗試不會使繁忙的應用程序服務器超載請求過多,而是將新請求分發給不太繁忙的服務器。
top —> task (line)—> zombie.
把父進程殺掉,父進程死后,過繼給1號進程init,init 始終負責清理僵尸進程,它產生的所有僵尸進程跟著消失;如果你使用kill ,一般都不能殺掉 defunct進程.。用了kill -15,kill -9以后 之后反而會多出更多的僵尸進程。
pgrep -au neteagle
lsof -i :[port]
iptables -t nat -A PREROUTING -d 10.0.0.8 -p tcp --dport 80 -j REDIRECT --to-ports 8080
etstat-n|awk"/^tcp/{++b[$NF]}END{for(ainb)printa,b[a]}"
ls/var/log/-lR|grep"^-"|wc-l
功能:可以對磁盤進行動態管理。動態按需調整大小
概念:
??PV 物理卷??:物理卷在邏輯卷管理中處于最底層,它可以是實際物理硬盤上的分區,也可以是整個物理硬盤,也可以是raid設備。VG 卷組:卷組建立在物理卷之上,一個卷組中至少要包括一個物理卷,在卷組建立之后可動態添加物理卷到卷組中。一個邏輯卷管理系統工程中可以只有一個卷組,也可以擁有多個卷組。LV 邏輯卷:邏輯卷建立在卷組之上,卷組中的未分配空間可以用于建立新的邏輯卷,邏輯卷建立后可以動態地擴展和縮小空間。系統中的多個邏輯卷可以屬于同一個卷組,也可以屬于不同的多個卷組。給/分區擴容步驟:
添加磁盤使用fdisk命令對新增加的磁盤進行分區分區完成后修改分區類型為lvm使用pvcreate創建物理卷使用vgextend命令將新增加的分區加入到根目錄分區中使用lvextend命令進行擴容使用xfs_growfs調整卷分區大小以下操作全部在vi/vim命令行狀態操作,不要在編輯狀態操作:
在文本里 移動到想要復制的行按yy想復制到哪就移動到哪,然后按P就黏貼了刪除行 移動到改行 按dd刪除全部dG這里注意G一定要大寫按行查找 :90 這樣就是找到第90行按字母查找 /path 這樣就是找到path這個單詞所在的位置,文本里可能存在多個,多次查找會顯示在不同的位置。一個位于客戶端和原始服務器(origin server)之間的服務器,為了從原始服務器取得內容,客戶端向代理發送一個請求并指定目標(原始服務器),然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。
客戶端才能使用正向代理。正向代理總結就一句話:代理端代理的是客戶端。例如說:我們使用的OpenVPN 等等。
反向代理(Reverse Proxy)方式,是指以代理服務器來接受 Internet上的連接請求,然后將請求,發給內部網絡上的服務器并將從服務器上得到的結果返回給 Internet 上請求連接的客戶端,此時代理服務器對外就表現為一個反向代理服務器。
反向代理總結就一句話:代理端代理的是服務端。
動態資源、靜態資源分離,是讓動態網站里的動態網頁根據一定規則把不變的資源和經常變的資源區分開來,動靜資源做好了拆分以后我們就可以根據靜態資源的特點將其做緩存操作,這就是網站靜態化處理的核心思路。
動態資源、靜態資源分離簡單的概括是:動態文件與靜態文件的分離。
在我們的軟件開發中,有些請求是需要后臺處理的(如:.jsp,.do 等等),有些請求是不需要經過后臺處理的(如:css、html、jpg、js 等等文件),這些不需要經過后臺處理的文件稱為靜態文件,否則動態文件。
因此我們后臺處理忽略靜態文件。這會有人又說那我后臺忽略靜態文件不就完了嗎?當然這是可以的,但是這樣后臺的請求次數就明顯增多了。在我們對資源的響應速度有要求的時候,我們應該使用這種動靜分離的策略去解決動、靜分離將網站靜態資源(HTML,JavaScript,CSS,img等文件)與后臺應用分開部署,提高用戶訪問靜態代碼的速度,降低對后臺應用訪問
這里我們將靜態資源放到 Nginx 中,動態資源轉發到 Tomcat 服務器中去。
當然,因為現在七牛、阿里云等 CDN 服務已經很成熟,主流的做法,是把靜態資源緩存到 CDN 服務中,從而提升訪問速度。
相比本地的 Nginx 來說,CDN 服務器由于在國內有更多的節點,可以實現用戶的就近訪問。并且,CDN 服務可以提供更大的帶寬,不像我們自己的應用服務,提供的帶寬是有限的。
vi /etc/sysconfig/network-scripts/ifcfg-eth0
查看網卡狀況IP -a -s 網卡的名字
A服務器設置相關網卡信息
子網掩碼:255.255.255.0IP=10.0.0.1網關=10.0.0.254重啟網卡生效查看路由信息route -n添加對應路由route add -net 10.0.1.0/24 gw 10.0.0.11
B服務器的設置相關信息
IP=10.0.1.10網關10.0.1.254重啟網卡生效route -n添加對應的路由route add -net 10.0.0.0/24 gw 10.0.1.11
C服務器的兩塊網卡
網卡1IP=10.0.0.11網關=10.0.0.254網卡2IP=10.0.1.11網關=10.0.1.254重啟網卡生效route -nvi /etc/sysctl.confnet.ipv4.ip_forword = 1
ifconfig 查看一下docker0網橋,ping一下網橋看看是否通,有可能是網橋配置問題
weave路由器端口6783
安裝docker容器的服務器沒有關閉防火墻(訪問一下安裝docker物理機的,是否能訪問,如果不能訪問就變不能訪問docker)docker在創建鏡像的時候沒有做端口映射(出現這種情況能訪問物理機不能訪問docker)使用dockers ps 查看鏡像的端口映射情況端口映射不正確查看網絡配置ping網橋看是否能ping通,有可能是網橋的原因判斷原因
首先我要以用戶的身份登錄我們的網站,判斷問題出現在我們自身原因,還是用戶那邊的原因。
如果是用戶問題有以下幾個原因:
用戶那邊的帶寬用戶的瀏覽器器版本低,安裝插件太多中毒和電腦里的垃圾文件過多用戶主機的主機的性能和操作系統??如果是我們的網站自身問題有一下幾個原因??
網絡帶寬服務器的cpu、硬盤、內存過低服務器負載不起來也就是說服務器自身的性能方面網站代碼不夠完善。如mysql語句沒有進行優化導致數據庫讀寫耗時服務器未開啟圖片壓縮網頁臺下死連接過多插件使用及js文件調用頻繁網站服務器的速度或是租用空間所在的服務器速度解決思路
1、檢測服務器速度的快慢
ping命令查看連接到服務器的時間和丟包情況(ping 測試網址的)查看丟包率(1000個包沒有丟一個是最理想的、一般一個速度好的機房丟包率不超過1%)ping值要小同城電信adsl ping平均值絕對不能超過20,一般都在10,跨省的平均值20-40屬于正常ping值要均勻最小值和最大值相差太大說明路由不穩定的表現2、查看服務器自身性能
查看cpu的使用率??uptime?
?
查看內存情況??free -m?
?
查看I/O讀寫iostat 磁盤I/O讀寫等看看是那個進程大量占用系統資源導致我的服務器變慢
3、看看訪問最多的URL和IP有什么特征,如果是惡意URL和IP就把他屏蔽掉如果是善意的就限流有可能是CDN回源量大造成網站無法訪問
4、查看同臺服務器上其他網站的打開速度,可以通過查詢工具查看和自己在同一臺服務器上的網站個數和網址可以看他們打開快慢
5、電信和聯通互訪的問題
如果是空間打開時快時慢,有時打不開那就是空間不穩定找空間商解決或是換空間傷,如果是有的地方快有的地方慢應該是網絡線路問題,比如電信用戶訪問放在聯通服務器上的網站,聯通用戶訪問放在電信服務器上的網站,解決辦吧是:使用雙線空間或是多線空間
6、從網站自身的原因
網站的程序設計結構是否合理是否由于幻燈片代碼影響網站打開速度(找程序設計相關人士解決)網頁的設計結構和代碼錯誤(請專業人士進行修改)網頁的內容如:大尺寸圖片、大尺寸flash、過多的引用其他網站內容,如果被引用內容的網站速度慢,也影響自身網站把。譬如友情連接可以把對方 的圖片放到自己網站上解決辦法
優化圖片,限制圖片大小尺寸,降低圖片質量,減少圖片數量限定圖片的格式:jpg,png,gif減少http的請求數(當打開網頁時瀏覽器會發出很多對象請求,每個對象的加載都會有所延時,如果網頁上的對象很多就會花費大量的時間,去除不必要的對象,將臨近的圖片合成一張,合并css文件) f r o m :w l j s l m z我們一般通過 hexdump 命令 來查看二進制文件的內容。
hexdump -C XXX(文件名) -C 是參數 不同的參數有不同的意義
-C 是比較規范的 十六進制和 ASCII 碼顯示
-c 是單字節字符顯示
-b 單字節八進制顯示
-o 是雙字節八進制顯示
-d 是雙字節十進制顯示
-x 是雙字節十六進制顯示
等等等等
在生產環境下,不管是應用數據、還是數據庫數據首先在部署的時候就會有主從架構、或者集群,這本身就是屬于數據的熱備份;其實考慮冷備份,用專門一臺服務器做為備份服務器,比如可以用rsync+inotify配合計劃任務來實現數據的冷備份,如果是發版的包備份,正常情況下有臺發布服務器,每次發版都會保存好發版的包。