ES + Redis + MySQL,這個高可用架構設計太頂了!

来源:https://www.cnblogs.com/javastack/archive/2022/09/01/16646559.html
-Advertisement-
Play Games

文章來源:【公眾號:同程藝龍技術中心】 背景 會員系統是一種基礎系統,跟公司所有業務線的下單主流程密切相關。如果會員系統出故障,會導致用戶無法下單,影響範圍是全公司所有業務線。所以,會員系統必須保證高性能、高可用,提供穩定、高效的基礎服務。 隨著同程和藝龍兩家公司的合併,越來越多的系統需要打通同程 ...


文章來源:【公眾號:同程藝龍技術中心】

背景

會員系統是一種基礎系統,跟公司所有業務線的下單主流程密切相關。如果會員系統出故障,會導致用戶無法下單,影響範圍是全公司所有業務線。所以,會員系統必須保證高性能、高可用,提供穩定、高效的基礎服務。

隨著同程和藝龍兩家公司的合併,越來越多的系統需要打通同程 APP、藝龍 APP、同程微信小程式、藝龍微信小程式等多平臺會員體系。

例如微信小程式的交叉營銷,用戶買了一張火車票,此時想給他發酒店紅包,這就需要查詢該用戶的統一會員關係。

因為火車票用的是同程會員體系,酒店用的是藝龍會員體系,只有查到對應的藝龍會員卡號後,才能將紅包掛載到該會員賬號。

除了上述講的交叉營銷,還有許多場景需要查詢統一會員關係,例如訂單中心、會員等級、里程、紅包、常旅、實名,以及各類營銷活動等等。

所以,會員系統的請求量越來越大,併發量越來越高,今年清明小長假的秒併發 tps 甚至超過 2 萬多。

在如此大流量的衝擊下,會員系統是如何做到高性能和高可用的呢?這就是本文著重要講述的內容。

ES 高可用方案

| ES 雙中心主備集群架構

同程和藝龍兩家公司融合後,全平臺所有體系的會員總量是十多億。在這麼大的數據體量下,業務線的查詢維度也比較複雜。

有的業務線基於手機號,有的基於微信 unionid,也有的基於藝龍卡號等查詢會員信息。

這麼大的數據量,又有這麼多的查詢維度,基於此,我們選擇 ES 用來存儲統一會員關係。ES 集群在整個會員系統架構中非常重要,那麼如何保證 ES 的高可用呢?

首先我們知道,ES 集群本身就是保證高可用的,如下圖所示:

當 ES 集群有一個節點宕機了,會將其他節點對應的 Replica Shard 升級為 Primary Shard,繼續提供服務。

但即使是這樣,還遠遠不夠。例如 ES 集群都部署在機房 A,現在機房 A 突然斷電了,怎麼辦?

例如伺服器硬體故障,ES 集群大部分機器宕機了,怎麼辦?或者突然有個非常熱門的搶購秒殺活動,帶來了一波非常大的流量,直接把 ES 集群打死了,怎麼辦?面對這些情況,讓運維兄弟衝到機房去解決?

這個非常不現實,因為會員系統直接影響全公司所有業務線的下單主流程,故障恢復的時間必須非常短,如果需要運維兄弟人工介入,那這個時間就太長了,是絕對不能容忍的。

那 ES 的高可用如何做呢?我們的方案是 ES 雙中心主備集群架構。

我們有兩個機房,分別是機房 A 和機房 B。我們把 ES 主集群部署在機房 A,把 ES 備集群部署在機房 B。會員系統的讀寫都在 ES 主集群,通過 MQ 將數據同步到 ES 備集群。

此時,如果 ES 主集群崩了,通過統一配置,將會員系統的讀寫切到機房 B 的 ES 備集群上,這樣即使 ES 主集群掛了,也能在很短的時間內實現故障轉移,確保會員系統的穩定運行。

最後,等 ES 主集群故障恢復後,打開開關,將故障期間的數據同步到 ES 主集群,等數據同步一致後,再將會員系統的讀寫切到 ES 主集群。

| ES 流量隔離三集群架構

雙中心 ES 主備集群做到這一步,感覺應該沒啥大問題了,但去年的一次恐怖流量衝擊讓我們改變了想法。

那是一個節假日,某個業務上線了一個營銷活動,在用戶的一次請求中,迴圈 10 多次調用了會員系統,導致會員系統的 tps 暴漲,差點把 ES 集群打爆。

這件事讓我們後怕不已,它讓我們意識到,一定要對調用方進行優先順序分類,實施更精細的隔離、熔斷、降級、限流策略。

首先,我們梳理了所有調用方,分出兩大類請求類型:

  • 第一類是跟用戶的下單主流程密切相關的請求,這類請求非常重要,應該高優先順序保障。
  • 第二類是營銷活動相關的,這類請求有個特點,他們的請求量很大,tps 很高,但不影響下單主流程。

基於此,我們又構建了一個 ES 集群,專門用來應對高 tps 的營銷秒殺類請求,這樣就跟 ES 主集群隔離開來,不會因為某個營銷活動的流量衝擊而影響用戶的下單主流程。

如下圖所示:

| ES 集群深度優化提升

講完了 ES 的雙中心主備集群高可用架構,接下來我們深入講解一下 ES 主集群的優化工作。

有一段時間,我們特別痛苦,就是每到飯點,ES 集群就開始報警,搞得每次吃飯都心慌慌的,生怕 ES 集群一個扛不住,就全公司炸鍋了。

那為什麼一到飯點就報警呢?因為流量比較大, 導致 ES 線程數飆高,cpu 直往上竄,查詢耗時增加,並傳導給所有調用方,導致更大範圍的延時。那麼如何解決這個問題呢?

通過深入 ES 集群,我們發現了以下幾個問題:

  • ES 負載不合理,熱點問題嚴重。ES 主集群一共有幾十個節點,有的節點上部署的 shard 數偏多,有的節點部署的 shard 數很少,導致某些伺服器的負載很高,每到流量高峰期,就經常預警。
  • ES 線程池的大小設置得太高,導致 cpu 飆高。我們知道,設置 ES 的 threadpool,一般將線程數設置為伺服器的 cpu 核數,即使 ES 的查詢壓力很大,需要增加線程數,那最好也不要超過“cpu core * 3 / 2 + 1”。如果設置的線程數過多,會導致 cpu 在多個線程上下文之間頻繁來回切換,浪費大量 cpu 資源。
  • shard 分配的記憶體太大,100g,導致查詢變慢。我們知道,ES 的索引要合理分配 shard 數,要控制一個 shard 的記憶體大小在 50g 以內。如果一個 shard 分配的記憶體過大,會導致查詢變慢,耗時增加,嚴重拖累性能。
  • string 類型的欄位設置了雙欄位,既是 text,又是 keyword,導致存儲容量增大了一倍。會員信息的查詢不需要關聯度打分,直接根據 keyword 查詢就行,所以完全可以將 text 欄位去掉,這樣就能節省很大一部分存儲空間,提升性能。
  • ES 查詢,使用 filter,不使用 query。因為 query 會對搜索結果進行相關度算分,比較耗 cpu,而會員信息的查詢是不需要算分的,這部分的性能損耗完全可以避免。
  • 節約 ES 算力,將 ES 的搜索結果排序放在會員系統的 jvm 記憶體中進行。
  • 增加 routing key。我們知道,一次 ES 查詢,會將請求分發給所有 shard,等所有shard返回結果後再聚合數據,最後將結果返回給調用方。如果我們事先已經知道數據分佈在哪些 shard 上,那麼就可以減少大量不必要的請求,提升查詢性能。

經過以上優化,成果非常顯著,ES 集群的 cpu 大幅下降,查詢性能大幅提升。ES 集群的 cpu 使用率:

會員系統的介面耗時:

會員 Redis 緩存方案

一直以來,會員系統是不做緩存的,原因主要有兩個:

  • 第一個,前面講的 ES 集群性能很好,秒併發 3 萬多,99 線耗時 5 毫秒左右,已經足夠應付各種棘手的場景。
  • 第二個,有的業務對會員的綁定關係要求實時一致,而會員是一個發展了 10 多年的老系統,是一個由好多介面、好多系統組成的分散式系統。

所以,只要有一個介面沒有考慮到位,沒有及時去更新緩存,就會導致臟數據,進而引發一系列的問題。

例如:用戶在 APP 上看不到微信訂單、APP 和微信的會員等級、里程等沒合併、微信和 APP 無法交叉營銷等等。

那後來為什麼又要做緩存呢?是因為今年機票的盲盒活動,它帶來的瞬時併發太高了。雖然會員系統安然無恙,但還是有點心有餘悸,穩妥起見,最終還是決定實施緩存方案。

| ES 近一秒延時導致的 Redis 緩存數據不一致問題的解決方案

在做會員緩存方案的過程中,遇到一個 ES 引發的問題,該問題會導致緩存數據的不一致。

我們知道,ES 操作數據是近實時的,往 ES 新增一個 Document,此時立即去查,是查不到的,需要等待 1 秒後才能查詢到。

如下圖所示:

ES 的近實時機製為什麼會導致 Redis 緩存數據不一致呢?具體來講,假設一個用戶註銷了自己的 APP 賬號,此時需要更新 ES,刪除 APP 賬號和微信賬號的綁定關係。而 ES 的數據更新是近實時的,也就是說,1 秒後你才能查詢到更新後的數據。

而就在這 1 秒內,有個請求來查詢該用戶的會員綁定關係,它先到 Redis 緩存中查,發現沒有,然後到 ES 查,查到了,但查到的是更新前的舊數據。

最後,該請求把查詢到的舊數據更新到 Redis 緩存並返回。就這樣,1 秒後,ES 中該用戶的會員數據更新了,但 Redis 緩存的數據還是舊數據,導致了 Redis 緩存跟 ES 的數據不一致。

如下圖所示:

面對該問題,如何解決呢?我們的思路是,在更新 ES 數據時,加一個 2 秒的 Redis 分散式併發鎖,為了保證緩存數據的一致性,接著再刪除 Redis 中該會員的緩存數據。

如果此時有請求來查詢數據,先獲取分散式鎖,發現該會員 ID 已經上鎖了,說明 ES 剛剛更新的數據尚未生效,那麼此時查詢完數據後就不更新 Redis 緩存了,直接返回,這樣就避免了緩存數據的不一致問題。

如下圖所示:

上述方案,乍一看似乎沒什麼問題了,但仔細分析,還是有可能導致緩存數據的不一致。

例如,在更新請求加分散式鎖之前,恰好有一個查詢請求獲取分散式鎖,而此時是沒有鎖的,所以它可以繼續更新緩存。

但就在他更新緩存之前,線程 block 了,此時更新請求來了,加了分散式鎖,並刪除了緩存。當更新請求完成操作後,查詢請求的線程活過來了,此時它再執行更新緩存,就把臟數據寫到緩存中了。

發現沒有?主要的問題癥結就在於“刪除緩存”和“更新緩存”發生了併發衝突,只要將它們互斥,就能解決問題。

如下圖所示:

實施了緩存方案後,經統計,緩存命中率 90%+,極大緩解了 ES 的壓力,會員系統整體性能得到了很大提升。

| Redis 雙中心多集群架構

接下來,我們看一下如何保障 Redis 集群的高可用。

如下圖所示:

關於 Redis 集群的高可用,我們採用了雙中心多集群的模式。在機房 A 和機房 B 各部署一套 Redis 集群。

更新緩存數據時,雙寫,只有兩個機房的 Redis 集群都寫成功了,才返回成功。查詢緩存數據時,機房內就近查詢,降低延時。這樣,即使機房 A 整體故障,機房 B 還能提供完整的會員服務。

高可用會員主庫方案

上述講到,全平臺會員的綁定關係數據存在 ES,而會員的註冊明細數據存在關係型資料庫。

最早,會員使用的資料庫是 SqlServer,直到有一天,DBA 找到我們說,單台 SqlServer 資料庫已經存儲了十多億的會員數據,伺服器已達到物理極限,不能再擴展了。按照現在的增長趨勢,過不了多久,整個 SqlServer 資料庫就崩了。

你想想,那是一種什麼樣的災難場景:會員資料庫崩了,會員系統就崩了;會員系統崩了,全公司所有業務線就崩了。想想就不寒而慄,酸爽無比,為此我們立刻開啟了遷移 DB 的工作。

| MySQL 雙中心 Partition 集群方案

經過調研,我們選擇了雙中心分庫分表的 MySQL 集群方案,如下圖所示:

會員一共有十多億的數據,我們把會員主庫分了 1000 多個分片,平分到每個分片大概百萬的量級,足夠使用了。

MySQL 集群採用 1 主 3 從的架構,主庫放在機房 A,從庫放在機房 B,兩個機房之間通過專線同步數據,延遲在 1 毫秒內。

會員系統通過 DBRoute 讀寫數據,寫數據都路由到 master 節點所在的機房 A,讀數據都路由到本地機房,就近訪問,減少網路延遲。

這樣,採用雙中心的 MySQL 集群架構,極大提高了可用性,即使機房 A 整體都崩了,還可以將機房 B 的 Slave 升級為 Master,繼續提供服務。

雙中心 MySQL 集群搭建好後,我們進行了壓測,測試下來,秒併發能達到 2 萬多,平均耗時在 10 毫秒內,性能達標。

| 會員主庫平滑遷移方案

接下來的工作,就是把會員系統的底層存儲從 SqlServer 切到 MySQL 上,這是個風險極高的工作。

主要有以下幾個難點:

  • 會員系統是一刻都不能停機的,要在不停機的情況下完成 SqlServer 到 MySQL 的切換,就像是在給高速行駛的汽車換輪子。
  • 會員系統是由很多個系統和介面組成的,畢竟發展了 10 多年,由於歷史原因,遺留了大量老介面,邏輯錯綜複雜。這麼多系統,必須一個不落的全部梳理清楚,DAL 層代碼必須重寫,而且不能出任何問題,否則將是災難性的。
  • 數據的遷移要做到無縫遷移,不僅是存量 10 多億數據的遷移,實時產生的數據也要無縫同步到 MySQL。另外,除了要保障數據同步的實時性,還要保證數據的正確性,以及 SqlServer 和 MySQL 數據的一致性。

基於以上痛點,我們設計了“全量同步、增量同步、實時流量灰度切換”的技術方案。

首先,為了保證數據的無縫切換,採用實時雙寫的方案。因為業務邏輯的複雜,以及 SqlServer 和 MySQL 的技術差異性,在雙寫 MySQL 的過程中,不一定會寫成功,而一旦寫失敗,就會導致 SqlServer 和 MySQL 的數據不一致,這是絕不允許的。

所以,我們採取的策略是,在試運行期間,主寫 SqlServer,然後通過線程池非同步寫 MySQL,如果寫失敗了,重試三次,如果依然失敗,則記日誌,然後人工排查原因,解決後,繼續雙寫,直到運行一段時間,沒有雙寫失敗的情況。

通過上述策略,可以確保在絕大部分情況下,雙寫操作的正確性和穩定性,即使在試運行期間出現了 SqlServer 和 MySQL 的數據不一致的情況,也可以基於 SqlServer 再次全量構建出 MySQL 的數據。

因為我們在設計雙寫策略時,會確保 SqlServer 一定能寫成功,也就是說,SqlServer 中的數據是全量最完整、最正確的。

如下圖所示:

講完了雙寫,接下來我們看一下“讀數據”如何灰度。整體思路是,通過 A/B 平臺逐步灰度流量,剛開始 100% 的流量讀取 SqlServer 資料庫,然後逐步切流量讀取 MySQL 資料庫,先 1%,如果沒有問題,再逐步放流量,最終 100% 的流量都走 MySQL資料庫。

在逐步灰度流量的過程中,需要有驗證機制,只有驗證沒問題了,才能進一步放大流量。

那麼這個驗證機制如何實施呢?方案是,在一次查詢請求里,通過非同步線程,比較 SqlServer 和 MySQL 的查詢結果是否一致,如果不一致,記日誌,再人工檢查不一致的原因,直到徹底解決不一致的問題後,再逐步灰度流量。

如下圖所示:

所以,整體的實施流程如下:

首先,在一個夜黑風高的深夜,流量最小的時候,完成 SqlServer 到 MySQL 資料庫的全量數據同步。

接著,開啟雙寫,此時,如果有用戶註冊,就會實時雙寫到兩個資料庫。那麼,在全量同步和實時雙寫開啟之間,兩個資料庫還相差這段時間的數據,所以需要再次增量同步,把數據補充完整,以防數據的不一致。

剩下的時間,就是各種日誌監控,看雙寫是否有問題,看數據比對是否一致等等。

這段時間是耗時最長的,也是最容易發生問題的,如果有的問題比較嚴重,導致數據不一致了,就需要從頭再來,再次基於 SqlServer 全量構建 MySQL 資料庫,然後重新灰度流量。

直到最後,100% 的流量全部灰度到 MySQL,此時就大功告成了,下線灰度邏輯,所有讀寫都切到 MySQL 集群。

| MySQL 和 ES 主備集群方案

做到這一步,感覺會員主庫應該沒問題了,可 dal 組件的一次嚴重故障改變了我們的想法。

那次故障很恐怖,公司很多應用連接不上資料庫了,創單量直線往下掉,這讓我們意識到,即使資料庫是好的,但 dal 組件異常,依然能讓會員系統掛掉。

所以,我們再次異構了會員主庫的數據源,雙寫數據到 ES,如下所示:

如果 dal 組件故障或 MySQL 資料庫掛了,可以把讀寫切到 ES,等 MySQL 恢復了,再把數據同步到 MySQL,最後把讀寫再切回到 MySQL 資料庫。

如下圖所示:

異常會員關係治理

會員系統不僅僅要保證系統的穩定和高可用,數據的精準和正確也同樣重要。

舉個例子,一個分散式併發故障,導致一名用戶的 APP 賬戶綁定了別人的微信小程式賬戶,這將會帶來非常惡劣的影響。

首先,一旦這兩個賬號綁定了,那麼這兩個用戶下的酒店、機票、火車票訂單是互相可以看到的。

你想想,別人能看到你訂的酒店訂單,你火不火,會不會投訴?除了能看到別人的訂單,你還能操作訂單。

例如,一個用戶在 APP 的訂單中心,看到了別人訂的機票訂單,他覺得不是自己的訂單,就把訂單取消了。

這將會帶來非常嚴重的客訴,大家知道,機票退訂費用是挺高的,這不僅影響了該用戶的正常出行,還導致了比較大的經濟損失,非常糟糕。

針對這些異常會員賬號,我們進行了詳細的梳理,通過非常複雜燒腦的邏輯識別出這些賬號,並對會員介面進行了深度優化治理,在代碼邏輯層堵住了相關漏洞,完成了異常會員的治理工作。

如下圖所示:

展望:更精細化的流控和降級策略

任何一個系統,都不能保證百分之一百不出問題,所以我們要有面向失敗的設計,那就是更精細化的流控和降級策略。

| 更精細化的流控策略

熱點控制。針對黑產刷單的場景,同一個會員 id 會有大量重覆的請求,形成熱點賬號,當這些賬號的訪問超過設定閾值時,實施限流策略。

基於調用賬號的流控規則。這個策略主要是防止調用方的代碼 bug 導致的大流量。例如,調用方在一次用戶請求中,迴圈很多次來調用會員介面,導致會員系統流量暴增很多倍。所以,要針對每個調用賬號設置流控規則,當超過閾值時,實施限流策略。

全局流控規則。我們會員系統能抗下 tps 3 萬多的秒併發請求量,如果此時,有個很恐怖的流量打過來,tps 高達 10 萬,與其讓這波流量把會員資料庫、ES 全部打死,還不如把超過會員系統承受範圍之外的流量快速失敗,至少 tps 3 萬內的會員請求能正常響應,不會讓整個會員系統全部崩潰。

| 更精細化的降級策略

基於平均響應時間的降級。會員介面也有依賴其他介面,當調用其他介面的平均響應時間超過閾值,進入準降級狀態。

如果接下來 1s 內進入的請求,它們的平均響應時間都持續超過閾值,那麼在接下的時間視窗內,自動地熔斷。

基於異常數和異常比例的降級。當會員介面依賴的其他介面發生異常,如果 1 分鐘內的異常數超過閾值,或者每秒異常總數占通過量的比值超過閾值,進入降級狀態,在接下的時間視窗之內,自動熔斷。

目前,我們最大的痛點是會員調用賬號的治理。公司內,想要調用會員介面,必須申請一個調用賬號,我們會記錄該賬號的使用場景,並設置流控、降級策略的規則。

但在實際使用的過程中,申請了該賬號的同事,可能異動到其他部門了,此時他可能也會調用會員系統,為了省事,他不會再次申請會員賬號,而是直接沿用以前的賬號過來調用,這導致我們無法判斷一個會員賬號的具體使用場景是什麼,也就無法實施更精細的流控和降級策略。

所以,接下來,我們將會對所有調用賬號進行一個個的梳理,這是個非常龐大且繁瑣的工作,但無路如何,硬著頭皮也要做好。

近期熱文推薦:

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆!Java 協程要來了。。。

3.Spring Boot 2.x 教程,太全了!

4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這才是優雅的方式!!

5.《Java開發手冊(嵩山版)》最新發佈,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!


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

-Advertisement-
Play Games
更多相關文章
  • 聲明 本文章中所有內容僅供學習交流使用,不用於其他任何目的,不提供完整代碼,抓包內容、敏感網址、數據介面等均已做脫敏處理,嚴禁用於商業用途和非法用途,否則由此產生的一切後果均與作者無關! 本文章未經許可禁止轉載,禁止任何修改後二次傳播,擅自使用本文講解的技術而導致的任何意外,作者均不負責,若有侵權, ...
  • “finally塊一定會執行嗎?” 這是最近一個工作3年的小伙伴去面試的時候遇到的問題。 你遇到這個問題會怎麼回答呢? 大家好,我是Mic,一個工作了14年的Java程式員 對於這個問題,面試官想考察什麼呢? 問題解析 這個問題,很明顯是考察Java基礎。 finally語句塊在實際開發中使用得非常 ...
  • 1 Docker 安裝 Nexus3 1.1 創建目錄 在硬碟上創建 Nexus3 的主目錄: mkdir -p /Users/yygnb/dockerMe/nexus3 為該目錄添加許可權: chmod 777 -R /Users/yygnb/dockerMe/nexus3 1.2 拉取鏡像 搜索鏡 ...
  • 1.type() 函數 使用 type() 函數可以查看數據類型。 示例: >>> type(123) <class 'int'> >>> type(12.3) <class 'float'> >>> type("abc") <class 'str'> >>> type([1,2,3]) <clas ...
  • 本文主要介紹火焰圖及使用技巧,學習如何使用火焰圖快速定位軟體的性能卡點。 結合最佳實踐實戰案例,幫助讀者更加深刻地理解火焰圖構造及原理,理解 CPU 耗時,定位性能瓶頸。 ...
  • 微服務Docker打包 現在的微服務時代,你的代碼沒個微服務、分散式人家都會覺得低端,當然!對於我們開發人員來說,掌握這些技術意味著漲薪。 ​ 我們項目中用到了多個微服務,我們上一節課程打包用的是手動上傳,但是很麻煩,有沒有更好的方式呢,是有的,我們可以直接通過idea將我們的微服務打包成Docke ...
  • 線程 筆記目錄:(https://www.cnblogs.com/wenjie2000/p/16378441.html) 程式(program) 是為完成特定任務、用某種語言編寫的一組指令的集合。簡單的說:就是我們寫的代碼 進程 進程是指運行中的程式,比如我們使用QQ,就啟動了一個進程,操作系統就會 ...
  • 摘要:都說 Python 簡單快捷,那本篇博客就為大家帶來一些實用的 Python 技巧,而且僅需要 1 行代碼,就可以解決一些小問題。 本文分享自華為雲社區《你猜 1 行Python代碼能幹什麼呢?神奇的單行 Python 代碼》,作者:夢想橡皮擦。 1 行代碼的由來 都說 Python 簡單快捷 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 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 ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...