互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享?
來(lái)自：網(wǎng)絡(luò)，侵刪
在講到使用hash還是string存儲(chǔ)的選擇前，先了解Redis的hash和string結(jié)構(gòu)。 以下資料引自老錢(qián)的Redis深度歷險(xiǎn)。 string string和hash都是Redis的一種數(shù)據(jù)結(jié)構(gòu)。string結(jié)構(gòu)常用來(lái)緩存用戶(hù)信息，通常將用戶(hù)信息結(jié)構(gòu)體使用JSON序列化成字符串，然后將序列化后的字符串存入Redis進(jìn)行緩存。 String數(shù)據(jù)結(jié)構(gòu) Redis的字符串是動(dòng)態(tài)字符串，可以修改，內(nèi)部結(jié)構(gòu)類(lèi)似于Java的ArrayList，采用預(yù)分配冗余空間的方式來(lái)減少內(nèi)存的頻繁分配。 如上圖鎖實(shí)，內(nèi)部為當(dāng)前字符串實(shí)際分配的空間capacity，一般高于實(shí)際字符串長(zhǎng)度len。使用的指令有set, get, mset, mget等 hash Redis的hash相當(dāng)于Java的HashMap,內(nèi)部結(jié)構(gòu)實(shí)現(xiàn)與HashMap一致，即數(shù)組+鏈表結(jié)構(gòu) hash數(shù)據(jù)結(jié)構(gòu) 不過(guò)Redis的hash的值只能是字符串，rehash方式不一樣，為了提高性能，Redis保留新舊兩個(gè)hash結(jié)構(gòu)，采用漸進(jìn)式rehash策略，查詢(xún)時(shí)會(huì)同事查詢(xún)兩個(gè)hash結(jié)構(gòu)，在后續(xù)的定時(shí)任務(wù)中以及hash操作指令中，循序漸進(jìn)將舊hash的內(nèi)容遷移到xinhash中，直至完全取代舊hash。hash移除最后一個(gè)元素后會(huì)自動(dòng)被刪除，內(nèi)存被回收。 前面說(shuō)到string適合存儲(chǔ)用戶(hù)信息，而hash結(jié)構(gòu)也可以存儲(chǔ)用戶(hù)信息，不過(guò)是對(duì)每個(gè)字段單獨(dú)存儲(chǔ)，因此可以在查詢(xún)時(shí)獲取部分字段的信息，節(jié)省網(wǎng)絡(luò)流量。 因此就引出了這篇文章，存儲(chǔ)結(jié)構(gòu)體信息是用hash還是string？ 以下信息出自StackOverflow ?Redis strings vs Redis hashes to represent JSON: efficiency? I?want?to?store?a?JSON?payload?into?redis.?There's?really?2?ways?I?can?do?this: t?predictable.?They're?not?all?short?such?as?the?bio?example?above.
該用戶(hù)也是同樣的疑問(wèn)，因?yàn)橹档拈L(zhǎng)度是不確定的，所以不知道采用string還是hash存儲(chǔ)更有效率 。這個(gè)問(wèn)題底下有個(gè)開(kāi)發(fā)者回答的非常好，這里翻譯出來(lái)供大家一起學(xué)習(xí)討論，如果有更好的方案，歡迎提出來(lái) 首先，答者建議參考redis官方的內(nèi)存優(yōu)化的文章：https://redis.io/topics/memory-optimization，用來(lái)理解官方的開(kāi)發(fā)者是內(nèi)存優(yōu)化方面基于什么考慮。 之后，答者列出了四個(gè)方案并給出了各個(gè)方案的利弊 1. 存儲(chǔ)整個(gè)對(duì)象，其中JSON序列化過(guò)的字符串作為key INCR?id:users'{"name":"Fred","age":25}'
優(yōu)勢(shì)：可以認(rèn)為是“最佳實(shí)踐”，因?yàn)槊總€(gè)對(duì)象都是全特性的key，JSON解析特別塊，尤其是一次性查詢(xún)很多個(gè)字段的時(shí)候 劣勢(shì)：如果只查詢(xún)一個(gè)字段，速度就顯得比較慢了 2. 在hash中存儲(chǔ)每個(gè)對(duì)象的屬性 INCR?id:users"Fred" ?age?25
優(yōu)勢(shì)：這也可以認(rèn)為是最佳時(shí)間。每個(gè)對(duì)象都是一個(gè)全特性的key。不需要解析JSON字符串 劣勢(shì)：如果要查詢(xún)對(duì)象的全部字段會(huì)比較慢。嵌套類(lèi)型的對(duì)象（即對(duì)象里面還包著對(duì)象）無(wú)法輕易存儲(chǔ) 3. 將對(duì)象轉(zhuǎn)化為JSON字符串，用hash結(jié)構(gòu)存儲(chǔ) INCR?id:users'{"name":"Fred","age":25}'
這個(gè)方案可以?xún)H用兩個(gè)key，不需要很多key。但是沒(méi)法對(duì)每個(gè)用戶(hù)對(duì)象設(shè)置TTL(Time to Live，剩余生存時(shí)間)，因?yàn)閷?duì)象僅僅是hash中的一個(gè)字段，而不是全特性的key 優(yōu)勢(shì)：JSON解析很快，尤其是一次查詢(xún)多個(gè)字段時(shí)，對(duì)主key的命名空間污染更少 劣勢(shì)：如果要存儲(chǔ)很多對(duì)象，那么內(nèi)存使用和方案1相當(dāng)。當(dāng)只需要查詢(xún)一個(gè)字段時(shí)，會(huì)比方案2速度慢。答者不認(rèn)為這是一個(gè)“最佳實(shí)踐” 4. 存儲(chǔ)對(duì)象的每個(gè)屬性作為單獨(dú)的key INCR?id:users"Fred"
根據(jù)上面的文章，即redis內(nèi)存優(yōu)化，這個(gè)方案不推薦（除非對(duì)象的屬性需要專(zhuān)門(mén)設(shè)置TTL或者別的設(shè)置） 優(yōu)勢(shì)：對(duì)象的屬性是全特征key，對(duì)于應(yīng)用來(lái)說(shuō)比較好處理 劣勢(shì)：慢，內(nèi)存消耗更大，不是一個(gè)“最佳實(shí)踐”。對(duì)主key的命名空間有很大污染 總的來(lái)說(shuō)，方案4是最不推薦的，方案1和方案2非常相似，也很常見(jiàn)。答者更推薦方案1，因?yàn)檫@個(gè)方案允許存儲(chǔ)更復(fù)雜的對(duì)象（也就是說(shuō)對(duì)象可以有很多層嵌套）。方案3通常用在對(duì)命名空間比較有要求的場(chǎng)景下，比如說(shuō)不想要太多key，不關(guān)心TTL等參數(shù)。 推薦閱讀：
裸辭全職接單一個(gè)月的感觸....
SpringBoot 搭建基于 minio 的高性能存儲(chǔ)服務(wù)
互聯(lián)網(wǎng)初中高級(jí)大廠面試題(9個(gè)G) 內(nèi)容包含Java基礎(chǔ)、JavaWeb、MySQL性能優(yōu)化、JVM、鎖、百萬(wàn)并發(fā)、消息隊(duì)列、高性能緩存、反射、Spring全家桶原理、微服務(wù)、Zookeeper、數(shù)據(jù)結(jié)構(gòu)、限流熔斷降級(jí)......等技術(shù)棧！
? 戳閱讀原文領(lǐng)?。?/span>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 朕已閱?
