Redis與其他key-value存儲有什么不同?

　　Redis有著更為復雜的數(shù)據(jù)結構并且提供對他們的原子性操作，這是一個不同于其他數(shù)據(jù)庫的進化路徑。

　　Redis的數(shù)據(jù)類型都是基于基本數(shù)據(jù)結構的同時對程序員透明，無需進行額外的抽象。

　　Redis運行在內(nèi)存中但是可以持久化到磁盤，所以在對不同數(shù)據(jù)集進行高速讀寫時需要權衡內(nèi)存，應為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫方面的另一個優(yōu)點是， 相比在磁盤上相同的復雜的數(shù)據(jù)結構，在內(nèi)存中操作起來非常簡單，這樣Redis可以做很多內(nèi)部復雜性很強的事情。

　　同時，在磁盤格式方面他們是緊湊的以追加的方式產(chǎn)生的，因為他們并不需要進行隨機訪問。

　　Redis的內(nèi)存占用情況怎么樣?

　　給你舉個例子： 100萬個鍵值對(鍵是0到999999值是字符串“hello world”)在我的32位的Mac筆記本上 用了100MB。同樣的數(shù)據(jù)放到一個key里只需要16MB， 這是因為鍵值有一個很大的開銷。 在Memcached上執(zhí)行也是類似的結果，但是相對Redis的開銷要小一點點，因為Redis會記錄類型信息引用計數(shù)等等。當然，大鍵值對時兩者的比例要好很多。64位的系統(tǒng)比32位的需要更多的內(nèi)存開銷，尤其是鍵值對都較小時，這是因為64位的系統(tǒng)里指針占用了8個字節(jié)。 但是，當然，64位系統(tǒng)支持更大的內(nèi)存，所以為了運行大型的Redis服務器或多或少的需要使用64位的系統(tǒng)。

　　都有哪些辦法可以降低Redis的內(nèi)存使用情況呢?

　　如果你使用的是32位的Redis實例，可以好好利用Hash,list,sorted set,set等集合類型數(shù)據(jù)，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到一起。

　　查看Redis使用情況及狀態(tài)信息用什么命令?

　　info

　　Redis是單線程的，如何提高多核CPU的利用率?

　　可以在同一個服務器部署多個Redis的實例，并把他們當作不同的服務器來使用，在某些時候，無論如何一個服務器是不夠的， 所以，如果你想使用多個CPU，你可以考慮一下分片(shard)。

　　一個Redis實例最多能存放多少的keys?

　　List、Set、Sorted Set他們最多能存放多少元素?理論上Redis可以處理多達232的keys，并且在實際中進行了測試，每個實例至少存放了2億5千萬的keys。我們正在測試一些較大的值。

　　任何list、set、和sorted set都可以放232個元素。換句話說，Redis的存儲極限是系統(tǒng)中的可用內(nèi)存值。

　　修改配置不重啟Redis會實時生效嗎?

　　針對運行實例，有許多配置選項可以通過 CONFIG SET 命令進行修改，而無需執(zhí)行任何形式的重啟。

　　從 Redis 2.2 開始，可以從 AOF 切換到 RDB 的快照持久性或其他方式而不需要重啟 Redis。

　　檢索 ‘CONFIG GET *’ 命令獲取更多信息。但偶爾重新啟動是必須的，如為升級 Redis 程序到新的版本，或者當你需要修改某些目前 CONFIG 命令還不支持的配置參數(shù)的時候。

　　Redis常見性能問題和解決方案?

　　(1) Master最好不要做任何持久化工作，如RDB內(nèi)存快照和AOF日志文件

　　(2) 如果數(shù)據(jù)比較重要，某個Slave開啟AOF備份數(shù)據(jù)，策略設置為每秒同步一次

　　(3) 為了主從復制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域網(wǎng)內(nèi)

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

　　(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩(wěn)定，即：Master