kubernetes 存儲流程

来源:https://www.cnblogs.com/daemon365/p/18171790
-Advertisement-
Play Games

PV 與 PVC PVC (PersistentVolumeClaim)，命名空間（namespace）級別的資源，由 用戶 or StatefulSet 控制器（根據VolumeClaimTemplate） 創建。PVC 類似於 Pod，Pod 消耗 Node 資源，PVC 消耗 PV 資源。Po ...


PV 與 PVC

PVC (PersistentVolumeClaim)，命名空間（namespace）級別的資源，由 用戶 or StatefulSet 控制器（根據VolumeClaimTemplate） 創建。PVC 類似於 Pod，Pod 消耗 Node 資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和記憶體），而 PVC 可以請求特定存儲捲的大小及訪問模式（Access Mode
PV（PersistentVolume）是集群中的一塊存儲資源，可以是 NFS、iSCSI、Ceph、GlusterFS 等存儲捲，PV 由集群管理員創建，然後由開發者使用 PVC 來申請 PV，PVC 是對 PV 的申請，類似於 Pod 對 Node 的申請。

靜態創建存儲捲

也就是我們手動創建一個pv和pvc，然後將pv和pvc綁定，然後pod使用pvc，這樣就可以使用pv了。

創建一個 nfs 的 pv 以及 對應的 pvc

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  nfs:
    server: 192.168.203.110
    path: /data/nfs

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

查看 pvc

$ kubectl get pvc
NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Bound    nfs-pv   10Gi       RWO                           101s

創建一個 pod 使用 pvc

apiVersion: v1
kind: Pod
metadata:
  name: test-nfs
spec:
  containers:
  - image: ubuntu:22.04
    name: ubuntu
    command:
    - /bin/sh
    - -c
    - sleep 10000
    volumeMounts:
    - mountPath: /data
      name: nfs-volume
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: nfs-pvc

❯ kubectl exec -it test-nfs -- cat /data/nfs
192.168.203.110:/data/nfs

pvc pv 綁定流程

func (ctrl *PersistentVolumeController) syncUnboundClaim(ctx context.Context, claim *v1.PersistentVolumeClaim) error {
	logger := klog.FromContext(ctx)
	if claim.Spec.VolumeName == "" {
		// 是不是延遲綁定 也就是 VolumeBindingMode 為 WaitForFirstConsumer
		delayBinding, err := storagehelpers.IsDelayBindingMode(claim, ctrl.classLister)
		if err != nil {
			return err
		}
    // 通過 pvc 找到最合適的 pv
		volume, err := ctrl.volumes.findBestMatchForClaim(claim, delayBinding)
		if err != nil {
			logger.V(2).Info("Synchronizing unbound PersistentVolumeClaim, Error finding PV for claim", "PVC", klog.KObj(claim), "err", err)
			return fmt.Errorf("error finding PV for claim %q: %w", claimToClaimKey(claim), err)
		}
		if volume == nil {
			//// No PV found for this claim
		} else /* pv != nil */ {
			
			claimKey := claimToClaimKey(claim)
			logger.V(4).Info("Synchronizing unbound PersistentVolumeClaim, volume found", "PVC", klog.KObj(claim), "volumeName", volume.Name, "volumeStatus", getVolumeStatusForLogging(volume))
      // 綁定 pv 和 pvc
      // 這裡會處理 pvc 的 spec.volumeName status 和 pv 的 status
			if err = ctrl.bind(ctx, volume, claim); err != nil {
				return err
			}
			return nil
		}
	} else /* pvc.Spec.VolumeName != nil */ {
		/*
      ......
    */
	}
}

// 選擇
func FindMatchingVolume(
	claim *v1.PersistentVolumeClaim,
	volumes []*v1.PersistentVolume,
	node *v1.Node,
	excludedVolumes map[string]*v1.PersistentVolume,
	delayBinding bool) (*v1.PersistentVolume, error) {

	var smallestVolume *v1.PersistentVolume
	var smallestVolumeQty resource.Quantity
	requestedQty := claim.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)]
	requestedClass := GetPersistentVolumeClaimClass(claim)

	var selector labels.Selector
	if claim.Spec.Selector != nil {
		internalSelector, err := metav1.LabelSelectorAsSelector(claim.Spec.Selector)
		if err != nil {
			return nil, fmt.Errorf("error creating internal label selector for claim: %v: %v", claimToClaimKey(claim), err)
		}
		selector = internalSelector
	}

	// Go through all available volumes with two goals:
	// - find a volume that is either pre-bound by user or dynamically
	//   provisioned for this claim. Because of this we need to loop through
	//   all volumes.
	// - find the smallest matching one if there is no volume pre-bound to
	//   the claim.
	for _, volume := range volumes {
		if _, ok := excludedVolumes[volume.Name]; ok {
			// Skip volumes in the excluded list
			continue
		}
		if volume.Spec.ClaimRef != nil && !IsVolumeBoundToClaim(volume, claim) {
			continue
		}

		volumeQty := volume.Spec.Capacity[v1.ResourceStorage]
		if volumeQty.Cmp(requestedQty) < 0 {
			continue
		}
		// filter out mismatching volumeModes
		if CheckVolumeModeMismatches(&claim.Spec, &volume.Spec) {
			continue
		}

		// check if PV's DeletionTimeStamp is set, if so, skip this volume.
		if volume.ObjectMeta.DeletionTimestamp != nil {
			continue
		}

		nodeAffinityValid := true
		if node != nil {
			// Scheduler path, check that the PV NodeAffinity
			// is satisfied by the node
			// CheckNodeAffinity is the most expensive call in this loop.
			// We should check cheaper conditions first or consider optimizing this function.
			err := CheckNodeAffinity(volume, node.Labels)
			if err != nil {
				nodeAffinityValid = false
			}
		}

		if IsVolumeBoundToClaim(volume, claim) {
			// If PV node affinity is invalid, return no match.
			// This means the prebound PV (and therefore PVC)
			// is not suitable for this node.
			if !nodeAffinityValid {
				return nil, nil
			}

			return volume, nil
		}

		if node == nil && delayBinding {
			// PV controller does not bind this claim.
			// Scheduler will handle binding unbound volumes
			// Scheduler path will have node != nil
			continue
		}

		// filter out:
		// - volumes in non-available phase
		// - volumes whose labels don't match the claim's selector, if specified
		// - volumes in Class that is not requested
		// - volumes whose NodeAffinity does not match the node
		if volume.Status.Phase != v1.VolumeAvailable {
			// We ignore volumes in non-available phase, because volumes that
			// satisfies matching criteria will be updated to available, binding
			// them now has high chance of encountering unnecessary failures
			// due to API conflicts.
			continue
		} else if selector != nil && !selector.Matches(labels.Set(volume.Labels)) {
			continue
		}
		if GetPersistentVolumeClass(volume) != requestedClass {
			continue
		}
		if !nodeAffinityValid {
			continue
		}

		if node != nil {
			// Scheduler path
			// Check that the access modes match
			if !CheckAccessModes(claim, volume) {
				continue
			}
		}

		if smallestVolume == nil || smallestVolumeQty.Cmp(volumeQty) > 0 {
			smallestVolume = volume
			smallestVolumeQty = volumeQty
		}
	}

	if smallestVolume != nil {
		// Found a matching volume
		return smallestVolume, nil
	}

	return nil, nil
}

kubelet 綁定

if err := os.MkdirAll(dir, 0750); err != nil {
		return err
}
source := fmt.Sprintf("%s:%s", nfsMounter.server, nfsMounter.exportPath)
options := []string{}
if nfsMounter.readOnly {
  options = append(options, "ro")
}
mountOptions := util.JoinMountOptions(nfsMounter.mountOptions, options)
err = nfsMounter.mounter.MountSensitiveWithoutSystemd(source, dir, "nfs", mountOptions, nil)

kubelet 就會在調用 sudo mount -t nfs ... 命令把 nfs 綁定到主機上 綁定的目錄大概為 /var/lib/kubelet/pods/[POD-ID]/volumes/

StorageClass

StorageClass 是 Kubernetes 中用來定義存儲捲的類型的資源對象，StorageClass 用來定義存儲捲的類型，比如 NFS、iSCSI、Ceph、GlusterFS 等存儲捲。StorageClass 是集群級別的資源，由集群管理員創建，用戶可以使用 StorageClass 來動態創建 PV。

動態創建存儲捲

動態創建存儲捲相比靜態創建存儲捲，少了集群管理員的干預，流程如下圖所示：

創建一個 StorageClass pvc pod

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: rancher.io/local-path
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-local-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 128Mi
  storageClassName: local-storage
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: ubuntu:22.04
    name: ubuntu
    command:
    - /bin/sh
    - -c
    - sleep 10000
    volumeMounts:
    - mountPath: /data
      name: my-local-pvc
  volumes:
  - name: my-local-pvc
    persistentVolumeClaim:
      claimName: my-local-pvc

查看 pv

❯ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS    REASON   AGE
pvc-9d257d8a-29a8-4abf-a1e2-c7e4953fc0ca   128Mi      RWO            Delete           Bound    default/my-local-pvc   local-storage            85s

StorageClass 創建 pv 流程

// 還是 syncUnboundClaim 中
// volume 為空，說明沒有找到合適的 pv 那麼去檢查 如果 pvc 的 storageClassName 不為空，那麼就會去找到對應的 storageClass
if volume == nil {

			switch {
			case delayBinding && !storagehelpers.IsDelayBindingProvisioning(claim):
        // ......
			case storagehelpers.GetPersistentVolumeClaimClass(claim) != "":
				// 如果 pvc 的 storageClassName 不為空，那麼就會去找到對應的 storageClass
				if err = ctrl.provisionClaim(ctx, claim); err != nil {
					return err
				}
				return nil
			default:
			}
			return nil
}

func (ctrl *PersistentVolumeController) provisionClaim(ctx context.Context, claim *v1.PersistentVolumeClaim) error {
	plugin, storageClass, err := ctrl.findProvisionablePlugin(claim)
	ctrl.scheduleOperation(logger, opName, func() error {
		var err error
		if plugin == nil {
      // 如果是外部的 provisioner 這裡我們就安裝了 rancher.io/local-path 這個插件
      // 所以這裡會調用 provisionClaimOperationExternal
			_, err = ctrl.provisionClaimOperationExternal(ctx, claim, storageClass)
		} else {
      // 內部的 provisioner 直接處理
			_, err = ctrl.provisionClaimOperation(ctx, claim, plugin, storageClass)
		}
		return err
	})
	return nil
}

// 如果是外部的 provisioner 會在 pvc 的 annotations 加入 volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path 和 volume.kubernetes.io/storage-provisioner: rancher.io/local-path
func (ctrl *PersistentVolumeController) setClaimProvisioner(ctx context.Context, claim *v1.PersistentVolumeClaim, provisionerName string) (*v1.PersistentVolumeClaim, error) {
	if val, ok := claim.Annotations[storagehelpers.AnnStorageProvisioner]; ok && val == provisionerName {
		// annotation is already set, nothing to do
		return claim, nil
	}

	// The volume from method args can be pointing to watcher cache. We must not
	// modify these, therefore create a copy.
	claimClone := claim.DeepCopy()
	// TODO: remove the beta storage provisioner anno after the deprecation period
	logger := klog.FromContext(ctx)
	metav1.SetMetaDataAnnotation(&claimClone.ObjectMeta, storagehelpers.AnnBetaStorageProvisioner, provisionerName)
	metav1.SetMetaDataAnnotation(&claimClone.ObjectMeta, storagehelpers.AnnStorageProvisioner, provisionerName)
	updateMigrationAnnotations(logger, ctrl.csiMigratedPluginManager, ctrl.translator, claimClone.Annotations, true)
	newClaim, err := ctrl.kubeClient.CoreV1().PersistentVolumeClaims(claim.Namespace).Update(ctx, claimClone, metav1.UpdateOptions{})
	if err != nil {
		return newClaim, err
	}
	_, err = ctrl.storeClaimUpdate(logger, newClaim)
	if err != nil {
		return newClaim, err
	}
	return newClaim, nil
}

kubernetes external provisioner

kubernetes external provisioner 是一個獨立的進程，用來動態創建 PV，它通過監聽 StorageClass 的事件，當 StorageClass 的 ReclaimPolicy 為 Retain 時，會創建 PV。

在這裡我新建一個 關於 nfs 的 external provisioner

package main

import (
	"context"
	"fmt"
	"path/filepath"

	"github.com/golang/glog"
	v1 "k8s.io/api/core/v1"
	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
	"k8s.io/client-go/util/homedir"
	"sigs.k8s.io/controller-runtime/pkg/log"
	"sigs.k8s.io/sig-storage-lib-external-provisioner/v10/controller"
)

const provisionerName = "provisioner.test.com/nfs"

var _ controller.Provisioner = &nfsProvisioner{}

type nfsProvisioner struct {
	client kubernetes.Interface
}

func (p *nfsProvisioner) Provision(ctx context.Context, options controller.ProvisionOptions) (*v1.PersistentVolume, controller.ProvisioningState, error) {
	if options.PVC.Spec.Selector != nil {
		return nil, controller.ProvisioningFinished, fmt.Errorf("claim Selector is not supported")
	}
	glog.V(4).Infof("nfs provisioner: VolumeOptions %v", options)

	pv := &v1.PersistentVolume{
		ObjectMeta: metav1.ObjectMeta{
			Name: options.PVName,
		},
		Spec: v1.PersistentVolumeSpec{
			PersistentVolumeReclaimPolicy: *options.StorageClass.ReclaimPolicy,
			AccessModes:                   options.PVC.Spec.AccessModes,
			MountOptions:                  options.StorageClass.MountOptions,
			Capacity: v1.ResourceList{
				v1.ResourceName(v1.ResourceStorage): options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)],
			},
			PersistentVolumeSource: v1.PersistentVolumeSource{
				NFS: &v1.NFSVolumeSource{
					Server:   options.StorageClass.Parameters["server"],
					Path:     options.StorageClass.Parameters["path"],
					ReadOnly: options.StorageClass.Parameters["readOnly"] == "true",
				},
			},
		},
	}

	return pv, controller.ProvisioningFinished, nil
}

func (p *nfsProvisioner) Delete(ctx context.Context, volume *v1.PersistentVolume) error {
	// 因為是 nfs 沒有產生實際的資源，所以這裡不需要刪除
	// 如果在 provisioner 中創建了資源，那麼這裡需要刪除
	// 一般是調用 csi 創建/刪除資源
	return nil
}

func main() {
	l := log.FromContext(context.Background())
	config, err := clientcmd.BuildConfigFromFlags("", filepath.Join(homedir.HomeDir(), ".kube", "config"))
	if err != nil {
		glog.Fatalf("Failed to create kubeconfig: %v", err)
	}
	clientset, err := kubernetes.NewForConfig(config)
	if err != nil {
		glog.Fatalf("Failed to create client: %v", err)
	}

	clientNFSProvisioner := &nfsProvisioner{
		client: clientset,
	}

	pc := controller.NewProvisionController(l,
		clientset,
		provisionerName,
		clientNFSProvisioner,
		controller.LeaderElection(true),
	)
	glog.Info("Starting provision controller")
	pc.Run(context.Background())
}

創建一個 nfs 的 storageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-nfs
provisioner: provisioner.test.com/nfs
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  server: "192.168.203.110"
  path: /data/nfs
  readOnly: "false"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-nfs-pvc
spec:
  storageClassName: my-nfs
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

apiVersion: v1
kind: Pod
metadata:
  name: test-nfs
spec:
  containers:
  - image: ubuntu:22.04
    name: ubuntu
    command:
    - /bin/sh
    - -c
    - sleep 10000
    volumeMounts:
    - mountPath: /data
      name: my-nfs-pvc
  volumes:
  - name: my-nfs-pvc
    persistentVolumeClaim:
      claimName: my-nfs-pvc

❯ kubectl exec -it test-nfs -- cat /data/nfs
192.168.203.110:/data/nfs

CSI 流程

持久化存儲流程圖如下：

Provisioner

當部署 csi-controller 時 ，會啟動一個伴生容器，項目地址為 https://github.com/kubernetes-csi/external-provisioner 這個項目是一個 csi 的 provisioner
它會監控屬於自己的pvc，當有新的pvc創建時，會調用 csi 的 createVolume 方法，創建一個 volume，然後創建一個 pv。當 pvc 刪除時，會調用 csi 的 deleteVolume 方法，然後刪除 volume 和 pv。

Attacher

external-attacher 也是 csi-controller 的伴生容器，項目地址為 https://github.com/kubernetes-csi/external-attacher 這個項目是一個 csi 的 attacher, 它會監控 AttachDetachController 資源，當有新的資源創建時，會調用 csi 的 controllerPublishVolume 方法，掛載 volume 到 node 上。當資源刪除時，會調用 csi 的 controllerUnpublishVolume 方法，卸載 volume。

Snapshotter

external-snapshotter 也是 csi-controller 的伴生容器，項目地址為 https://github.com/kubernetes-csi/external-snapshotter 這個項目是一個 csi 的 snapshotter, 它會監控 VolumeSnapshot 資源，當有新的資源創建時，會調用 csi 的 createSnapshot 方法，創建一個快照。當資源刪除時，會調用 csi 的 deleteSnapshot 方法，刪除快照。

csi-node

csi-node 是一個 kubelet 的插件，所以它需要每個節點上都運行，當 pod 創建時，並且 VolumeAttachment 的 .spec.Attached 時，kubelet 會調用 csi 的 NodeStageVolume 函數，之後插件（csiAttacher）調用內部 in-tree CSI 插件（csiMountMgr）的 SetUp 函數，該函數內部會調用 csi 的 NodePublishVolume 函數，掛載 volume 到 pod 上。當 pod 刪除時，kubelet 觀察到包含 CSI 存儲捲的 Pod 被刪除，於是調用內部 in-tree CSI 插件（csiMountMgr）的 TearDown 函數，該函數內部會通過 unix domain socket 調用外部 CSI 插件的 NodeUnpublishVolume 函數。kubelet 調用內部 in-tree CSI 插件（csiAttacher）的 UnmountDevice 函數，該函數內部會通過 unix domain socket 調用外部 CSI 插件的 NodeUnstageVolume 函數。

csi-node-driver-registrar

這個是 csi-node 的伴生容器，項目地址為 https://github.com/kubernetes-csi/node-driver-registrar,
它的主要作用是向 kubelet 註冊 csi 插件，kubelet 會調用 csi 插件的 Probe 方法，如果返回成功，kubelet 會調用 csi 插件的 NodeGetInfo 方法，獲取節點信息。

csi-livenessprobe

這個是 csi-node 的伴生容器，項目地址為 https://github.com/kubernetes-csi/livenessprobe, 它的主要作用是給 kubernetes 的 livenessprobe 提供一個介面，用來檢查 csi 插件是否正常運行。它在 /healthz 時，會調用 csi 的 Probe 方法，如果返回成功，返回 200，否則返回 500。

Reference


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Vue列表過濾與排序
    一、介紹 Promise，譯為承諾，是非同步編程的一種解決方案，比傳統的解決方案（回調函數）更加合理和更加強大 在以往我們如果處理多層非同步操作，我們往往會像下麵那樣編寫我們的代碼 doSomething(function(result) { doSomethingElse(result, functi ...
  • Radash庫使用說明——數組方法篇（全）
    寫在前面 tips：點贊 + 收藏 = 學會！ 本文包含radash中數組相關的所有方法說明 + 使用示例 + 思維導圖查看 這邊會整理出一份數組相關方法的使用大綱（不含源碼解析），方便大家查閱使用； 作者會按照大類進行整理分享，本次也會同步給出Array所有方法的思維導圖； 所有方法整理完畢後，作 ...
  • 微信讀書助手迎來史詩級增強
    大家好,我前夕.最近,我分享了個人開發的微信讀書網頁插件,這個小項目意外收穫了眾多用戶的喜愛. 這讓我意識到技術作品能跨越專業界限,幫助到有需要的人.受此激勵,我決定對插件進行全面重構與優化 ...
  • 一款極簡的聊天應用
    大家好，我是 Java陳序員。 今天，給大家介紹一個開源的聊天應用程式，支持PC端和移動端。 關註微信公眾號：【Java陳序員】，獲取開源項目分享、AI副業分享、超200本經典電腦電子書籍等。 項目介紹 HasChat —— 一個基於 Vue3 + Socket.io 的聊天應用，同時支持PC端和 ...
  • Vue3+Ts i18n實現國際化
    一、什麼是雙向綁定 我們先從單向綁定切入單向綁定非常簡單，就是把Model綁定到View，當我們用JavaScript代碼更新Model時，View就會自動更新雙向綁定就很容易聯想到了，在單向綁定的基礎上，用戶更新了View，Model的數據也自動被更新了，這種情況就是雙向綁定舉個慄子 當用戶填寫表 ...
  • 無線模塊透明傳輸原理及過程解析
    透明傳輸，顧名思義，是指在傳輸過程中對外界完全透明，不需要關註傳輸過程以及傳輸協議，最終目的是要把傳輸的內容原封不動地傳遞給接收端，發送和接收的內容完全一致。在無線模塊中，透明傳輸通常是通過特定的技術和機制來實現的。 無線模塊透明傳輸的原理主要基於串口數據的透明傳輸。這種傳輸方式下，無線模塊被配置為 ...
  • 4.3萬字詳解PHP+RabbitMQ（AMQP協議、通訊架構、6大模式、交換機隊列消息持久化、死信隊列、延時隊列、消息丟失、重覆消費、消息應答、消息應答、發佈確認、故障轉移、不公平分發、優先順序、等）
    理論（後半部分有實操詳解） 哲學思考 易經思維：向各國人講述一種動物叫烏龜，要學很久的各國語言，但是隨手畫一個烏龜，全世界的人都能看得懂。 道家思維：努力沒有用（指勞神費心的機械性重覆、肢体受累、刻意行為），要用心（深度思考、去感悟、透過現象看本質）才有用。 舉例：類似中學做不出來的幾何題的底層原理 ...
  • JAVA也能用上Seq啦
    前言 在.NET生態中，Serilog憑藉其強大的結構化日誌記錄功能和與Seq的無縫集成，已經成為許多開發者的首選日誌記錄工具。Seq作為一個日誌檢索和儀錶板工具，能夠將日誌中的插值轉換為結構化數據，極大地方便了開發者快速檢索日誌、定位問題併進行簡單的統計分析。這種便捷性讓人難以割捨。 背景 最近需 ...
一周排行
    -Advertisement-
    Play Games
  • .NET 6 Entity Framework Core Db First（1） 創建模型
    .Net8.0 Blazor Hybird 桌面端 (WPF/Winform) 實測可以完整運行在 win7sp1/win10/win11. 如果用其他工具打包,還可以運行在mac/linux下, 傳送門BlazorHybrid 發佈為無依賴包方式 安裝 WebView2Runtime 1.57 M ...
  • 資料庫升級PostgreSql+Garnet
    目錄前言PostgreSql安裝測試額外Nuget安裝Person.cs模擬運行Navicate連postgresql解決方案Garnet為什麼要選擇Garnet而不是RedisRedis不再開源Windows版的Redis是由微軟維護的Windows Redis版本老舊，後續可能不再更新Garne ...
  • 如何基於surging架設流媒體視頻推流（視頻講解）
    C#TMS系統代碼-聯表報表學習 領導被裁了之後很快就有人上任了，幾乎是無縫銜接，很難讓我不想到這早就決定好了。我的職責沒有任何變化。感受下來這個系統封裝程度很高，我只要會調用方法就行。這個系統交付之後不會有太多問題，更多應該是做小需求，有大的開發任務應該也是第二期的事，嗯？怎麼感覺我變成運維了？而 ...
  • EAV模型（實體-屬性-值）的設計和低代碼的處理方案（2）--數據的查詢處理
    我在隨筆《EAV模型（實體-屬性-值）的設計和低代碼的處理方案（1）》中介紹了一些基本的EAV模型設計知識和基於Winform場景下低代碼（或者說無代碼）的一些實現思路，在本篇隨筆中，我們來分析一下這種針對通用業務，且只需定義就能構建業務模塊存儲和界面的解決方案，其中的數據查詢處理的操作。 ...
  • C# 程式集、模塊和類型概念及關係
    對某個遠程伺服器啟用和設置NTP服務(Windows系統) 打開註冊表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer 將 Enabled 的值設置為 1，這將啟用NTP伺服器功 ...
  • Django信號與擴展：深入理解與實踐
    title: Django信號與擴展：深入理解與實踐 date: 2024/5/15 22:40:52 updated: 2024/5/15 22:40:52 categories: 後端開發 tags: Django 信號 松耦合 觀察者 擴展 安全 性能 第一部分：Django信號基礎 Djan ...
  • Django3.2安裝源碼xadmin2步驟以及遇到的問題
    使用xadmin2遇到的問題&解決 環境配置： 使用的模塊版本： 關聯的包 Django 3.2.15 mysqlclient 2.2.4 xadmin 2.0.1 django-crispy-forms >= 1.6.0 django-import-export >= 0.5.1 django-r ...
  • 原創->CommonsCollections1-DefaultMap鏈
    今天我打算整點兒不一樣的內容，通過之前學習的TransformerMap和LazyMap鏈，想搞點不一樣的，所以我關註了另外一條鏈DefaultedMap鏈，主要調用鏈為： 調用鏈詳細描述： ObjectInputStream.readObject() DefaultedMap.readObject ...
  • 05-應用級開發者 AI 時代破局點
    後端應用級開發者該如何擁抱 AI GC？就是在這樣的一個大的浪潮下，我們的傳統的應用級開發者。我們該如何選擇職業或者是如何去快速轉型，跟上這樣的一個行業的一個浪潮? 0 AI金字塔模型 越往上它的整個難度就是職業機會也好，或者說是整個的這個運作也好,它的難度會越大,然後越往下機會就會越多,所以這是一 ...
  • Java面試題：讓依賴註入變得簡單，面對@Autowired和@Resource，該如何選擇？
    @Autowired是Spring框架提供的註解，@Resource是Java EE 5規範提供的註解。 @Autowired預設按照類型自動裝配，而@Resource預設按照名稱自動裝配。 @Autowired支持@Qualifier註解來指定裝配哪一個具有相同類型的bean，而@Resourc... ...
所有分類