redis如何被挖礦

A. redis被攻擊，怎麼預防

1，主從是必須的，不過現在redis的proxy還不穩定，主從異常還得手工切換
2，持久化，根據數據變化頻率和數據量，調整持久化參數，選擇RDB或者AOF做持久化
3，可是，如果是做緩存，最好是能從業務中重建的。
4，國內有個ssdb，個人測試的結果顯示ssdb能有redis 20%左右的性能，但集群比較好，一些項目中可以用來替換redis.

B. redis 如何測出redis的最高並發

1.評估光用 benchmark 不可靠，得具體根據你的業務使用場景，如使用 string 還是 list ，或者是 zset ， list 和 zset 長度不同有些操作的單次耗時是不同的，你得預估你的數據量，然後自己寫測試代碼，這樣最靠譜
2.一個 redis 撐不住可以用多個，具體兩種策略，一個是客戶端路由，一個是服務端加代理層，由服務端路由，如 codis
3.redis 內部是單線程的，所以不會有並發問題，即使你業務代碼是並發的，但是到 redis 那裡，你可以理解成一個隊列，先到先做，順序執行

PS:redis 最該考慮的我覺得還是容量問題，畢竟內存資源還是比較寶貴的

C. 求助各位，關於redis耗時比較嚴重的問題

（1）redis部署的機器性能，IO.CPU，帶寬等等都是沒有問題的
（2）我們訪問redis的伺服器的IO,CPU,負載也是沒問題的
（3）訪問redis使用的是mget操作，一次最多獲取50個key，查看redis的慢操作日誌，由於mget導致的查詢慢操作情況很少
（4）是否是由於訪問redis的服務訪問其他數據資源耗時嚴重的問題，因為服務還訪問了其他的redis資源，其他redis的耗時還算比較正常，因此可以排除這個問題

D. redis為什麼能實現秒殺

redis是單線程的 可以很好地解決並發問題
如果使用普通的代碼邏輯實現秒殺會出現並發問題導致多人秒殺成功貨物超發的情況 二使用redis可以把並發的請求進行隊列 就好像把一擁而上的人排成了一個隊一個一個來 先通過redis減庫存成功後在進入我們網站的資料庫進行減庫存，當redis中庫存沒有了請求就不會再進入數據秒殺就不會再成功

E. redis能解決並發嗎

可以

redis真的是一個很好的技術，它可以很好的在一定程度上解決網站一瞬間的並發量，例如商品搶購秒殺等活動。。。

redis之所以能解決高並發的原因是它可以直接訪問內存，而以往我們用的是資料庫(硬碟),提高了訪問效率,解決了資料庫伺服器壓力。

為什麼redis的地位越來越高，我們為何不選擇memcache，這是因為memcache只能存儲字元串，而redis存儲類型很豐富（例如有字元串、LIST、SET等），memcache每個值最大隻能存儲1M,存儲資源非常有限,十分消耗內存資源,而redis可以存儲1G,最重要的是memcache它不如redis安全,當伺服器發生故障或者意外關機等情況時,redsi會把內存中的數據備份到硬碟中,而memcache所存儲的東西全部丟失;這也說明了memcache不適合做資料庫來用,可以用來做緩存。

下面用redis解決瞬間秒殺活動來說明：

下面這個程序模擬了20w人一瞬間湧入這個頁面進行秒殺,能夠秒殺成功的只有500人,我們把先進來的用戶放入redis隊列中,當隊列中的用戶達到500時，後來用戶就轉到秒殺結束頁面。這里用隨機數來表示不同的用戶。

我們可以看到從秒殺成功隊列中依次取出的第一個用戶id是208522，最後一個用戶是176260，可以看出結果是很准確的。

redis在解決高並發這方面的能力是真的挺不錯的。

F. redis怎樣解決高並發

Redis是個單線程程序!這點必須銘記。

也許你會懷疑高並發的Redis 中間件怎麼可能是單線程。很抱歉，它就是單線程，你的懷疑暴露了你基礎知識的不足。莫要瞧不起單線程，除了Redis 之外，Node.js 也是單線程，Nginx也是單線程，但是它們都是伺服器高性能的典範。

Redis單線程為什麼還能這么快?

因為它所有的數據都在內存中，所有的運算都是內存級別的運算。正因為Redis是單線程，所以要小心使用Redis 指令，對於那些時間復雜度為O(n) 級別的指令，- -定要謹慎使用，一不小心就可能會導致Redis 卡頓。

Redis單線程如何處理那麼多的並發客戶端連接?

這個問題，有很多中高級程序員都無法回答，因為他們沒聽過多路復用這個詞彙，不知

道select 系列的事件輪詢API, 沒用過非阻塞IO。

非阻塞IO

G. redis是怎麼實現的

第一：Redis 是什麼？

Redis是基於內存、可持久化的日誌型、Key-Value資料庫 高性能存儲系統，並提供多種語言的API.

第二：出現背景

• 數據結構(Data Structure)需求越來越多, 但memcache中沒有, 影響開發效率

• 性能需求, 隨著讀操作的量的上升需要解決，經歷的過程有:
  資料庫讀寫分離(M/S)–>資料庫使用多個Slave–>增加Cache (memcache)–>轉到Redis

• 解決寫的問題：
  水平拆分，對表的拆分，將有的用戶放在這個表，有的用戶放在另外一個表；

• 可靠性需求
  Cache的"雪崩"問題讓人糾結
  Cache面臨著快速恢復的挑戰

• 開發成本需求
  Cache和DB的一致性維護成本越來越高(先清理DB, 再清理緩存, 不行啊, 太慢了!)
  開發需要跟上不斷湧入的產品需求
  硬體成本最貴的就是資料庫層面的機器，基本上比前端的機器要貴幾倍，主要是IO密集型，很耗硬體；

• 維護性復雜
  一致性維護成本越來越高；
  BerkeleyDB使用B樹，會一直寫新的，內部不會有文件重新組織；這樣會導致文件越來越大；大的時候需要進行文件歸檔，歸檔的操作要定期做；
  這樣，就需要有一定的down time；

基於以上考慮， 選擇了Redis

第三：Redis 在新浪微博中的應用

Redis簡介

1. 支持5種數據結構

支持strings, hashes, lists, sets, sorted sets
string是很好的存儲方式，用來做計數存儲。sets用於建立索引庫非常棒；

2. K-V 存儲 vs K-V 緩存

新浪微博目前使用的98%都是持久化的應用，2%的是緩存，用到了600+伺服器
Redis中持久化的應用和非持久化的方式不會差別很大：
非持久化的為8-9萬tps，那麼持久化在7-8萬tps左右；
當使用持久化時，需要考慮到持久化和寫性能的配比，也就是要考慮redis使用的內存大小和硬碟寫的速率的比例計算；

3. 社區活躍

Redis目前有3萬多行代碼, 代碼寫的精簡，有很多巧妙的實現，作者有技術潔癖
Redis的社區活躍度很高，這是衡量開源軟體質量的重要指標，開源軟體的初期一般都沒有商業技術服務支持，如果沒有活躍社區做支撐，一旦發生問題都無處求救；

Redis基本原理

redis持久化(aof) append online file：
寫log(aof), 到一定程度再和內存合並. 追加再追加, 順序寫磁碟, 對性能影響非常小

1. 單實例單進程

Redis使用的是單進程，所以在配置時，一個實例只會用到一個CPU；
在配置時，如果需要讓CPU使用率最大化，可以配置Redis實例數對應CPU數, Redis實例數對應埠數(8核Cpu, 8個實例, 8個埠), 以提高並發:
單機測試時, 單條數據在200位元組, 測試的結果為8~9萬tps；

2. Replication

過程: 數據寫到master–>master存儲到slave的rdb中–>slave載入rdb到內存。
存儲點(save point): 當網路中斷了, 連上之後, 繼續傳.
Master-slave下第一次同步是全傳，後面是增量同步；、

3. 數據一致性

長期運行後多個結點之間存在不一致的可能性；
開發兩個工具程序：
1.對於數據量大的數據，會周期性的全量檢查；
2.實時的檢查增量數據，是否具有一致性；

對於主庫未及時同步從庫導致的不一致，稱之為延時問題；
對於一致性要求不是那麼嚴格的場景，我們只需要要保證最終一致性即可；
對於延時問題，需要根據業務場景特點分析，從應用層面增加策略來解決這個問題；
例如：
1.新注冊的用戶，必須先查詢主庫；
2.注冊成功之後，需要等待3s之後跳轉，後台此時就是在做數據同步。

第四：分布式緩存的架構設計

1.架構設計

由於redis是單點，項目中需要使用，必須自己實現分布式。基本架構圖如下所示：



2.分布式實現

通過key做一致性哈希，實現key對應redis結點的分布。

一致性哈希的實現：

lhash值計算：通過支持MD5與MurmurHash兩種計算方式，默認是採用MurmurHash，高效的hash計算.

l一致性的實現：通過java的TreeMap來模擬環狀結構，實現均勻分布

3.client的選擇

對於jedis修改的主要是分區模塊的修改，使其支持了跟據BufferKey進行分區，跟據不同的redis結點信息，可以初始化不同的 ShardInfo，同時也修改了JedisPool的底層實現，使其連接pool池支持跟據key,value的構造方法，跟據不同 ShardInfos，創建不同的jedis連接客戶端，達到分區的效果，供應用層調用

4.模塊的說明

l臟數據處理模塊，處理失敗執行的緩存操作。

l屏蔽監控模塊，對於jedis操作的異常監控，當某結點出現異常可控制redis結點的切除等操作。

整個分布式模塊通過hornetq，來切除異常redis結點。對於新結點的增加，也可以通過reload方法實現增加。（此模塊對於新增結點也可以很方便實現）

對於以上分布式架構的實現滿足了項目的需求。另外使用中對於一些比較重要用途的緩存數據可以單獨設置一些redis結點，設定特定的優先順序。另外對 於緩存介面的設計，也可以跟據需求，實現基本介面與一些特殊邏輯介面。對於cas相關操作，以及一些事物操作可以通過其watch機制來實現。

聲明：所有博客服務於分布式框架，作為框架的技術支持及說明，框架面向企業，是大型互聯網分布式企業架構，後期會介紹linux上部署高可用集群項目。

H. 如何解決 redis value 較大的問題

used_memory是Redis使用的內存總量，它包含了實際緩存佔用的內存和Redis自身運行所佔用的內存(如元數據、lua)。它是由Redis使用內存分配器分配的內存，所以這個數據並沒有把內存碎片浪費掉的內存給統計進去。

I. redis怎麼取值

用 Get 命令取值：

redis 127.0.0.1:6379> GET KEY_NAME

詳見：http://www.apiref.com/redis-zh/24.html