我們在快取json資料到redis時經常會面臨是選擇string型別還是選擇hash型別去儲存。接下來我從佔用空間和IO兩方面來分析這兩種型別的優勢。 ### 1、佔用空間 根據資料結構的共識我們知道hashtable型別是要比string型別更佔用空間， 而ziplist型別與string型別佔用的空間基本相差不大。 如下圖就是ziplist的儲存的格式  那我們接下來分別分析redis的string和hash型別佔用空間方面的知識 - string型別： string型別當然如其名，如果json資料以string型別去儲存，那麼它的空間佔用方面肯定是相當的。 - hash型別： redis對hash型別是有兩種編碼方式，分別是ziplist和hashtable。 > 當如下情況時redis的hash型別，底層是用ziplist編碼的： > > 1. 雜湊物件儲存的所有鍵值對的鍵和值的字串長度都小於 64 位元組； > 2. 雜湊物件儲存的鍵值對數量小於 512 個； > > 不滿足上述情況時，redis的hash型別，底層編碼格式為hashtable。 ### 2、IO 從IO的角度來分析string和hash型別，我們得有一個共識，我們知道redis是有服務端的，也就是部署redis的所在機器他們會運算能力的。 - string型別： - 取資料：根據redis鍵取對應的整個value值。 - 存資料：根據redis鍵存這個value值 - 更新資料： 根據redis鍵更新整個value值 - hash型別： - 取資料：根據redis鍵，然後遍歷整個hash鍵值對（相對string的取資料更加耗時）。 - 存資料：根據redis鍵，在value出存鍵值對 - 更新資料：根據redis鍵和hash key更新對應的資料 ### 3、總結 綜上所述，那具體怎麼選擇是用string型別還是hash型別儲存json資料呢？給出以下結論 - 如果你的業務型別中對於快取的讀取快取的場景更多，並且更新快取不頻繁（或者每次更新都更新json資料中的大多數key），那麼選擇string型別作為儲存方式會比較好。 - 如果你的業務型別中對於快取的更新比較頻繁（特別是每次只更新少數幾個鍵）時， 或者我們每次只想取json資料中的少數幾個鍵值時，我們選擇hash型別作為我們的儲存方式會比