redis挖礦原理
『壹』 redis原理，單線程怎麼做到高並發的
但線程，只能靠單個處理器速度，內存速度，處理器上的緩存速度，匯流排傳輸速度。餘下的是你的網路IO。但線程高並發完全依賴程序的運行速度。redis這種東西肯定不是但線程的。一個連接就是一個線程，你這樣理解應該不準確。
『貳』 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上部署高可用集群項目。
『叄』 redis如何實現多線程
redis是以單進程的形式運行的，命令是一個接著一個執行的，能很好的解決程序的並發問題
所以在當數據涉及並發問題 比如秒殺 我們就是把數據線存進redis 然後用戶請求的時候在redis中減庫存redis是單線程所以不會減超 redis減成功了之後就拒絕之後的請求然後在資料庫減庫存 這樣就不會出現庫存為負的問題 這就是基本的運作原理
『肆』 利用redis什麼原理實現分布式鎖
Redis有一系列的命令，特點是以NX結尾，NX是Not eXists的縮寫，如SETNX命令就應該理解為：SET if Not eXists。這系列的命令非常有用，這里講使用SETNX來實現分布式鎖。
用SETNX實現分布式鎖
利用SETNX非常簡單地實現分布式鎖。例如：某客戶端要獲得一個名字foo的鎖，客戶端使用下面的命令進行獲取：
SETNX lock.foo <current Unix time + lock timeout + 1>
如返回1，則該客戶端獲得鎖，把lock.foo的鍵值設置為時間值表示該鍵已被鎖定，該客戶端最後可以通過DEL lock.foo來釋放該鎖。
如返回0，表明該鎖已被其他客戶端取得，這時我們可以先返回或進行重試等對方完成或等待鎖超時。
解決死鎖
上面的鎖定邏輯有一個問題：如果一個持有鎖的客戶端失敗或崩潰了不能釋放鎖，該怎麼解決？我們可以通過鎖的鍵對應的時間戳來判斷這種情況是否發生了，如果當前的時間已經大於lock.foo的值，說明該鎖已失效，可以被重新使用。
發生這種情況時，可不能簡單的通過DEL來刪除鎖，然後再SETNX一次，當多個客戶端檢測到鎖超時後都會嘗試去釋放它，這里就可能出現一個競態條件,讓我們模擬一下這個場景：
C0操作超時了，但它還持有著鎖，C1和C2讀取lock.foo檢查時間戳，先後發現超時了。
C1 發送DEL lock.foo
C1 發送SETNX lock.foo 並且成功了。
C2 發送DEL lock.foo
C2 發送SETNX lock.foo 並且成功了。
這樣一來，C1，C2都拿到了鎖！問題大了！
幸好這種問題是可以避免D，讓我們來看看C3這個客戶端是怎樣做的：
C3發送SETNX lock.foo 想要獲得鎖，由於C0還持有鎖，所以Redis返回給C3一個0
C3發送GET lock.foo 以檢查鎖是否超時了，如果沒超時，則等待或重試。
反之，如果已超時，C3通過下面的操作來嘗試獲得鎖：
GETSET lock.foo <current Unix time + lock timeout + 1>
通過GETSET，C3拿到的時間戳如果仍然是超時的，那就說明，C3如願以償拿到鎖了。
如果在C3之前，有個叫C4的客戶端比C3快一步執行了上面的操作，那麼C3拿到的時間戳是個未超時的值，這時，C3沒有如期獲得鎖，需要再次等待或重試。留意一下，盡管C3沒拿到鎖，但它改寫了C4設置的鎖的超時值，不過這一點非常微小的誤差帶來的影響可以忽略不計。
注意：為了讓分布式鎖的演算法更穩鍵些，持有鎖的客戶端在解鎖之前應該再檢查一次自己的鎖是否已經超時，再去做DEL操作，因為可能客戶端因為某個耗時的操作而掛起，操作完的時候鎖因為超時已經被別人獲得，這時就不必解鎖了。
示例偽代碼
根據上面的代碼，我寫了一小段Fake代碼來描述使用分布式鎖的全過程：
# get lock
lock = 0
while lock != 1:
timestamp = current Unix time + lock timeout + 1
lock = SETNX lock.foo timestamp
if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):
break;
else:
sleep(10ms)
# do your job
do_job()
# release
if now() < GET lock.foo:
DEL lock.foo
是的，要想這段邏輯可以重用，使用python的你馬上就想到了Decorator，而用Java的你是不是也想到了那誰？AOP + annotation？行，怎樣舒服怎樣用吧，別重復代碼就行。
『伍』 redis和MQ做並發測試原理是什麼
1 單線程模型
Redis客戶端對服務端的每次調用都經歷了發送命令，執行命令，返回結果三個過程。其中執行命令階段，由於Redis是單線程來處理命令的，所有每一條到達服務端的命令不會立刻執行，所有的命令都會進入一個隊列中，然後逐個被執行。並且多個客戶端發送的命令的執行順序是不確定的。但是可以確定的是不會有兩條命令被同時執行，不會產生並發問題，這就是Redis的單線程基本模型。
2 單線程模型每秒萬級別處理能力的原因
（1）純內存訪問。數據存放在內存中，內存的響應時間大約是100納秒，這是Redis每秒萬億級別訪問的重要基礎。
（2）非阻塞I/O，Redis採用epoll做為I/O多路復用技術的實現，再加上Redis自身的事件處理模型將epoll中的連接，讀寫，關閉都轉換為了事件，不在I/O上浪費過多的時間。
（3）單線程避免了線程切換和競態產生的消耗。
（4）Redis採用單線程模型，每條命令執行如果佔用大量時間，會造成其他線程阻塞，對於Redis這種高性能服務是致命的，所以Redis是面向高速執行的資料庫。
『陸』 redis緩存原理
redis緩存原理是sql語句時key值，查詢結果resultSet是value，當同一個查詢語句訪問時（select * from t_proct），只要曾經查詢過，調用緩存直接返回resultSet，節省了資料庫讀取磁碟數據的時間。
redis的存儲分為內存存儲、磁碟存儲和log文件三部分，配置文件中有三個參數對其進行配置。
save seconds updates，save配置，指出在多長時間內，有多少次更新操作，就將數據同步到數據文件。這個可以多個條件配合，比如默認配置文件中的設置，就設置了三個條件。
appendonly yes/no ，appendonly配置，指出是否在每次更新操作後進行日誌記錄，如果不開啟，可能會在斷電時導致一段時間內的數據丟失。因為redis本身同步數據文件是按上面的save條件來同步的，所以有的數據會在一段時間內只存在於內存中。
(6)redis挖礦原理擴展閱讀
redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系資料庫起到很好的補充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。
Redis支持主從同步。數據可以從主伺服器向任意數量的從伺服器上同步，從伺服器可以是關聯其他從伺服器的主伺服器。這使得Redis可執行單層樹復制。
存檔可以有意無意的對數據進行寫操作。由於完全實現了發布/訂閱機制，使得從資料庫在任何地方同步樹時，可訂閱一個頻道並接收主伺服器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗餘很有幫助。
redis的官網地址，redis.io。（域名後綴io屬於國家域名，是british Indian Ocean territory，即英屬印度洋領地）
『柒』 使用redis實現的分布式鎖原理是什麼
一、寫在前面
現在面試，一般都會聊聊分布式系統這塊的東西。通常面試官都會從服務框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事務、分布式鎖、ZooKeeper等知識。
所以咱們這篇文章就來聊聊分布式鎖這塊知識，具體的來看看Redis分布式鎖的實現原理。
說實話，如果在公司里落地生產環境用分布式鎖的時候，一定是會用開源類庫的，比如Redis分布式鎖，一般就是用Redisson框架就好了，非常的簡便易用。
大家如果有興趣，可以去看看Redisson的官網，看看如何在項目中引入Redisson的依賴，然後基於Redis實現分布式鎖的加鎖與釋放鎖。
下面給大家看一段簡單的使用代碼片段，先直觀的感受一下：
大家看到了吧，那個myLock的hash數據結構中的那個客戶端ID，就對應著加鎖的次數
（5）釋放鎖機制
如果執行lock.unlock()，就可以釋放分布式鎖，此時的業務邏輯也是非常簡單的。
其實說白了，就是每次都對myLock數據結構中的那個加鎖次數減1。
如果發現加鎖次數是0了，說明這個客戶端已經不再持有鎖了，此時就會用：
「del myLock」命令，從redis里刪除這個key。
然後呢，另外的客戶端2就可以嘗試完成加鎖了。
這就是所謂的分布式鎖的開源Redisson框架的實現機制。
一般我們在生產系統中，可以用Redisson框架提供的這個類庫來基於redis進行分布式鎖的加鎖與釋放鎖。
（6）上述Redis分布式鎖的缺點
其實上面那種方案最大的問題，就是如果你對某個redis master實例，寫入了myLock這種鎖key的value，此時會非同步復制給對應的master slave實例。
但是這個過程中一旦發生redis master宕機，主備切換，redis slave變為了redis master。
接著就會導致，客戶端2來嘗試加鎖的時候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。
此時就會導致多個客戶端對一個分布式鎖完成了加鎖。
這時系統在業務語義上一定會出現問題，導致各種臟數據的產生。
所以這個就是redis cluster，或者是redis master-slave架構的主從非同步復制導致的redis分布式鎖的最大缺陷：在redis master實例宕機的時候，可能導致多個客戶端同時完成加鎖。
『捌』 redis怎樣解決高並發
Redis是個單線程程序!這點必須銘記。
也許你會懷疑高並發的Redis 中間件怎麼可能是單線程。很抱歉，它就是單線程，你的懷疑暴露了你基礎知識的不足。莫要瞧不起單線程，除了Redis 之外，Node.js 也是單線程，Nginx也是單線程，但是它們都是伺服器高性能的典範。
Redis單線程為什麼還能這么快?
因為它所有的數據都在內存中，所有的運算都是內存級別的運算。正因為Redis是單線程，所以要小心使用Redis 指令，對於那些時間復雜度為O(n) 級別的指令，- -定要謹慎使用，一不小心就可能會導致Redis 卡頓。
Redis單線程如何處理那麼多的並發客戶端連接?
這個問題，有很多中高級程序員都無法回答，因為他們沒聽過多路復用這個詞彙，不知
道select 系列的事件輪詢API, 沒用過非阻塞IO。
非阻塞IO