全網最全整理60個Redis面試題

• • 1、Redis是什麼
  • 2、Redis相比memcached有哪些優勢
  • 3、Redis是單線程
  • 4、Reids常用5種資料類型
  • 5、Reids6種淘汰政策：
  • 6、Redis的并發競争問題如何解決?
  • 7、Redis是使用c語言開發的
  • 8、Redis前端啟動指令
  • 9、Reids支援的語言：
  • 10、Redis 持久化方案：
  • 11、Redis 的主從複制
  • 12、Redis是單線程的，但Redis為什麼這麼快？
  • 13、為什麼Redis是單線程的？
  • 14、Redis info檢視指令：info memory
  • 15、Redis記憶體模型
  • 16、Redis記憶體劃分
  • • 1）資料
    • 2）程序本身運作需要的記憶體
    • 3）緩沖記憶體
    • 4）記憶體碎片
  • 17.Redis對象有5種類型
  • 18.Redis沒有直接使用C字元串
  • 19.Reidis的SDS在C字元串的基礎上加入了free和len字段
  • 20.Reids主從複制
  • 21、Redis哨兵
  • 22、Reids持久化觸發條件
  • 23、Redis 開啟AOF
  • 24、AOF常用配置總結
  • 25、RDB和AOF的優缺點
  • 26、持久化政策選擇
  • 27、redis緩存被擊穿處理機制
  • 28、Redis還提供的進階工具
  • 29、Redis常用管理指令
  • 30、緩存有哪些類型
  • • 1）本地緩存：
    • 2）分布式緩存：
    • 3）多級緩存：
  • 31、Reids工具指令
  • 32、為什麼需要持久化？
  • 33、判斷key是否存在
  • 34、删除key
  • 35、緩存和資料庫間資料一緻性問題
  • 36、布隆過濾器
  • 37、緩存雪崩問題
  • 38、緩存并發問題
  • 39、Redis分布式
  • 40、讀寫分離模型
  • 41、資料分片模型
  • 42、redis常見性能問題和解決方案：
  • 43、redis通訊協定
  • 44、Redis分布式鎖實作
  • 45、Redis做異步隊列
  • 46、Redis中海量資料的正确操作方式
  • 47、SCAN系列指令注意事項
  • 48、Redis 管道 Pipeline
  • 49、事務不支援復原
  • 50、手寫一個 LRU 算法
  • 51、多節點 Redis 分布式鎖：Redlock 算法
  • 52、Redis 中設定過期時間主要通過以下四種方式
  • 53、Reids三種不同删除政策
  • 54、定時删除
  • 55、定期删除
  • 56、惰性删除
  • 57、Reids 管理工具：Redis Manager 2.0
  • 58、Redis常見的幾種緩存政策
  • 59、Redis Module 實作布隆過濾器
  • 60、Redis 到底是怎麼實作“附近的人”

1、Redis是什麼

是一個基于記憶體的高性能key-value資料庫

2、Redis相比memcached有哪些優勢

memcached所有的值均是簡單的字元串

redis作為其替代者，支援更為豐富的資料類型

redis的速度比memcached快很多

redis可以持久化其資料

3、Redis是單線程

redis利用隊列技術将并發通路變為串行通路，消除了傳統資料庫串行控制的開銷

4、Reids常用5種資料類型

string，list，set，sorted set，hash

5、Reids6種淘汰政策：

noeviction: 不删除政策, 達到最大記憶體限制時, 如果需要更多記憶體, 直接傳回錯誤資訊。大多數寫指令都會導緻占用更多的記憶體(有極少數會例外。

**allkeys-lru:**所有key通用; 優先删除最近最少使用(less recently used ,LRU) 的 key。

**volatile-lru:**隻限于設定了 expire 的部分; 優先删除最近最少使用(less recently used ,LRU) 的 key。

**allkeys-random:**所有key通用; 随機删除一部分 key。

volatile-random: 隻限于設定了 expire 的部分; 随機删除一部分 key。

volatile-ttl: 隻限于設定了 expire 的部分; 優先删除剩餘時間(time to live,TTL) 短的key。

6、Redis的并發競争問題如何解決?

單程序單線程模式，采用隊列模式将并發通路變為串行通路。Redis本身沒有鎖的概念，Redis對于多個用戶端連接配接并不存在競争，利用setnx實作鎖。

7、Redis是使用c語言開發的

8、Redis前端啟動指令

./redis-server

9、Reids支援的語言：

java、C、C#、C++、php、Node.js、Go等。

10、Redis 持久化方案：

Rdb 和 Aof

11、Redis 的主從複制

持久化保證了即使redis服務重新開機也不會丢失資料，因為redis服務重新開機後會将硬碟上持久化的資料恢複到記憶體中，但是當redis伺服器的硬碟損壞了可能會導緻資料丢失，如果通過redis的主從複制機制就可以避免這種單點故障

12、Redis是單線程的，但Redis為什麼這麼快？

1、完全基于記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似于HashMap，HashMap的優勢就是查找和操作的時間複雜度都是O(1)；

2、資料結構簡單，對資料操作也簡單，Redis中的資料結構是專門進行設計的；

3、采用單線程，避免了不必要的上下文切換和競争條件，也不存在多程序或者多線程導緻的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導緻的性能消耗；

4、使用多路I/O複用模型，非阻塞IO；這裡“多路”指的是多個網絡連接配接，“複用”指的是複用同一個線程

5、使用底層模型不同，它們之間底層實作方式以及與用戶端之間通信的應用協定不一樣，Redis直接自己建構了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求；

13、為什麼Redis是單線程的？

Redis是基于記憶體的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或者網絡帶寬。既然單線程容易實作，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了（畢竟采用多線程會有很多麻煩！）。

14、Redis info檢視指令：info memory

15、Redis記憶體模型

used_memory：Redis配置設定器配置設定的記憶體總量（機關是位元組），包括使用的虛拟記憶體（即swap）；Redis配置設定器後面會介紹。used_memory_human隻是顯示更友好。

used_memory_rss**：**Redis程序占據作業系統的記憶體（機關是位元組），與top及ps指令看到的值是一緻的；除了配置設定器配置設定的記憶體之外，used_memory_rss還包括程序運作本身需要的記憶體、記憶體碎片等，但是不包括虛拟記憶體。

mem_fragmentation_ratio**：**記憶體碎片比率，該值是used_memory_rss / used_memory的比值。

mem_allocator**：**Redis使用的記憶體配置設定器，在編譯時指定；可以是 libc 、jemalloc或者tcmalloc，預設是jemalloc；截圖中使用的便是預設的jemalloc。

16、Redis記憶體劃分

1）資料

作為資料庫，資料是最主要的部分；這部分占用的記憶體會統計在used_memory中。

2）程序本身運作需要的記憶體

Redis主程序本身運作肯定需要占用記憶體，如代碼、常量池等等；這部分記憶體大約幾兆，在大多數生産環境中與Redis資料占用的記憶體相比可以忽略。這部分記憶體不是由jemalloc配置設定，是以不會統計在used_memory中。

3）緩沖記憶體

緩沖記憶體包括用戶端緩沖區、複制積壓緩沖區、AOF緩沖區等；其中，用戶端緩沖存儲用戶端連接配接的輸入輸出緩沖；複制積壓緩沖用于部分複制功能；

AOF緩沖區用于在進行AOF重寫時，儲存最近的寫入指令。在了解相應功能之前，不需要知道這些緩沖的細節；這部分記憶體由jemalloc配置設定，是以會統計在used_memory中。

4）記憶體碎片

記憶體碎片是Redis在配置設定、回收實體記憶體過程中産生的。例如，如果對資料的更改頻繁，而且資料之間的大小相差很大，可能導緻redis釋放的空間在實體記憶體中并沒有釋放，但redis又無法有效利用，這就形成了記憶體碎片。記憶體碎片不會統計在used_memory中。

17.Redis對象有5種類型

無論是哪種類型，Redis都不會直接存儲，而是通過redisObject對象進行存儲。

18.Redis沒有直接使用C字元串

(即以空字元’\0’結尾的字元數組)作為預設的字元串表示，而是使用了SDS。SDS是簡單動态字元串(Simple Dynamic String)的縮寫。

19.Reidis的SDS在C字元串的基礎上加入了free和len字段

20.Reids主從複制

複制是高可用Redis的基礎，哨兵和叢集都是在複制基礎上實作高可用的。複制主要實作了資料的多機備份，以及對于讀操作的負載均衡和簡單的故障恢複。缺陷：故障恢複無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。

21、Redis哨兵

在複制的基礎上，哨兵實作了自動化的故障恢複。

缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。

22、Reids持久化觸發條件

RDB持久化的觸發分為手動觸發和自動觸發兩種。

23、Redis 開啟AOF

Redis伺服器預設開啟RDB，關閉AOF；

要開啟AOF，需要在配置檔案中配置：

appendonly yes

24、AOF常用配置總結

下面是AOF常用的配置項，以及預設值；前面介紹過的這裡不再詳細介紹。

appendonly no：是否開啟AOFappendfilename “appendonly.aof”：AOF檔案名dir ./：

RDB檔案和AOF檔案所在目錄appendfsync everysec：fsync持久化政策no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕檔案重寫時CPU和硬碟的負載（尤其是硬碟），但是可能會丢失AOF重寫期間的資料；需要在負載和安全性之間進行平衡auto-aof-rewrite-percentage 100：檔案重寫觸發條件之一auto-aof-rewrite-min-size 64mb：檔案重寫觸發送出之一aof-load-truncated yes：如果AOF檔案結尾損壞，Redis啟動時是否仍載入AOF檔案

25、RDB和AOF的優缺點

RDB持久化

優點：RDB檔案緊湊，體積小，網絡傳輸快，适合全量複制；恢複速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。

缺點：RDB檔案的緻命缺點在于其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料的大量丢失很多時候是無法接受的，是以AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差（如老版本的Redis不相容新版本的RDB檔案）。

AOF持久化

與RDB持久化相對應，AOF的優點在于支援秒級持久化、相容性好，缺點是檔案大、恢複速度慢、對性能影響大。

26、持久化政策選擇

（1）如果Redis中的資料完全丢棄也沒有關系（如Redis完全用作DB層資料的cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。

（2）在單機環境下（對于個人開發者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的資料丢失，選擇RDB對Redis的性能更加有利；如果隻能接受秒級别的資料丢失，應該選擇AOF。

（3）但在多數情況下，我們都會配置主從環境，slave的存在既可以實作資料的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。

27、redis緩存被擊穿處理機制

使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用緩存工具的某些帶成功操作傳回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一個mutex key，當操作傳回成功時，再進行load db的操作并回設緩存；否則，就重試整個get緩存的方法

28、Redis還提供的進階工具

像慢查詢分析、性能測試、Pipeline、事務、Lua自定義指令、Bitmaps、HyperLogLog、釋出/訂閱、Geo等個性化功能。

29、Redis常用管理指令

dbsize 傳回目前資料庫 key 的數量。

info 傳回目前 redis 伺服器狀态和一些統計資訊。

monitor 實時監聽并傳回redis伺服器接收到的所有請求資訊。

shutdown 把資料同步儲存到磁盤上，并關閉redis服務。

config get parameter 擷取一個 redis 配置參數資訊。（個别參數可能無法擷取）

config set parameter value 設定一個 redis 配置參數資訊。（個别參數可能無法擷取）

config resetstat 重置 info 指令的統計資訊。（重置包括：keyspace 命中數、

keyspace 錯誤數、 處理指令數，接收連接配接數、過期 key 數）

debug object key 擷取一個 key 的調試資訊。

debug segfault 制造一次伺服器當機。

flushdb 删除目前資料庫中所有 key,此方法不會失敗。小心慎用

flushall 删除全部資料庫中所有 key，此方法不會失敗。小心慎用

30、緩存有哪些類型

緩存是高并發場景下提高熱點資料通路性能的一個有效手段，在開發項目時會經常使用到。

緩存的類型分為：本地緩存、分布式緩存和多級緩存。

1）本地緩存：

本地緩存就是在程序的記憶體中進行緩存，比如我們的 JVM 堆中，可以用 LRUMap 來實作，也可以使用 Ehcache 這樣的工具來實作。

本地緩存是記憶體通路，沒有遠端互動開銷，性能最好，但是受限于單機容量，一般緩存較小且無法擴充。

2）分布式緩存：

分布式緩存可以很好得解決這個問題。

分布式緩存一般都具有良好的水準擴充能力，對較大資料量的場景也能應付自如。缺點就是需要進行遠端請求，性能不如本地緩存。

3）多級緩存：

為了平衡這種情況，實際業務中一般采用多級緩存，本地緩存隻儲存通路頻率最高的部分熱點資料，其他的熱點資料放在分布式緩存中。

在目前的一線大廠中，這也是最常用的緩存方案，單考單一的緩存方案往往難以撐住很多高并發的場景。

31、Reids工具指令

redis-server：Redis 伺服器的 daemon 啟動程式

redis-cli：Redis 指令行操作工具。當然，你也可以用 telnet 根據其純文字協定來操作

redis-benchmark：Redis 性能測試工具，測試 Redis 在你的系統及你的配置下的讀寫性能

redis-benchmark -n 100000 –c 50

#模拟同時由 50 個用戶端發送 100000 個 SETs/GETs 查詢

redis-check-aof：更新日志檢查

redis-check-dump：本地資料庫檢查

32、為什麼需要持久化？

由于Redis是一種記憶體型資料庫，即伺服器在運作時，系統為其配置設定了一部分記憶體存儲資料，一旦伺服器挂了，或者突然當機了，那麼資料庫裡面的資料将會丢失，為了使伺服器即使突然關機也能儲存資料，必須通過持久化的方式将資料從記憶體儲存到磁盤中。

33、判斷key是否存在

exists key +key名字

存在則是1，不存在，則0

34、删除key

del key1 key2 …

35、緩存和資料庫間資料一緻性問題

分布式環境下（單機就不用說了）非常容易出現緩存和資料庫間的資料一緻性問題，針對這一點的話，隻能說，如果你的項目對緩存的要求是強一緻性的，那麼請不要使用緩存。我們隻能采取合适的政策來降低緩存和資料庫間資料不一緻的機率，而無法保證兩者間的強一緻性。合适的政策包括 合适的緩存更新政策，更新資料庫後要及時更新緩存、緩存失敗時增加重試機制，例如MQ模式的消息隊列。

36、布隆過濾器

bloomfilter就類似于一個hash set，用于快速判某個元素是否存在于集合中，其典型的應用場景就是快速判斷一個key是否存在于某容器，不存在就直接傳回。布隆過濾器的關鍵就在于hash算法和容器大小

37、緩存雪崩問題

存在同一時間内大量鍵過期（失效），接着來的一大波請求瞬間都落在了資料庫中導緻連接配接異常。

解決方案：

1、也是像解決緩存穿透一樣加鎖排隊。

2、建立備份緩存，緩存A和緩存B，A設定逾時時間，B不設值逾時時間，先從A讀緩存，A沒有讀B，并且更新A緩存和B緩存;

38、緩存并發問題

這裡的并發指的是多個redis的client同時set key引起的并發問題。比較有效的解決方案就是把redis.set操作放在隊列中使其串行化，必須的一個一個執行，具體的代碼就不上了，當然加鎖也是可以的，至于為什麼不用redis中的事務，留給各位看官自己思考探究。

39、Redis分布式

redis支援主從的模式。原則：Master會将資料同步到slave，而slave不會将資料同步到master。Slave啟動時會連接配接master來同步資料。

這是一個典型的分布式讀寫分離模型。我們可以利用master來插入資料，slave提供檢索服務。這樣可以有效減少單個機器的并發通路數量

40、讀寫分離模型

通過增加Slave DB的數量，讀的性能可以線性增長。為了避免Master DB的單點故障，叢集一般都會采用兩台Master DB做雙機熱備，是以整個叢集的讀和寫的可用性都非常高。讀寫分離架構的缺陷在于，不管是Master還是Slave，每個節點都必須儲存完整的資料，如果在資料量很大的情況下，叢集的擴充能力還是受限于單個節點的存儲能力，而且對于Write-intensive類型的應用，讀寫分離架構并不适合。

41、資料分片模型

為了解決讀寫分離模型的缺陷，可以将資料分片模型應用進來。

可以将每個節點看成都是獨立的master，然後通過業務實作資料分片。

結合上面兩種模型，可以将每個master設計成由一個master和多個slave組成的模型。

42、redis常見性能問題和解決方案：

Master最好不要做任何持久化工作，如RDB記憶體快照和AOF日志檔案

如果資料比較重要，某個Slave開啟AOF備份資料，政策設定為每秒同步一次

為了主從複制的速度和連接配接的穩定性，Master和Slave最好在同一個區域網路内

盡量避免在壓力很大的主庫上增加從庫

43、redis通訊協定

RESP 是redis用戶端和服務端之前使用的一種通訊協定；RESP 的特點：實作簡單、快速解析、可讀性好

44、Redis分布式鎖實作

先拿setnx來争搶鎖，搶到之後，再用expire給鎖加一個過期時間防止鎖忘記了釋放。**如果在setnx之後執行expire之前程序意外crash或者要重新開機維護了，那會怎麼樣？**set指令有非常複雜的參數，這個應該是可以同時把setnx和expire合成一條指令來用的！

45、Redis做異步隊列

一般使用list結構作為隊列，rpush生産消息，lpop消費消息。當lpop沒有消息的時候，要适當sleep一會再重試。缺點：在消費者下線的情況下，生産的消息會丢失，得使用專業的消息隊列如rabbitmq等。**能不能生産一次消費多次呢？**使用pub/sub主題訂閱者模式，可以實作1:N的消息隊列。

46、Redis中海量資料的正确操作方式

利用SCAN系列指令（SCAN、SSCAN、HSCAN、ZSCAN）完成資料疊代。

47、SCAN系列指令注意事項

SCAN的參數沒有key，因為其疊代對象是DB内資料；傳回值都是數組，第一個值都是下一次疊代遊标；時間複雜度：每次請求都是O(1)，完成所有疊代需要O(N)，N是元素數量；可用版本：version >= 2.8.0；
           

48、Redis 管道 Pipeline

在某些場景下我們在一次操作中可能需要執行多個指令，而如果我們隻是一個指令一個指令去執行則會浪費很多網絡消耗時間，如果将指令一次性傳輸到 Redis中去再執行，則會減少很多開銷時間。但是需要注意的是 pipeline中的指令并不是原子性執行的，也就是說管道中的指令到達 Redis伺服器的時候可能會被其他的指令穿插

49、事務不支援復原

50、手寫一個 LRU 算法

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int CACHE_SIZE;

    /**
     * 傳遞進來最多能緩存多少資料
     *
     * @param cacheSize 緩存大小
     */
    public LRUCache(int cacheSize) {
        // true 表示讓 linkedHashMap 按照通路順序來進行排序，最近通路的放在頭部，最老通路的放在尾部。
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        // 當 map中的資料量大于指定的緩存個數的時候，就自動删除最老的資料。
        return size() > CACHE_SIZE;
    }
}
           

51、多節點 Redis 分布式鎖：Redlock 算法

擷取目前時間（start）。

依次向 N 個 Redis節點請求鎖。請求鎖的方式與從單節點 Redis擷取鎖的方式一緻。為了保證在某個 Redis節點不可用時該算法能夠繼續運作，擷取鎖的操作都需要設定逾時時間，需要保證該逾時時間遠小于鎖的有效時間。這樣才能保證用戶端在向某個 Redis節點擷取鎖失敗之後，可以立刻嘗試下一個節點。

計算擷取鎖的過程總共消耗多長時間（consumeTime = end - start）。如果用戶端從大多數 Redis節點（>= N/2 + 1) 成功擷取鎖，并且擷取鎖總時長沒有超過鎖的有效時間，這種情況下，用戶端會認為擷取鎖成功，否則，擷取鎖失敗。

如果最終擷取鎖成功，鎖的有效時間應該重新設定為鎖最初的有效時間減去 consumeTime。

如果最終擷取鎖失敗，用戶端應該立刻向所有 Redis節點發起釋放鎖的請求。

52、Redis 中設定過期時間主要通過以下四種方式

expire key seconds：設定 key 在 n 秒後過期；pexpire key milliseconds：設定 key 在 n 毫秒後過期；expireat key timestamp：設定 key 在某個時間戳（精确到秒）之後過期；pexpireat key millisecondsTimestamp：設定 key 在某個時間戳（精确到毫秒）之後過期；
           

53、Reids三種不同删除政策

定時删除：在設定鍵的過期時間的同時，建立一個定時任務，當鍵達到過期時間時，立即執行對鍵的删除操作

惰性删除：放任鍵過期不管，但在每次從鍵空間擷取鍵時，都檢查取得的鍵是否過期，如果過期的話，就删除該鍵，如果沒有過期，就傳回該鍵

定期删除：每隔一點時間，程式就對資料庫進行一次檢查，删除裡面的過期鍵，至于要删除多少過期鍵，以及要檢查多少個資料庫，則由算法決定。

54、定時删除

優點：對記憶體友好，定時删除政策可以保證過期鍵會盡可能快地被删除，并釋放國期間所占用的記憶體

缺點：對cpu時間不友好，在過期鍵比較多時，删除任務會占用很大一部分cpu時間，在記憶體不緊張但cpu時間緊張的情況下，将cpu時間用在删除和目前任務無關的過期鍵上，影響伺服器的響應時間和吞吐量

55、定期删除

由于定時删除會占用太多cpu時間，影響伺服器的響應時間和吞吐量以及惰性删除浪費太多記憶體，有記憶體洩露的危險，是以出現一種整合和折中這兩種政策的定期删除政策。

定期删除政策每隔一段時間執行一次删除過期鍵操作，并通過限制删除操作執行的時長和頻率來減少删除操作對CPU時間的影響。定時删除政策有效地減少了因為過期鍵帶來的記憶體浪費。

56、惰性删除

優點：對cpu時間友好，在每次從鍵空間擷取鍵時進行過期鍵檢查并是否删除，删除目标也僅限目前處理的鍵，這個政策不會在其他無關的删除任務上花費任何cpu時間。

缺點：對記憶體不友好，過期鍵過期也可能不會被删除，導緻所占的記憶體也不會釋放。甚至可能會出現記憶體洩露的現象，當存在很多過期鍵，而這些過期鍵又沒有被通路到，這會可能導緻它們會一直儲存在記憶體中，造成記憶體洩露。

57、Reids 管理工具：Redis Manager 2.0

https://github.com/ngbdf/redis-manager

github位址

58、Redis常見的幾種緩存政策

Cache-Aside
Read-Through
Write-Through
Write-Behind
           

59、Redis Module 實作布隆過濾器

Redis module 是Redis 4.0 以後支援的新的特性，這裡很多國外牛逼的大學和機構提供了很多牛逼的Module 隻要編譯引入到Redis 中就能輕松的實作我們某些需求的功能。在Redis 官方Module 中有一些我們常見的一些子產品，我們在這裡就做一個簡單的使用。

neural-redis 主要是神經網絡的機器學，內建到redis 可以做一些機器訓練感興趣的可以嘗試RedisSearch 主要支援一些富文本的的搜尋RedisBloom 支援分布式環境下的Bloom 過濾器

60、Redis 到底是怎麼實作“附近的人”

使用方式

GEOADD key longitude latitude member [longitude latitude member …]

将給定的位置對象（緯度、經度、名字）添加到指定的key。其中，key為集合名稱，member為該經緯度所對應的對象。在實際運用中，當所需存儲的對象數量過多時，可通過設定多key(如一個省一個key)的方式對對象集合變相做sharding，避免單集合數量過多。

成功插入後的傳回值：

(integer) N

其中N為成功插入的個數。