向大神學習！
儘管redis是乙個非常快速的記憶體資料儲存媒介，也並不代表redis不會產生效能問題。
前文中提到過，redis採用單執行緒模型，所有的命令都是由乙個執行緒序列執行的，所以當某個命令執行耗時較長時，會拖慢其後的所有命令，這使得redis對每個任務的執行效率更加敏感。
針對redis的效能優化，主要從下面幾個層面入手：
redis絕大多數讀寫命令的時間複雜度都在o(1)到o(n)之間，在文字和官方文件中均對每個命令的時間複雜度有說明。
通常來說，o(1)的命令是安全的，o(n)命令在使用時需要注意，如果n的數量級不可預知，則應避免使用。例如對乙個field數未知的hash資料執行hgetall/hkeys/hvals命令，通常來說這些命令執行的很快，但如果這個hash中的field數量極多，耗時就會成倍增長。
又如使用sunion對兩個set執行union操作，或使用sort對list/set執行排序操作等時，都應該嚴加注意。
避免在使用這些o(n)命令時發生問題主要有幾個辦法：
redis提供了scan命令，可以對redis中儲存的所有key進行游標式的遍歷，避免使用keys命令帶來的效能問題。同時還有sscan/hscan/zscan等命令，分別用於對set/hash/sorted set中的元素進行游標式遍歷。scan類命令的使用請參考官方文件：
slowlog-log-slower-than ***ms #執行時間慢於***毫秒的命令計入slow log
slowlog-max-len *** #slow log的長度，即最大紀錄多少條slow log
使用slowlog reset命令，可以重置slow log
redis的資料持久化工作本身就會帶來延遲，需要根據資料的安全級別和效能要求制定合理的持久化策略：
redis在fork子程序時需要將記憶體分頁表拷貝至子程序，以占用了24gb記憶體的redis例項為例，共需要拷貝24gb / 4kb * 8 = 48mb的資料。在使用單xeon 2.27ghz的物理機上，這一fork操作耗時216ms。當linux將redis所用的記憶體分頁移至swap空間時，將會阻塞redis程序，導致redis出現不正常的延遲。swap通常在物理記憶體不足或一些程序在進行大量i/o操作時發生，應盡可能避免上述兩種情況的出現。可以通過info命令返回的latest_fork_usec欄位檢視上一次fork操作的耗時（微秒）
/proc//smaps檔案中會儲存程序的swap記錄，通過檢視這個檔案，能夠判斷redis的延遲是否由swap產生。如果這個檔案中記錄了較大的swap size，則說明延遲很有可能是swap造成的。
當同一秒內有大量key過期時，也會引發redis的延遲。在使用時應盡量將key的失效時間錯開。
redis的主從複製能力可以實現一主多從的多節點架構，在這一架構下，主節點接收所有寫請求，並將資料同步給多個從節點。
在這一基礎上，我們可以讓從節點提供對實時性要求不高的讀請求服務，以減小主節點的壓力。
尤其是針對一些使用了長耗時命令的統計類任務，完全可以指定在乙個或多個從節點上執行，避免這些長耗時命令影響其他請求的響應。
Redis效能調優
1.估算redis記憶體使用量 以非數字的字串鍵值對為例，假設key和value的長度均為12個位元組，則內部使用的編碼方式為embstr。共計90000個鍵值對占用的空間 redis中儲存鍵值對使用字典，字典內部使用雜湊表陣列，陣列的每個元素dictentry中共有三個指標 指向鍵的指標，指向值的...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...