一直以單線程為一大特點的REDIS，為什么也支持多線程了？

如果在網上查過“Redis為什么快”這個問題的同學，一定看到過其中一個原因：Redis采用了單線程模型，減少了線程的上下文切換和競爭。然后又使用了I/O多路復用模型，關於I/O多路復用，可以看下這篇文章：I/O多路復用。epoll的時間復雜度是O(1)，的確並發不是問題，但是為什么最新發布的Redis6.0里，竟然支持了多線程呢？
  請注意！！I/O多路復用的epoll，解決的是並發問題，並發，而不是並行。
  Redis是靠着基於內存，處理效率高來規避並行問題的，這就像是一個高效的程序員，產品無論給他什么需求，他都能在1天內干完；然后I/O多路復用就像是一個很棒開發流程中的項目經理，只要你干完我就能立刻給你安排好下一份工作，一點不會耽誤時間，於是乎兩人搭配，一點都不會阻塞住，就算產品一天提了3個需求（並發），那3天后也全部交付了；於是乎也用不到別的程序員了，這位大哥一個人就能搞定了（單線程），也用不着和其他程序員溝通（上下文切換），更是省時省力。但是終於有一天，產品經理終搞出了一個非常難搞的需求，這個需求，需要15人日才能做完，但是其他工作，依然在不斷產生，這下就算其他需求花不了多長時間，也只能排到15天以后了，這樣看起來，一個人的問題就來了，他不能分身（並行）。所以，Redis的生產環境一般是禁用keys這種命令的，因為一個不能很快結束的命令會阻塞其他的請求。
  Redis的多線程部分只是用來處理網絡數據的讀寫和協議解析，執行命令仍然是單線程。之所以這么設計是不想 Redis 因為多線程而變得復雜，需要去控制 key、lua、事務，LPUSH/LPOP 等等的並發問題。Redis 在最新的幾個版本中加入了一些可以被其他線程異步處理的刪除操作，也就是我們在上面提到的 UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC，我們為什么會需要這些刪除操作，而它們為什么需要通過多線程的方式異步處理？
  我們知道Redis可以使用del命令刪除一個元素，如果這個元素非常大，可能占據了幾十兆或者是幾百兆，那么在短時間內是不能完成的，這樣一來就需要多線程的異步支持。
  而上面提到的keys命令是需要同步返回的，所以即使在Redis6.0，這個命令應該在生產環境依然會被禁用。