溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
本篇內(nèi)容主要講解“Redis基準(zhǔn)參數(shù)怎么查看”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Redis基準(zhǔn)參數(shù)怎么查看”吧!
Redis 自帶了一個(gè)叫redis-benchmark的工具來(lái)模擬 N 個(gè)客戶端同時(shí)發(fā)出 M 個(gè)請(qǐng)求。 （類似于 Apacheab程序）。你可以使用redis-benchmark -h來(lái)查看基準(zhǔn)參數(shù)。
以下參數(shù)被支持： Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>] -h <hostname> Server hostname (default 127.0.0.1) -p <port> Server port (default 6379) -s <socket> Server socket (overrides host and port) -c <clients> Number of parallel connections (default 50) -n <requests> Total number of requests (default 10000) -d <size> Data size of SET/GET value in bytes (default 2) -k <boolean> 1=keep alive 0=reconnect (default 1) -r <keyspacelen> Use random keys for SET/GET/INCR, random values for SADD Using this option the benchmark will get/set keys in the form mykey_rand:000000012456 instead of constant keys, the <keyspacelen> argument determines the max number of values for the random number. For instance if set to 10 only rand:000000000000 - rand:000000000009 range will be allowed. -P <numreq> Pipeline <numreq> requests. Default 1 (no pipeline). -q Quiet. Just show query/sec values --csv Output in CSV format -l Loop. Run the tests forever -t <tests> Only run the comma separated list of tests. The test names are the same as the ones produced as output. -I Idle mode. Just open N idle connections and wait.
你需要在基準(zhǔn)測(cè)試之前啟動(dòng)一個(gè) Redis 實(shí)例。一般這樣啟動(dòng)測(cè)試：
redis-benchmark -q -n 100000
這個(gè)工具使用起來(lái)非常方便，同時(shí)你可以使用自己的基準(zhǔn)測(cè)試工具， 不過(guò)開(kāi)始基準(zhǔn)測(cè)試時(shí)候，我們需要注意一些細(xì)節(jié)。
你不必每次都運(yùn)行 redis-benchmark 默認(rèn)的所有測(cè)試。 使用-t參數(shù)可以選擇你需要運(yùn)行的測(cè)試用例，比如下面的范例：
$ redis-benchmark -t set,lpush -n 100000 -q SET: 74239.05 requests per second LPUSH: 79239.30 requests per second
在上面的測(cè)試中，我們只運(yùn)行了 SET 和 LPUSH 命令， 并且運(yùn)行在安靜模式中（使用-q參數(shù)）。
也可以直接指定命令來(lái)直接運(yùn)行，比如下面的范例：
$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second默認(rèn)情況下面，基準(zhǔn)測(cè)試使用單一的 key。在一個(gè)基于內(nèi)存的數(shù)據(jù)庫(kù)里， 單一 key 測(cè)試和真實(shí)情況下面不會(huì)有巨大變化。當(dāng)然，使用一個(gè)大的 key 范圍空間， 可以模擬現(xiàn)實(shí)情況下面的緩存不命中情況。
這時(shí)候我們可以使用-r命令。比如，假設(shè)我們想設(shè)置 10 萬(wàn)隨機(jī) key 連續(xù) SET 100 萬(wàn)次，我們可以使用下列的命令：
$ redis-cli flushall OK $ redis-benchmark -t set -r 100000 -n 1000000 ====== SET ====== 1000000 requests completed in 13.86 seconds 50 parallel clients 3 bytes payload keep alive: 1 99.76% `<=` 1 milliseconds 99.98% `<=` 2 milliseconds 100.00% `<=` 3 milliseconds 100.00% `<=` 3 milliseconds 72144.87 requests per second $ redis-cli dbsize (integer) 99993
默認(rèn)情況下，每個(gè)客戶端都是在一個(gè)請(qǐng)求完成之后才發(fā)送下一個(gè)請(qǐng)求 （benchmark 會(huì)模擬 50 個(gè)客戶端除非使用-c指定特別的數(shù)量）， 這意味著服務(wù)器幾乎是按順序讀取每個(gè)客戶端的命令。Also RTT is payed as well.
真實(shí)世界會(huì)更復(fù)雜，Redis 支持/topics/pipelining，使得可以一次性執(zhí)行多條命令成為可能。 Redis pipelining 可以提高服務(wù)器的 TPS。
下面這個(gè)案例是在 Macbook air 11" 上使用 pipelining 組織 16 條命令的測(cè)試范例：
$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second
記得在多條命令需要處理時(shí)候使用 pipelining。
第一點(diǎn)是顯而易見(jiàn)的：基準(zhǔn)測(cè)試的黃金準(zhǔn)則是使用相同的標(biāo)準(zhǔn)。 用相同的任務(wù)量測(cè)試不同版本的 Redis，或者用相同的參數(shù)測(cè)試測(cè)試不同版本 Redis。 如果把 Redis 和其他工具測(cè)試，那就需要小心功能細(xì)節(jié)差異。
Redis 是一個(gè)服務(wù)器：所有的命令都包含網(wǎng)絡(luò)或 IPC 消耗。這意味著和它和 SQLite， Berkeley DB， Tokyo/Kyoto Cabinet 等比較起來(lái)無(wú)意義， 因?yàn)榇蟛糠值南亩荚诰W(wǎng)絡(luò)協(xié)議上面。
Redis 的大部分常用命令都有確認(rèn)返回。有些數(shù)據(jù)存儲(chǔ)系統(tǒng)則沒(méi)有（比如 MongoDB 的寫(xiě)操作沒(méi)有返回確認(rèn)）。把 Redis 和其他單向調(diào)用命令存儲(chǔ)系統(tǒng)比較意義不大。
簡(jiǎn)單的循環(huán)操作 Redis 其實(shí)不是對(duì) Redis 進(jìn)行基準(zhǔn)測(cè)試，而是測(cè)試你的網(wǎng)絡(luò)（或者 IPC）延遲。想要真正測(cè)試 Redis，需要使用多個(gè)連接（比如 redis-benchmark)， 或者使用 pipelining 來(lái)聚合多個(gè)命令，另外還可以采用多線程或多進(jìn)程。
Redis 是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，同時(shí)提供一些可選的持久化功能。 如果你想和一個(gè)持久化服務(wù)器（MySQL, PostgreSQL 等等） 對(duì)比的話， 那你需要考慮啟用 AOF 和適當(dāng)?shù)?fsync 策略。
Redis 是單線程服務(wù)。它并沒(méi)有設(shè)計(jì)為多 CPU 進(jìn)行優(yōu)化。如果想要從多核獲取好處， 那就考慮啟用多個(gè)實(shí)例吧。將單實(shí)例 Redis 和多線程數(shù)據(jù)庫(kù)對(duì)比是不公平的。
一個(gè)普遍的誤解是 redis-benchmark 特意讓基準(zhǔn)測(cè)試看起來(lái)更好， 所表現(xiàn)出來(lái)的數(shù)據(jù)像是人造的，而不是真實(shí)產(chǎn)品下面的。
Redis-benchmark 程序可以簡(jiǎn)單快捷的對(duì)給定硬件條件下面的機(jī)器計(jì)算出性能參數(shù)。 但是，通常情況下面這并不是 Redis 服務(wù)器可以達(dá)到的最大吞吐量。 事實(shí)上，使用 pipelining 和更快的客戶端（hiredis）可以達(dá)到更大的吞吐量。 redis-benchmark 默認(rèn)情況下面僅僅使用并發(fā)來(lái)提高吞吐量（創(chuàng)建多條連接）。 它并沒(méi)有使用 pipelining 或者其他并行技術(shù)（僅僅多條連接，而不是多線程）。
如果想使用 pipelining 模式來(lái)進(jìn)行基準(zhǔn)測(cè)試（了達(dá)到更高吞吐量），可以使用-P參數(shù)。這種方案的確可以提高性能，有很多使用 Redis 的應(yīng)用在生產(chǎn)環(huán)境中這樣做。
最后，基準(zhǔn)測(cè)試需要使用相同的操作和數(shù)據(jù)來(lái)對(duì)比，如果這些不一樣， 那么基準(zhǔn)測(cè)試是無(wú)意義的。
比如，Redis 和 memcached 可以在單線程模式下面對(duì)比 GET/SET 操作。 兩者都是內(nèi)存數(shù)據(jù)庫(kù)，協(xié)議也基本相同，甚至把多個(gè)請(qǐng)求合并為一條請(qǐng)求的方式也類似 （pipelining）。在使用相同數(shù)量的連接后，這個(gè)對(duì)比是很有意義的。
下面這個(gè)很不錯(cuò)例子是在 Redis（antirez）和 memcached（dormando）測(cè)試的。
antirez 1 - On Redis, Memcached, Speed, Benchmarks and The Toilet
dormando - Redis VS Memcached (slightly better bench)
antirez 2 - An update on the Memcached/Redis benchmark
你可以發(fā)現(xiàn)相同條件下面最終結(jié)果是兩者差別不大。請(qǐng)注意最終測(cè)試時(shí)候， 兩者都經(jīng)過(guò)了充分優(yōu)化。
最后，當(dāng)特別高性能的服務(wù)器在基準(zhǔn)測(cè)試時(shí)候（比如 Redis、memcached 這類）， 很難讓服務(wù)器性能充分發(fā)揮，通常情況下，客戶端回事瓶頸限制而不是服務(wù)器端。 在這種情況下面，客戶端（比如 benchmark 程序自身）需要優(yōu)化，或者使用多實(shí)例， 從而能達(dá)到最大的吞吐量。
有幾個(gè)因素直接決定 Redis 的性能。它們能夠改變基準(zhǔn)測(cè)試的結(jié)果， 所以我們必須注意到它們。一般情況下，Redis 默認(rèn)參數(shù)已經(jīng)可以提供足夠的性能， 不需要調(diào)優(yōu)。
網(wǎng)絡(luò)帶寬和延遲通常是最大短板。建議在基準(zhǔn)測(cè)試之前使用 ping 來(lái)檢查服務(wù)端到客戶端的延遲。根據(jù)帶寬，可以計(jì)算出最大吞吐量。 比如將 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么實(shí)際需要 3.2 Gbits/s 的帶寬，所以需要 10 GBits/s 網(wǎng)絡(luò)連接， 1 Gbits/s 是不夠的。 在很多線上服務(wù)中，Redis 吞吐會(huì)先被網(wǎng)絡(luò)帶寬限制住，而不是 CPU。 為了達(dá)到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的網(wǎng)卡， 或者多個(gè) 1 Gbits/s 網(wǎng)卡。
CPU 是另外一個(gè)重要的影響因素，由于是單線程模型，Redis 更喜歡大緩存快速 CPU， 而不是多核。這種場(chǎng)景下面，比較推薦 Intel CPU。AMD CPU 可能只有 Intel CPU 的一半性能（通過(guò)對(duì) Nehalem EP/Westmere EP/Sandy 平臺(tái)的對(duì)比）。 當(dāng)其他條件相當(dāng)時(shí)候，CPU 就成了 redis-benchmark 的限制因素。
在小對(duì)象存取時(shí)候，內(nèi)存速度和帶寬看上去不是很重要，但是對(duì)大對(duì)象（> 10 KB）， 它就變得重要起來(lái)。不過(guò)通常情況下面，倒不至于為了優(yōu)化 Redis 而購(gòu)買更高性能的內(nèi)存模塊。
Redis 在 VM 上會(huì)變慢。虛擬化對(duì)普通操作會(huì)有額外的消耗，Redis 對(duì)系統(tǒng)調(diào)用和網(wǎng)絡(luò)終端不會(huì)有太多的 overhead。建議把 Redis 運(yùn)行在物理機(jī)器上， 特別是當(dāng)你很在意延遲時(shí)候。在最先進(jìn)的虛擬化設(shè)備（VMWare）上面，redis-benchmark 的測(cè)試結(jié)果比物理機(jī)器上慢了一倍，很多 CPU 時(shí)間被消費(fèi)在系統(tǒng)調(diào)用和中斷上面。
如果服務(wù)器和客戶端都運(yùn)行在同一個(gè)機(jī)器上面，那么 TCP/IP loopback 和 unix domain sockets 都可以使用。對(duì) Linux 來(lái)說(shuō)，使用 unix socket 可以比 TCP/IP loopback 快 50%。 默認(rèn) redis-benchmark 是使用 TCP/IP loopback。
當(dāng)大量使用 pipelining 時(shí)候，unix domain sockets 的優(yōu)勢(shì)就不那么明顯了。
當(dāng)使用網(wǎng)絡(luò)連接時(shí)，并且以太網(wǎng)網(wǎng)數(shù)據(jù)包在 1500 bytes 以下時(shí)， 將多條命令包裝成 pipelining 可以大大提高效率。事實(shí)上，處理 10 bytes，100 bytes， 1000 bytes 的請(qǐng)求時(shí)候，吞吐量是差不多的，詳細(xì)可以見(jiàn)下圖。
在多核 CPU 服務(wù)器上面，Redis 的性能還依賴 NUMA 配置和 處理器綁定位置。 最明顯的影響是 redis-benchmark 會(huì)隨機(jī)使用 CPU 內(nèi)核。為了獲得精準(zhǔn)的結(jié)果， 需要使用固定處理器工具（在 Linux 上可以使用 taskset 或 numactl）。 最有效的辦法是將客戶端和服務(wù)端分離到兩個(gè)不同的 CPU 來(lái)高校使用三級(jí)緩存。 這里有一些使用 4 KB 數(shù)據(jù) SET 的基準(zhǔn)測(cè)試，針對(duì)三種 CPU（AMD Istanbul, Intel Nehalem EX， 和 Intel Westmere）使用不同的配置。請(qǐng)注意， 這不是針對(duì) CPU 的測(cè)試。
在高配置下面，客戶端的連接數(shù)也是一個(gè)重要的因素。得益于 epoll/kqueue， Redis 的事件循環(huán)具有相當(dāng)可擴(kuò)展性。Redis 已經(jīng)在超過(guò) 60000 連接下面基準(zhǔn)測(cè)試過(guò)， 仍然可以維持 50000 q/s。一條經(jīng)驗(yàn)法則是，30000 的連接數(shù)只有 100 連接的一半吞吐量。 下面有一個(gè)關(guān)于連接數(shù)和吞吐量的測(cè)試。
在高配置下面，可以通過(guò)調(diào)優(yōu) NIC 來(lái)獲得更高性能。最高性能在綁定 Rx/Tx 隊(duì)列和 CPU 內(nèi)核下面才能達(dá)到，還需要開(kāi)啟 RPS（網(wǎng)卡中斷負(fù)載均衡）。更多信息可以在thread。Jumbo frames 還可以在大對(duì)象使用時(shí)候獲得更高性能。
在不同平臺(tái)下面，Redis 可以被編譯成不同的內(nèi)存分配方式（libc malloc, jemalloc, tcmalloc），他們?cè)诓煌俣?、連續(xù)和非連續(xù)片段下會(huì)有不一樣的表現(xiàn)。 如果你不是自己編譯的 Redis，可以使用 INFO 命令來(lái)檢查內(nèi)存分配方式。 請(qǐng)注意，大部分基準(zhǔn)測(cè)試不會(huì)長(zhǎng)時(shí)間運(yùn)行來(lái)感知不同分配模式下面的差異， 只能通過(guò)生產(chǎn)環(huán)境下面的 Redis 實(shí)例來(lái)查看。
任何基準(zhǔn)測(cè)試的一個(gè)重要目標(biāo)是獲得可重現(xiàn)的結(jié)果，這樣才能將此和其他測(cè)試進(jìn)行對(duì)比。
一個(gè)好的實(shí)踐是盡可能在隔離的硬件上面測(cè)試。如果沒(méi)法實(shí)現(xiàn)，那就需要檢測(cè) benchmark 沒(méi)有受其他服務(wù)器活動(dòng)影響。
有些配置（桌面環(huán)境和筆記本，有些服務(wù)器也會(huì)）會(huì)使用可變的 CPU 分配策略。 這種策略可以在 OS 層面配置。有些 CPU 型號(hào)相對(duì)其他能更好的調(diào)整 CPU 負(fù)載。 為了達(dá)到可重現(xiàn)的測(cè)試結(jié)果，最好在做基準(zhǔn)測(cè)試時(shí)候設(shè)定 CPU 到最高使用限制。
一個(gè)重要因素是配置盡可能大內(nèi)存，千萬(wàn)不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的內(nèi)存限制。
如果你計(jì)劃在基準(zhǔn)測(cè)試時(shí)候使用 RDB 或 AOF，請(qǐng)注意不要讓系統(tǒng)同時(shí)有其他 I/O 操作。 避免將 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依賴網(wǎng)絡(luò)的存儲(chǔ)設(shè)備上面（比如 Amazon EC2 上 的 EBS）。
將 Redis 日志級(jí)別設(shè)置到 warning 或者 notice。避免將日志放到遠(yuǎn)程文件系統(tǒng)。
避免使用檢測(cè)工具，它們會(huì)影響基準(zhǔn)測(cè)試結(jié)果。使用 INFO 來(lái)查看服務(wù)器狀態(tài)沒(méi)問(wèn)題， 但是使用 MONITOR 將大大影響測(cè)試準(zhǔn)確度。
這些測(cè)試模擬了 50 客戶端和 200w 請(qǐng)求。
使用了 Redis 2.6.14。
使用了 loopback 網(wǎng)卡。
key 的范圍是 100 w。
同時(shí)測(cè)試了 有 pipelining 和沒(méi)有的情況（16 條命令使用 pipelining）。
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q SET: 552028.75 requests per second GET: 707463.75 requests per second LPUSH: 767459.75 requests per second LPOP: 770119.38 requests per second
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 122556.53 requests per second GET: 123601.76 requests per second LPUSH: 136752.14 requests per second LPOP: 132424.03 requests per second
Linode 2048 instance (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16 SET: 195503.42 requests per second GET: 250187.64 requests per second LPUSH: 230547.55 requests per second LPOP: 250815.16 requests per second
Linode 2048 instance (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 35001.75 requests per second GET: 37481.26 requests per second LPUSH: 36968.58 requests per second LPOP: 35186.49 requests per second
$ redis-benchmark -n 100000 ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <= 0 milliseconds 99.17% <= 1 milliseconds 99.58% <= 2 milliseconds 99.85% <= 3 milliseconds 99.90% <= 6 milliseconds 100.00% <= 9 milliseconds 114293.71 requests per second ====== GET ====== 100000 requests completed in 1.23 seconds 50 parallel clients 3 bytes payload keep alive: 1 43.12% <= 0 milliseconds 96.82% <= 1 milliseconds 98.62% <= 2 milliseconds 100.00% <= 3 milliseconds 81234.77 requests per second ====== INCR ====== 100018 requests completed in 1.46 seconds 50 parallel clients 3 bytes payload keep alive: 1 32.32% <= 0 milliseconds 96.67% <= 1 milliseconds 99.14% <= 2 milliseconds 99.83% <= 3 milliseconds 99.88% <= 4 milliseconds 99.89% <= 5 milliseconds 99.96% <= 9 milliseconds 100.00% <= 18 milliseconds 68458.59 requests per second ====== LPUSH ====== 100004 requests completed in 1.14 seconds 50 parallel clients 3 bytes payload keep alive: 1 62.27% <= 0 milliseconds 99.74% <= 1 milliseconds 99.85% <= 2 milliseconds 99.86% <= 3 milliseconds 99.89% <= 5 milliseconds 99.93% <= 7 milliseconds 99.96% <= 9 milliseconds 100.00% <= 22 milliseconds 100.00% <= 208 milliseconds 88109.25 requests per second ====== LPOP ====== 100001 requests completed in 1.39 seconds 50 parallel clients 3 bytes payload keep alive: 1 54.83% <= 0 milliseconds 97.34% <= 1 milliseconds 99.95% <= 2 milliseconds 99.96% <= 3 milliseconds 99.96% <= 4 milliseconds 100.00% <= 9 milliseconds 100.00% <= 208 milliseconds 71994.96 requests per second
注意：包大小從 256 到 1024 或者 4096 bytes 不會(huì)改變結(jié)果的量級(jí) （但是到 1024 bytes 后，GETs 操作會(huì)變慢）。同樣的，50 到 256 客戶端的測(cè)試結(jié)果相同。 10 個(gè)客戶端時(shí)候，吞吐量會(huì)變?。ㄗg者按：總量到不了最大吞吐量）。
不同機(jī)器可以獲的不一樣的結(jié)果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的結(jié)果：
$ ./redis-benchmark -q -n 100000 SET: 53684.38 requests per second GET: 45497.73 requests per second INCR: 39370.47 requests per second LPUSH: 34803.41 requests per second LPOP: 37367.20 requests per second
另外一個(gè)是 64 位 Xeon L5420 2.5 GHz 的結(jié)果：
$ ./redis-benchmark -q -n 100000 PING: 111731.84 requests per second SET: 108114.59 requests per second GET: 98717.67 requests per second INCR: 95241.91 requests per second LPUSH: 104712.05 requests per second LPOP: 93722.59 requests per second
Redis2.4.2 。
默認(rèn)連接數(shù)，數(shù)據(jù)包大小 256 bytes。
Linux 是SLES10 SP3 2.6.16.60-0.54.5-smp，CPU 是 2 xIntel X5670 @ 2.93 GHz。
固定 CPU，但是使用不同 CPU 內(nèi)核。
使用 unix domain socket：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256 PING (inline): 200803.22 requests per second PING: 200803.22 requests per second MSET (10 keys): 78064.01 requests per second SET: 198412.69 requests per second GET: 198019.80 requests per second INCR: 200400.80 requests per second LPUSH: 200000.00 requests per second LPOP: 198019.80 requests per second SADD: 203665.98 requests per second SPOP: 200803.22 requests per second LPUSH (again, in order to bench LRANGE): 200000.00 requests per second LRANGE (first 100 elements): 42123.00 requests per second LRANGE (first 300 elements): 15015.02 requests per second LRANGE (first 450 elements): 10159.50 requests per second LRANGE (first 600 elements): 7548.31 requests per second
使用 TCP loopback：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -d 256 PING (inline): 145137.88 requests per second PING: 144717.80 requests per second MSET (10 keys): 65487.89 requests per second SET: 142653.36 requests per second GET: 142450.14 requests per second INCR: 143061.52 requests per second LPUSH: 144092.22 requests per second LPOP: 142247.52 requests per second SADD: 144717.80 requests per second SPOP: 143678.17 requests per second LPUSH (again, in order to bench LRANGE): 143061.52 requests per second LRANGE (first 100 elements): 29577.05 requests per second LRANGE (first 300 elements): 10431.88 requests per second LRANGE (first 450 elements): 7010.66 requests per second LRANGE (first 600 elements): 5296.61 requests per second
到此，相信大家對(duì)“Redis基準(zhǔn)參數(shù)怎么查看”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼