一 資源限制

1.1 pod資源限制

pod可以包括資源請求和資源限制:

• 資源請求

用於調度，並控制pod不能在計算資源少於指定數量的情況下運行。調度程序試圖找到一個具有足夠計算資源的節點來滿足pod請求。

• 資源限制

用於防止pod耗盡節點的所有計算資源，基於pod的節點配置Linux內核cgroups特性，以執行pod的資源限制。

儘管資源請求和資源限制是pod定義的一部分，但通常建議在dc中設置。OpenShift推薦的實踐規定，不應該單獨創建pod，而應該由dc創建。

1.2 應用配額

OCP可以執行跟蹤和限制兩種資源使用的配額:

對象的數量：Kubernetes資源的數量，如pod、service和route。

計算資源：物理或虛擬硬件資源的數量，如CPU、內存和存儲容量。

通過避免master的Etcd數據庫的無限制增長，對Kubernetes資源的數量設置配額有助於OpenShift master服務器的穩定性。對Kubernetes資源設置配額還可以避免耗盡其他有限的軟件資源，比如服務的IP地址。

同樣，對計算資源的數量施加配額可以避免耗盡OpenShift集群中單個節點的計算能力。還避免了一個應用程序使用所有集群容量，從而影響共享集群的其他應用程序。

OpenShift通過使用ResourceQuota對象或簡單的quota來管理對象使用的配額及計算資源。

ResourceQuota對象指定項目的硬資源使用限制。配額的所有屬性都是可選的，這意味着任何不受配額限制的資源都可以無限制地使用。

注意：一個項目可以包含多個ResourceQuota對象，其效果是累積的，但是對於同一個項目，兩個不同的 ResourceQuota 不會試圖限制相同類型的對象或計算資源。

1.3 ResourceQuota限制資源

下錶显示 ResourceQuota 可以限制的主要對象和計算資源：

對象名	描述
pods	總計的pod數量
replicationcontrollers	總計的rc數量
services	總計的service數量
secrets	總計的secret數量
persistentvolumeclaims	總計的pvc數量
cpu	所有容器的CPU使用總量
memory	所有容器的總內存使用
storage	所有容器的磁盤總使用量

Quota屬性可以跟蹤項目中所有pod的資源請求或資源限制。默認情況下，配額屬性跟蹤資源請求。要跟蹤資源限制，可以在計算資源名稱前面加上限制，例如limit.cpu。

示例一：使用YAML語法定義的ResourceQuota資源，它為對象計數和計算資源指定了配額：

  1 $ cat
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: dev-quota
  6 spec:
  7   hard:
  8     services: "10"
  9     cpu: "1300m"
 10     memory: "1.5Gi"
 11 $ oc create -f dev-quota.yml

示例二：使用oc create quota命令創建：

  1 $ oc create quota dev-quota \
  2 --hard=services=10 \
  3 --hard=cpu=1300m \
  4 --hard=memory=1.5Gi
  5 $ oc get resourcequota				#列出可用的配額
  6 $ oc describe resourcequota NAME		#查看與配額中定義的任何與限制相關的統計信息
  7 $ oc delete resourcequota compute-quota		#按名稱刪除活動配額

提示：若oc describe resourcequota命令不帶參數，只显示項目中所有resourcequota對象的累積限制集，而不显示哪個對象定義了哪個限制。

當在項目中首次創建配額時，項目將限制創建任何可能超出配額約束的新資源的能力，然後重新計算資源使用情況。在創建配額和使用數據統計更新之後，項目接受新內容的創建。當創建新資源時，配額使用量立即增加。當一個資源被刪除時，在下一次對項目的 quota 統計數據進行全面重新計算時，配額使用將減少。

ResourceQuota 應用於整個項目，但許多 OpenShift 過程，例如 build 和 deployment，在項目中創建 pod，可能會失敗，因為啟動它們將超過項目 quota。

如果對項目的修改超過了對象數量的 quota，則服務器將拒絕操作，並向用戶返回錯誤消息。但如果修改超出了計算資源的quota，則操作不會立即失敗。OpenShift 將重試該操作幾次，使管理員有機會增加配額或執行糾正操作，比如上線新節點，擴容節點資源。

注意：如果設置了計算資源的 quota，OpenShift 拒絕創建不指定該計算資源的資源請求或資源限制的pod。

1.3 應用限制範圍

LimitRange資源，也稱為limit，定義了計算資源請求的默認值、最小值和最大值，以及項目中定義的單個pod或單個容器的限制，pod的資源請求或限制是其容器的總和。

要理解limit rang和resource quota之間的區別，limit rang為單個pod定義了有效範圍和默認值，而resource quota僅為項目中所有pod的和定義了最高值。

通常可同時定義項目的限制和配額。

LimitRange資源還可以為image、is或pvc的存儲容量定義默認值、最小值和最大值。如果添加到項目中的資源不提供計算資源請求，那麼它將接受項目的limit ranges提供的默認值。如果新資源提供的計算資源請求或限制小於項目的limit range指定的最小值，則不創建該資源。同樣，如果新資源提供的計算資源請求或限制高於項目的limit range所指定的最大值，則不會創建該資源。

OpenShift 提供的大多數標準 S2I builder image 和 templabe 都沒有指定。要使用受配額限制的 template 和 builder，項目需要包含一個 limit range 對象，該對象為容器資源請求指定默認值。

如下為描述了一些可以由LimitRange對象指定的計算資源。

類型	資源名稱	描述
Container	cpu	每個容器允許的最小和最大CPU。
Container	memory	每個容器允許的最小和最大內存
Pod	cpu	一個pod中所有容器允許的最小和最大CPU
Pod	memory	一個pod中所有容器允許的最小和最大內存
Image	storage	可以推送到內部倉庫的圖像的最大大小
PVC	storage	一個pvc的容量的最小和最大容量

示例一：limit rang的yaml示例：

  1 $ cat dev-limits.yml
  2 apiVersion: "v1"
  3 kind: "LimitRange"
  4 metadata:
  5   name: "dev-limits"
  6 spec:
  7   limits:
  8     - type: "Pod"
  9       max:
 10         cpu: "2"
 11         memory: "1Gi"
 12       min:
 13         cpu: "200m"
 14         memory: "6Mi"
 15     - type: "Container"
 16       default:
 17         cpu: "1"
 18         memory: "512Mi"
 19 $ oc create -f dev-limits.yml
 20 $ oc describe limitranges NAME		#查看項目中強制執行的限制約束
 21 $ oc get limits				#查看項目中強制執行的限制約束
 22 $ oc delete limitranges name		#按名稱刪除活動的限制範圍

提示：OCP 3.9不支持使用oc create命令參數形式創建limit rang。

在項目中創建limit rang之後，將根據項目中的每個limit rang資源評估所有資源創建請求。如果新資源違反由任何limit rang設置的最小或最大約束，則拒絕該資源。如果新資源沒有聲明配置值，且約束支持默認值，則將默認值作為其使用值應用於新資源。

所有資源更新請求也將根據項目中的每個limit rang資源進行評估，如果更新后的資源違反了任何約束，則拒絕更新。

注意：避免將LimitRange設的過高，或ResourceQuota設的過低。違反LimitRange將阻止pod創建，並清晰保存。違反ResourceQuota將阻止pod被調度，狀態轉為pending。

1.4 多項目quota配額

ClusterResourceQuota資源是在集群級別創建的，創建方式類似持久卷，並指定應用於多個項目的資源約束。

可以通過以下兩種方式指定哪些項目受集群資源配額限制:

• 使用openshift.io/requester標記，定義項目所有者，該所有者的所有項目均應用quota；
• 使用selector，匹配該selector的項目將應用quota。

示例1：

  1 $ oc create clusterquota user-qa \
  2 --project-annotation-selector openshift.io/requester=qa \
  3 --hard pods=12 \
  4 --hard secrets=20			#為qa用戶擁有的所有項目創建集群資源配額
  5 $ oc create clusterquota env-qa \
  6 --project-label-selector environment=qa \
  7 --hard pods=10 \
  8 --hard services=5			#為所有具有environment=qa標籤的項目創建集群資源配額
  9 $ oc describe QUOTA NAME		#查看應用於當前項目的集群資源配額
 10 $ oc delete clusterquota NAME		#刪除集群資源配額

提示：不建議使用一個集群資源配額來匹配超過100個項目。這是為了避免較大的locking開銷。當創建或更新項目中的資源時，在搜索所有適用的資源配額時鎖定項目需要較大的資源消耗。

二 限制資源使用

2.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

2.2 本練習準備

  1 [student@workstation ~]$ lab monitor-limit setup

2.3 查看當前資源

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  3 [student@workstation ~]$ oc describe node node2.lab.example.com | grep -A 4 Allocated

2.4 創建應用

  1 [student@workstation ~]$ oc new-project resources
  2 [student@workstation ~]$ oc new-app --name=hello \
  3 --docker-image=registry.lab.example.com/openshift/hello-openshift
  4 [student@workstation ~]$ oc get pod -o wide
  5 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
  6 hello-1-znk56   1/1       Running   0          24s       10.128.0.16   node1.lab.example.com

2.5 刪除應用

  1 [student@workstation ~]$ oc delete all -l app=hello

2.6 添加資源限制

作為集群管理員，向項目quota和limit range，以便為項目中的pod提供默認資源請求。

  1 [student@workstation ~]$ cd /home/student/DO280/labs/monitor-limit/
  2 [student@workstation monitor-limit]$ cat limits.yml		#創建limit range
  3 apiVersion: "v1"
  4 kind: "LimitRange"
  5 metadata:
  6   name: "project-limits"
  7 spec:
  8   limits:
  9     - type: "Container"
 10       default:
 11         cpu: "250m
 12 [student@workstation monitor-limit]$ oc create -f limits.yml	#創建limit range
 13 [student@workstation monitor-limit]$ oc describe limitrange	#查看limit range

  1 [student@workstation monitor-limit]$ cat quota.yml		#創建配額
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: project-quota
  6 spec:
  7   hard:
  8     cpu: "900m"
  9 [student@workstation monitor-limit]$ oc create -f quota.yml
 10 [student@workstation monitor-limit]$ oc describe quota		#確保創建了resource限制

2.7 授權項目

  1 [student@workstation monitor-limit]$ oc adm policy add-role-to-user edit developer

2.8 驗證資源限制

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc project resources			#選擇項目
  3 Already on project "resources" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc get limits				#查看limit
  5 NAME             AGE
  6 project-limits   14m
  7 [student@workstation ~]$ oc delete limits project-limits	#驗證限制是否有效，但developer用戶不能刪除該限制
  8 Error from server (Forbidden): limitranges "project-limits" is forbidden: User "developer" cannot delete limitranges in the namespace "resources": User "developer" cannot delete limitranges in project "resources"
  9 [student@workstation ~]$ oc get quota
 10 NAME            AGE
 11 project-quota   15m

2.9 創建應用

  1 [student@workstation ~]$ oc new-app --name=hello \
  2 --docker-image=registry.lab.example.com/openshift/hello-openshift
  3 [student@workstation ~]$ oc get pod
  4 NAME            READY     STATUS    RESTARTS   AGE
  5 hello-1-t7tfn   1/1       Running   0          35s

2.10 查看quota

  1 [student@workstation ~]$ oc describe quota
  2 Name:       project-quota
  3 Namespace:  resources
  4 Resource    Used  Hard
  5 --------    ----  ----
  6 cpu         250m  900m

2.11 查看節點可用資源

  1 [student@workstation ~]$ oc login -u admin -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc get pod -o wide -n resources
  4 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  5 [student@workstation ~]$ oc describe pod hello-1-t7tfn | grep -A2 Requests

2.12 擴容應用

  1 [student@workstation ~]$ oc scale dc hello --replicas=2		#擴容應用
  2 [student@workstation ~]$ oc get pod				#查看擴容后的pod
  3 [student@workstation ~]$ oc describe quota			#查看擴容后的quota情況
  4 [student@workstation ~]$ oc scale dc hello --replicas=4		#繼續擴容至4個
  5 [student@workstation ~]$ oc get pod				#查看擴容的pod
  6 [student@workstation ~]$ oc describe dc hello | grep Replicas	#查看replaces情況

結論：由於超過了配額規定，會提示控制器無法創建第四個pod。

2.13 添加配額請求

  1 [student@workstation ~]$ oc scale dc hello --replicas=1
  2 [student@workstation ~]$ oc get pod
  3 [student@workstation ~]$ oc set resources dc hello --requests=memory=256Mi	#設置資源請求
  4 [student@workstation ~]$ oc get pod
  5 [student@workstation ~]$ oc describe pod hello-2-4jvpw | grep -A 3 Requests
  6 [student@workstation ~]$ oc describe quota					#查看quota

結論：由上可知從項目的配額角度來看，沒有什麼變化。

2.14 增大配額請求

  1 [student@workstation ~]$ oc set resources dc hello --requests=memory=8Gi	#將內存請求增大到超過node最大值
  2 [student@workstation ~]$ oc get pod						#查看pod
  3 [student@workstation ~]$ oc logs hello-3-deploy					#查看log
  4 [student@workstation ~]$ oc status

結論：由於資源請求超過node最大值，最終显示一個警告，說明由於內存不足，無法將pod調度到任何節點。

三 OCP升級

3.1 升級OPENSHIFT

當OCP的新版本發布時，可以升級現有集群，以應用最新的增強功能和bug修復。這包括從以前的次要版本(如從3.7升級到3.9)升級，以及對次要版本(3.7)應用更新。

提示：OCP 3.9包含了Kubernetes 1.8和1.9的特性和補丁的合併。由於主要版本之間的核心架構變化，OpenShift Enterprise 2環境無法升級為OpenShift容器平台3，必須需要重新安裝。

通常，主版本中不同子版本的node是向前和向後兼容的。但是，運行不匹配的版本的時間不應超過升級整個集群所需的時間。此外，不支持使用quick installer將版本3.7升級到3.9。

3.2 升級方式

有兩種方法可以執行OpenShift容器平台集群升級，一種為in-place升級(可以自動升級或手動升級)，也可以使用blue-green部署方法進行升級。

in-place升級：使用此方式，集群升級將在單個運行的集群中的所有主機上執行。首先升級master，然後升級node。在node升級開始之前，Pods被遷移到集群中的其他節點。這有助於減少用戶應用程序的停機時間。

注意：對於使用quick和高級安裝方法安裝的集群，可以使用自動in-place方式升級。

當使用高級安裝方法安裝集群時，您可以通過重用它們的庫存文件執行自動化或手動就地升級。

blue-green部署：blue-green部署是一種旨在減少停機時間同時升級環境的方法。在blue-green部署中，相同的環境與一個活動環境一起運行，而另一個環境則被更新。OpenShift升級方法標記了不可調度節點，並將pod調度到可用節點。升級成功后，節點將恢復到可調度狀態。

3.3 執行自動化集群升級

使用高級安裝方法，可以使用Ansible playbook自動化執行OpenShift集群升級過程。用於升級的劇本位於/usr/share/ansible/openshift-ansible/Playbooks/common/openshift-cluster/updates/中。該目錄包含一組用於升級集群的子目錄，例如v3_9。

注意：將集群升級到 OCP 3.9 前，集群必須已經升級到 3.7。集群升級一次不能跨越一個以上的次要版本，因此，如果集群的版本早於3.6，則必須先漸進地升級，例如從3.5升級到3.6，然後從3.6升級到3.7

要執行升級，可以使用ansible-playbook命令運行升級劇本，如使用v3_9 playbook將運行3.7版本的現有OpenShift集群升級到3.9版本。

自動升級主要執行以下任務:

• 應用最新的配置更改；
• 保存Etcd數據；
• 將api從3.7更新到3.8，然後從3.8更新到3.9；
• 如果存在，將默認路由器從3.7更新到3.9；
• 如果存在，則將默認倉庫從3.7更新到3.9；
• 更新默認is和Templates。

注意：在繼續升級之前，確保已經滿足了所有先決條件，否則可能導致升級失敗。

如果使用容器化的GlusterFS，節點將不會從pod中撤離，因為GlusterFS pod作為daemonset的一部分運行。要正確地升級運行容器化GlusterFS的集群，需要:

1：升級master服務器、Etcd和基礎設施服務(route、內部倉庫、日誌記錄和metric)。

2：升級運行應用程序容器的節點。

3：一次升級一個運行GlusterFS的節點。

注意：在升級之前，使用oc adm diagnostics命令驗證集群的健康狀況。這確認節點處於ready狀態，運行預期的啟動版本，並且沒有診斷錯誤或警告。對於離線安裝，使用–network-pod-image=’REGISTRY URL/ IMAGE參數指定要使用的image。

3.4 準備自動升級

下面的過程展示了如何為自動升級準備環境，在執行升級之前，Red Hat建議檢查配置Inventory文件，以確保對Inventory文件進行了手動更新。如果配置沒有修改，則使用默認值覆蓋更改。

1. 如果這是從OCP 3.7升級到3.9，手動禁用3.7存儲庫，並在每個master節點和node節點上啟用3.8和3.9存儲庫：

  1 [root@demo ~]# subscription-manager repos \
  2 --disable="rhel-7-server-ose-3.7-rpms" \
  3 --enable="rhel-7-server-ose-3.9-rpms" \
  4 --enable="rhel-7-server-ose-3.8-rpms" \
  5 --enable="rhel-7-server-rpms" \
  6 --enable="rhel-7-server-extras-rpms" \
  7 --enable="rhel-7-server-ansible-2.4-rpms" \
  8 --enable="rhel-7-fast-datapath-rpms"
  9 [root@demo ~]# yum clean all

1. 確保在每個RHEL 7系統上都有最新版本的atom-openshift-utils包，它還更新openshift-ansible-*包。

  1 [root@demo ~]# yum update atomic-openshift-utils

1. 在OpenShift容器平台的以前版本中，安裝程序默認將master節點標記為不可調度，但是，從OCP 3.9開始，master節點必須標記為可調度的，這是在升級過程中自動完成的。

如果沒有設置默認的節點選擇器(如下配置)，它們將在升級過程中添加。則master節點也將被標記為master節點角色。所有其他節點都將標記為compute node角色。

  1 openshift_node_labels="{'region':'infra', 'node-role.kubernetes.io/compute':'true'}

1. 如果將openshift_disable_swap=false變量添加到的Ansible目錄中，或者在node上手動配置swap，那麼在運行升級之前禁用swap內存。

3.5 升級master節點和node節點

在滿足了先決條件(如準備工作)之後，則可以按照如下步驟進行升級：

1. 在清單文件中設置openshift_deployment_type=openshift-enterprise變量。
2. 如果使用自定義Docker倉庫，則必須顯式地將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變量。這些值由Ansible在升級過程中使用。

  1 openshift_web_console_prefix=registry.demo.example.com/openshift3/ose-
  2 template_service_broker_prefix=registry.demo.example.com/openshift3/ose-

1. 如果希望重啟service或重啟node，請在Inventory文件中設置openshift_rolling_restart_mode=system選項。如果未設置該選項，則默認值表明升級過程在master節點上執行service重啟，但不重啟系統。
2. 可以通過運行一個Ansible Playbook (upgrade.yml)來更新環境中的所有節點，也可以通過使用單獨的Playbook分多個階段進行升級。
3. 重新啟動所有主機，重啟之後，如果沒有部署任何額外的功能，可以驗證升級。

3.6 分階段升級集群

如果決定分多個階段升級環境，根據Ansible Playbook (upgrade_control_plan .yml)確定的第一個階段，升級以下組件:

1. master節點；
2. 運行master節點的節點services；
3. Docker服務位於master節點和任何獨立Etcd主機上。

第二階段由upgrade_nodes.yml playbook，升級了以下組件。在運行此第二階段之前，必須已經升級了master節點。

1. node節點的服務；
2. 運行在獨立節點上的Docker服務。

兩個階段的升級過程允許通過指定自定義變量自定義升級的運行方式。例如，要升級總節點的50%，可以運行以下命令:

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="50%"

若要在HA region一次升級兩個節點，請運行以下命令：

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="2"
  5 -e openshift_upgrade_nodes_label="region=HA"

要指定每個更新批處理中允許有多少節點失敗，可使用openshift_upgrade_nodes_max_fail_percent選項。當故障百分比超過定義的值時，Ansible將中止升級。

使用openshift_upgrade_nodes_drain_timeout選項指定中止play前等待的時間。

示例：如下所示一次升級10個節點，以及如果20%以上的節點(兩個節點)失敗，以及終止play執行的等待時間。

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial=10 \
  5 -e openshift_upgrade_nodes_max_fail_percentage=20 \
  6 -e openshift_upgrade_nodes_drain_timeout=600

3.7 使用Ansible Hooks

可以通過hook為特定的操作執行定製的任務。hook允許通過定義在升級過程中特定點之前或之後執行的任務來擴展升級過程的默認行為。例如，可以在升級集群時驗證或更新自定義基礎設施組件。

提示：hook沒有任何錯誤處理機制，因此，hook中的任何錯誤都會中斷升級過程。需要修復hook並重新運行升級過程。

使用Inventory文件的[OSEv3:vars]部分來定義hook。每個hook必須指向一個.yaml文件，該文件定義了可能的任務。該文件是作為include語句的一部分集成的，該語句要求定義一組任務，而不是一個劇本。Red Hat建議使用絕對路徑來避免任何歧義。

以下hook可用於定製升級過程：

1. openshift_master_upgrade_pre_hook：hook在更新每個master節點之前運行。

2. openshift_master_upgrade_hook：hook在每個master節點升級之後、主服務或節點重新啟動之前運行。

3.openshift_master_upgrade_post_hook：hook在每個master節點升級並重啟服務或系統之後運行。

示例：在庫存文件中集成一個鈎子。

  1 [OSEv3:vars]
  2 openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
  3 openshift_master_upgrade_hook=/usr/share/custom/master.yml
  4 openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

如上示例，引入了一個pre_master.yml，包括了以下任務：

  1 ---
  2 - name: note the start of a master upgrade
  3 debug:
  4 msg: "Master upgrade of {{ inventory_hostname }} is about to start"
  5 - name: require an operator agree to start an upgrade pause:
  6 prompt: "Hit enter to start the master upgrade"

3.8 驗證升級

升級完成后，應該執行以下步驟以確保升級成功。

  1 [root@demo ~]# oc get nodes		#驗證node處於ready
  2 [root@demo ~]# oc get -n default dc/docker-registry -o json | grep \"image\"
  3 #驗證倉庫版本
  4 [root@demo ~]# oc get -n default dc/router -o json | grep \"image\
  5 #驗證image版本
  6 [root@demo ~]# oc adm diagnostics	#使用診斷工具

3.9 升級步驟匯總

1. 確保在每個RHEL 7系統上都有atom-openshift-utils包的最新版本。
2. 如果使用自定義Docker倉庫，可以選擇將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變量。
3. 禁用所有節點上的swap。
4. 重新啟動所有主機，重啟之後，檢查升級。
5. 可選地：檢查Inventory文件中的節點選擇器。
6. 禁用3.7存儲庫，並在每個master主機和node節點主機上啟用3.8和3.9存儲庫。
7. 通過使用合適的Ansible劇本集，使用單個或多個階段策略進行更新。
8. 在清單文件中設置openshift_deployment_type=openshift-enterprise變量。

四 使用probes監視應用

4.1 OPENSHIFT探針介紹

OpenShift應用程序可能會因為臨時連接丟失、配置錯誤或應用程序錯誤等問題而異常。開發人員可以使用探針來監視他們的應用程序。探針是一種Kubernetes操作，它定期對正在運行的容器執行診斷。可以使用oc客戶端命令或OpenShift web控制台配置探針。

目前，可以使用兩種類型的探測:

• Liveness探針

Liveness探針確定在容器中運行的應用程序是否處於健康狀態。如果Liveness探針返回檢測到一個不健康的狀態，OpenShift將殺死pod並試圖重新部署它。開發人員可以通過配置template.spec.container.livenessprobe來設置Liveness探針。

• Readiness探針

Readiness探針確定容器是否準備好為請求服務，如果Readiness探針返回失敗狀態，OpenShift將從所有服務的端點刪除容器的IP地址。開發人員可以使用Readiness探針向OpenShift發出信號，即使容器正在運行，它也不應該從代理接收任何流量。開發人員可以通過配置template.spec.containers.readinessprobe來設置Readiness探針。

OpenShift為探測提供了許多超時選項，有五個選項控制支持如上兩個探針:

initialDelaySeconds：強制性的。確定容器啟動后，在開始探測之前要等待多長時間。

timeoutSeconds：強制性的確定等待探測完成所需的時間。如果超過這個時間，OpenShift容器平台會認為探測失敗。

periodSeconds：可選的，指定檢查的頻率。

successThreshold：可選的，指定探測失敗后被認為成功的最小連續成功數。

failureThreshold：可選的，指定探測器成功后被認為失敗的最小連續故障。

4.2 檢查應用程序健康

Readiness和liveness probes可以通過三種方式檢查應用程序的健康狀況：

HTTP檢查：當使用HTTP檢查時，OpenShift使用一個webhook來確定容器的健康狀況。如果HTTP響應代碼在200到399之間，則認為檢查成功。

示例：演示如何使用HTTP檢查方法實現readiness probe 。

  1 ...
  2 readinessProbe:
  3   httpGet:
  4     path: /health			#檢測的URL
  5     port: 8080				#端口
  6   initialDelaySeconds: 15		#在容器啟動后多久才能檢查其健康狀況
  7   timeoutSeconds: 1			#要等多久探測器才能完成
  8 ...

4.3 容器執行檢查

當使用容器執行檢查時，kubelet agent在容器內執行命令。退出狀態為0的檢查被認為是成功的。

示例：實現容器檢查。

  1 ...
  2 livenessProbe:
  3   exec:
  4     command:
  5     - cat
  6     - /tmp/health
  7   initialDelaySeconds: 15
  8   timeoutSeconds: 1
  9 ...

4.4 TCP Socket檢查

當使用TCP Socket檢查時，kubelet agent嘗試打開容器的socket。如果檢查能夠建立連接，則認為容器是健康的。

示例：使用TCP套接字檢查方法實現活動探測。

  1 ...
  2 livenessProbe:
  3   tcpSocket:
  4     port: 8080
  5   initialDelaySeconds: 15
  6   timeoutSeconds: 1
  7 ...

4.5 使用Web管理probes

開發人員可以使用OpenShift web控制台管理readiness和liveness探針。對於每個部署，探針管理都可以從Actions下拉列表中獲得。

對於每種探針類型，開發人員可以選擇該類型，例如HTTP GET、TCP套接字或命令，併為每種類型指定參數。web控制台還提供了刪除探針的選項。

web控制台還可以用於編輯定義部署配置的YAML文件。在創建探針之後，將一個新條目添加到DC的配置文件中。使用DC編輯器來檢查或編輯探針。實時編輯器允許編輯周期秒、成功閾值和失敗閾值選項。

五 使用探針監視應用程序實驗

5.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

5.2 本練習準備

  1 [student@workstation ~]$ lab probes setup

5.3 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc new-project probes
  4 [student@workstation ~]$ oc new-app --name=probes \
  5 http://services.lab.example.com/node-hello
  6 [student@workstation ~]$ oc status

  1 [student@workstation ~]$ oc get pods -w
  2 NAME             READY     STATUS      RESTARTS   AGE
  3 probes-1-build   0/1       Completed   0          1m
  4 probes-1-nqpwh   1/1       Running     0          12s

5.4 暴露服務

  1 [student@workstation ~]$ oc expose svc probes --hostname=probe.apps.lab.example.com
  2 [student@workstation ~]$ curl http://probe.apps.lab.example.com
  3 Hi! I am running on host -> probes-1-nqpwh

5.5 檢查服務

  1 [student@workstation ~]$ curl http://probe.apps.lab.example.com/health
  2 OK
  3 [student@workstation ~]$ curl http://probe.apps.lab.example.com/ready
  4 READY

5.6 創建readiness探針

使用Web控制台登錄。並創建readiness探針。

Add readiness probe

參考5.5存在的用於檢查健康的鏈接添加probe。

5.7 創建Liveness探針

使用Web控制台登錄。並創建Liveness探針。

參考5.5存在的用於檢查健康，特意使用healtz錯誤的值而不是health創建，從而測試相關報錯。這個錯誤將導致OpenShift認為pod不健康，這將觸發pod的重新部署。

提示：由於探針更新了部署配置，因此更改將觸發一個新的部署。

5.8 確認探測

通過單擊側欄上的Monitoring查看探測的實現。觀察事件面板的實時更新。此時將標記為不健康的條目，這表明liveness探針無法訪問/healtz資源。

view details查看詳情。

[student@workstation ~]$ oc get events –sort-by=’.metadata.creationTimestamp’ | grep ‘probe failed’ #查看probe失敗事件

5.9 修正probe

修正healtz為health。

5.10 再次確認

  1 [student@workstation ~]$ oc get events \
  2 --sort-by='.metadata.creationTimestamp'

#從終端重新運行oc get events命令，此時OpenShift在重新部署DC新版本，以及殺死舊pod。同時將不會有任何關於pod不健康的信息。

六 Web控制台使用

6.1 WEB控制台簡介

OpenShift web控制台是一個可以從web瀏覽器訪問的用戶界面。它是管理和監視應用程序的一種方便的方法。儘管命令行界面可以用於管理應用程序的生命周期，但是web控制台提供了額外的優勢，比如部署、pod、服務和其他資源的狀態，以及

關於系統範圍內事件的信息。

可使用Web查看基礎設施內的重要信息，包括:

• pod各種狀態；
• volume的可用性；
• 通過使用probes獲得應用程序的健康行；

登錄並選擇項目之後，web控制台將提供項目項目的概述。

1. 項目允許在授權訪問的項目之間切換。
2. Search Catalog：瀏覽image目錄。
3. Add to project：向項目添加新的資源和應用程序。可以從文件或現有項目導入資源。
4. Overview：提供當前項目的高級視圖。它显示service的名稱及其在項目中運行的相關pod。
5. Applications：提供對部署、pod、服務和路由的訪問。它還提供了對Stateful set的訪問，Kubernetes hat特性為pod提供了一個惟一的標識，用於管理部署的順序。
6. build：提供對構建和IS的訪問。
7. Resources：提供對配額管理和各種資源(如角色和端點)的訪問。
8. Storage：提供對持久卷和存儲請求的訪問。
9. Monitoring選項卡提供對構建、部署和pod日誌的訪問。它還提供了對項目中各種對象的事件通知的訪問。
10. Catalog選項卡提供對可用於部署應用程序包的模板的訪問。

6.2 使用HAWKULAR管理指標

Hawkular是一組用於監控環境的開源項目。它由各種組件組成，如Hawkular services、Hawkular Application Performance Management (APM)和Hawkular metrics。Hawkular可以通過Hawkular OpenShift代理在OpenShift集群中收集應用程序指標。通過在OpenShift集群中部署Hawkular，可以訪問各種指標，比如pod使用的內存、cpu數量和網絡使用情況。

在部署了Hawkular代理之後，web控制台可以查看各種pod的圖表了。

6.3 管理Deployments和Pods

·Actions按鈕可用於pod和部署，允許管理各種設置。例如，可以向部署添加存儲或健康檢查(包括準備就緒和活動探測)。該按鈕還允許訪問YAML編輯器，以便通過web控制台實時更新配置。

6.4 管理存儲

web控制台允許訪問存儲管理，可以使用該接口創建卷聲明，以使用向項目公開的卷。注意，該接口不能用於創建持久卷，因為只有管理員才能執行此任務。管理員創建持久性卷之後，可以使用web控制台創建請求。該接口支持使用選擇器和標籤屬性。

定義卷聲明之後，控制台將显示它所使用的持久性卷，這是由管理員定義的。、

七 Web控制台監控指標

7.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

同時安裝OpenShift Metrics，參考《008.OpenShift Metric應用》3.1

7.2 本練習準備

  1 [student@workstation ~]$ lab web-console setup

7.3 創建項目

  1 [student@workstation ~]$ oc login -u developer -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc new-project load
  4 [student@workstation ~]$ oc new-app --name=load http://services.lab.example.com/node-hello

7.4 ·暴露服務

  1 [student@workstation ~]$ oc expose svc load
  2 [student@workstation ~]$ oc get pod
  3 NAME           READY     STATUS    RESTARTS   AGE
  4 load-1-build   1/1       Running   0          48s

7.5 壓力測試

  1 [student@workstation ~]$ sudo yum install httpd-tools
  2 [student@workstation ~]$ ab -n 3000000 -c 20 \
  3 http://load-load.apps.lab.example.com/

7.6 控制台擴容pod

workstation節點上登錄控制填，並擴展應用。

查看概覽頁面，確保有一個pod在運行。單擊部署配置load #1，所显示的第一個圖，它對應於pod使用的內存。並指示pod使用了多少內存，突出显示第二張圖，該圖表示pods使用的cpu數量。突出显示第三個圖，它表示pod的網絡流量。

單擊pod視圖圈旁的向上指向的箭頭，將此應用程序的pod數量增加到兩個。

導航到應用程序→部署以訪問項目的部署

注意右側的Actions按鈕，單擊它並選擇Edit YAML來編輯部署配置。

檢查部署的YAML文件，確保replicas條目的值為2，該值與為該部署運行的pod的數量相匹配。

7.7 查看metric

單擊Metrics選項卡訪問項目的度量，可以看到應用程序的四個圖：使用的內存數量、使用的cpu數量、接收的網絡數據包數量和發送的網絡數據包數量。對於每個圖，有兩個圖，每個圖被分配到一個pod。

7.8 查看web控制監視

在側窗格中，單擊Monitoring以訪問Monitoring頁面。Pods部分下應該有兩個條目，deployment部分下應該有一個條目。

向下滾動以訪問部署，並單擊部署名稱旁邊的箭頭以打開框架。日誌下面應該有三個圖表：一個表示pod使用的內存數量，一個表示pod使用的cpu數量，一個表示pod發送和接收的網絡數據包。

7.9 創建PV

為應用程序創建PVC，此練習環境已經提供了聲明將綁定到的持久卷。

單擊Storage創建持久卷聲明，單擊Create Storage來定義聲明。輸入web-storage作為名稱。選擇Shared Access (RWX)作為訪問模式。輸入1作為大小，並將單元保留為GiB

單擊Create創建持久卷聲明。

7.10 嚮應用程序添加存儲

導航到應用程序——>部署來管理部署，單擊load條目以訪問部署。單擊部署的Actions，然後選擇Add Storage選項。此選項允許將現有的持久卷聲明添加到部署配置的模板中。選擇web-storage作為存儲聲明，輸入/web-storage作為掛載路徑，web-storage作為卷名。

7.11 檢查存儲

從deployment頁面中，單擊由(latest)指示的最新部署。等待兩個副本被標記為活動的。確保卷部分將卷web存儲作為持久卷。從底部的Pods部分中，選擇一個正在運行的Pods。單擊Terminal選項卡打開pod的外殼。

也可在任何一個pod中運行如下命令查看:

八 管理和監控OpenShift

8.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

8.2 本練習準備

  1 [student@workstation ~]$ lab review-monitor setup

8.3 創建項目

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com、
  2 [student@workstation ~]$ oc new-project load-review

8.4 創建limit range

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc project load-review
  3 [student@workstation ~]$ cat /home/student/DO280/labs/monitor-review/limits.yml
  4 apiVersion: "v1"
  5 kind: "LimitRange"
  6 metadata:
  7   name: "review-limits"
  8 spec:
  9   limits:
 10     - type: "Container"
 11       max:
 12         memory: "300Mi"
 13       default:
 14         memory: "200Mi"
 15 [student@workstation ~]$ oc create -f /home/student/DO280/labs/monitor-review/limits.yml
 16 [student@workstation ~]$ oc describe limitrange
 17 Name:       review-limits
 18 Namespace:  load-review
 19 Type        Resource  Min  Max    Default Request  Default Limit  Max Limit/Request Ratio
 20 ----        --------  ---  ---    ---------------  -------------  -----------------------
 21 Container   memory    -    300Mi  200Mi            200Mi          -

8.5 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ oc new-app --name=load http://services.lab.example.com/node-hello
  3 [student@workstation ~]$ oc get pods
  4 NAME           READY     STATUS      RESTARTS   AGE
  5 load-1-6szhm   1/1       Running     0          6s
  6 load-1-build   0/1       Completed   0          43s
  7 [student@workstation ~]$ oc describe pod load-1-6szhm

8.6 擴大資源請求

  1 [student@workstation ~]$ oc set resources dc load --requests=memory=350M
  2 [student@workstation ~]$ oc get events | grep Warning

結論：請求資源超過limit限制，則會出現如上告警。

  1 [student@workstation ~]$ oc set resources dc load --requests=memory=200Mi

8.7 創建ResourceQuota

  1 [student@workstation ~]$ oc status ; oc get pod

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ cat /home/student/DO280/labs/monitor-review/quotas.yml
  3 apiVersion: "v1"
  4 kind: "LimitRange"
  5 metadata:
  6   name: "review-limits"
  7 spec:
  8   limits:
  9     - type: "Container"
 10       max:
 11         memory: "300Mi"
 12       default:
 13         memory: "200Mi"
 14 [student@workstation ~]$ oc create -f /home/student/DO280/labs/monitor-review/quotas.yml
 15 [student@workstation ~]$ oc describe quota
 16 Name:            review-quotas
 17 Namespace:       load-review
 18 Resource         Used  Hard
 19 --------         ----  ----
 20 requests.memory  200M  600Mi   -

8.8 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ oc scale --replicas=4 dc load
  3 [student@workstation ~]$ oc get pods
  4 NAME           READY     STATUS      RESTARTS   AGE
  5 load-1-build   0/1       Completed   0          7m
  6 load-3-577fc   1/1       Running     0          5s
  7 load-3-nnncf   1/1       Running     0          4m
  8 load-3-nps4w   1/1       Running     0          5s
  9 [student@workstation ~]$  oc get events | grep Warning

結論：當前已應用配額規定會阻止創建第四個pod。

  1 [student@workstation ~]$ oc scale --replicas=1 dc load

8.9 暴露服務

  1 [student@workstation ~]$ oc expose svc load --hostname=load-review.apps.lab.example.com

8.10 創建探針

Web控制台創建。

Applications ——> Deployments ——> Actions ——> Edit Health Checks。

9.11 確認驗證

導航到Applications ——> Deployments，選擇應用程序的最新部署。

在Template部分中，找到以下條目：

  1 [student@workstation ~]$ lab review-monitor grade #腳本判斷結果
  2 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

前言：

　　俗話說的好工欲善其事必先利其器，Git分佈式版本控制系統是我們日常開發中不可或缺的。目前市面上比較流行的Git可視化管理工具有SourceTree、Github Desktop、TortoiseGit，綜合網上的一些文章分析和自己的日常開發實踐心得個人比較推薦開發者使用SourceTree，因為SourceTree同時支持Windows和Mac，並且界面十分的精美簡潔，大大的簡化了開發者與代碼庫之間的Git操作方式。該篇文章主要是對日常開發中使用SourceTree可視化管理工具的一些常用操作進行詳細講解。

SourceTree | Github Desktop | TortoiseGit 可視化管理工具對比：

  https://blog.csdn.net/hmllittlekoi/article/details/104504406/

SourceTree介紹和Atlassian賬號註冊和登錄教程：

https://www.cnblogs.com/Can-daydayup/p/13128511.html

連接Gitee or GitHub，獲取代碼:

注意：這裏介紹的是使用SSH協議獲取關聯遠程倉庫的代碼，大家也可以直接使用過HTTPS協議的方式直接輸入賬號密碼獲取關聯代碼！

全面概述Gitee和GitHub生成/添加SSH公鑰：

https://www.cnblogs.com/Can-daydayup/p/13063280.html

在SourceTree中添加SSH密鑰：

工具=>選擇：

   
添加SSH密鑰位置：C:\Users\xxxxx\.ssh\id_rsa.pub：

SSH客戶端選擇OpenSSH：

 

Clone對應託管平台倉庫（以Gitee為例）：

打開碼雲，找到自己需要Clone的倉庫！

 

 

SourceTree設置默認工作目錄：

　　由上面我們可以發現每次Clone克隆項目的時候，克隆下來的項目默認存儲位置都是在C盤，因此每次都需要我們去選擇項目存放的路徑，作為一個喜歡偷懶的人而言當然不喜歡這種方式啦，因此我們可以設置一個默認的項目存儲位置。

設置SourceTree默認項目目錄：

點擊工具=>選項=>一般=>找到項目目錄設置Clone項目默認存儲的位置  

SourceTree代碼提交：

1.首先切換到需要修改功能代碼所在的分支：

 

 

2.將修改的代碼提交到暫存區：

3.將暫存區中的代碼提交到本地代碼倉庫：

注意：多人同時開發項目的時候，不推薦默認選中立即推送變更到origin/develop，避免一些不必要的麻煩！

 4.代碼拉取更新本地代碼庫，並將代碼推送到遠程倉庫：

 
 勾選需要推送的分支，點擊推送到遠程分支：  
代碼成功推送到遠程代碼庫：

5.在Gitee中查看推送結果：

SourceTree分支切換，新建，合併：

1.分支切換：

雙擊切換：   單擊鼠標右鍵切換：

2.新建分支：

注意：在新建分支時，我們需要在哪個主分支的基礎上新建分支必須先要切換到對應的主分支才能到該主分支上創建分支，如下我們要在master分支上創建一個feature-0613分支：  

3.合併分支:

注意：在合併代碼之前我們都需要將需要合併的分支拉取到最新狀態（**避免覆蓋別人的代碼，或者丟失一些重要文件）!!!!!   在master分支上點擊右鍵，選擇合併feature-0613至當前分支即可進行合併:   分支合併成功：

SourceTree代碼衝突解決：

首先我們需要製造一個提交文件遇到衝突的情景：

在SoureceTree中在Clone一個新項目，命名為pingrixuexilianxi2，如下圖所示：

 

 

我們以項目中的【代碼合併衝突測試.txt】文件為例：   在pingrixuexilianxi2中添加內容，並提交到遠程代碼庫，添加的內容如下：   在pingrixuexilianxi中添加內容，提交代碼（不選擇立即推送變更到origin/master），拉取代碼即會遇到衝突：  

 

 

  衝突文件中的內容：  

直接打開衝突文件手動解決衝突：

由下面的衝突文件中的衝突內容我們了解到：

<<<<<<< HEAD
6月19日 pingrixuexilianxi添加了內容
=======
6月18日 pingrixuexilianxi2修改了這個文件哦
>>>>>>> a8284fd41903c54212d1105a6feb6c57292e07b5

  <<<<<<< HEAD到 =======裏面的【6月19日 pingrixuexilianxi添加了內容】是自己剛才的Commit提交的內容 =======到 >>>>>>> a8284fd41903c54212d1105a6feb6c57292e07b5裏面的【6月18日 pingrixuexilianxi2修改了這個文件哦】是遠程代碼庫更新的內容（即為pingrixuexilianxi2本地代碼庫推送修改內容）。   手動衝突解決方法：

　　根據項目需求刪除不需要的代碼就行了，假如都需要的話我們只需要把 <<<<<<< HEAD=======     >>>>>>> a8284fd41903c54212d1105a6feb6c57292e07b5都刪掉衝突就解決了（注意，在項目中最後這些符號都不能存在，否則可能會報異常）。

  最後將衝突文件標記為已解決，提交到遠程倉庫：  

採用外部文本文件對比工具Beyond Compare解決衝突:

SourceTree配置文本文件對比工具Beyond Compare:

工具=>選項=>比較：  

 

使用Beyond Compare解決衝突：

Beyond Compare使用技巧： 官方全面教程： https://www.beyondcompare.cc/jiqiao/   SourceTree打開外部和合併工具：

 

注意：第一次啟動Beynod Compare軟件需要一會時間，請耐心等待：
    Beynod Compare進行衝突合併：   點擊保存文件后關閉Beynod Compare工具，SourceTree中的衝突就解決了，在SourceTree中我們會發現多了一個 .orig 的文件。接着選中那個.orig文件，單擊右鍵 => 移除，最後我們推送到遠程代碼庫即可：  

Sourcetree中的基本名詞說明：

克隆/新建(clone)：從遠程倉庫URL加載創建一個與遠程倉庫一樣的本地倉庫。 提交(commit)：將暫存區文件上傳到本地代碼倉庫。
推送(push)：將本地倉庫同步至遠程倉庫，一般推送（push）前先拉取（pull）一次，確保一致（十分注意：這樣你才能達到和別人最新代碼同步的狀態，同時也能夠規避很多不必要的問題）。 拉取(pull)：從遠程倉庫獲取信息並同步至本地倉庫，並且自動執行合併（merge）操作（git pull=git fetch+git merge）。 獲取(fetch)：從遠程倉庫獲取信息並同步至本地倉庫。 分支(branch)：創建/修改/刪除分枝。 合併(merge)：將多個同名文件合併為一個文件，該文件包含多個同名文件的所有內容，相同內容抵消。 貯藏(git stash)：保存工作現場。 丟棄(Discard)：丟棄更改,恢復文件改動/重置所有改動,即將已暫存的文件丟回未暫存的文件。 標籤(tag)：給項目增添標籤。 工作流(Git Flow)：團隊工作時，每個人創建屬於自己的分枝（branch），確定無誤后提交到master分支。 終端(terminal)：可以輸入git命令行。 每次拉取和推送的時候不用每次輸入密碼的命令行：git config credential.helper osxkeychain sourcetree。 檢出(checkout)：切換不同分支。 添加（add）：添加文件到緩存區。 移除（remove）：移除文件至緩存區。 重置(reset)：回到最近添加(add)/提交(commit)狀態。

Git分佈式版本控制器常用命令和使用：

當然作為一個有逼格的程序員， 一些常用的命令我們還是需要了解和掌握的，詳情可參考我之前寫過的文章：

https://www.cnblogs.com/Can-daydayup/p/10134733.html

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

一：講故事

上一篇介紹的 6 個特性從園子里的反饋來看效果不錯，那這一篇就再帶來 6 個特性同大家一起欣賞。

二：特性分析

1. 像弱類型語言一樣解析 json

大家都知道弱類型的語言有很多，如: nodejs，python，php，它們有一個的地方就是處理json，不需要像 強類型語言 那樣還要給它配一個類，什麼意思呢？ 就拿下面的 json 說事。

{
  "DisplayName": "新一代算法模型",
  "CustomerType": 1,
  "Report": {
    "TotalCustomerCount": 1000,
    "TotalTradeCount": 50
  },
  "CustomerIDHash": [1,2,3,4,5]
}

這個 json 如果想灌到 C# 中處理，你就得給它定義一個適配的類，就如 初篇 的客戶算法模型類，所以這裏就有了一個需求，能不能不定義類也可以自由解析上面這串 json 呢？？？ 哈哈，當然是可以的， 反序列化成 Dictionary 即可，就拿提取 Report.TotalCustomerCount 和 CustomerIDHash 這兩個字段演示一下。

        static void Main(string[] args)
        {
            var json = @"{
                           'DisplayName': '新一代算法模型',
                           'CustomerType': 1,
                           'Report': {
                             'TotalCustomerCount': 1000,
                             'TotalTradeCount': 50
                           },
                           'CustomerIDHash': [1,2,3,4,5]
                         }";

            var dict = JsonConvert.DeserializeObject<Dictionary<object, object>>(json);

            var report = dict["Report"] as JObject;
            var totalCustomerCount = report["TotalCustomerCount"];

            Console.WriteLine($"totalCustomerCount={totalCustomerCount}");

            var arr = dict["CustomerIDHash"] as JArray;
            var list = arr.Select(m => m.Value<int>()).ToList();

            Console.WriteLine($"list={string.Join(",", list)}");
        }

2. 如何讓json中的枚舉保持更易讀的字符串型

這句話是什麼意思呢？ 默認情況下， SerializeObject 會將 Model 中的 Enum 變成數值型，大家都知道數值型語義性是非常差的，如下代碼所示：

    static void Main(string[] args)
    {
        var model = new ThreadModel() { ThreadStateEnum = System.Threading.ThreadState.Running };

        var json = JsonConvert.SerializeObject(model);

        Console.WriteLine(json);
    }

    class ThreadModel
    {
        public System.Threading.ThreadState ThreadStateEnum { get; set; }
    }

對吧，確實語義特別差，那能不能直接生成 Running 這種字符串形式呢？ 當然可以了。。。改造如下：

  var json = JsonConvert.SerializeObject(model, new StringEnumConverter());

這裏可能就有人鑽牛角尖了，能不能部分指定讓枚舉生成 string，其他的生成 int ，沒關係，這也難不倒我，哪裡使用就用 JsonConverter 標記哪裡。。。

        static void Main(string[] args)
        {
            var model = new ThreadModel()
            {
                ThreadStateEnum = System.Threading.ThreadState.Running,
                TaskStatusEnum = TaskStatus.RanToCompletion
            };

            var json = JsonConvert.SerializeObject(model);

            Console.WriteLine(json);
        }

        class ThreadModel
        {
            public System.Threading.ThreadState ThreadStateEnum { get; set; }

            [JsonConverter(typeof(StringEnumConverter))]
            public TaskStatus TaskStatusEnum { get; set; }
        }        

3. 格式化 json 中的時間類型

在 model 轉化成 json 的過程中，總少不了 時間類型，為了讓時間類型 可讀性更高，通常會 格式化為 YYYY年/MM月/dd日 ，那如何實現呢？ 很簡單撒，在 JsonConvert 中也是一個 枚舉 幫你搞定。。。

        static void Main(string[] args)
        {
            var json = JsonConvert.SerializeObject(new Order()
            {
                OrderTitle = "女裝大佬",
                Created = DateTime.Now
            }, new JsonSerializerSettings
            {
                DateFormatString = "yyyy年/MM月/dd日",
            });

            Console.WriteLine(json);
        }
        public class Order
        {
            public string OrderTitle { get; set; }
            public DateTime Created { get; set; }
        }   

對了，我記得很早的時候，C# 自帶了一個 JavaScriptSerializer, 也是用來進行 model 轉 json的，但是它會將 datetime 轉成 時間戳，而不是時間字符串形式，如果你因為特殊原因想通過 JsonConvert 將時間生成時間戳的話，也是可以的, 用 DateFormatHandling.MicrosoftDateFormat 枚舉指定一下即可，如下：

4. 對一些常用設置進行全局化

在之前所有演示的特性技巧中都是在 JsonConvert 上指定的，也就是說 100 個 JsonConvert 我就要指定 100 次，那有沒有類似一次指定，整個進程通用呢？ 這麼強大的 Newtonsoft 早就支持啦, 就拿上面的 Order 舉例：

        JsonConvert.DefaultSettings = () =>
        {
            var settings = new JsonSerializerSettings
            {
                Formatting = Formatting.Indented
            };
            return settings;
        };

        var order = new Order() { OrderTitle = "女裝大佬", Created = DateTime.Now };

        var json1 = JsonConvert.SerializeObject(order);
        var json2 = JsonConvert.SerializeObject(order);

        Console.WriteLine(json1);
        Console.WriteLine(json2);

可以看到，Formatting.Indented 對兩串 json 都生效了。

5. 如何保證 json 到 model 的嚴謹性 及提取 json 未知字段

有時候我們有這樣的需求，一旦 json 中出現 model 未知的字段，有兩種選擇： 要麼報錯，要麼提取出未知字段，在 Newtonsoft 中默認的情況是忽略，場景大家可以自己找哈。

• 未知字段報錯

        static void Main(string[] args)
        {
            var json = "{'OrderTitle':'女裝大佬', 'Created':'2020/6/23','Memo':'訂單備註'}";

            var order = JsonConvert.DeserializeObject<Order>(json, new JsonSerializerSettings
            {
                MissingMemberHandling = MissingMemberHandling.Error
            });

            Console.WriteLine(order);
        }

        public class Order
        {
            public string OrderTitle { get; set; }
            public DateTime Created { get; set; }
            public override string ToString()
            {
                return $"OrderTitle={OrderTitle}, Created={Created}";
            }
        }        

• 提取未知字段

我依稀的記得 WCF 在這種場景下也是使用一個 ExtenstionDataObject 來存儲客戶端傳過來的未知字段，有可能是客戶端的 model 已更新，server端還是舊版本，通常在 json 序列化中也會遇到這種情況，這裏只要使用 JsonExtensionData 特性就可以幫你搞定，在 OnDeserialized 這種AOP方法中進行攔截，如下代碼：

    static void Main(string[] args)
    {
        var json = "{'OrderTitle':'女裝大佬', 'Created':'2020/6/23','Memo':'訂單備註'}";

        var order = JsonConvert.DeserializeObject<Order>(json);

        Console.WriteLine(order);
    }

    public class Order
    {
        public string OrderTitle { get; set; }

        public DateTime Created { get; set; }

        [JsonExtensionData]
        private IDictionary<string, JToken> _additionalData;

        public Order()
        {
            _additionalData = new Dictionary<string, JToken>();
        }

        [OnDeserialized]
        private void OnDeserialized(StreamingContext context)
        {
            var dict = _additionalData;
        }

        public override string ToString()
        {
            return $"OrderTitle={OrderTitle}, Created={Created}";
        }
    }        

6. 開啟 JsonConvert 詳細日誌功能

有時候在查閱源碼的時候開啟日誌功能更加有利於理解源碼的內部運作，所以這也是一個非常實用的功能，看看如何配置吧。

        static void Main(string[] args)
        {
            var json = "{'OrderTitle':'女裝大佬', 'Created':'2020/6/23','Memo':'訂單備註'}";

            MemoryTraceWriter traceWriter = new MemoryTraceWriter();

            var account = JsonConvert.DeserializeObject<Order>(json, new JsonSerializerSettings
            {
                TraceWriter = traceWriter
            });

            Console.WriteLine(traceWriter.ToString());
        }

        public class Order
        {
            public string OrderTitle { get; set; }

            public DateTime Created { get; set; }

            public override string ToString()
            {
                return $"OrderTitle={OrderTitle}, Created={Created}";
            }
        }

三：總結

嘿嘿，這篇 6 個特性就算說完了， 結合上一篇一共 12 個特性，是不是非常簡單且實用，後面準備給大家帶來一些源碼解讀吧! 希望本篇對您有幫助，謝謝！

如您有更多問題與我互動，掃描下方進來吧~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

介紹

使用Spring Bboot是快樂並且簡單的，不需要繁瑣的配置就能夠完成一套非常強大的應用。

spring boot 2.3.1

Spring Boot 2.3.1 發佈於：2020/06/12，現在已經提交到 Spring 倉庫和 Maven 中央倉庫了。

這個版本包括 127 個 bug 修復、Spring Boot 文檔改進增強、依賴升級等，另外還新增了一些新特性：

•提供基於新的 Maven 坐標 com.oracle.database 對 Oracle JDBC driver 的依賴管理；

•優化 Spring Cloud 的 CachedRandomPropertySource 不能正確適配的問題；•限制使用定製的 YAML 類型；

•增強對 NoSuchMethodErrors 異常失敗分析，能显示基類從哪被加載的；•提供更佳的錯誤消息，如果 Docker 停止運行了；

•優化 SystemEnvironmentPropertyMapper 類；

•提供更佳的診斷信息，當構建 OCI 鏡像失敗時 Docker 響應的 500 錯誤；

•支持通過 alwaysUseFullPath=true 參數來配置 UrlPathHelper；•支持在 Elasticsearch URIs 中使用用戶信息；

•支持在 Spring WebFlux 框架中使用歡迎頁面；

這個小版本還增加了蠻多東西的，大家也沒有必要跟着版本走，可以根據需要進行升級。疫情也擋不住外國友人更新的熱情。

實現

使用STS，可以去官方網站下載最新版。網站地址 https://Spring.io/tools/sts/ Spring Tool Suite™是基於eclipse開發的專門為Spring開發使用的工具包。

新建工程

選擇Spring Starter Project，

輸入工程名 對應的Name 打包方式 對應的Packaging，可以選擇jar或者war的方式。

輸入組織名 對應的Group 輸入描述 對應的Description

輸入包名 對應的Package 點擊next，然後選擇web和mysql

這裏的版本用的是2.3.1 如果沒有本地maven庫或者私庫會下載很長時間。

添加默認請求

進入 Chapter0301Application 添加

@RestController
@SpringBootApplication
public class Chapter0301Application {
    
    @RequestMapping("/")
    String home() {
         return "歡迎使用Spring Boot!";
    }

    public static void main(String[] args) {
        SpringApplication.run(Chapter0301Application.class, args);
    }

}

使用@RestController 相當於@Controller 和 @RequestBody。是Sspring Bboot 基於Sspring MVC的基礎上進行了改進， 將@Controller 與@ResponseBody 進行了合併形成的一個新的註解。 @EnableAutoConfiguration 作用 從classpath中搜索所有META-INF/spring.factories配置文件然後，將其中org.springframework.boot.autoconfigure.EnableAutoConfiguration key對應的配置項加載到spring容器 只有spring.boot.enableautoconfiguration為true（默認為true）的時候，才啟用自動配置 @EnableAutoConfiguration還可以進行排除，排除方式有2種，一是根據class來排除（exclude），二是根據class name（excludeName）來排除 其內部實現的關鍵點有

1.ImportSelector 該接口的方法的返回值都會被納入到spring容器管理中

2.SpringFactoriesLoader 該類可以從classpath中搜索所有META-INF/spring.factories配置文件，並讀取配置

啟動spring boot

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.3.1.RELEASE)

2020-06-23 13:30:11.611  INFO 9916 --- [           main] com.cloud.sky.Chapter0301Application     : Starting Chapter0301Application on DADI-PC with PID 9916 (D:\java\microservice\chapter0301\target\classes started by Administrator in D:\java\microservice\chapter0301)
2020-06-23 13:30:11.614  INFO 9916 --- [           main] com.cloud.sky.Chapter0301Application     : No active profile set, falling back to default profiles: default
2020-06-23 13:30:12.415  INFO 9916 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2020-06-23 13:30:12.423  INFO 9916 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2020-06-23 13:30:12.424  INFO 9916 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.36]
2020-06-23 13:30:12.512  INFO 9916 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2020-06-23 13:30:12.512  INFO 9916 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 830 ms
2020-06-23 13:30:12.665  INFO 9916 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2020-06-23 13:30:12.809  INFO 9916 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-06-23 13:30:12.818  INFO 9916 --- [           main] com.cloud.sky.Chapter0301Application     : Started Chapter0301Application in 1.492 seconds (JVM running for 3.109)
2020-06-23 13:30:20.675  INFO 9916 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2020-06-23 13:30:20.676  INFO 9916 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2020-06-23 13:30:20.680  INFO 9916 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 4 ms

打開瀏覽器訪問 http://localhost:8080/ 可以得到如下頁面

遇到問題

構建的過程中遇到問題

[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-parseable POM D:\java\apache-maven-3.1.1\repo\org\jetbrains\kotlin\kotlin-bom\1.3.72\kotlin-bom-1.3.72.pom: entity reference names can not start with character ')' (position: START_TAG seen ...ost,s="";function qs(n){var u=D.URL;var t=u.match(eval(\'/(\\?|#|&)... @1:243)  @ D:\java\apache-maven-3.1.1\repo\org\jetbrains\kotlin\kotlin-bom\1.3.72\kotlin-bom-1.3.72.pom, line 1, column 243
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.cloudskyme:chapter0301:0.0.1 (D:\java\microservice\chapter0301\pom.xml) has 1 error
[ERROR]     Non-parseable POM D:\java\apache-maven-3.1.1\repo\org\jetbrains\kotlin\kotlin-bom\1.3.72\kotlin-bom-1.3.72.pom: entity reference names can not start with character ')' (position: START_TAG seen ...ost,s="";function qs(n){var u=D.URL;var t=u.match(eval(\'/(\\?|#|&)... @1:243)  @ D:\java\apache-maven-3.1.1\repo\org\jetbrains\kotlin\kotlin-bom\1.3.72\kotlin-bom-1.3.72.pom, line 1, column 243 -> [Help 2]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException

1. 解決

修改maven默認源配置
我使用的是阿里的maven倉庫，國外的東西沒個代理還真麻煩。

<repositories>
        <repository>  
            <id>alimaven</id>
            <name>aliyun maven</name>
            <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
        </repository> 
        <repository>
            <id>sonatype-nexus-snapshots</id>
            <url>https://oss.sonatype.org/content/repositories/snapshots</url>
            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>

然後執行 mvn help:system
成功可以看到如下界面：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

redis源碼分析系列文章

[Redis源碼系列]在Liunx安裝和常見API 

為什麼要從Redis源碼分析 

String底層實現——動態字符串SDS 

Redis的雙向鏈表一文全知道

面試官：說說Redis的Hash底層 我：……（來自閱文的面試題）

前言

hello，大家好，周五見了。前面幾周我們一起看了Redis底層數據結構，如動態字符串SDS，雙向鏈表Adlist，字典Dict，如果有對Redis常見的類型或底層數據結構不明白的請看上面傳送門。

今天我們來看下ZSET的底層架構，如果不知道ZSET是什麼的，可以看上面傳送門第一篇。簡單來說，ZSET是Redis提供的根據數據和分數來判斷其排名的數據結構。最常見的就是微信運動的排名，每個用戶對應自己的步數，每天晚上可以給出用戶的排名。

有小夥伴可能會想，如果是實現排名的話，各種排序方法都可以實現的，沒必要引入Redis的ZSET結構啊？

當然，如果是採用排序方法的話，是可以實現相同功能的，但是代碼裏面需要硬編碼，會添加工作量，還會提供代碼的Bug哦，哈哈哈。而且Redis的底層是C實現的，直接操作內存，速度也會比Java方法實現提升。

綜上，使用Redis的ZSET結構，好處多多。那話不多說，開始把。在正式開始之前，我們需要引入下跳躍表的概念，其是ZSET結構的底層實現。以下可能有點枯燥，我盡量說的簡單點哈。

什麼是跳躍表？

對於數據量大的鏈表結構，插入和刪除比較快，但是查詢速度卻很慢。那是因為無法直接獲取某個節點，需要從頭節點開始，藉助某個節點的next指針來獲取下一節點。即使數據是有序排放的，想要查詢某個數據，只能從頭到尾遍歷變量，查詢效率會很低，時間複雜度為O(n)。

如果我們需要快速查詢鏈表有啥辦法呢？有同學說用數組存放，但是如果不改數據結構呢？

我們可以先想想在有序數組結構中有二分法，每次將範圍都縮小一半，這樣查詢速度提升了很多，那麼在鏈表中能不能也使用這種思想。

這就到了今天講的主角——跳躍表。（一點也生硬的引出概念）

步驟一  新建有序單項鏈表

先看下圖有序單向鏈表，存放了1，2，3，4，5，6，7這7個元素。

步驟二 抽取二級索引節點

我們可以在鏈表中抽取部分節點，下圖抽取了1，3，5，7四個節點，也就是每兩個節點提取了一個節點到上級，抽取出來的叫做索引。

注意不是每次都能抽取到這麼完美，這其實就跟拋硬幣一樣，每個硬幣的正反兩面的概率是一樣的，都是1/2。當數據量小的時候，正反的概率可能差別較大。但是隨着數據量的加大，正反的概率越來越接近於1/2。類比過來是一個意思，每個節點的機會都是一樣的，要麼停留原級，要麼提取到上級，概率都是1/2。但是隨着節點數量的增加，抽取的節點越來越接近與1/2。

步驟三 抽取三級索引節點

我們可以在鏈表中抽取部分節點，下圖抽取了1，5兩個節點，也就是每兩個節點提取了一個節點到上級，抽取出來的叫做索引。

步驟四 類二分法查詢

我們假設要查找值為6的節點，先從三級索引開始，找到值為1的節點，發現比5小，根據值為1節點的next指針，找到值為5的節點，5後面沒有其他的三級索引啦。

於是順着往下找，到了二級索引，根據值為5的節點的next指針找到值為7的節點，發現比6小，說明要找到的節點6在此範圍內。

再接着到了一級索引位置，根據值為5的節點next指針指向值為6的節點，發現是想要查詢的數據，所以查詢過程結束。

根據上面的查詢過程（下圖的藍色連線），我們發現其採用的核心思想是二分法，不斷縮小查詢範圍，如果在上層索引找到區間，則順延深入到下一層找到真正的數據。

總結

從上面的整個過程中可以看出，數據量小的時候，這種拿空間換時間，消耗內存方法的並不是最優解。所以Redis的zset結構在數據量小的時候採用壓縮表，數據量大的時候採用跳躍表。

像這種鏈表加多級索引的結構，就是跳躍表。這名字起的形象，過程是跳躍着來查詢的。

Redis中跳躍表圖解

下圖簡單來說是對跳躍表的改進和再封裝，首先引入了表頭的概念，這與雙向鏈表，字典結構一樣，都是對數據的封裝，因為他們都是採用的指針，而指針必然導致在計算長度，獲取最後節點的數據問題上會產生查詢太慢的性能問題，所以封裝表頭是為了在這些問題上提升速度，浪費的只是添加，刪除等操作的時間，與此對比，是可以忽略的。

其次是引入管理所有節點的層數數組，我們可以看到有32層，即32個數組，這和後面的數據節點結構是一樣的。引入它是為了便於直接根據此數組的層數定位到每個元素。

再其次是數據節點的每個level都有層級和span（也就是下圖箭頭指針上的数字，其是為了方便統計兩個節點相距多少長度）。

最後就是數據節點的後退指針backward，引入目的是Level數組只有前指針，即只能指向下一個節點地址，而後退指針是為了能往回找節點。

上圖主要分為3大塊：（這邊大致看下就行，下面將對各模塊進行代碼詳細解釋）

表頭

主要包括四個屬性，分別是頭指針header,尾指針tail,節點長度length,所有節點的最大level。

header：指向跳躍表的表頭節點，通過這個指針地址可以直接找到表頭，時間複雜度為O（1）。

tail：指向跳躍表的表尾節點，通過這個指針可以直接找到表尾，時間複雜度為O（1）。

length：記錄跳躍表的長度，即不包含表頭節點，整個跳躍表中有多少個元素。

level：記錄當前跳躍表內，所有節點層數最大的level（排除表頭節點）。

管理所有節點層數level的數組

其對象值為空，level數組為32層，目的是為了管理真正的數據節點。關於具體的level有哪些屬性放在數據節點來說。

數據節點

主要包括四個屬性對象值obj，分數score，後退指針backward和level數組。每個數據的Level數組有多少層，是隨機產生的，這跟上面說過的跳躍表是一樣的。

成員對象obj：真正的實際數據，每個節點的數據都是唯一的，但是節點的分數可能相同。兩個相同分數的節點是按照成員對象在字典中的大小進行排序的，成員對象較小的節點會排在前面，成員對象較大的節點會排在後面。

分數score:各個節點中的数字是節點所保存的分數，在跳躍表中，節點按各自所保存的分數從小到大排列。

後退指針backward:用於從表尾向表頭遍歷，每個節點只有一個後退指針，即每次只能後退一步。

層級level：節點中用1，2，3等字樣標記節點的各個層，L1代表第一層，L2代表第二層，L3代表第三層，並以此類推。

跳躍表的定義

表頭結構zskiplist

 

typedef struct zskiplist {
    //表頭的頭指針header和尾指針tail
    struct zskiplistNode *header, *tail;
    //一共有多少個節點length
    unsigned long length;
    // 所有節點最大的層級level
   int level;
} zskiplist;

具體數據節點zskiplistNode

 

//跳錶的具體節點 
typedef struct zskiplistNode {
    sds ele; //具體的數據，對應張三
    double score;//分數，對應70
    struct zskiplistNode *backward;//後退指針backward
     //層級數組    struct zskiplistLevel {
        struct zskiplistNode *forward;//前進指針forward
        unsigned int span;//跨度span
    } level[];
} zskiplistNode; 

 

跳躍表的實現（源碼分析）

redis關於跳躍表的API都定義在t_zset.c文件中。

千萬不要看到源碼分析就跑開了，一定要看哦。

創建跳躍表

創建空的跳躍表，其實就是創建表頭和管理所有的節點的level數組。首先，定義一些變量，嘗試分配內存空間。其次是初始化表頭的level和length，分別賦值1和0。接着創建管理所有節點的Level的數組，是調用zslCreateNode函數，輸入參數為數組大小宏常量ZSKIPLIST_MAXLEVEL（32），分數為0，對象值為NULL。(此為跳躍表得以實現重點)。再接着就是為此數組每個元素的前指針forword和跨度span初始化。最後初始化尾指針並返回值。

可以參照下面的圖解和源碼：

 

//創建一個空表頭的跳躍表
zskiplist *zslCreate(void) {
    int j;
    zskiplist *zsl;
    //嘗試分配內存空間
    zsl = zmalloc(sizeof(*zsl));
    //初始化level和length
    zsl->level = 1;
    zsl->length = 0;
    //調用下面的方法zslCreateNode,傳入的參數有數組長度ZSKIPLIST_MAXLEVEL 32
    //分數0，對象值NuLL
    //這一步就是創建管理所有節點的數組
    //並且設置表頭的頭頭指針為此對象的地址
    zsl->header = zslCreateNode(ZSKIPLIST_MAXLEVEL,0,NULL);
    //為這32個數組賦值前指針forward和跨度span
    for (j = 0; j < ZSKIPLIST_MAXLEVEL; j++) {
        zsl->header->level[j].forward = NULL;
        zsl->header->level[j].span = 0;
    }
    //設置尾指針
    zsl->header->backward = NULL;
    zsl->tail = NULL;
    //返回對象
    return zsl;
}
zskiplistNode *zslCreateNode(int level, double score, sds ele) {
    zskiplistNode *zn =
        zmalloc(sizeof(*zn)+level*sizeof(struct zskiplistLevel));
    zn->score = score;
    zn->ele = ele;
    return zn;
}

 

插入節點

比如有下圖6個元素，需要插入值為趙六，分數為101的元素，我們大致想一想，大致的步驟包括找到要插入的位置，新建一個數據節點，然後調整與之相關的頭尾指針的level數組。那就看看redis咋做的，和我們想的一樣不一樣呢？

噔噔噔噔，答案揭曉。當然了大框架是相同的。

正文開始了：（先來圖片）

1.遍歷管理所有節點的level數組，從最大的level開始，即3，挨個對比值，如果有分數比他大的值或者分數相同，但是數據的值比他大，記錄到數組裡面，同時記錄跨度。

這樣說太抽象了。拿上圖舉個例子，從表頭的level即3開始，首先到張三的L3，發現分數70，比目標分數101小跳過，根據其前指針找到趙六的L3,發現分數102，比目標分數101大，將趙六L3記錄在待更新數組update中，同時記錄跨度span為4。接着到下一層，張三的L2層，發現分數70比目標分數101小跳過，根據前指針找到王五的L2，發現分數90，比目標分數101小跳過，根據前指針找到趙六的L2，發現分數102比目標分數101大，將趙六的L2記錄到待更新數組update中，同時記錄跨度span為2。最後到下一層，張三的L1層，邏輯和剛才一樣的，也是記錄趙六的L1層和跨度span為1。

2.為新節點隨機生成層級數level（通過位運算），如果生成的level大於目前level最大值3，則將將大於部分挨個遍歷，並將跨度等信息記錄到上面update表中。

比如，新節點生成的level為5，目前level最大值為3，說明這個節點只會有一個，並且跨越了之前的所有節點，那麼我們將從第四層和第五層都遍歷下，記錄到待更新數組update中。

3.準備工作都做好了，找到了該節點將插入到哪一位置，處於哪一層，每層對應的跨度是多少，下面就要新增數據節點了。把上兩步的信息都添加到新節點上，並且調整位置前後指針即可。

4.最後就是一些收尾工作，比如修改表頭的層級level，節點大小length和尾指針tail等屬性。

綜上，整個流程就已經結束了。可能看着有點複雜，可以對照下面代碼來。

 

//插入節點，輸入參數為
//zsl:表頭
//score:插入元素的分數score
//ele:插入元素的具體數據ele
zskiplistNode *zslInsert(zskiplist *zsl, double score, sds ele) {
    //使用update數組記錄每層待插入元素的前一個元素
    zskiplistNode *update[ZSKIPLIST_MAXLEVEL], *x;
    //記錄前置節點與第一個節點之間的跨度，即元素在列表中的排名-1
    unsigned int rank[ZSKIPLIST_MAXLEVEL];
    int i, level;

    serverAssert(!isnan(score));
    x = zsl->header;
    //從最大的level開始遍歷，從頂到底，找到每一層待插入的位置
    for (i = zsl->level-1; i >= 0; i--) {
        /* store rank that is crossed to reach the insert position */
        rank[i] = i == (zsl->level-1) ? 0 : rank[i+1];
    //直接找到第一個分數比該元素大的位置
    //或者分數與該元素相同但是對象的ASSICC碼比該元素大的位置
        while (x->level[i].forward &&
                (x->level[i].forward->score < score ||
                    (x->level[i].forward->score == score &&
                    sdscmp(x->level[i].forward->ele,ele) < 0)))
        {
            //將已走過元素的跨越元素進行計數，得到元素在列表中排名，或者是已搜尋的路徑長度
            rank[i] += x->level[i].span;
            x = x->level[i].forward;
        }
    //記錄待插入位置
        update[i] = x;
    }
     //隨機產生一個層數，在1到32之間，層數越高，生成的概率越低
    level = zslRandomLevel();
    //如果產生的層數大於現有的最高層數，則超出層數都需要初始化
    if (level > zsl->level) {
        //開始循環
        for (i = zsl->level; i < level; i++) {
            rank[i] = 0;
            //該元素作為這些層的第一個節點，前節點就是header
            update[i] = zsl->header;
            //初始化后這些層每層有兩個元素，走一步就是跨越所有元素
            update[i]->level[i].span = zsl->length;
        }
        zsl->level = level;
    }
    //創建節點
    x = zslCreateNode(level,score,ele);
    for (i = 0; i < level; i++) {
        //將新節點插入到各層鏈表中
        x->level[i].forward = update[i]->level[i].forward;
        update[i]->level[i].forward = x;

        // rank[0]是第0層的前置節點P1（也就是底層插入節點前面那個節點）與第一個節點的跨度
        // rank[i]是第i層的前置節點P2（這一層里在插入節點前面那個節點）與第一個節點的跨度
        // 插入節點X與後置節點Y的跨度f(X,Y)可由以下公式計算
        // 關鍵在於f(P1,0)-f(P2,0)+1等於新節點與P2的跨度，這是因為跨度呈扇形形向下延伸到最底層
        // 記錄節點各層跨越元素情況span, 由層與層之間的跨越元素總和rank相減而得
        x->level[i].span = update[i]->level[i].span - (rank[0] - rank[i]);
               // 插入位置前一個節點的span在原基礎上加1即可(新節點在rank[0]的后一個位置)

 update[i]->level[i].span = (rank[0] - rank[i]) + 1;
    }

    /* increment span for untouched levels */
    for (i = level; i < zsl->level; i++) {
        update[i]->level[i].span++;
    }
    // 第0層是雙向鏈表, 便於redis常支持逆序類查找
    x->backward = (update[0] == zsl->header) ? NULL : update[0];
    if (x->level[0].forward)
        x->level[0].forward->backward = x;
    else
        zsl->tail = x;
    zsl->length++;
    return x;
}

 

int zslRandomLevel(void) {
    int level = 1;
    while ((random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
        level += 1;
    return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}

 

獲取節點排名

擔心大家忘了這張圖，再粘貼一遍。如下圖，這部分邏輯比較簡單，就不寫了，具體參考代碼分析。

 

//得到節點的排名
//輸入參數為表頭結構zsl，分數score，真正的數據ele
unsigned long zslGetRank(zskiplist *zsl, double score, sds ele) {
    zskiplistNode *x;
    unsigned long rank = 0;
    int i;
    //先獲取表頭的頭指針，即找到管理所有節點的level數組
    x = zsl->header;
     //從表頭的level，即最大值開始循環遍歷
    for (i = zsl->level-1; i >= 0; i--) {
        //如果找到分數小於目標分數的，排名加上其跨度
        //或者分數相同，但是具體數據小於目標數據的，排名也加上跨度
        while (x->level[i].forward &&
            (x->level[i].forward->score < score ||
                (x->level[i].forward->score == score &&
                sdscmp(x->level[i].forward->ele,ele) <= 0))) {
            rank += x->level[i].span;
            x = x->level[i].forward;
        }

        //確保在第i層找到分值相同，且對象相同時才會返回排位值
        if (x->ele && sdscmp(x->ele,ele) == 0) {
            return rank;
        }
    }
    return 0;
}

 

結語

該篇主要講了Redis的ZSET數據類型的底層實現跳躍表，先從跳躍表是什麼，引出跳躍表的概念和數據結構，剖析了其主要組成部分，進而通過多幅過程圖解釋了Redis是如何設計跳躍表的，最後結合源碼對跳躍表進行描述，如創建過程，添加節點過程，獲取某個節點排名過程，中間穿插例子和過程圖。

如果覺得寫得還行，麻煩給個贊，您的認可才是我寫作的動力！

如果覺得有說的不對的地方，歡迎評論指出。

好了，拜拜咯。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?