redis正常應該是10萬QPS，你這才100QPS，就算1核1G的機器也不至於，難道你存了大KEY?建議單KEY不超過1K

題主需要將問題描述得更詳細一些，不然真的無法解答，正常來說redis是不會只有這個表現的。現在只能猜測：

1、題主的redis執行在效能極低的主機上，或者資源受到了極大的限制，導致redis效能低下

2、題主單個數據內容極大，達到或超過了redis執行環境的儲存限制

3、實際瓶頸在其他環節，導致redis被誤解，比如在將資料儲存到redis之前需要呼叫外部介面獲取資料，而這個外部介面比較慢，我認為這種情況的機率比較大。

redis只有100的ops確實是有問題的，這違背了redis高效能的定義。可以從以下幾個方面排查下：

1.部署redis的伺服器資源是否充足，包括CPU、記憶體等，redis的資料是儲存再記憶體中的，充足的記憶體是必要條件，redis是單執行緒架構，所以很容易把單核cpu跑滿；

2.客戶端和redis伺服器端的網路頻寬是否充足，redis的高效能指的是他自身的處理速度極快，但是如果網路延遲比較大，也會導致ops較低；

3.是否有bigkey，大的鍵值對會佔用比較大的記憶體，在操作時也會耗費更多的計算資源和網路資源，這可以使用redis-cli --bigkeys命令查詢出來，如果存在需要根據業務條件做鍵值的拆分；

4.是否採用了錯誤的value型別，redis一般包括string(字串)、list(連結串列)、set(集合)、zset(sorted set有序集合)和hash（雜湊型別），需要結合實際業務選擇value型別；

5.是否多度使用了高演算法複雜度的命令，比如hgetall、smembers、keys等，可以替換成hmget、sscan、scan等；

6.查詢redis的慢查詢日誌，命令是slowlog get，可以定位到具體的慢操作，針對性的做最佳化；

7.redis如果打開了持久化功能，rdb和aof都有可能導致效能問題，可以透過info persistence檢視持久過相關的統計資料是否有異常，比如fork是否會過慢，aof_delayed_fsync是否過大等。