?2016-2026 Matools All rights reserved,
粵ICP備17059708號
1.什么是redis?
Redis 是一個基于內(nèi)存的高性能key-value數(shù)據(jù)庫。
2.Redis的特點(diǎn)
Redis本質(zhì)上是一個Key-Value類型的內(nèi)存數(shù)據(jù)庫，很像memcached，整個數(shù)據(jù)庫統(tǒng)統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過異步操作把數(shù)據(jù)庫數(shù)據(jù)flush到硬盤上進(jìn)行保存。因?yàn)槭羌儍?nèi)存操作，Redis的性能非常出色，每秒可以處理超過
10萬次讀寫操作，是已知性能最快的Key-Value DB。
Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數(shù)據(jù)結(jié)構(gòu)，此外單個value的最大限制是1GB，不像
memcached只能保存1MB的數(shù)據(jù)。因此Redis可以用來實(shí)現(xiàn)很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實(shí)現(xiàn)一個輕量級的高性
能消息隊列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。
另外Redis也可以對存入的Key-Value設(shè)置expire時間，因此也可以被當(dāng)作一 個功能加強(qiáng)版的memcached來用。
Redis的主要缺點(diǎn)是數(shù)據(jù)庫容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，因此Redis適合的場景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。
3.使用redis有哪些好處？
*
速度快：因?yàn)閿?shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復(fù)雜度都是O(1)
*
支持豐富數(shù)據(jù)類型：支持string，list，set，sorted set，hash
*
支持事務(wù)：操作都是原子性，所謂的原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行
*
豐富的特性：可用于緩存，消息，按key設(shè)置過期時間，過期后將會自動刪除
4.redis相比memcached有哪些優(yōu)勢？
*
memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型
*
redis的速度比memcached快很多
*
redis可以持久化其數(shù)據(jù)
5.Memcache與Redis的區(qū)別都有哪些？
*
存儲方式：Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會掛掉，數(shù)據(jù)不能超過內(nèi)存大小。Redis有部份存在硬盤上，這樣能保證數(shù)據(jù)的持久性。
*
數(shù)據(jù)支持類型：Memcache對數(shù)據(jù)類型支持相對簡單。Redis有復(fù)雜的數(shù)據(jù)類型。
*
使用底層模型不同：它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。Redis直接自己構(gòu)建了VM 機(jī)制
，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費(fèi)一定的時間去移動和請求。?
6.redis常見性能問題和解決方案：
1).Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會阻塞主線程的工作，當(dāng)快照比較大時對性能影響是非常大的，會間斷性暫停服務(wù)，所以Master最好不要寫內(nèi)存快照。
2).Master
AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化，如果數(shù)據(jù)比較關(guān)鍵，某個Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。
3).Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫停現(xiàn)象。
4).Redis主從復(fù)制的性能問題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個局域網(wǎng)內(nèi)
7.mySQL里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)，如何保證redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)
相關(guān)知識：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會施行數(shù)據(jù)淘汰策略（回收策略）。redis 提供 6種數(shù)據(jù)淘汰策略：
*
volatile-lru：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
*
volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
*
volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
*
allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰
*
allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
*
no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)
8.請用Redis和任意語言實(shí)現(xiàn)一段惡意登錄保護(hù)的代碼，限制1小時內(nèi)每用戶Id最多只能登錄5次。
具體登錄函數(shù)或功能用空函數(shù)即可，不用詳細(xì)寫出。
用列表實(shí)現(xiàn)：列表中每個元素代表登陸時間，只要最后的第5次登陸時間和現(xiàn)在時間差不超過1小時就禁止登陸。用Python寫的代碼如下：
1 #!/usr/bin/env python3 2 import redis 3 import sys 4 import time 5 6 r
= redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0) 7 try: 8 id =
sys.argv[1] 9 except: 10 print(‘input argument error’) 11 sys.exit(0) 12 if
r.llen(id) >= 5and time.time() – float(r.lindex(id, 4)) <= 3600: 13 print(“you
are forbidden logining”)14 else: 15 print(‘you are allowed to login’) 16
r.lpush(id, time.time())17 # login_func()
9.為什么redis需要把所有數(shù)據(jù)放到內(nèi)存中?
Redis為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將數(shù)據(jù)寫入磁盤。所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中，磁盤I/O速度為嚴(yán)重影響redis的性能。在內(nèi)存越來越便宜的今天，redis將會越來越受歡迎。
如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。
10.Redis是單進(jìn)程單線程的
redis利用隊列技術(shù)將并發(fā)訪問變?yōu)榇性L問，消除了傳統(tǒng)數(shù)據(jù)庫串行控制的開銷。
11.redis的并發(fā)競爭問題如何解決?
Redis為單進(jìn)程單線程模式，采用隊列模式將并發(fā)訪問變?yōu)榇性L問。Redis本身沒有鎖的概念，Redis對于多個客戶端連接并不存在競爭，但是在Jedis客戶端對Redis進(jìn)行并發(fā)訪問時會發(fā)生連接超時、數(shù)據(jù)轉(zhuǎn)換錯誤、阻塞、客戶端關(guān)閉連接等問題，這些問題均是
由于客戶端連接混亂造成。對此有2種解決方法：
*
客戶端角度，為保證每個客戶端間正常有序與Redis進(jìn)行通信，對連接進(jìn)行池化，同時對客戶端讀寫Redis操作采用內(nèi)部鎖synchronized。
*
服務(wù)器角度，利用setnx實(shí)現(xiàn)鎖。
注：對于第一種，需要應(yīng)用程序自己處理資源的同步，可以使用的方法比較通俗，可以使用synchronized也可以使用lock；第二種需要用到Redis的setnx命令，但是需要注意一些問題。
12.redis事物的了解CAS(check-and-set 操作實(shí)現(xiàn)樂觀鎖 )?
和眾多其它數(shù)據(jù)庫一樣，Redis作為NoSQL數(shù)據(jù)庫也同樣提供了事務(wù)機(jī)制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實(shí)現(xiàn)事務(wù)的基石。
相信對有關(guān)系型數(shù)據(jù)庫開發(fā)經(jīng)驗(yàn)的開發(fā)者而言這一概念并不陌生，即便如此，我們還是會簡要的列出Redis中事務(wù)的實(shí)現(xiàn)特征：
*
在事務(wù)中的所有命令都將會被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis不會再為其它客戶端的請求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。
*
和關(guān)系型數(shù)據(jù)庫中的事務(wù)相比，在Redis事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會被繼續(xù)執(zhí)行。
*
我們可以通過MULTI命令開啟一個事務(wù)，有關(guān)系型數(shù)據(jù)庫開發(fā)經(jīng)驗(yàn)的人可以將其理解為"BEGIN
TRANSACTION"語句。在該語句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作，最后我們可以通過執(zhí)行EXEC/DISCARD命令來提交/回滾該事務(wù)內(nèi)的所有操作。這兩個Redis命令可被視為等同于關(guān)系型數(shù)據(jù)庫中的COMMIT/ROLLBACK語句。
*
在事務(wù)開啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開，其后所有待執(zhí)行的語句都將不會被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后，那么該事務(wù)中的所有命令都會被服務(wù)器執(zhí)行。
*
當(dāng)使用Append-Only模式時，Redis會通過調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時也許只有部分?jǐn)?shù)據(jù)被寫入到磁盤，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。
Redis服務(wù)器會在重新啟動時執(zhí)行一系列必要的一致性檢測，一旦發(fā)現(xiàn)類似問題，就會立即退出并給出相應(yīng)的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯誤，并將已經(jīng)寫入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動Redis服務(wù)器了。
13.WATCH命令和基于CAS的樂觀鎖：
在Redis的事務(wù)中，WATCH命令可用于提供CAS(check-and-set)功能。假設(shè)我們通過WATCH命令在事務(wù)執(zhí)行之前監(jiān)控了多個Keys，倘若在WATCH之后有任何Key的值發(fā)生了變化，EXEC命令執(zhí)行的事務(wù)都將被放棄，同時返回Null
multi-bulk應(yīng)答以通知調(diào)用者事務(wù)執(zhí)行失敗。例如，我們再次假設(shè)Redis中并未提供incr命令來完成鍵值的原子性遞增，如果要實(shí)現(xiàn)該功能，我們只能自行編寫相應(yīng)的代碼。其偽碼如下：
1 val = GET mykey 2 val = val + 1 3 SET mykey $val
以上代碼只有在單連接的情況下才可以保證執(zhí)行結(jié)果是正確的，因?yàn)槿绻谕粫r刻有多個客戶端在同時執(zhí)行該段代碼，那么就會出現(xiàn)多線程程序中經(jīng)常出現(xiàn)的一種錯誤場景--競態(tài)爭用(race
condition)。
比如，客戶端A和B都在同一時刻讀取了mykey的原有值，假設(shè)該值為10，此后兩個客戶端又均將該值加一后set回Redis服務(wù)器，這樣就會導(dǎo)致mykey的結(jié)果為11，而不是我們認(rèn)為的12。為了解決類似的問題，我們需要借助WATCH命令的幫助，見如下代碼：
1 WATCH mykey 2 val = GET mykey 3 val = val + 1 4 MULTI 5 SET mykey $val 6
EXEC
和此前代碼不同的是，新代碼在獲取mykey的值之前先通過WATCH命令監(jiān)控了該鍵，此后又將set命令包圍在事務(wù)中，這樣就可以有效的保證每個連接在執(zhí)行EXEC之前，如果當(dāng)前連接獲取的mykey的值被其它連接的客戶端修改，那么當(dāng)前連接的EXEC命令將執(zhí)行失敗。這樣調(diào)用者在判斷返回值后就可以獲悉val是否被重新設(shè)置成功。
14.redis持久化的幾種方式
1、快照（snapshots）
缺省情況情況下，Redis把數(shù)據(jù)快照存放在磁盤上的二進(jìn)制文件中，文件名為dump。rdb。你可以配置Redis的持久化策略，例如數(shù)據(jù)集中每N秒鐘有超過M次更新，就將數(shù)據(jù)寫入磁盤；或者你可以手工調(diào)用命令SAVE或BGSAVE。
工作原理
*
Redis forks。
*
子進(jìn)程開始將數(shù)據(jù)寫到臨時RDB文件中。
*
當(dāng)子進(jìn)程完成寫RDB文件，用新文件替換老文件。
*
這種方式可以使Redis使用copy-on-write技術(shù)。
2、AOF
快照模式并不十分健壯，當(dāng)系統(tǒng)停止，或者無意中Redis被kill掉，最后寫入Redis的數(shù)據(jù)就會丟失。這對某些應(yīng)用也許不是大問題，但對于要求高可靠性的應(yīng)用來說，Redis就不是一個合適的選擇。
Append-only文件模式是另一種選擇。你可以在配置文件中打開AOF模式。
3、虛擬內(nèi)存方式
當(dāng)你的key很小而value很大時，使用VM的效果會比較好。因?yàn)檫@樣節(jié)約的內(nèi)存比較大。當(dāng)你的key不小時，可以考慮使用一些非常方法將很大的key變成很大的value，比如你可以考慮將key，value組合成一個新的value。
vm-max-threads這個參數(shù)，可以設(shè)置訪問swap文件的線程數(shù)，設(shè)置最好不要超過機(jī)器的核數(shù)，如果設(shè)置為0，那么所有對swap文件的操作都是串行的?？赡軙斐杀容^長時間的延遲，但是對數(shù)據(jù)完整性有很好的保證。
自己測試的時候發(fā)現(xiàn)用虛擬內(nèi)存性能也不錯。如果數(shù)據(jù)量很大，可以考慮分布式或者其他數(shù)據(jù)庫
15.redis的緩存失效策略和主鍵失效機(jī)制
作為緩存系統(tǒng)都要定期清理無效數(shù)據(jù)，就需要一個主鍵失效和淘汰策略。
在Redis當(dāng)中，有生存期的key被稱為volatile。在創(chuàng)建緩存時，要為給定的key設(shè)置生存期，當(dāng)key過期的時候（生存期為0），它可能會被刪除。
1、影響生存時間的一些操作
生存時間可以通過使用 DEL 命令來刪除整個 key 來移除，或者被 SET 和 GETSET
命令覆蓋原來的數(shù)據(jù)，也就是說，修改key對應(yīng)的value和使用另外相同的key和value來覆蓋以后，當(dāng)前數(shù)據(jù)的生存時間不同。
比如說，對一個 key 執(zhí)行INCR命令，對一個列表進(jìn)行LPUSH命令，或者對一個哈希表執(zhí)行HSET命令，這類操作都不會修改 key
本身的生存時間。另一方面，如果使用RENAME對一個 key 進(jìn)行改名，那么改名后的 key的生存時間和改名前一樣。
RENAME命令的另一種可能是，嘗試將一個帶生存時間的 key 改名成另一個帶生存時間的 another_key ，這時舊的 another_key
(以及它的生存時間)會被刪除，然后舊的 key 會改名為 another_key ，因此，新的 another_key 的生存時間也和原本的 key
一樣。使用PERSIST命令可以在不刪除 key 的情況下，移除 key 的生存時間，讓 key 重新成為一個persistent key 。
2、如何更新生存時間
可以對一個已經(jīng)帶有生存時間的 key
執(zhí)行EXPIRE命令，新指定的生存時間會取代舊的生存時間。過期時間的精度已經(jīng)被控制在1ms之內(nèi)，主鍵失效的時間復(fù)雜度是O（1），EXPIRE和TTL命令搭配使用，TTL可以查看key的當(dāng)前生存時間。設(shè)置成功返回
1；當(dāng) key 不存在或者不能為 key 設(shè)置生存時間時，返回 0 。
最大緩存配置
在 redis
中，允許用戶設(shè)置最大使用內(nèi)存大小，server。maxmemory默認(rèn)為0，沒有指定最大緩存，如果有新的數(shù)據(jù)添加，超過最大內(nèi)存，則會使redis崩潰，所以一定要設(shè)置。redis
內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會實(shí)行數(shù)據(jù)淘汰策略。
redis 提供 6種數(shù)據(jù)淘汰策略：
*
volatile-lru：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
*
volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
*
volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
*
allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰
*
allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
*
no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)
注意這里的6種機(jī)制，volatile和allkeys規(guī)定了是對已設(shè)置過期時間的數(shù)據(jù)集淘汰數(shù)據(jù)還是從全部數(shù)據(jù)集淘汰數(shù)據(jù)，后面的lru、ttl以及random是三種不同的淘汰策略，再加上一種no-enviction永不回收的策略。
使用策略規(guī)則：
*
如果數(shù)據(jù)呈現(xiàn)冪律分布，也就是一部分?jǐn)?shù)據(jù)訪問頻率高，一部分?jǐn)?shù)據(jù)訪問頻率低，則使用allkeys-lru
*
如果數(shù)據(jù)呈現(xiàn)平等分布，也就是所有的數(shù)據(jù)訪問頻率都相同，則使用allkeys-random
三種數(shù)據(jù)淘汰策略：
ttl和random比較容易理解，實(shí)現(xiàn)也會比較簡單。主要是Lru最近最少使用淘汰策略，設(shè)計上會對key 按失效時間排序，然后取最先失效的key進(jìn)行淘汰。
16.redis 最適合的場景
Redis最適合所有數(shù)據(jù)in-momory的場景，雖然Redis也提供持久化功能，但實(shí)際更多的是一個disk-backed的功能，跟傳統(tǒng)意義上的持久化有比較大的差別，那么可能大家就會有疑問，似乎Redis更像一個加強(qiáng)版的Memcached，那么何時使用Memcached，何時使用Redis呢?
如果簡單地比較Redis與Memcached的區(qū)別，大多數(shù)都會得到以下觀點(diǎn)：
*
Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。
*
Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。
*
Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時候可以再次加載進(jìn)行使用。
（1）、會話緩存（Session Cache）
最常用的一種使用Redis的情景是會話緩存（session
cache）。用Redis緩存會話比其他存儲（如Memcached）的優(yōu)勢在于：Redis提供持久化。當(dāng)維護(hù)一個不是嚴(yán)格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現(xiàn)在，他們還會這樣嗎？
幸運(yùn)的是，隨著 Redis 這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會話的文檔。甚至廣為人知的商業(yè)平臺Magento也提供Redis的插件。
（2）、全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平臺?；氐揭恢滦詥栴}，即使重啟了Redis實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進(jìn)，類似PHP本地FPC。
再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存后端。
此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。
（3）、隊列
Reids在內(nèi)存存儲引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set
操作，這使得Redis能作為一個很好的消息隊列平臺來使用。Redis作為隊列使用的操作，就類似于本地程序語言（如Python）對 list 的
push/pop 操作。
如果你快速的在Google中搜索“Redis
queues”，你馬上就能找到大量的開源項(xiàng)目，這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具，以滿足各種隊列需求。例如，Celery有一個后臺就是使用Redis作為broker，你可以從這里去查看。
（4）、排行榜/計數(shù)器
Redis在內(nèi)存中對數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。集合（Set）和有序集合（Sorted
Set）也使得我們在執(zhí)行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為“user_scores”。
當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù)，你需要這樣執(zhí)行：
ZRANGE?user_scores?0?10?WITHSCORES
Agora Games就是一個很好的例子，用Ruby實(shí)現(xiàn)的，它的排行榜就是使用Redis來存儲數(shù)據(jù)的，你可以在這里看到。
（5）、發(fā)布/訂閱
最后（但肯定不是最不重要的）是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場景確實(shí)非常多。我已看見人們在社交網(wǎng)絡(luò)連接中使用，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)?。ú唬@是真的，你可以去核實(shí)）。
Redis提供的所有特性中，我感覺這個是喜歡的人最少的一個，雖然它為用戶提供如此多功能。
熱門工具 換一換