redis單例、主從模式、sentinel以及集羣的配置方式及優缺點對比

轉自https://my.oschina.net/zhangxufeng/blog/905611

摘要: redis做爲一種NoSql數據庫，其提供了一種高效的緩存方案，本文則主要對其單例，主從模式，sentinel以及集羣的配置方式進行說明，對比其優缺點，闡述redis做爲一種緩存框架的高可用性。

      redis做爲一種高效的緩存框架，使用是很是普遍的，在數據存儲上，在運行時其將數據存儲在內存中，以實現數據的高效讀寫，而且根據定製的持久化規則不一樣，其會不按期的將數據持久化到硬盤中。另外相較於其餘的NoSql數據庫，redis提供了很是豐富的數據結構，如dict，sds，linkedlist，ziplist，set，quicklist，geometry。在這些存儲結構的基礎上，redis爲用戶提供了很是豐富的操做選擇，如經過zskiplist來達到對某種類型的數據的排序目的，而排序在數據庫中是一個很是耗時的操做。

1.redis單例的安裝和使用

      redis相對於其餘的緩存框架安裝很是的方便，只須要從https://redis.io/download下載後解壓，進入redis目錄以後執行以下命令即安裝完成：

make install

 

這裏須要注意的是make是gcc中的一個命令，安裝以前請確保機器安裝了gcc。redis中全部的命令都在redis安裝目錄中的src子目錄下，其中比較重要的是redis-server，redis-sentinel，redis-cli。

      編譯完成以後在src目錄下執行./redis-server啓動redis（啓動後可關閉該窗口），而後新開一個窗口，在命令行中執行./redis-cli便可鏈接啓動的redis服務。在其中執行以下命令便可看到編譯安裝成功了：

1.  
   127.0.0.1:6379> set hello world
2.  
   OK
3.  
   127.0.0.1:6379> get hello
4.  
   "world"

      這裏須要說明的是，按照上述方式啓動redis，其使用的ip爲本機ip 127.0.0.1，端口爲6379，而且其他的配置採用的都是默認配置，相關配置可在redis安裝目錄下的redis.conf文件中查看。若是須要按照指定的配置文件來啓動，可在redis-server後接上配置文件名，如：

./src/redis-server redis.conf

 

另外，上述使用redis-cli鏈接redis客戶端時若是不帶任何參數，那麼其鏈接的默認ip和端口爲127.0.0.1:6379。若是須要鏈接指定ip和端口的客戶端，可使用以下方式：

./src/redis-cli -h 127.0.0.1 -p 6379

 

這裏-h參數表示鏈接的ip，-p則表示鏈接的端口。

      配置好redis以後，咱們就能夠在redis中執行相關命令來操做數據，關於redis的經常使用命令，可查看本人的另外一篇博客《redis經常使用命令大全》，其中有比較詳細的講解。

2.redis主從模式的配置

      redis單例提供了一種數據緩存方式和豐富的數據操做api，可是將數據徹底存儲在單個redis中主要存在兩個問題：數據備份和數據體量較大形成的性能下降。這裏redis的主從模式爲這兩個問題提供了一個較好的解決方案。主從模式指的是使用一個redis實例做爲主機，其他的實例做爲備份機。主機和從機的數據徹底一致，主機支持數據的寫入和讀取等各項操做，而從機則只支持與主機數據的同步和讀取，也就是說，客戶端能夠將數據寫入到主機，由主機自動將數據的寫入操做同步到從機。主從模式很好的解決了數據備份問題，而且因爲主從服務數據幾乎是一致的，於是能夠將寫入數據的命令發送給主機執行，而讀取數據的命令發送給不一樣的從機執行，從而達到讀寫分離的目的。以下所示主機redis-A分別有redis-B、redis-C、redis-D、redis-E四個從機：

      前面第1點中咱們已經介紹了redis單例的配置方式，而上面咱們也介紹了主從模式其實也是多個redis實例組成的，於是redis主從模式的配置能夠理解爲多個不一樣的redis實例經過必定的配置告知其相互之間的主從關係。而前面已經介紹，每一個redis實例都會佔用一個本機的端口號，主從模式的配置主要的配置點有兩個：當前實例端口號和當前實例是主機仍是從機，是從機的話其主機的ip和端口是什麼。通常的redis目錄下的redis.conf保存的是默認配置，儘可能不要對其進行修改，這裏咱們複製三份redis.conf文件，分別命名爲6379.conf，6380.conf和6381.conf，以下是端口爲6379的主機的主要配置：

1.  
   bind 127.0.0.1
2.  
   port 6379
3.  
   logfile "6379.log"
4.  
   dbfilename "dump-6379.rdb"

以下是端口爲6380和6381的從機的配置：

1.  
   bind 127.0.0.1
2.  
   port 6380
3.  
   logfile "6380.log"
4.  
   dbfilename "dump-6380.rdb"
5.  
   slaveof 127.0.0.1 6379

1.  
   bind 127.0.0.1
2.  
   port 6381
3.  
   logfile "6381.log"
4.  
   dbfilename "dump-6381.rdb"
5.  
   slaveof 127.0.0.1 6379

      能夠看到，端口爲6380和6381的實例被配置爲端口爲6379的實例的從機。配置完成後使用redis-server分別執行以下命令啓動三個實例：

1.  
   . /src/redis-server 6379.conf
2.  
   . /src/redis-server 6380.conf
3.  
   . /src/redis-server 6381.conf

啓動以後分別開啓開啓三個命令行工具分別執行如下命令鏈接redis實例：

1.  
   . /src/redis-cli -p 6379
2.  
   . /src/redis-cli -p 6380
3.  
   . /src/redis-cli -p 6381

分別在三個命令行工具中執行一個get命令，獲取鍵名爲msg的數據，以下所示：

1.  
   127.0.0.1:6379> get msg
2.  
   (nil)

1.  
   127.0.0.1:6380> get msg
2.  
   (nil)

1.  
   127.0.0.1:6381> get msg
2.  
   (nil)

能夠看到，在三個redis實例中都不存在鍵爲msg的數據，如今咱們在主機6379上設置一個鍵爲msg的數據，以下所示：

1.  
   127.0.0.1:6379> set msg "hello"
2.  
   OK

能夠看到設置成功了，此時咱們在6380和6381的實例上執行get msg的命令，以下所示：

1.  
   127.0.0.1:6380> get msg
2.  
   "hello"

1.  
   127.0.0.1:6381> get msg
2.  
   "hello"

能夠看到，雖然咱們只是在6379的實例上設置了msg這條數據，可是在6380和6381的實例上也存有了相應的數據，說明咱們成功配置了redis的主從模式。另外，若是不在配置文件中指定主從節點的關係，也能夠在啓動相關redis實例以後使用slaveof命令來指定當前節點稱爲某個節點的從節點，如：

127.0.0.1:6380> slaveof 127.0.0.1 6379127.0.0.1:6380> slaveof 127.0.0.1 6379

 

3.redis中sentinel配置

      redis主從模式解決了數據備份和單例可能存在的性能問題，可是其也引入了新的問題。因爲主從模式配置了三個redis實例，而且每一個實例都使用不一樣的ip（若是在不一樣的機器上）和端口號，根據前面所述，主從模式下能夠將讀寫操做分配給不一樣的實例進行從而達到提升系統吞吐量的目的，但也正是由於這種方式形成了使用上的不便，由於每一個客戶端鏈接redis實例的時候都是指定了ip和端口號的，若是所鏈接的redis實例由於故障下線了，而主從模式也沒有提供必定的手段通知客戶端另外可鏈接的客戶端地址，於是須要手動更改客戶端配置從新鏈接。另外，主從模式下，若是主節點因爲故障下線了，那麼從節點由於沒有主節點而同步中斷，於是須要人工進行故障轉移工做。

      爲了解決這兩個問題，在2.8版本以後redis正式提供了sentinel（哨兵）架構。關於sentinel，這裏須要說明幾個概念：

名詞	邏輯結構	物理結構
主節點	redis主服務/數據庫	一個獨立的redis進程
從節點	redis從服務/數據庫	一個獨立的redis進程
sentinel節點	監控redis數據節點	一個獨立的sentinel進程
sentinel節點集合	若干sentinel節點的抽象集合	若干sentinel節點進程
應用方	泛指一個或多個客戶端	一個或多個客戶端線程或進程

      每一個sentinel節點其實就是一個redis實例，與主從節點不一樣的是sentinel節點做用是用於監控redis數據節點的，而sentinel節點集合則表示監控一組主從redis實例多個sentinel監控節點的集合，好比有主節點master和從節點slave-一、slave-2，爲了監控這三個主從節點，這裏配置N個sentinel節點sentinel-1，sentinel-2，...，sentinel-N。以下圖是sentinel監控主從節點的示例圖：

      從圖中能夠看出，對於一組主從節點，sentinel只是在其外部額外添加的一組用於監控做用的redis實例。在主從節點和sentinel節點集合配置好以後，sentinel節點之間會相互發送消息，以檢測其他sentinel節點是否正常工做，而且sentinel節點也會向主從節點發送消息，以檢測監控的主從節點是否正常工做。。前面講到，sentinel架構的主要做用是解決主從模式下主節點的故障轉移工做的。這裏若是主節點由於故障下線，那麼某個sentinel節點發送檢測消息給主節點時，若是在指定時間內收不到回覆，那麼該sentinel就會主觀的判斷該主節點已經下線，那麼其會發送消息給其他的sentinel節點，詢問其是否「認爲」該主節點已下線，其他的sentinel收到消息後也會發送檢測消息給主節點，若是其認爲該主節點已經下線，那麼其會回覆向其詢問的sentinel節點，告知其也認爲主節點已經下線，當該sentinel節點最早收到超過指定數目（配置文件中配置的數目和當前sentinel節點集合數的一半，這裏兩個數目的較大值）的sentinel節點回復說當前主節點已下線，那麼其就會對主節點進行故障轉移工做，故障轉移的基本思路是在從節點中選取某個從節點向其發送slaveof no one（假設選取的從節點爲127.0.0.1:6380），使其稱爲獨立的節點（也就是新的主節點），而後sentinel向其他的從節點發送slaveof 127.0.0.1 6380命令使它們從新成爲新的主節點的從節點。從新分配以後sentinel節點集合還會繼續監控已經下線的主節點（假設爲127.0.0.1:6379），若是其從新上線，那麼sentinel會向其發送slaveof命令，使其成爲新的主機點的從節點，如此故障轉移工做完成。

      上面咱們講到了，每一個sentinel節點在本質上仍是一個redis實例，只不過和redis數據節點不一樣的是，其主要做用是監控redis數據節點。在redis安裝目錄下有個默認的sentinel配置文件sentinel.conf，和配置主從節點相似，這裏複製三個配置文件：sentinel-26379.conf，sentinel-26380.conf和sentinel-26381.conf。分別按照以下示例編輯這三個配置文件：

1.  
   port 26379
2.  
   daemonize yes
3.  
   logfile "26379.log"
4.  
   dir /opt/soft/redis/data
5.  
   sentinel monitor mymaster 127.0.0.1 6379 2
6.  
   sentinel down-after-milliseconds mymaster 30000
7.  
   sentinel parallel-syncs mymaster 1
8.  
   sentinel failover-timeout mymaster 180000
9.  
   sentinel myid mm55d2d712b1f3f312b637f9b546f00cdcedc787

對於端口爲26380和26381的sentinel，其配置和上述相似，只須要把相應的端口號修改成對應的端口號便可。這裏注意兩點：①每一個sentinel的myid參數也要進行修改，由於sentinel之間是經過該屬性來惟一區分其餘sentinel節點的；②參數中sentinel monitor mymaster 127.0.0.1 6379 2這裏的端口號6379是不用更改的，由於sentinel是經過檢測主節點的狀態來得知當前主節點的從節點有哪些的，於是設置爲主節點的端口號便可。配置完成後咱們首先啓動三個主從節點，而後分別使用三個配置文件使用以下命令啓用sentinel：

1.  
   . /src/redis-sentinel sentinel-26379.conf
2.  
   . /src/redis-sentinel sentinel-26380.conf
3.  
   . /src/redis-sentinel sentinel-26381.conf

因爲sentinel節點也是一個redis實例，於是咱們能夠經過以下命令使用redis-cli鏈接sentinel節點：

./src/redis-cli -p 26379

 

連上sentinel節點以後咱們能夠經過以下命令查看sentinel狀態：

127.0.0.1:26379> info sentinel127.0.0.1:26379> info sentinel

 

結果以下：

1.  
   # Sentinel
2.  
   sentinel_masters:1
3.  
   sentinel_tilt:0
4.  
   sentinel_running_scripts:0
5.  
   sentinel_scripts_queue_length:0
6.  
   sentinel_simulate_failure_flags:0
7.  
   master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

能夠看到，sentinel檢測到主從節點總共有三個，其中一個主節點，兩個從節點，而且sentinel節點總共也有三個。啓動完成以後，咱們能夠經過主動下線主節點來模擬sentinel的故障轉移過程。首先咱們鏈接上端口爲6379的主節點，使用以下命令查看主從節點狀態：

127.0.0.1:6379> info replication127.0.0.1:6379> info replication

 

結果以下：

1.  
   # Replication
2.  
   role:master
3.  
   connected_slaves:2
4.  
   slave0:ip=127.0.0.1,port=6380,state=online,offset=45616,lag=1
5.  
   slave1:ip=127.0.0.1,port=6381,state=online,offset=45616,lag=1
6.  
   master_repl_offset:45616
7.  
   repl_backlog_active:1
8.  
   repl_backlog_size:1048576
9.  
   repl_backlog_first_byte_offset:2
10.  
    repl_backlog_histlen:45615

能夠看到，當前主節點有兩個從節點，端口分別爲6380和6381。而後咱們對主節點執行以下命令：

127.0.0.1:6379> shutdown save127.0.0.1:6379> shutdown save

 

而後咱們鏈接上端口號爲6380的從節點，並執行以下命令：

127.0.0.1:6380> info replication 

 

結果以下：

1.  
   # Replication
2.  
   role:master
3.  
   connected_slaves:1
4.  
   slave0:ip=127.0.0.1,port=6381,state=online,offset=12344,lag=0
5.  
   master_repl_offset:12477
6.  
   repl_backlog_active:1
7.  
   repl_backlog_size:1048576
8.  
   repl_backlog_first_byte_offset:2
9.  
   repl_backlog_histlen:12476

能夠看到，當端口爲6379的實例下線以後，端口爲6380的實例被從新競選爲新的主節點，而且端口爲6381的實例被設置爲6380的實例的從節點。若是咱們此時從新啓用端口爲6379的節點，而後再查看主從狀態，結果以下：

1.  
   # Replication
2.  
   role:master
3.  
   connected_slaves:2
4.  
   slave0:ip=127.0.0.1,port=6381,state=online,offset=59918,lag=0
5.  
   slave1:ip=127.0.0.1,port=6379,state=online,offset=59918,lag=1
6.  
   master_repl_offset:60051
7.  
   repl_backlog_active:1
8.  
   repl_backlog_size:1048576
9.  
   repl_backlog_first_byte_offset:2
10.  
    repl_backlog_histlen:60050

能夠看到，端口爲6379的redis實例從新鏈接後，sentinel節點檢測到其從新鏈接，那麼對其發送命令，使其成爲新的主節點的從節點。

4.redis集羣的配置

      redis集羣是在redis 3.0版本推出的一個功能，其有效的解決了redis在分佈式方面的需求。當遇到單機內存，併發和流量瓶頸等問題時，可採用Cluster方案達到負載均衡的目的。而且從另外一方面講，redis中sentinel有效的解決了故障轉移的問題，也解決了主節點下線客戶端沒法識別新的可用節點的問題，可是若是是從節點下線了，sentinel是不會對其進行故障轉移的，而且鏈接從節點的客戶端也沒法獲取到新的可用從節點，而這些問題在Cluster中都獲得了有效的解決。

      redis集羣中數據是和槽（slot）掛鉤的，其總共定義了16384個槽，全部的數據根據一致哈希算法會被映射到這16384個槽中的某個槽中；另外一方面，這16384個槽是按照設置被分配到不一樣的redis節點上的，好比啓動了三個redis實例：cluster-A，cluster-B和cluster-C，這裏將0-5460號槽分配給cluster-A，將5461-10922號槽分配給cluster-B，將10923-16383號槽分配給cluster-C（總共有16384個槽，可是其標號相似數組下標，是從0到16383）。也就是說數據的存儲只和槽有關，而且槽的數量是必定的，因爲一致hash算法是必定的，於是將這16384個槽分配給不管多少個redis實例，對於確認的數據其都將被分配到肯定的槽位上。redis集羣經過這種方式來達到redis的高效和高可用性目的。

      這裏須要進行說明的一點是，一致哈希算法根據數據的key值計算映射位置時和所使用的節點數量有很是大的關係。一致哈希分區的實現思路是爲系統中每一個節點分配一個token，範圍通常在0~2^32，這些token構成一個哈希環，數據讀寫執行節點查找操做時，先根據key計算hash值，而後順時針找到第一個大於等於該hash值的token節點，須要操做的數據就保存在該節點上。經過分析能夠發現，一致哈希分區存在以下問題：

1. 加減節點會形成哈希環中部分數據沒法命中，須要手動處理或忽略這部分數據；
2. 當使用少許節點時，節點變化將大範圍影響環中數據映射，所以這種方式不適合少許節點的分佈式方案；
3. 普通的一致性哈希分區在增減節點時須要增長一倍或減去一半節點才能保證數據和負載的平衡。

正是因爲一致哈希分區的這些問題，redis使用了虛擬槽來處理分區時節點變化的問題，也即將全部的數據映射到16384個虛擬槽位上，當redis節點變化時數據映射的槽位將不會變化，而且這也是redis進行節點擴張的基礎。

      對於redis集羣的配置，首先將redis安裝目錄下的redis.conf文件複製六份，分別取名爲：cluster-6379.conf、cluster-6380.conf、cluster-6381.conf、cluster-6382.conf、cluster-6383.conf、cluster-6384.conf。對於一個高可用的集羣方案，集羣每一個節點都將爲其分配一個從節點，以防止數據節點由於故障下線，這裏使用六份配置文件定義六個redis實例，其中三個做爲主節點，剩餘三個分別做爲其從節點。對於這六份配置文件，以其中一份爲例，如下是其須要修改的參數：

1.  
   port 6379
2.  
   cluster-enabled yes
3.  
   cluster-node-timeout 15000
4.  
   cluster-config- file "nodes-6379.conf"
5.  
   pidfile /var/run/redis_6379. pid
6.  
   logfile "cluster-6379.log"
7.  
   dbfilename dump-cluster -6379.rdb
8.  
   appendfilename "appendonly-cluster-6379.aof"

對於其他的配置文件，只須要將其中對應項的端口號和帶有端口號的文件名修改成當前要指定的端口號和端口號的文件名便可。配置文件配置好以後使用以下命令啓動集羣中的每一個實例：

1.  
   . /src/redis-server cluster-6379.conf
2.  
   . /src/redis-server cluster-6380.conf
3.  
   . /src/redis-server cluster-6381.conf
4.  
   . /src/redis-server cluster-6382.conf
5.  
   . /src/redis-server cluster-6383.conf
6.  
   . /src/redis-server cluster-6384.conf

仔細閱讀上述配置文件可發現，當前配置和啓動過程當中並無指定這六個實例的主從關係，也沒有對16384個槽位進行分配。於是咱們還須要進行進一步的配置，槽位的分配和主從關係的設定有兩種方式進行，一種是使用redis-cli鏈接到集羣節點上後使用cluster meet命令鏈接其餘的節點，如咱們首先執行以下命令鏈接到6379端口的節點：

./src/redis-cli -p 6379

 

鏈接上後使用cluster meet命令分別鏈接其他節點：

1.  
   127.0.0.1:6379>cluster meet 127.0.0.1 6380
2.  
   127.0.0.1:6379>cluster meet 127.0.0.1 6381
3.  
   127.0.0.1:6379>cluster meet 127.0.0.1 6382
4.  
   127.0.0.1:6379>cluster meet 127.0.0.1 6383
5.  
   127.0.0.1:6379>cluster meet 127.0.0.1 6384

鏈接好後可使用cluster nodes命令查看當前集羣狀態：

1.  
   127.0.0.1:6379> cluster nodes
2.  
   4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 master - 0 1468073975551 5 connected
3.  
   cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected
4.  
   be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 1468073978579 4 connected
5.  
   40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 1468073980598 3 connected
6.  
   8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 1468073974541 1 connected
7.  
   40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1468073979589 2 connected

能夠看到配置的六個節點都已經加入到了集羣中，可是其如今還不能使用，由於尚未將16384個槽分配到集羣節點中。虛擬槽的分配可使用redis-cli分別鏈接到6379，6380和6381端口的節點中，而後分別執行以下命令：

127.0.0.1:6379>cluster addslots {0...5461}

 

127.0.0.1:6380>cluster addslots {5462...10922}

 

127.0.0.1:6381>cluster addslots {10923...16383}

 

添加完槽位後可以使用cluster info命令查看當前集羣狀態：

1.  
   127.0.0.1:6379> cluster info
2.  
   cluster_state:ok
3.  
   cluster_slots_assigned:16384
4.  
   cluster_slots_ok:16384
5.  
   cluster_slots_pfail:0
6.  
   cluster_slots_fail:0
7.  
   cluster_known_nodes:6
8.  
   cluster_size:3
9.  
   cluster_current_epoch:5
10.  
    cluster_my_epoch:0
11.  
    cluster_stats_messages_sent:4874
12.  
    cluster_stats_messages_received:4726

這裏咱們將16384個虛擬槽位分配給了三個節點，而剩餘的三個節點咱們經過以下命令將其配置爲這三個節點的從節點，從而達到高可用的目的：

1.  
   127.0.0.1:6382>cluster replicate cfb28ef1deee4e0fa78da86abe5d24566744411e
2.  
   OK
3.  
   127.0.0.1:6383>cluster replicate 8e41673d59c9568aa9d29fb174ce733345b3e8f1
4.  
   OK
5.  
   127.0.0.1:6384>cluster replicate 40b8d09d44294d2e23c7c768efc8fcd153446746
6.  
   OK

如此，全部的集羣節點都配置完畢，而且處於可用狀態。這裏可使用cluster nodes命令查看當前節點的狀態：

1.  
   127.0.0.1:6379> cluster nodes
2.  
   4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 slave 40b8d09d44294d2e23c7c768efc8fcd153446746 0 1468076865939 5 connected
3.  
   cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected 0-5461
4.  
   be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 slave 8e41673d59c9568aa9d29fb174ce733345b3e8f1 0 1468076868966 4 connected
5.  
   40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 slave cfb28ef1deee4e0fa78da86abe5d24566744411e 0 1468076869976 3 connected
6.  
   8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 1468076870987 1 connected 5462-10922
7.  
   40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1468076867957 2 connected 10923-16383

咱們使用redis-cli使用以下命令鏈接集羣：

./src/redis-cli -c -p 6380

 

注意鏈接集羣模式的redis實例時須要加上參數-c，表示鏈接的是集羣模式的實例。鏈接上後執行get命令：

1.  
   127.0.0.1:6380> get hello
2.  
   -> Redirected to slot [866] located at 127.0.0.1:6379
3.  
   (nil)

能夠看到，在6380端口的實例上執行get命令時，其首先會爲當前的鍵經過一致哈希算法計算其所在的槽位，而且判斷該槽位不在當前redis實例中，於是重定向到目標實例上執行該命令，最後發現沒有該鍵對應的值，於是返回了一個（nil）。

--------------------- 本文來自 可可keketrtr 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/keketrtr/article/details/78802571?utm_source=copy