etcd/raft選舉源碼解讀

来源:https://www.cnblogs.com/lt6668964/archive/2023/04/08/17298416.html
-Advertisement-
Play Games

一、為什麼要確定付費客戶特征？ 先講個案例，以 Shopify 網站為例進行分析。該網站提供了許多功能，圍繞著潛在客戶在全生命周期中所需的業務需求，包括從創建業務開始、賺取收益等整個閉環鏈上所需的任何工具，如： 開始做生意：Business name generator 線上工具、功能變數名稱選擇頁面、Bu ...


ETCD-raft筆記

0. 引言

該篇博客基於etcd v3.5.7版本，首先會簡單介紹etcd/raft對Raft選舉部分的演算法優化，然後通過源碼分析etcd/raft的選舉實現。

1. etcd對於raft選舉演算法優化措施

該優化措施均在raft博士論文中有講解

etcd/raft實現的與選舉有關的優化有Pre-Vote、Check Quorum、和Leader Lease。在這三種優化中，只有Pre-Vote和Leader Lease最初是對選舉過程的優化，Check Quorum是為了更高效地實現線性一致性讀（Linearizable Read）而做出的優化，但是由於Leader Lease需要依賴Check Quorum，因此也放在這講。

1.1 Pre-Vote

如下圖所示，當Raft集群的網路發生分區時，會出現節點數達不到quorum（達成共識至少需要的節點數）的分區，如圖中的Partition 1。

網路分區示意圖

在節點數能夠達到quorum的分區中，選舉流程會正常進行，該分區中的所有節點的term最終會穩定為新選舉出的leader節點的term。不幸的是，在節點數無法達到quorum的分區中，如果該分區中沒有leader節點，因為節點總是無法收到數量達到quorum的投票而不會選舉出新的leader，所以該分區中的節點在election timeout超時後，會增大term併發起下一輪選舉，這導致該分區中的節點的term會不斷增大。

如果網路一直沒有恢復，這是沒有問題的。但是，如果網路分區恢復，此時，達不到quorum的分區中的節點的term值會遠大於能夠達到quorum的分區中的節點的term，這會導致能夠達到quorum的分區的leader退位（step down）並增大自己的term到更大的term，使集群產生一輪不必要的選舉。

Pre-Vote機制就是為瞭解決這一問題而設計的，其解決的思路在於不允許達不到quorum的分區正常進入投票流程，也就避免了其term號的增大。為此，Pre-Vote引入了“預投票”，也就是說，當節點election timeout超時時，它們不會立即增大自身的term並請求投票，而是先發起一輪預投票。收到預投票請求的節點不會退位。只有當節點收到了達到quorum的預投票響應時，節點才能增大自身term號併發起投票請求。這樣，達不到quorum的分區中的節點永遠無法增大term，也就不會在分區恢復後引起不必要的一輪投票。

1.2 Check Quorum

在Raft演算法中，保證線性一致性讀取的最簡單的方式，就是講讀請求同樣當做一條Raft提議，通過與其它日誌相同的方式執行，因此這種方式也叫作Log Read。顯然，Log Read的性能很差。而在很多系統中，讀多寫少的負載是很常見的場景。因此，為了提高讀取的性能，就要試圖繞過日誌機制。

但是，直接繞過日誌機制從leader讀取，可能會讀到陳舊的數據，也就是說存在stale read的問題。在下圖的場景中，假設網路分區前，Node 5是整個集群的leader。在網路發生分區後，Partition 0分區中選舉出了新leader，也就是圖中的Node 1。

stale read示意圖

但是，由於網路分區，Node 5無法收到Partition 0中節點的消息，Node 5不會意識到集群中出現了新的leader。此時，雖然它不能成功地完成日誌提交，但是如果讀取時繞過了日誌，它還是能夠提供讀取服務的。這會導致連接到Node 5的client讀取到陳舊的數據。

Check Quorum可以減輕這一問題帶來的影響，其機制也非常簡單：讓leader每隔一段時間主動地檢查follower是否活躍。如果活躍的follower數量達不到quorum，那麼說明該leader可能是分區前的舊leader，所以此時該leader會主動退位轉為follower。

需要註意的是，Check Quorum並不能完全避免stale read的發生，只能減小其發生時間，降低影響。如果需要嚴格的線性一致性，需要通過其它機制實現。

1.3 Leader Lease

分散式系統中的網路環境十分複雜，有時可能出現網路不完全分區的情況，即整個整個網路拓補圖是一個連通圖，但是可能並非任意的兩個節點都能互相訪問。

不完全分區示意圖

這種現象不止會出現在網路故障中，還會出現在成員變更中。在通過ConfChange移除節點時，不同節點應用該ConfChange的時間可能不同，這也可能導致這一現象發生——TODO （舉個例子）。

在上圖的場景下，Node 1與Node 2之間無法通信。如果它們之間的通信中斷前，Node 1是集群的leader，在通信中斷後，Node 2無法再收到來自Node 1的心跳。因此，Node 2會開始選舉。如果在Node 2發起選舉前，Node 1和Node 3中都沒有新的日誌，那麼Node 2仍可以收到能達到quorum的投票（來自Node 2本身的投票和來自Node 3的投票），併成為leader。

Leader Lease機制對投票引入了一條新的約束以解決這一問題：當節點在election timeout超時前，如果收到了leader的消息，那麼它不會為其它發起投票或預投票請求的節點投票。也就是說，Leader Lease機制會阻止了正常工作的集群中的節點給其它節點投票。

Leader Lease需要依賴Check Quorum機制才能正常工作。接下來筆者通過一個例子說明其原因。

假如在一個5個節點組成的Raft集群中，出現了下圖中的分區情況：Node 1與Node 2互通，Node 3、Node 4、Node 5之間兩兩互通、Node 5與任一節點不通。在網路分區前，Node 1是集群的leader。

一種可能的網路分區示意圖

在既沒有Leader Lease也沒有Check Quorum的情況下，Node 3、Node 4會因收不到leader的心跳而發起投票，因為Node 2、Node 3、Node 4互通，該分區節點數能達到quorum，因此它們可以選舉出新的leader。

而在使用了Leader Lease而不使用Check Quorum的情況下，由於Node 2仍能夠收到原leader Node 1的心跳，受Leader Lease機制的約束，它不會為其它節點投票。這會導致即使整個集群中存在可用節點數達到quorum的分區，但是集群仍無法正常工作。

而如果同時使用了Leader Lease和Check Quorum，那麼在上圖的情況下，Node 1會在election timeout超時後因檢測不到數量達到quorum的活躍節點而退位為follower。這樣，Node 2、Node 3、Node 4之間的選舉可以正常進行。

1.4 引入的新問題與解決方案

引入Pre-Vote和Check Quorum（etcd/raft的實現中，開啟Check Quorum會自動開啟Leader Lease）會為Raft演算法引入一些新的問題。

當一個節點收到了term比自己低的消息時，原本的邏輯是直接忽略該消息，因為term比自己低的消息僅可能是因網路延遲的遲到的舊消息。然而，開啟了這些機制後，在如下的場景中會出現問題：

場景1示意圖

場景1： 如上圖所示，在開啟了Check Quorum / Leader Lease後（假設沒有開啟Pre-Vote，Pre-Vote的問題在下一場景中討論），數量達不到quorum的分區中的leader會退位，且該分區中的節點永遠都無法選舉出leader，因此該分區的節點的term會不斷增大。當該分區與整個集群的網路恢復後，由於開啟了Check Quorum / Leader Lease，即使該分區中的節點有更大的term，由於原分區的節點工作正常，它們的選舉請求會被丟棄。同時，由於該節點的term比原分區的leader節點的term大，因此它會丟棄原分區的leader的請求。這樣，該節點永遠都無法重新加入集群，也無法當選新leader。（詳見issue #5451、issue #5468）。

場景2示意圖

場景2： Pre-Vote機制也有類似的問題。如上圖所示，假如發起預投票的節點，在預投票通過後正要發起正式投票的請求時出現網路分區。此時，該節點的term會高於原集群的term。而原集群因沒有收到真正的投票請求，不會更新term，繼續正常運行。在網路分區恢復後，原集群的term低於分區節點的term，但是日誌比分區節點更新。此時，該節點發起的預投票請求因沒有日誌落後會被丟棄，而原集群leader發給該節點的請求會因term比該節點小而被丟棄。同樣，該節點永遠都無法重新加入集群，也無法當選新leader。（詳見issue #8501、issue #8525）。

場景3： 在更複雜的情況中，比如，在變更配置時，開啟了原本沒有開啟的Pre-Vote機制。此時可能會出現與上一條類似的情況，即可能因term更高但是log更舊的節點的存在導致整個集群的死鎖，所有節點都無法預投票成功。這種情況比上一種情況更危險，上一種情況只有之前分區的節點無法加入集群，在這種情況下，整個集群都會不可用。（詳見issue #8501、issue #8525）。

為瞭解決以上問題，節點在收到term比自己低的請求時，需要做特殊的處理。處理邏輯也很簡單：

  1. 如果收到了term比當前節點term低的leader的消息，且集群開啟了Check Quorum / Leader Lease或Pre-Vote，那麼發送一條term為當前term的消息，令term低的節點成為follower。（針對場景1、場景2）
  2. 對於term比當前節點term低的預投票請求，無論是否開啟了Check Quorum / Leader Lease或Pre-Vote，都要通過一條term為當前term的消息，迫使其轉為follower並更新term。（針對場景3）

2. etcd中Raft選舉的實現

2.1 發起vote或pre-vote流程

2.1.1 Election timeout

在集群剛啟動時，所有節點的狀態都為 follower，等待超時觸發 leader election。超時時間由 Config 設置。etcd/raft 沒有用真實時間而是使用邏輯時鐘，當調用 tick 的次數超過指定次數時觸發超時事件。 對於 follower 和 candidate 而言，tick 中會判斷是否超時，若超時則會本地生成一個 MsgHup 類型的消息觸發 leader election:

// tickElection is run by followers and candidates after r.electionTimeout.
func (r *raft) tickElection() {
	r.electionElapsed++

	if r.promotable() && r.pastElectionTimeout() {
		r.electionElapsed = 0
		r.Step(pb.Message{From: r.id, Type: pb.MsgHup})
	}
}

2.1.2 MsgHup消息處理與hup方法

etcd/raft通過raft結構體的Step方法實現Raft狀態機的狀態轉移。Step 方法是消息處理的入口，不同 state 處理的消息不同且處理方式不同，所以有多個 step 方法:

  • raft.Step(): 消息處理的入口，做一些共性的檢查，如 term，或處理所有狀態都需要處理的消息。若需要更進一步處理，會根據狀態 調用下麵的方法:
    • raft.stepLeader(): leader 狀態的消息處理方法；
    • raft.stepFollower(): follower 狀態的消息處理方法；
    • raft.stepCandidate(): candidate 狀態的消息處理方法。
func (r *raft) Step(m pb.Message) error {
	// ... ...
	switch m.Type {
	case pb.MsgHup:
		if r.preVote {
			r.hup(campaignPreElection)
		} else {
			r.hup(campaignElection)
		}
	// ... ...
	}
	// ... ...
}

Step方法在處理MsgHup消息時，會根據當前配置中是否開啟了Pre-Vote機制，以不同的CampaignType調用hup方法。CampaignType是一種枚舉類型（go語言的枚舉實現方式），其可能值如下表所示。

值 描述
campaignPreElection 表示Pre-Vote的預選舉階段。
campaignElection 表示正常的選舉階段（僅超時選舉，不包括Leader Transfer）。
campaignTransfer 表示Leader Transfer階段。

接下來對hup的實現進行分析。

func (r *raft) hup(t CampaignType) {
	if r.state == StateLeader {
		r.logger.Debugf("%x ignoring MsgHup because already leader", r.id)
		return
	}

	if !r.promotable() {
		r.logger.Warningf("%x is unpromotable and can not campaign", r.id)
		return
	}
	ents, err := r.raftLog.slice(r.raftLog.applied+1, r.raftLog.committed+1, noLimit)
	if err != nil {
		r.logger.Panicf("unexpected error getting unapplied entries (%v)", err)
	}
	if n := numOfPendingConf(ents); n != 0 && r.raftLog.committed > r.raftLog.applied {
		r.logger.Warningf("%x cannot campaign at term %d since there are still %d pending configuration changes to apply", r.id, r.Term, n)
		return
	}

	r.logger.Infof("%x is starting a new election at term %d", r.id, r.Term)
	r.campaign(t)
}

// promotable indicates whether state machine can be promoted to leader,
// which is true when its own id is in progress list.
func (r *raft) promotable() bool {
	pr := r.prs.Progress[r.id]
	return pr != nil && !pr.IsLearner && !r.raftLog.hasPendingSnapshot()
}

總結當節點出現以下情況時不能發起選舉：

  1. 節點被移出集群
  2. 節點是learner
  3. 節點還有未保存到穩定存儲的snapshot
  4. 節點有還未被應用的集群配置變更ConfChange消息

2.1.3 campaign

官方註釋很詳細了，因此不多廢筆墨解釋

// campaign transitions the raft instance to candidate state. This must only be
// called after verifying that this is a legitimate transition.
func (r *raft) campaign(t CampaignType) {
    // 因為調用campaign的方法不止有hup，campaign方法首先還是會檢查promotable()是否為真。
	if !r.promotable() {
		// This path should not be hit (callers are supposed to check), but
		// better safe than sorry.
		r.logger.Warningf("%x is unpromotable; campaign() should have been called", r.id)
	}
	var term uint64
	var voteMsg pb.MessageType
	if t == campaignPreElection {
		r.becomePreCandidate()
		voteMsg = pb.MsgPreVote
		// PreVote RPCs are sent for the next term before we've incremented r.Term.
		term = r.Term + 1
	} else {
		r.becomeCandidate()
		voteMsg = pb.MsgVote
		term = r.Term
	}
	if _, _, res := r.poll(r.id, voteRespMsgType(voteMsg), true); res == quorum.VoteWon {
		// We won the election after voting for ourselves (which must mean that
		// this is a single-node cluster). Advance to the next state.
		if t == campaignPreElection {
			r.campaign(campaignElection)
		} else {
			r.becomeLeader()
		}
		return
	}
	var ids []uint64
	{
		//won't send requestVote to learners, beacause learners[] are not in incoming[] and outgoing[]
		idMap := r.prs.Voters.IDs()
		ids = make([]uint64, 0, len(idMap))
		for id := range idMap {
			ids = append(ids, id)
		}
		sort.Slice(ids, func(i, j int) bool { return ids[i] < ids[j] })
	}
	for _, id := range ids {
		if id == r.id {
			continue
		}
		r.logger.Infof("%x [logterm: %d, index: %d] sent %s request to %x at term %d",
			r.id, r.raftLog.lastTerm(), r.raftLog.lastIndex(), voteMsg, id, r.Term)

		var ctx []byte
		if t == campaignTransfer {
			ctx = []byte(t)
		}
		r.send(pb.Message{Term: term, To: id, Type: voteMsg, Index: r.raftLog.lastIndex(), LogTerm: r.raftLog.lastTerm(), Context: ctx})
	}
}

至此，該節點已向其他節點發送MsgVote或MsgPreVote消息

2.2 節點收到vote或pre-vote消息處理流程

處理vote或pre-vote消息都在Step方法內，不會進入各自的step方法，有效的MsgPreVote必須滿足其中一個條件（m.Term > r.Term）

官方註釋很詳細，簡單易理解，因此不多廢筆墨解釋

func (r *raft) Step(m pb.Message) error {
	// Handle the message term, which may result in our stepping down to a follower.
	switch {
	case m.Term == 0:
		// local message
	case m.Term > r.Term:
		if m.Type == pb.MsgVote || m.Type == pb.MsgPreVote {
			force := bytes.Equal(m.Context, []byte(campaignTransfer))
			inLease := r.checkQuorum && r.lead != None && r.electionElapsed < r.electionTimeout
			if !force && inLease {
				// If a server receives a RequestVote request within the minimum election timeout
				// of hearing from a current leader, it does not update its term or grant its vote
				return nil
			}
		}
		switch {
		case m.Type == pb.MsgPreVote:
			// Never change our term in response to a PreVote
		case m.Type == pb.MsgPreVoteResp && !m.Reject:
			// We send pre-vote requests with a term in our future. If the
			// pre-vote is granted, we will increment our term when we get a
			// quorum. If it is not, the term comes from the node that
			// rejected our vote so we should become a follower at the new
			// term.
		default:
			if m.Type == pb.MsgApp || m.Type == pb.MsgHeartbeat || m.Type == pb.MsgSnap {
				r.becomeFollower(m.Term, m.From)
			} else {
				r.becomeFollower(m.Term, None)
			}
		}

	case m.Term < r.Term:
        // ........
	}

	switch m.Type {
	case pb.MsgHup:
        // ........
	case pb.MsgVote, pb.MsgPreVote:
		// We can vote if this is a repeat of a vote we've already cast...
		canVote := r.Vote == m.From ||
			// ...we haven't voted and we don't think there's a leader yet in this term...
			(r.Vote == None && r.lead == None) ||
			// ...or this is a PreVote for a future term...
			(m.Type == pb.MsgPreVote && m.Term > r.Term)
		// ...and we believe the candidate is up to date.
		if canVote && r.raftLog.isUpToDate(m.Index, m.LogTerm) {
			// Note: it turns out that that learners must be allowed to cast votes.
			// This seems counter- intuitive but is necessary in the situation in which
			// a learner has been promoted (i.e. is now a voter) but has not learned
			// about this yet.
			// For example, consider a group in which id=1 is a learner and id=2 and
			// id=3 are voters. A configuration change promoting 1 can be committed on
			// the quorum `{2,3}` without the config change being appended to the
			// learner's log. If the leader (say 2) fails, there are de facto two
			// voters remaining. Only 3 can win an election (due to its log containing
			// all committed entries), but to do so it will need 1 to vote. But 1
			// considers itself a learner and will continue to do so until 3 has
			// stepped up as leader, replicates the conf change to 1, and 1 applies it.
			// Ultimately, by receiving a request to vote, the learner realizes that
			// the candidate believes it to be a voter, and that it should act
			// accordingly. The candidate's config may be stale, too; but in that case
			// it won't win the election, at least in the absence of the bug discussed
			// in:
			// https://github.com/etcd-io/etcd/issues/7625#issuecomment-488798263.

			// When responding to Msg{Pre,}Vote messages we include the term
			// from the message, not the local term. To see why, consider the
			// case where a single node was previously partitioned away and
			// it's local term is now out of date. If we include the local term
			// (recall that for pre-votes we don't update the local term), the
			// (pre-)campaigning node on the other end will proceed to ignore
			// the message (it ignores all out of date messages).
			// The term in the original message and current local term are the
			// same in the case of regular votes, but different for pre-votes.
			r.send(pb.Message{To: m.From, Term: m.Term, Type: voteRespMsgType(m.Type)})
			if m.Type == pb.MsgVote {
				// Only record real votes.
				r.electionElapsed = 0
				r.Vote = m.From
			}
		} else {
			r.send(pb.Message{To: m.From, Term: r.Term, Type: voteRespMsgType(m.Type), Reject: true})
		}

	default:
        // ...........
	}
	return nil
}

註意：節點同意投票消息帶的是m.Term，拒絕投票消息是r.Term，如果拒接MsgPreVote消息，那麼發送pre-vote消息的節點就變為

在r.Term的follower，在2.3.1節內體現

2.3 節點收到處理MsgPreVoteResp或MsgVoteResp消息流程

2.3.1 Step內處理

根據2.2節可以看到Step內有這樣一段代碼：在2.2節最後有解釋，官方也給了詳細註釋

		switch {
		case m.Type == pb.MsgPreVote:
			// Never change our term in response to a PreVote
		case m.Type == pb.MsgPreVoteResp && !m.Reject:
			// We send pre-vote requests with a term in our future. If the
			// pre-vote is granted, we will increment our term when we get a
			// quorum. If it is not, the term comes from the node that
			// rejected our vote so we should become a follower at the new
			// term.
		default:
			if m.Type == pb.MsgApp || m.Type == pb.MsgHeartbeat || m.Type == pb.MsgSnap {
				r.becomeFollower(m.Term, m.From)
			} else {
				r.becomeFollower(m.Term, None)
			}
		}

2.3.2 stepCandidate內處理

	case myVoteRespType:
		gr, rj, res := r.poll(m.From, m.Type, !m.Reject)
		r.logger.Infof("%x has received %d %s votes and %d vote rejections", r.id, gr, m.Type, rj)
		switch res {
		case quorum.VoteWon:
			if r.state == StatePreCandidate {
				r.campaign(campaignElection)
			} else {
				r.becomeLeader()
				r.bcastAppend()
			}
		case quorum.VoteLost:
			// pb.MsgPreVoteResp contains future term of pre-candidate
			// m.Term > r.Term; reuse r.Term
			r.becomeFollower(r.Term, None)
		}

如果預投票成功，則發起新一輪正式投票。如果正式投票成功，則轉為leader，接著後續操作

2.4 轉變領導者身份

2.4.1 becomeLeader()

func (r *raft) becomeLeader() {
	// TODO(xiangli) remove the panic when the raft implementation is stable
	if r.state == StateFollower {
		panic("invalid transition [follower -> leader]")
	}
	r.step = stepLeader
	r.reset(r.Term)
	r.tick = r.tickHeartbeat
	r.lead = r.id
	r.state = StateLeader
	// Followers enter replicate mode when they've been successfully probed
	// (perhaps after having received a snapshot as a result). The leader is
	// trivially in this state. Note that r.reset() has initialized this
	// progress with the last index already.
	r.prs.Progress[r.id].BecomeReplicate()

	// Conservatively set the pendingConfIndex to the last index in the
	// log. There may or may not be a pending config change, but it's
	// safe to delay any future proposals until we commit all our
	// pending log entries, and scanning the entire tail of the log
	// could be expensive.
	r.pendingConfIndex = r.raftLog.lastIndex()

	emptyEnt := pb.Entry{Data: nil}
	if !r.appendEntry(emptyEnt) {
		// This won't happen because we just called reset() above.
		r.logger.Panic("empty entry was dropped")
	}
	// As a special case, don't count the initial empty entry towards the
	// uncommitted log quota. This is because we want to preserve the
	// behavior of allowing one entry larger than quota if the current
	// usage is zero.
	r.reduceUncommittedSize([]pb.Entry{emptyEnt})
	r.logger.Infof("%x became leader at term %d", r.id, r.Term)
}

從candidate轉變為leader，需要在自己的log中append一條當前term的日誌，並廣播給其他節點


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

-Advertisement-
Play Games
更多相關文章
  • sip消息拆包原理及組包流程
    操作系統 ：CentOS 7.6_x64 freeswitch版本 ：1.10.9 sofia-sip版本： sofia-sip-1.13.14 freeswitch使用sip協議進行通信，當sip消息超過mtu時，會出現拆包的情況，這裡整理下sip消息拆包原理及組包流程。 一、拆包的原理 簡單來說 ...
  • Django筆記十九之manager用法介紹
    函數式語言特性：-迭代器和閉包 本章內容 閉包（closures） 迭代器（iterators) 優化改善 12 章的實例項目 討論閉包和迭代器的運行時性能 一、閉包（1）- 使用閉包創建抽象行為 什麼是閉包（closure） 閉包：可以捕獲其所在環境的匿名函數。 閉包： 是匿名函數 保存為變數、作 ...
  • 【演算法數據結構專題】「延時隊列演算法」史上手把手教你針對層級時間輪（TimingWheel）實現延時隊列的開發實戰落地（下）
    承接上文 承接上一篇文章【演算法數據結構專題】「延時隊列演算法」史上手把手教你針對層級時間輪（TimingWheel）實現延時隊列的開發實戰落地（上）】我們基本上對層級時間輪演算法的基本原理有了一定的認識，本章節就從落地的角度進行分析和介紹如何通過Java進行實現一個屬於我們自己的時間輪服務組件，最後，在 ...
  • java -- 異常處理、Collection、Iterator迭代器、泛型
    實現一個簡單的UDP通信程式，僅作為筆記使用 網路編程中有三要素：IP、埠號和通信協議，分別用來確定對方在互聯網上的地址、指定接受數據的軟體和確定數據在網路中傳輸的規則。 IP地址 IP地址分為IPv4地址和IPv6地址，這裡不做討論。 IPv4地址中分為公網地址(萬維網使用)和私有地址(區域網使 ...
  • python中shutil和shutil庫的用法
    第二章 線程管控 std::thread 簡介 構造和析構函數 /// 預設構造 /// 創建一個線程，什麼也不做 thread() noexcept; /// 帶參構造 /// 創建一個線程，以 A 為參數執行 F 函數 template <class Fn, class... Args> exp ...
  • Python 元編程
    作者：袁首京 原創文章，轉載時請保留此聲明，並給出原文連接。 元編程並不象它聽起來那麼時髦和新奇。常用的 decorator 就可以認為是一種元編程。簡單來說，元編程就是編寫操作代碼的代碼。 有點繞，是吧？彆著急，咱們一點一點來討論。 註意：本文中的代碼適用於 Python 3.3 及以上。 元類 ...
  • 《Flask Web 開髮指南 pt.2》
    哈嘍大家好，我是鹹魚 在《Flask Web 開髮指南 pt.1》中，鹹魚跟大家介紹了 Flask 的由來——誕生於一個愚人節玩笑，簡單介紹了一些關於 Flask 的概念，並且編寫了一個簡單的 Flask 程式 在編寫 Flask 程式的時候，你需要註意你的程式文件不要命名為 flask.py，建議 ...
  • Java-SPI機制詳解
    Java之SPI機制詳解 1: SPI機制簡介 SPI 全稱是 Service Provider Interface，是一種 JDK 內置的動態載入實現擴展點的機制，通過 SPI 技術我們可以動態獲取介面的實現類，不用自己來創建。這個不是什麼特別的技術，只是 一種設計理念。 2: SPI原理 Jav ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類