1樓：Kevin2000178
Redis服務端乙個例項是單執行緒處理所有的客戶端請求的，不存在併發、鎖之類的問題。
乙個伺服器可以啟動多個例項，目前新版支援集群了。
但是仍然存在很多客戶端同時訪問乙個例項的情況， 這個沒辦法，單執行緒模式，那些客戶端只能排隊。
2樓：李波
先來看看Redis和Mysql的資料儲存，Mysql是需要落到磁碟的，而Redis的資料是寫入記憶體即表示成功，至於持久化是非同步刷到磁碟的（雖然可以同步刷到磁碟，但那樣效率和Mysql沒有多大差別）。記憶體的讀寫效能大概是磁碟的1-2個數量級，所以這裡從本質上決定了Redis的讀寫效能高於Mysql。
再來看看Redis和Mysql的儲存模型，Redis是Key-Value的，Mysql是關係型資料庫，Key-Value的插入和查詢基本都是O(1)的複雜度，而關係型資料庫會涉及到索引的查詢和插入，是對數級的複雜度（InnoDB，有索引），但這個在InnoDB下並不是太大的問題，因為Mysql是多執行緒的，並且引入了MVCC（多版本併發控制），插入的時候不會鎖表，還能更好的利用多核，所以不會因為併發在插入時造成太大的效能問題。
然後看看樓主提出的併發問題，應該指的是Mysql使用MyISAM時，資料的插入都會鎖表，但並不是死鎖（死鎖是互相持有對方所需資源等待對方釋放），只是這個時候針對單錶的插入Mysql的多執行緒並不能發揮優勢，所有的資料只能一條一條插入，所以相對於Redis，最終的效能差異在磁碟和演算法本身的複雜度上。
最後說說題主說的Redis的訊息佇列，題主的意思應該是Redis的執行緒模型是單執行緒的，所有的命令都是在乙個命令佇列裡，乙個接著乙個執行，並不能併發執行。這種模型的最大優勢是程式設計簡單，並不會為併發帶來優勢，相反，不能利用多核是其最大的弊病，這種模型基本都是利用NIO來解決併發問題。當然，Redis這樣也就不會造成死鎖，因為沒有資源的競爭，但Mysql的死鎖是可以通過良好的設計避免的，所以，訊息佇列並不是Redis效能高的原因。
3樓：
MySQL的寫操作會鎖表，大量併發請求時尤其突出；
Redis可以應對高併發場景，是因為它的讀寫請求均是單執行緒機制，不存在併發問題。而且Redis是基於記憶體的，讀寫速度也比MySQL快得多；
4樓：張延俊
瀉藥mysql大併發下的插入死鎖是可以通過調整SQL和mysql配置避免的。
訊息佇列的模式一般都是內部維護了乙個自增mutex（互斥量，一種輕量級的鎖），mysql的非表鎖auto incement insert就是用的這種方式。
Redis 怎麼做訊息佇列？
網易數帆 PUB SUB 實現輕量的訊息佇列機制也算是種 Redis典型應場景吧。Redis作為個 Key Value 儲存具，它提供的很多特性可以來實現些級應功能。如 PUBLISH 和 SUBSCRIBE 這兩個命令，可以來快速解決訊息佇列應場景的問題。簡單的講 SUBSCRIBE 於監聽個頻道...
使用nodejs的話，還需要訊息佇列嗎？
在微服務流行的當下，訊息佇列主要是用於服務解耦。將不需要立即獲取結果的請求，投遞到訊息佇列中，由訊息佇列來保證其他服務執行該訊息。而訊息的投遞方就能繼續幹自己的活了。例如 下單成功後，傳送郵件通知，就是個典型的可以用訊息佇列來解耦的服務。因為傳送郵件通知的重要性並不高，有延時也是完全能接受的事情。所...
使用Golang實現的無鎖佇列，效能與Disruptor相當達到1400萬 秒
這樣才會有翻第二三遍的衝動，如果某本書裡面給你某個暗喻，你能從中體會感受到的話，那說什麼也不會忘了，會再回想，就像驚鴻一瞥的美女，忘不了。有些書就算當時沒看懂，過後也可能在某個因緣際會下再相遇。何況連柏拉圖這樣的聖人都不能始終如一的堅持自己的思想，我們凡人又何必牢記所謂的金科玉律呢 多讀書不是記不記...