一文掌握Redis的三種集群方案

来源:https://www.cnblogs.com/spec-dog/archive/2020/03/16/12501895.html
-Advertisement-
Play Games

在開發測試環境中,我們一般搭建Redis的單實例來應對開發測試需求,但是在生產環境,如果對可用性、可靠性要求較高,則需要引入Redis的集群方案。雖然現在各大雲平臺有提供緩存服務可以直接使用,但瞭解一下其背後的實現與原理總還是有些必要(比如面試), 本文就一起來學習一下Redis的幾種集群方案。 R ...


在開發測試環境中,我們一般搭建Redis的單實例來應對開發測試需求,但是在生產環境,如果對可用性、可靠性要求較高,則需要引入Redis的集群方案。雖然現在各大雲平臺有提供緩存服務可以直接使用,但瞭解一下其背後的實現與原理總還是有些必要(比如面試), 本文就一起來學習一下Redis的幾種集群方案。

Redis支持三種集群方案

  • 主從複製模式
  • Sentinel(哨兵)模式
  • Cluster模式

主從複製模式

1. 基本原理

主從複製模式中包含一個主資料庫實例(master)與一個或多個從資料庫實例(slave),如下圖

redis-master-slave

客戶端可對主資料庫進行讀寫操作,對從資料庫進行讀操作,主資料庫寫入的數據會實時自動同步給從資料庫。

具體工作機製為:

  1. slave啟動後,向master發送SYNC命令,master接收到SYNC命令後通過bgsave保存快照(即上文所介紹的RDB持久化),並使用緩衝區記錄保存快照這段時間內執行的寫命令
  2. master將保存的快照文件發送給slave,並繼續記錄執行的寫命令
  3. slave接收到快照文件後,載入快照文件,載入數據
  4. master快照發送完後開始向slave發送緩衝區的寫命令,slave接收命令並執行,完成複製初始化
  5. 此後master每次執行一個寫命令都會同步發送給slave,保持master與slave之間數據的一致性

2. 部署示例

本示例基於Redis 5.0.3版。

redis.conf的主要配置

###網路相關###
# bind 127.0.0.1 # 綁定監聽的網卡IP,註釋掉或配置成0.0.0.0可使任意IP均可訪問
protected-mode no # 關閉保護模式,使用密碼訪問
port 6379  # 設置監聽埠,建議生產環境均使用自定義埠
timeout 30 # 客戶端連接空閑多久後斷開連接,單位秒,0表示禁用

###通用配置###
daemonize yes # 在後臺運行
pidfile /var/run/redis_6379.pid  # pid進程文件名
logfile /usr/local/redis/logs/redis.log # 日誌文件的位置

###RDB持久化配置###
save 900 1 # 900s內至少一次寫操作則執行bgsave進行RDB持久化
save 300 10
save 60 10000 
# 如果禁用RDB持久化,可在這裡添加 save ""
rdbcompression yes #是否對RDB文件進行壓縮,建議設置為no,以(磁碟)空間換(CPU)時間
dbfilename dump.rdb # RDB文件名稱
dir /usr/local/redis/datas # RDB文件保存路徑,AOF文件也保存在這裡

###AOF配置###
appendonly yes # 預設值是no,表示不使用AOF增量持久化的方式,使用RDB全量持久化的方式
appendfsync everysec # 可選值 always, everysec,no,建議設置為everysec

###設置密碼###
requirepass 123456 # 設置複雜一點的密碼

部署主從複製模式只需稍微調整slave的配置,在redis.conf中添加

replicaof 127.0.0.1 6379 # master的ip,port
masterauth 123456 # master的密碼
replica-serve-stale-data no # 如果slave無法與master同步,設置成slave不可讀,方便監控腳本發現問題

本示例在單台伺服器上配置master埠6379,兩個slave埠分別為7001,7002,啟動master,再啟動兩個slave

[root@dev-server-1 master-slave]# redis-server master.conf
[root@dev-server-1 master-slave]# redis-server slave1.conf
[root@dev-server-1 master-slave]# redis-server slave2.conf

進入master資料庫,寫入一個數據,再進入一個slave資料庫,立即便可訪問剛纔寫入master資料庫的數據。如下所示

[root@dev-server-1 master-slave]# redis-cli 
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> set site blog.jboost.cn
OK
127.0.0.1:6379> get site
"blog.jboost.cn"
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1
slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738,lag=0
...
127.0.0.1:6379> exit

[root@dev-server-1 master-slave]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> get site
"blog.jboost.cn"

執行info replication命令可以查看連接該資料庫的其它庫的信息,如上可看到有兩個slave連接到master

3. 主從複製的優缺點

優點:

  1. master能自動將數據同步到slave,可以進行讀寫分離,分擔master的讀壓力
  2. master、slave之間的同步是以非阻塞的方式進行的,同步期間,客戶端仍然可以提交查詢或更新請求

缺點:

  1. 不具備自動容錯與恢復功能,master或slave的宕機都可能導致客戶端請求失敗,需要等待機器重啟或手動切換客戶端IP才能恢復
  2. master宕機,如果宕機前數據沒有同步完,則切換IP後會存在數據不一致的問題
  3. 難以支持線上擴容,Redis的容量受限於單機配置

Sentinel(哨兵)模式

1. 基本原理

哨兵模式基於主從複製模式,只是引入了哨兵來監控與自動處理故障。如圖

redis-sentinel

哨兵顧名思義,就是來為Redis集群站哨的,一旦發現問題能做出相應的應對處理。其功能包括

  1. 監控master、slave是否正常運行
  2. 當master出現故障時,能自動將一個slave轉換為master(大哥掛了,選一個小弟上位)
  3. 多個哨兵可以監控同一個Redis,哨兵之間也會自動監控

哨兵模式的具體工作機制:

在配置文件中通過 sentinel monitor <master-name> <ip> <redis-port> <quorum> 來定位master的IP、埠,一個哨兵可以監控多個master資料庫,只需要提供多個該配置項即可。哨兵啟動後,會與要監控的master建立兩條連接:

  1. 一條連接用來訂閱master的_sentinel_:hello頻道與獲取其他監控該master的哨兵節點信息
  2. 另一條連接定期向master發送INFO等命令獲取master本身的信息

與master建立連接後,哨兵會執行三個操作:

  1. 定期(一般10s一次,當master被標記為主觀下線時,改為1s一次)向master和slave發送INFO命令
  2. 定期向master和slave的_sentinel_:hello頻道發送自己的信息
  3. 定期(1s一次)向master、slave和其他哨兵發送PING命令

發送INFO命令可以獲取當前資料庫的相關信息從而實現新節點的自動發現。所以說哨兵只需要配置master資料庫信息就可以自動發現其slave信息。獲取到slave信息後,哨兵也會與slave建立兩條連接執行監控。通過INFO命令,哨兵可以獲取主從資料庫的最新信息,併進行相應的操作,比如角色變更等。

接下來哨兵向主從資料庫的_sentinel_:hello頻道發送信息與同樣監控這些資料庫的哨兵共用自己的信息,發送內容為哨兵的ip埠、運行id、配置版本、master名字、master的ip埠還有master的配置版本。這些信息有以下用處:

  1. 其他哨兵可以通過該信息判斷發送者是否是新發現的哨兵,如果是的話會創建一個到該哨兵的連接用於發送PING命令。
  2. 其他哨兵通過該信息可以判斷master的版本,如果該版本高於直接記錄的版本,將會更新
  3. 當實現了自動發現slave和其他哨兵節點後,哨兵就可以通過定期發送PING命令定時監控這些資料庫和節點有沒有停止服務。

如果被PING的資料庫或者節點超時(通過 sentinel down-after-milliseconds master-name milliseconds 配置)未回覆,哨兵認為其主觀下線(sdown,s就是Subjectively —— 主觀地)。如果下線的是master,哨兵會向其它哨兵發送命令詢問它們是否也認為該master主觀下線,如果達到一定數目(即配置文件中的quorum)投票,哨兵會認為該master已經客觀下線(odown,o就是Objectively —— 客觀地),並選舉領頭的哨兵節點對主從系統發起故障恢復。若沒有足夠的sentinel進程同意master下線,master的客觀下線狀態會被移除,若master重新向sentinel進程發送的PING命令返回有效回覆,master的主觀下線狀態就會被移除

哨兵認為master客觀下線後,故障恢復的操作需要由選舉的領頭哨兵來執行,選舉採用Raft演算法:

  1. 發現master下線的哨兵節點(我們稱他為A)向每個哨兵發送命令,要求對方選自己為領頭哨兵
  2. 如果目標哨兵節點沒有選過其他人,則會同意選舉A為領頭哨兵
  3. 如果有超過一半的哨兵同意選舉A為領頭,則A當選
  4. 如果有多個哨兵節點同時參選領頭,此時有可能存在一輪投票無競選者勝出,此時每個參選的節點等待一個隨機時間後再次發起參選請求,進行下一輪投票競選,直至選舉出領頭哨兵

選出領頭哨兵後,領頭者開始對系統進行故障恢復,從出現故障的master的從資料庫中挑選一個來當選新的master,選擇規則如下:

  1. 所有線上的slave中選擇優先順序最高的,優先順序可以通過slave-priority配置
  2. 如果有多個最高優先順序的slave,則選取複製偏移量最大(即複製越完整)的當選
  3. 如果以上條件都一樣,選取id最小的slave

挑選出需要繼任的slave後,領頭哨兵向該資料庫發送命令使其升格為master,然後再向其他slave發送命令接受新的master,最後更新數據。將已經停止的舊的master更新為新的master的從資料庫,使其恢復服務後以slave的身份繼續運行。

2. 部署演示

本示例基於Redis 5.0.3版。

哨兵模式基於前文的主從複製模式。哨兵的配置文件為sentinel.conf,在文件中添加

sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定義一個master資料庫的名稱,後面是master的ip, port,1表示至少需要一個Sentinel進程同意才能將master判斷為失效,如果不滿足這個條件,則自動故障轉移(failover)不會執行
sentinel auth-pass mymaster 123456 # master的密碼

sentinel down-after-milliseconds mymaster 5000 # 5s未回覆PING,則認為master主觀下線,預設為30s
sentinel parallel-syncs mymaster 2  # 指定在執行故障轉移時,最多可以有多少個slave實例在同步新的master實例,在slave實例較多的情況下這個數字越小,同步的時間越長,完成故障轉移所需的時間就越長
sentinel failover-timeout mymaster 300000 # 如果在該時間(ms)內未能完成故障轉移操作,則認為故障轉移失敗,生產環境需要根據數據量設置該值

一個哨兵可以監控多個master資料庫,只需按上述配置添加多套

分別以26379,36379,46379埠啟動三個sentinel

[root@dev-server-1 sentinel]# redis-server sentinel1.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel2.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel3.conf --sentinel

也可以使用redis-sentinel sentinel1.conf 命令啟動。此時集群包含一個master、兩個slave、三個sentinel,如圖,

redis-cluster-instance

我們來模擬master掛掉的場景,執行 kill -9 3017 將master進程幹掉,進入slave中執行 info replication查看,

[root@dev-server-1 sentinel]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7002
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
# 省略
127.0.0.1:7001> exit
[root@dev-server-1 sentinel]# redis-cli -p 7002
127.0.0.1:7002> auth 123456
OK
127.0.0.1:7002> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=7001,state=online,offset=13642721,lag=1
# 省略

可以看到slave 7002已經成功上位晉升為master(role:master),接收一個slave 7001的連接。此時查看slave2.conf配置文件,發現replicaof的配置已經被移除了,slave1.conf的配置文件里replicaof 127.0.0.1 6379 被改為 replicaof 127.0.0.1 7002。重新啟動master,也可以看到master.conf配置文件中添加了replicaof 127.0.0.1 7002的配置項,可見大哥(master)下位後,再出來混就只能噹噹小弟(slave)了,三十年河東三十年河西。

3. 哨兵模式的優缺點

優點:

  1. 哨兵模式基於主從複製模式,所以主從複製模式有的優點,哨兵模式也有
  2. 哨兵模式下,master掛掉可以自動進行切換,系統可用性更高

缺點:

  1. 同樣也繼承了主從模式難以線上擴容的缺點,Redis的容量受限於單機配置
  2. 需要額外的資源來啟動sentinel進程,實現相對複雜一點,同時slave節點作為備份節點不提供服務

Cluster模式

1. 基本原理

哨兵模式解決了主從複製不能自動故障轉移,達不到高可用的問題,但還是存在難以線上擴容,Redis容量受限於單機配置的問題。Cluster模式實現了Redis的分散式存儲,即每台節點存儲不同的內容,來解決線上擴容的問題。如圖

redis-cluster

Cluster採用無中心結構,它的特點如下:

  1. 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進位協議優化傳輸速度和帶寬
  2. 節點的fail是通過集群中超過半數的節點檢測失效時才生效
  3. 客戶端與redis節點直連,不需要中間代理層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可

Cluster模式的具體工作機制:

  1. 在Redis的每個節點上,都有一個插槽(slot),取值範圍為0-16383
  2. 當我們存取key的時候,Redis會根據CRC16的演算法得出一個結果,然後把結果對16384求餘數,這樣每個key都會對應一個編號在0-16383之間的哈希槽,通過這個值,去找到對應的插槽所對應的節點,然後直接自動跳轉到這個對應的節點上進行存取操作
  3. 為了保證高可用,Cluster模式也引入主從複製模式,一個主節點對應一個或者多個從節點,當主節點宕機的時候,就會啟用從節點
  4. 當其它主節點ping一個主節點A時,如果半數以上的主節點與A通信超時,那麼認為主節點A宕機了。如果主節點A和它的從節點都宕機了,那麼該集群就無法再提供服務了

Cluster模式集群節點最小配置6個節點(3主3從,因為需要半數以上),其中主節點提供讀寫操作,從節點作為備用節點,不提供請求,只作為故障轉移使用。

2. 部署演示

本示例基於Redis 5.0.3版。

Cluster模式的部署比較簡單,首先在redis.conf中

port 7100 # 本示例6個節點埠分別為7100,7200,7300,7400,7500,7600 
daemonize yes # r後臺運行 
pidfile /var/run/redis_7100.pid # pidfile文件對應7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 開啟集群模式 
masterauth passw0rd # 如果設置了密碼,需要指定master密碼
cluster-config-file nodes_7100.conf # 集群的配置文件,同樣對應7100,7200等六個節點
cluster-node-timeout 15000 # 請求超時 預設15秒,可自行設置 

分別以埠7100,7200,7300,7400,7500,7600 啟動六個實例(如果是每個伺服器一個實例則配置可一樣)

[root@dev-server-1 cluster]# redis-server redis_7100.conf
[root@dev-server-1 cluster]# redis-server redis_7200.conf
...

然後通過命令將這個6個實例組成一個3主節點3從節點的集群,

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7100 127.0.0.1:7200 127.0.0.1:7300 127.0.0.1:7400 127.0.0.1:7500 127.0.0.1:7600 -a passw0rd

執行結果如圖

redis-cluster-deploy

可以看到 7100, 7200, 7300 作為3個主節點,分配的slot分別為 0-5460, 5461-10922, 10923-16383, 7600作為7100的slave, 7500作為7300的slave,7400作為7200的slave。

我們連接7100設置一個值

[root@dev-server-1 cluster]# redis-cli -p 7100 -c -a passw0rd
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:7100> set site blog.jboost.cn
-> Redirected to slot [9421] located at 127.0.0.1:7200
OK
127.0.0.1:7200> get site
"blog.jboost.cn"
127.0.0.1:7200>

註意添加 -c 參數表示以集群模式,否則報 (error) MOVED 9421 127.0.0.1:7200 錯誤, 以 -a 參數指定密碼,否則報(error) NOAUTH Authentication required錯誤。

從上面命令看到key為site算出的slot為9421,落在7200節點上,所以有Redirected to slot [9421] located at 127.0.0.1:7200,集群會自動進行跳轉。因此客戶端可以連接任何一個節點來進行數據的存取。

通過cluster nodes可查看集群的節點信息

127.0.0.1:7200> cluster nodes
eb28aaf090ed1b6b05033335e3d90a202b422d6c 127.0.0.1:7500@17500 slave c1047de2a1b5d5fa4666d554376ca8960895a955 0 1584165266071 5 connected
4cc0463878ae00e5dcf0b36c4345182e021932bc 127.0.0.1:7400@17400 slave 5544aa5ff20f14c4c3665476de6e537d76316b4a 0 1584165267074 4 connected
dbbb6420d64db22f35a9b6fa460b0878c172a2fb 127.0.0.1:7100@17100 master - 0 1584165266000 1 connected 0-5460
d4b434f5829e73e7e779147e905eea6247ffa5a2 127.0.0.1:7600@17600 slave dbbb6420d64db22f35a9b6fa460b0878c172a2fb 0 1584165265000 6 connected
5544aa5ff20f14c4c3665476de6e537d76316b4a 127.0.0.1:7200@17200 myself,master - 0 1584165267000 2 connected 5461-10922
c1047de2a1b5d5fa4666d554376ca8960895a955 127.0.0.1:7300@17300 master - 0 1584165268076 3 connected 10923-16383

我們將7200通過 kill -9 pid殺死進程來驗證集群的高可用,重新進入集群執行cluster nodes可以看到7200 fail了,但是7400成了master,重新啟動7200,可以看到此時7200已經變成了slave。

3. Cluster模式的優缺點

優點:

  1. 無中心架構,數據按照slot分佈在多個節點。
  2. 集群中的每個節點都是平等的關係,每個節點都保存各自的數據和整個集群的狀態。每個節點都和其他所有節點連接,而且這些連接保持活躍,這樣就保證了我們只需要連接集群中的任意一個節點,就可以獲取到其他節點的數據。
  3. 可線性擴展到1000多個節點,節點可動態添加或刪除
  4. 能夠實現自動故障轉移,節點之間通過gossip協議交換狀態信息,用投票機制完成slave到master的角色轉換

缺點:

  1. 客戶端實現複雜,驅動要求實現Smart Client,緩存slots mapping信息並及時更新,提高了開發難度。目前僅JedisCluster相對成熟,異常處理還不完善,比如常見的“max redirect exception”
  2. 節點會因為某些原因發生阻塞(阻塞時間大於 cluster-node-timeout)被判斷下線,這種failover是沒有必要的
  3. 數據通過非同步複製,不保證數據的強一致性
  4. slave充當“冷備”,不能緩解讀壓力
  5. 批量操作限制,目前只支持具有相同slot值的key執行批量操作,對mset、mget、sunion等操作支持不友好
  6. key事務操作支持有線,只支持多key在同一節點的事務操作,多key分佈不同節點時無法使用事務功能
  7. 不支持多資料庫空間,單機redis可以支持16個db,集群模式下只能使用一個,即db 0

Redis Cluster模式不建議使用pipeline和multi-keys操作,減少max redirect產生的場景。

總結

本文介紹了Redis集群方案的三種模式,其中主從複製模式能實現讀寫分離,但是不能自動故障轉移;哨兵模式基於主從複製模式,能實現自動故障轉移,達到高可用,但與主從複製模式一樣,不能線上擴容,容量受限於單機的配置;Cluster模式通過無中心化架構,實現分散式存儲,可進行線性擴展,也能高可用,但對於像批量操作、事務操作等的支持性不夠好。三種模式各有優缺點,可根據實際場景進行選擇。

參考:

  1. https://blog.csdn.net/q649381130/article/details/79931791
  2. https://www.cnblogs.com/51life/p/10233340.html
  3. https://www.cnblogs.com/chensuqian/p/10538365.html
  4. https://stor.51cto.com/art/201910/604653.htm

作者:空山新雨,一枚仍在學習路上的大齡碼農
近期作者寫了幾十篇技術博客,內容包括Java、Spring Boot、Spring Cloud、Docker,技術管理心得等
歡迎關註作者微信公眾號:空山新雨的技術空間,一起學習成長

微信公眾號


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

-Advertisement-
Play Games
更多相關文章
  • [toc] oracle中wm_concat oracle中wm_concat標識符無效原因: 11gr2和12C上已經摒棄了wm\_concat函數,當時我們很多程式員在程式中確使用了該函數,導致程式出現錯誤,為了減輕程式員修改程式的工作量,只有通過手工創建個wm\_concat函數,來臨時解決該 ...
  • [toc] oracle加密encrypt,解密decrypt 有的oracle版本沒有加解密函數,以下操作可以手動添加 oracle數據使用加密解密,我們首先要先賦予dbms_crypto許可權給用戶。 加密 解密 ...
  • 在測試環境中我們需要每天備份oracle中的數據,以便錯誤的操作、測試或者覆蓋其中有價值的數據,暫時不考慮生產環境的全量增量備份策略,本文只是簡單的oracle資料庫使用expdp命令設置定時任務備份數據。 ...
  • [toc] 阿裡雲centos安裝oracle 阿裡雲預設沒有swap分區,oracle安裝需要 創建swap分區是為了彌補物理記憶體的不足,也就是虛擬記憶體的概念,把硬碟的一部分劃分作為虛擬記憶體,但這個空間不是越大越好,硬碟的速度遠低於記憶體,設置不當反而拖慢系統的速度。 阿裡雲的主機預設沒有swap分 ...
  • 我們大家鏈接這個資料庫可能都用root作為用戶名!但預設不可以遠程訪問!如果要遠程訪問怎麼處理呢?1 GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;2 FLUSH PRIVIL... ...
  • 本文檔主要是用來解決物理備庫的性能監控問題。我們都知道,當物理備庫出現問題的時候,由於備庫是只讀模式的,所以無法在備庫上使用AWR/Statspack/ash/addm等性能報告來分析。因此,在故障分析和調優應用的時候,只能手動收集相關的統計數據信息,這樣給我們的工作帶來了巨大的不變。隨著Oracl ...
  • Clustered and Secondary Indexes(聚集索引和二級索引) Every InnoDB table has a special index called the clustered index where the data for the rows is stored. Ty ...
  • 如果應用程式遇到了下麵錯誤信息,那麼意味著連接池(connection pool)的連接數量由於一些原因導致其超過了Max Pool Size參數的限制。 英文錯誤信息: Timeout expired. The timeout period elapsed prior to obtaining a... ...
一周排行
    -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.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...