国产成人在线综合网,GOGO大胆国模一区二区私拍,国产真实老熟女无套内射

[導讀]?這可能是最中肯的Redis使用規(guī)范了碼哥，昨天我被公司Leader批評了。我在單身紅娘婚戀類型互聯(lián)網(wǎng)公司工作，在雙十一推出下單就送女朋友的活動。誰曾想，凌晨12點之后，用戶量暴增，出現(xiàn)了一個技術(shù)故障，用戶無法下單，當時老大火冒三丈！經(jīng)過查找發(fā)現(xiàn)Redis報Couldnotgetaresourcefromthepool。獲取不到連接資源，并且集群中的單臺Redis連接量很高。于是各種更改最大連接數(shù)、連接等待數(shù)，雖然報錯信息頻率有所緩解，但還是持續(xù)報錯。后來經(jīng)過線下測試，發(fā)現(xiàn)存放Redis中的字符數(shù)據(jù)很大，平均1s返回數(shù)據(jù)。?碼哥，可以分享下使用Redis的規(guī)范么？我想做一個唯快不破的真男人！R...

?這可能是最中肯的 Redis 使用規(guī)范了

碼哥，昨天我被公司 Leader 批評了。

我在單身紅娘婚戀類型互聯(lián)網(wǎng)公司工作，在雙十一推出下單就送女朋友的活動。

誰曾想，凌晨 12 點之后，用戶量暴增，出現(xiàn)了一個技術(shù)故障，用戶無法下單，當時老大火冒三丈！

經(jīng)過查找發(fā)現(xiàn) Redis 報 Could not get a resource from the pool。

獲取不到連接資源，并且集群中的單臺 Redis 連接量很高。

于是各種更改最大連接數(shù)、連接等待數(shù)，雖然報錯信息頻率有所緩解，但還是持續(xù)報錯。

后來經(jīng)過線下測試，發(fā)現(xiàn)存放 Redis 中的字符數(shù)據(jù)很大，平均 1s 返回數(shù)據(jù)。

?碼哥，可以分享下使用 Redis 的規(guī)范么？我想做一個唯快不破的真男人！

Redis 使用規(guī)范圍繞如下幾個緯度展開：

鍵值對使用規(guī)范；
命令使用規(guī)范；
數(shù)據(jù)保存規(guī)范；
運維規(guī)范。

鍵值對使用規(guī)范

有兩點需要注意：

好的 key 命名，才能提供可讀性強、可維護性高的 key，便于定位問題和尋找數(shù)據(jù)。
value要避免出現(xiàn) bigkey、選擇高效的序列化和壓縮、使用對象共享池、選擇高效恰當?shù)臄?shù)據(jù)類型（可參考《Redis 實戰(zhàn)篇：巧用數(shù)據(jù)類型實現(xiàn)億級數(shù)據(jù)統(tǒng)計》）。

key 命名規(guī)范

規(guī)范的 key命名，在遇到問題的時候能夠方便定位。Redis 屬于沒有 Scheme的 NoSQL數(shù)據(jù)庫。

所以要靠規(guī)范來建立其 Scheme 語意，就好比根據(jù)不同的場景我們建立不同的數(shù)據(jù)庫。

敲黑板

把「業(yè)務模塊名」作為前綴（好比數(shù)據(jù)庫 Scheme），通過「冒號」分隔，再加上「具體業(yè)務名」。

這樣我們就可以通過 key 前綴來區(qū)分不同的業(yè)務數(shù)據(jù)，清晰明了。

總結(jié)起來就是：「業(yè)務名:表名:id」

比如我們要統(tǒng)計公眾號屬于技術(shù)類型的博主「碼哥字節(jié)」的粉絲數(shù)。

set?公眾號:技術(shù)類:碼哥字節(jié)?100000

?碼哥，key 太長的話有什么問題么？

key 是字符串，底層的數(shù)據(jù)結(jié)構(gòu)是 SDS，SDS 結(jié)構(gòu)中會包含字符串長度、分配空間大小等元數(shù)據(jù)信息。

字符串長度增加，SDS 的元數(shù)據(jù)也會占用更多的內(nèi)存空間。

所以當字符串太長的時候，我們可以采用適當縮寫的形式。

不要使用 bigkey

?碼哥，我就中招了，導致報錯獲取不到連接。

因為 Redis 是單線程執(zhí)行讀寫指令，如果出現(xiàn)bigkey 的讀寫操作就會阻塞線程，降低 Redis 的處理效率。

bigkey包含兩種情況：

鍵值對的 value很大，比如 value保存了 2MB的 String數(shù)據(jù)；
鍵值對的 value是集合類型，元素很多，比如保存了 5 萬個元素的 List 集合。

雖然 Redis 官方說明了 key和string類型 value限制均為512MB。

防止網(wǎng)卡流量、慢查詢，string類型控制在10KB以內(nèi)，hash、list、set、zset元素個數(shù)不要超過 5000。

?碼哥，如果業(yè)務數(shù)據(jù)就是這么大咋辦？比如保存的是《金瓶梅》這個大作。

我們還可以通過 gzip 數(shù)據(jù)壓縮來減小數(shù)據(jù)大小:

/**
?*?使用gzip壓縮字符串
?*/
public?static?String?compress(String?str)?{
????if?(str?==?null?||?str.length()?==?0)?{
????????return?str;
????}

????try?(ByteArrayOutputStream?out?=?new?ByteArrayOutputStream();
????GZIPOutputStream?gzip?=?new?GZIPOutputStream(out))?{
????????gzip.write(str.getBytes());
????}?catch?(IOException?e)?{
????????e.printStackTrace();
????}
????return?new?sun.misc.BASE64Encoder().encode(out.toByteArray());
}

/**
?*?使用gzip解壓縮
?*/
public?static?String?uncompress(String?compressedStr)?{
????if?(compressedStr?==?null?||?compressedStr.length()?==?0)?{
????????return?compressedStr;
????}
????byte[]?compressed?=?new?sun.misc.BASE64Decoder().decodeBuffer(compressedStr);;
????String?decompressed?=?null;
????try?(ByteArrayOutputStream?out?=?new?ByteArrayOutputStream();
????ByteArrayInputStream?in?=?new?ByteArrayInputStream(compressed);
????GZIPInputStream?ginzip?=?new?GZIPInputStream(in);)?{
????????byte[]?buffer?=?new?byte[1024];
????????int?offset?=?-1;
????????while?((offset?=?ginzip.read(buffer))?!=?-1)?{
????????????out.write(buffer,?0,?offset);
????????}
????????decompressed?=?out.toString();
????}?catch?(IOException?e)?{
????????e.printStackTrace();
????}
????return?decompressed;
}

集合類型

如果集合類型的元素的確很多，我們可以將一個大集合拆分成多個小集合來保存。

使用高效序列化和壓縮方法

為了節(jié)省內(nèi)存，我們可以使用高效的序列化方法和壓縮方法去減少 value的大小。

protostuff和 kryo這兩種序列化方法，就要比 Java內(nèi)置的序列化方法效率更高。

上述的兩種序列化方式雖然省內(nèi)存，但是序列化后都是二進制數(shù)據(jù)，可讀性太差。

通常我們會序列化成 JSON或者 XML，為了避免數(shù)據(jù)占用空間大，我們可以使用壓縮工具（snappy、 gzip）將數(shù)據(jù)壓縮再存到 Redis 中。

使用整數(shù)對象共享池

Redis 內(nèi)部維護了 0 到 9999 這 1 萬個整數(shù)對象，并把這些整數(shù)作為一個共享池使用。

即使大量鍵值對保存了 0 到 9999 范圍內(nèi)的整數(shù)，在 Redis 實例中，其實只保存了一份整數(shù)對象，可以節(jié)省內(nèi)存空間。

需要注意的是，有兩種情況是不生效的：

Redis 中設置了 maxmemory，而且啟用了 LRU策略（allkeys-lru 或 volatile-lru 策略），那么，整數(shù)對象共享池就無法使用了。
?這是因為 LRU 需要統(tǒng)計每個鍵值對的使用時間，如果不同的鍵值對都復用一個整數(shù)對象就無法統(tǒng)計了。
如果集合類型數(shù)據(jù)采用 ziplist 編碼，而集合元素是整數(shù)，這個時候，也不能使用共享池。
?因為 ziplist 使用了緊湊型內(nèi)存結(jié)構(gòu)，判斷整數(shù)對象的共享情況效率低。

命令使用規(guī)范

有的命令的執(zhí)行會造成很大的性能問題，我們需要格外注意。

生產(chǎn)禁用的指令

Redis 是單線程處理請求操作，如果我們執(zhí)行一些涉及大量操作、耗時長的命令，就會嚴重阻塞主線程，導致其它請求無法得到正常處理。

KEYS：該命令需要對 Redis 的全局哈希表進行全表掃描，嚴重阻塞 Redis 主線程；
?應該使用 SCAN 來代替，分批返回符合條件的鍵值對，避免主線程阻塞。
FLUSHALL：刪除 Redis 實例上的所有數(shù)據(jù)，如果數(shù)據(jù)量很大，會嚴重阻塞 Redis 主線程；
FLUSHDB，刪除當前數(shù)據(jù)庫中的數(shù)據(jù)，如果數(shù)據(jù)量很大，同樣會阻塞 Redis 主線程。
?加上 ASYNC 選項，讓 FLUSHALL，F(xiàn)LUSHDB 異步執(zhí)行。

我們也可以直接禁用，用rename-command命令在配置文件中對這些命令進行重命名，讓客戶端無法使用這些命令。