高併發情況下Redis 的可用性測試與分析及部署架構說明
建立執行緒數在50以下時程式可以正常執行，當執行緒數設定為100以上時，某些執行緒執行出現異常：
java.net.SocketTimeoutException: Read timed out
造成這種異常可能有以下兩個原因：
原因一：在連線Redis的Jedis的預設構造方法中，超時一般被預設設定為2000毫秒，也就是2秒。當然這個時間，對於Redis這種從記憶體中讀取資料的資料庫來說應該是相當大了，但是為什麼還會超時？可能的原因是，當Redis的資料量很大時，可能在Redis server可能會出現超時。因為Redis在執行時，是單執行緒來處理所有的客戶端的連線的。當連線數非常多或者資料量很大時，也要遵循FIFO的排程策略，這就造成等待佇列過長，因此可能會出現超時的情況。
解決方法：嘗試在呼叫jedis的構造方法時，將超時時間設定的更大些。
Jedis jedis = new Jedis("127.0.0.1", 8371,100000);//將超時時間設定為100000毫秒
原因二：因為Redis是基於TCP連線的，大量資料反覆互動相當於遠端讀寫記憶體的操作，勢必會造成頻寬的使用緊張，在頻寬吃緊的情況下，Redis客戶端即Jedis拿不到連線或拿不到後續資料包。
解決方法：最直接的方法是增加頻寬，但針對這種問題，對併發互動資料的頻率進行調整，對資料量進行精減才是解決這一問題的最佳方案。
2、AOF模式相關問題與快照模式的優點
建立50個執行緒，執行1分鐘之後，每個執行緒大約迴圈了13800次，AOF日誌（appendonly.aof）的大小是25.5M。Redis重啟時會先載入appendonly.aof檔案，載入25M配置檔案大約耗時5秒。同時做了多次突然關閉Redis 的試驗，日誌記錄準確沒有出現丟失資料的情況。
AOF生成的命令日誌，只是操作過程的記錄檔案，它的主要作用是保證高可用性。因為在高併發的情況下，AOF日誌檔案appendonly.aof會迅速變得很大（當我將執行緒數調整為50，1分鐘appendonly.aof 的檔案大小已達到了25M）。
Redis AOF rewrite（重新生成一份AOF檔案）設定：
（1）Redis接收到客戶端傳送的BGREWRITEAOF指令請求，執行AOF rewrite；
（2）在Redis配置檔案redis.conf中，如果使用者設定了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size引數，當AOF日誌檔案大小大於auto-aof-rewrite-min-size，同時AOF檔案大小的增長率大於auto-aof-rewrite-percentage時，會自動觸發AOF rewrite；
另外需要注意的是根據網上反饋AOF曾經出現過，因為個別命令導致 AOF 檔案在重新載入時，無法恢復原樣的問題。
快照模式的優點是：日誌的內容更加緊湊，可以在加密後儲存到其他資料中心或者亞馬遜 S3；快照可以最大化 Redis 的效能：父程序在儲存快照檔案時唯一要做的就是生成一個子程序，然後這個子程序就會處理接下來的所有儲存工作，父程序無須執行任何磁碟 I/O 操作；
快照在恢復大資料集時的速度比 AOF 的恢復速度要快。一個原因是快照檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。另一個原因是快照檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要小於AOF日誌的載入。
四、部署架構說明
結合以上分析，建議採用如下的部署方式：Redis Master上不做持久化保證讀寫效能，Slave上同時開啟RDB（快照）和AOF，保證資料的安全性。當 Redis啟動時，程式會優先使用 AOF 檔案來恢復資料集，因為AOF檔案所儲存的資料通常是最完整的。
相關推薦
高併發情況下Redis 的可用性測試與分析及部署架構說明
1、讀取Redis的timeout異常 建立執行緒數在50以下時程式可以正常執行，當執行緒數設定為100以上時，某些執行緒執行出現異常： java.net.SocketTimeoutException: Read timed out 造成這種異常可能有以下兩個原因： 原因一：在連線Redis的Jedis的預設
測試Nginx 和 Tomcat 高併發情況下處理靜態頁面的效能
以下是 ab 壓力測試的結果（為了得到比較科學的資料可以進行多次的測試，一般至少10次） ab 可執行檔案的位置 /usr/local/web/apache/bin 測試命令：ab -n1000
如何處理高併發情況下的DB插入
插入資料庫，在大家開發過程中是很經常的事情，假設我們有這麼一個需求： 1、我們需要接收一個外部的訂單，而這個訂單號是不允許重複的 2、資料庫對外部訂單號沒有做唯一性約束 3、外部經常插入相同的訂單，對於已經存在的訂單則拒絕處理 對於這個需求，很簡單我們會用下面的
高併發情況下 如何支撐大量的請求
儘量使用快取，包括使用者快取，資訊快取等，多花點記憶體來做快取，可以大量減少與資料庫的互動，提高效能。用jprofiler等工具找出效能瓶頸，減少額外的開銷。優化資料庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做優化）。優化資料庫結構，多做索引，提高查詢效率。統計的功能儘量
高併發情況下如何保證訊息的順序
在知乎上看到一位大牛總結了一些保證訊息順序的方案，在此記錄下來學習一下。 在多佇列訊息處理的場景中，怎樣保持多個訊息之間的時間順序，是一個很經典的問題。解決方法當然是有的。 為了討論這個問題，讓我們做一些簡化問題的假設：有若干個訊息佇列A、
Mysql在高併發情況下，防止庫存超賣而小於0的解決方案
背景： 本人上次做申領campaign的PHP後臺時，因為專案上線後某些時段同時申領的人過多，導致一些專櫃的存貨為負數（<0），還好併發量不是特別大，只存在於小部分專櫃而且一般都是-1的狀況，沒有造成特別特別嚴重的後果，但還是要反思了自己的過錯。 這次又有新的申
提高MySQL在高併發情況下的負載
（只作為日後參考的記錄，沒有實際測試過） TCMalloc（Thread-Caching Malloc）是google開發的開源工具──“google-perftools”中的成員。與標準的glibc庫的malloc相比，TCMalloc在記憶體的分配上效率和速度要高得多
【大廠面試01期】高併發場景下，如何保證快取與資料庫一致性？
> PS:本文已收錄到1.1K Star數開源學習指南——《大廠面試指北》，如果想要了解更多大廠面試相關的內容及獲取《大廠面試指北》離線PDF版，請掃描下方二維碼碼關注公眾號“大廠面試”，謝謝大家了！專案地址：https://github.com/NotFound9/interviewGuide **
高併發場景系列(一) 利用redis實現分散式事務鎖,解決高併發環境下減庫存
問題描述:某電商平臺,首發一款新品手機,每人限購2臺,預計會有10W的併發,在該情況下,如果扣減庫存,保證不會超賣 方案一 利用資料庫鎖機制,對記錄進行鎖定,再進行操作 SELECT * from goods where ID =1 for updat
設計高併發場景下的高可用後端系統
PS：前段時間和Mentor們一起參與研發”百度地圖百城千店感恩節AR遊戲送大禮”的後端專案，積累了一些高併發情景下的系統設計經驗，這裡統一抽象成【秒殺情景下的後端系統】，歸納總結一下學習到的知識點。轉載地址：http://blog.daijiale.cn/2016/12/0
利用redis實現分散式事務鎖,解決高併發環境下減庫存
http://download.redis.io/releases/ 安裝： sudo make test 測試編譯 sudo make install 啟動： redis-servre cd “安裝目錄” redis-server ./redis-3.2.9/redis
多執行緒模擬高併發情況redis 與資料庫快取不一致
import com.mysql.jdbc.Connection; import entity.User; import org.junit.Test; import redis.clients.jedis.Jedis; import java.sql.*; import
公司流程不規範的情況下，如何做好測試工作？（轉http://www.51testing.com/html/11/15160311-3719792.html）
www html 相關 負責人 ron 測試 testin pac div 這對我們來說是個機遇！ 首先我要說，公司目前制度不規範，對我們來說是個機遇，絕對是個機遇！遇到這個好機會你還在等什麽？如果說這個公司已經足夠好了，那他還請你過來做什麽？你的能力還足以讓公司有更高的
主流原型工具可用性測試橫向比較
原型工具 原型測試 可用性測試 原型 原型圖 原型設計 可用性測試是指通過觀察用戶使用產品（或原型）的過程，記錄和分析用戶的行為和感受，以改善產品可用性的一系列方法。可用性測試適用於產品前期設計開發，中期改進和後期維護的各個階段，是用戶中心設計的思想的重要體現。同時，由於它反映了
對可用性測試的8種誤解，你中槍了嗎
使用者測試是理解使用者行為和動機的過程。 好的設計能讓使用者輕鬆找到想看的， 輕鬆做到想做的。 然而很多時候， 由於時間和預算的限制， 使用者測試被邊緣化、 甚至直接被略過了。 究其根本， 還是在於使用者測試的價值被誤解和低估了。 蜜汁誤解1
併發情況下引發的血案
首先澄清一下，最近更博比較少，最近在研究新的東西的同時還有大量的任務在做，這個月會繼續的更新，把rabbitmq的系列更新完成，同時把我研究的新的東西的完整的系列也整理髮布出來，大家一起學習進步。 一、問題描述： 很多時候面試都會被問到併發的問題，那個時候我們總覺的遇不到這種
如何解決jquery.jsonp請求在併發情況下容易發生異常的bug
知道現在使用jsonp的公司越來越少了，似乎有比jsonp更好的跨域方案。但是我發現騰訊視屏、愛奇藝視訊、優酷土豆等大型網際網路公司還在使用它時，我決定寫一篇文章徹底解決jsonp在併發條件下報錯的問題。畢竟jsonp有最好的相容性。 先附上原始碼連線 Github
linux下redis的安裝測試
伺服器的檔案目錄如下 1，下載redis的安裝包 下載地址：http://redis.io/download 包：redis-5.0.2.tar.gz 2，將包上傳到伺服器的指定路徑並解壓 3，進入redis解壓後的目錄
高併發場景下的快取有哪些常見的問題？
一、快取一致性問題 當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。 這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。 二、快取併發
快取在高併發場景下的常見問題 侵立刪
快取一致性問題 當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。