自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

作者：Java知音
存儲 存儲軟件 Redis
我們在面試時，常?？梢杂龅降拿嬖囶}是關(guān)于redis，這是很多面試官都喜歡的一個部分。而今天要講的，是redis的底層數(shù)據(jù)結(jié)構(gòu)，并非是我們所理解中的五大數(shù)據(jù)結(jié)構(gòu)。

我們在面試時，常?？梢杂龅降拿嬖囶}是關(guān)于redis，這是很多面試官都喜歡的一個部分。而今天要講的，是redis的底層數(shù)據(jù)結(jié)構(gòu)，并非是我們所理解中的五大數(shù)據(jù)結(jié)構(gòu)。那么，redis底層數(shù)據(jù)結(jié)構(gòu)到底是怎樣的呢?你知道 Rdidis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎?

[[278045]]

1. 字符串處理(string)

我們都知道redis是用C語言寫，但是C語言處理字符串和數(shù)組的成本是很高的，下面我分別說幾個例子。

沒有數(shù)據(jù)結(jié)構(gòu)支撐的幾個問題

  1. 及其容易造成緩沖區(qū)溢出問題，比如用strcat()，在用這個函數(shù)之前必須要先給目標(biāo)變量分配足夠的空間，否則就會溢出。
  2. 如果要獲取字符串的長度，沒有數(shù)據(jù)結(jié)構(gòu)的支撐，可能就需要遍歷，它的復(fù)雜度是O(N)
  3. 內(nèi)存重分配。C字符串的每次變更(曾長或縮短)都會對數(shù)組作內(nèi)存重分配。同樣，如果是縮短，沒有處理好多余的空間，也會造成內(nèi)存泄漏。

好了，Redis自己構(gòu)建了一種名叫Simple dynamic string(SDS)的數(shù)據(jù)結(jié)構(gòu)，他分別對這幾個問題作了處理。我們先來看看它的結(jié)構(gòu)源碼：

  1. struct sdshdr{ 
  2.  //記錄buf數(shù)組中已使用字節(jié)的數(shù)量 
  3.  //等于 SDS 保存字符串的長度 
  4.  int len; 
  5.  //記錄 buf 數(shù)組中未使用字節(jié)的數(shù)量 
  6.  int free; 
  7.  //字節(jié)數(shù)組，用于保存字符串 
  8.  char buf[]; 
  9. } 

再來說說它的優(yōu)點(diǎn)：

  1. 開發(fā)者不用擔(dān)心字符串變更造成的內(nèi)存溢出問題。
  2. 常數(shù)時間復(fù)雜度獲取字符串長度len字段。
  3. 空間預(yù)分配free字段，會默認(rèn)留夠一定的空間防止多次重分配內(nèi)存。

這就是string的底層實現(xiàn)，更是redis對所有字符串?dāng)?shù)據(jù)的處理方式(SDS會被嵌套到別的數(shù)據(jù)結(jié)構(gòu)里使用)。

2. 鏈表

Redis的鏈表在雙向鏈表上擴(kuò)展了頭、尾節(jié)點(diǎn)、元素數(shù)等屬性。

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

2.1 源碼

ListNode節(jié)點(diǎn)數(shù)據(jù)結(jié)構(gòu)：

  1. typedef struct listNode{ 
  2.  //前置節(jié)點(diǎn) 
  3.  struct listNode *prev; 
  4.  //后置節(jié)點(diǎn) 
  5.  struct listNode *next; 
  6.  //節(jié)點(diǎn)的值 
  7.  void *value;  
  8. }listNode 

鏈表數(shù)據(jù)結(jié)構(gòu)：

  1. typedef struct list{ 
  2.  //表頭節(jié)點(diǎn) 
  3.  listNode *head; 
  4.  //表尾節(jié)點(diǎn) 
  5.  listNode *tail; 
  6.  //鏈表所包含的節(jié)點(diǎn)數(shù)量 
  7.  unsigned long len; 
  8.  //節(jié)點(diǎn)值復(fù)制函數(shù) 
  9.  void (*free) (void *ptr); 
  10.  //節(jié)點(diǎn)值釋放函數(shù) 
  11.  void (*free) (void *ptr); 
  12.  //節(jié)點(diǎn)值對比函數(shù) 
  13.  int (*match) (void *ptr,void *key); 
  14. }list; 

從上面可以看到，Redis的鏈表有這幾個特點(diǎn)：

  1. 可以直接獲得頭、尾節(jié)點(diǎn)。
  2. 常數(shù)時間復(fù)雜度得到鏈表長度。
  3. 是雙向鏈表。

3. 字典(Hash)

Redis的Hash，就是在數(shù)組+鏈表的基礎(chǔ)上，進(jìn)行了一些rehash優(yōu)化等。

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

3.1 數(shù)據(jù)結(jié)構(gòu)源碼

哈希表：

  1. typedef struct dictht { 
  2.  // 哈希表數(shù)組 
  3.  dictEntry **table; 
  4.  // 哈希表大小 
  5.  unsigned long size; 
  6.  // 哈希表大小掩碼，用于計算索引值 
  7.  // 總是等于 size - 1 
  8.  unsigned long sizemask; 
  9.  // 該哈希表已有節(jié)點(diǎn)的數(shù)量 
  10.  unsigned long used; 
  11. } dictht; 

Hash表節(jié)點(diǎn)：

  1. typedef struct dictEntry { 
  2.  // 鍵 
  3.  void *key; 
  4.  // 值 
  5.  union { 
  6.  void *val; 
  7.  uint64_t u64; 
  8.  int64_t s64; 
  9.  } v; 
  10.  // 指向下個哈希表節(jié)點(diǎn)，形成鏈表 
  11.  struct dictEntry *next; // 單鏈表結(jié)構(gòu) 
  12. } dictEntry; 

字典：

  1. typedef struct dict { 
  2.  // 類型特定函數(shù) 
  3.  dictType *type; 
  4.  // 私有數(shù)據(jù) 
  5.  void *privdata; 
  6.  // 哈希表 
  7.  dictht ht[2]; 
  8.  // rehash 索引 
  9.  // 當(dāng) rehash 不在進(jìn)行時，值為 -1 
  10.  int rehashidx; /* rehashing not in progress if rehashidx == -1 */ 
  11. } dict; 

可以看出：

  1. Reids的Hash采用鏈地址法來處理沖突，然后它沒有使用紅黑樹優(yōu)化。
  2. 哈希表節(jié)點(diǎn)采用單鏈表結(jié)構(gòu)。
  3. rehash優(yōu)化。

下面我們講一下它的rehash優(yōu)化。

3.2 rehash

當(dāng)哈希表的鍵對泰國或者太少，就需要對哈希表的大小進(jìn)行調(diào)整，redis是如何調(diào)整的呢?

我們仔細(xì)可以看到dict結(jié)構(gòu)里有個字段dictht ht[2]代表有兩個dictht數(shù)組。第一步就是為ht[1]哈希表分配空間，大小取決于ht[0]當(dāng)前使用的情況。

將保存在ht[0]中的數(shù)據(jù)rehash(重新計算哈希值)到ht[1]上。

當(dāng)ht[0]中所有鍵值對都遷移到ht[1]后，釋放ht[0]，將ht[1]設(shè)置為ht[0]，并ht[1]初始化，為下一次rehash做準(zhǔn)備。

3.3 漸進(jìn)式rehash

我們在3.2中看到，redis處理rehash的流程，但是更細(xì)一點(diǎn)的講，它如何進(jìn)行數(shù)據(jù)遷的呢?

這就涉及到了漸進(jìn)式rehash，redis考慮到大量數(shù)據(jù)遷移帶來的cpu繁忙(可能導(dǎo)致一段時間內(nèi)停止服務(wù))，所以采用了漸進(jìn)式rehash的方案。步驟如下：

為ht[1]分配空間，同時持有兩個哈希表(一個空表、一個有數(shù)據(jù))。

維持一個技術(shù)器rehashidx，初始值0。

每次對字典增刪改查，會順帶將ht[0]中的數(shù)據(jù)遷移到ht[1],rehashidx++(注意：ht[0]中的數(shù)據(jù)是只減不增的)。

直到rehash操作完成，rehashidx值設(shè)為-1。

它的好處：采用分而治之的思想，將龐大的遷移工作量劃分到每一次CURD中，避免了服務(wù)繁忙。

4. 跳躍表

這個數(shù)據(jù)結(jié)構(gòu)是我面試中見過最多的，它其實特別簡單。學(xué)過的人可能都知道，它和平衡樹性能很相似，但為什么不用平衡樹而用skipList呢?

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

4.1 skipList & AVL 之間的選擇

  • 從算法實現(xiàn)難度上來比較，skiplist比平衡樹要簡單得多。
  • 平衡樹的插入和刪除操作可能引發(fā)子樹的調(diào)整，邏輯復(fù)雜，而skiplist的插入和刪除只需要修改相鄰節(jié)點(diǎn)的指針，操作簡單又快速。
  • 查找單個key，skiplist和平衡樹的時間復(fù)雜度都為O(log n)，大體相當(dāng)。
  • 在做范圍查找的時候，平衡樹比skiplist操作要復(fù)雜。
  • skiplist和各種平衡樹(如AVL、紅黑樹等)的元素是有序排列的。

可以看到，skipList中的元素是有序的，所以跳躍表在redis中用在有序集合鍵、集群節(jié)點(diǎn)內(nèi)部數(shù)據(jù)結(jié)構(gòu)

4.2 源碼

跳躍表節(jié)點(diǎn)：

  1. typedef struct zskiplistNode { 
  2.   
  3.  // 后退指針 
  4.  struct zskiplistNode *backward; 
  5.   
  6.  // 分值 
  7.  double score; 
  8.   
  9.  // 成員對象 
  10.  robj *obj; 
  11.   
  12.  // 層 
  13.  struct zskiplistLevel { 
  14.   
  15.  // 前進(jìn)指針 
  16.  struct zskiplistNode *forward; 
  17.   
  18.  // 跨度 
  19.  unsigned int span; 
  20.   
  21.  } level[]; 
  22.   
  23. } zskiplistNode; 

跳躍表：

  1. typedef struct zskiplist { 
  2.   
  3.  // 表頭節(jié)點(diǎn)和表尾節(jié)點(diǎn) 
  4.  struct zskiplistNode *header, *tail; 
  5.   
  6.  // 表中節(jié)點(diǎn)的數(shù)量 
  7.  unsigned long length; 
  8.   
  9.  // 表中層數(shù)最大的節(jié)點(diǎn)的層數(shù) 
  10.  int level; 
  11.   
  12. } zskiplist; 

它有幾個概念：

4.2.1 層(level[])

層，也就是level[]字段，層的數(shù)量越多，訪問節(jié)點(diǎn)速度越快。(因為它相當(dāng)于是索引，層數(shù)越多，它索引就越細(xì)，就能很快找到索引值)

4.2.2 前進(jìn)指針(forward)

層中有一個forward字段，用于從表頭向表尾方向訪問。

4.2.3 跨度(span)

用于記錄兩個節(jié)點(diǎn)之間的距離

4.2.4 后退指針(backward)

用于從表尾向表頭方向訪問。

案例

  1. level0 1---------->5 
  2. level1 1---->3---->5 
  3. level2 1->2->3->4->5->6->7->8 

比如我要找鍵為6的元素，在level0中直接定位到5，然后再往后走一個元素就找到了。

5. 整數(shù)集合(intset)

Reids對整數(shù)存儲專門作了優(yōu)化，intset就是redis用于保存整數(shù)值的集合數(shù)據(jù)結(jié)構(gòu)。當(dāng)一個結(jié)合中只包含整數(shù)元素，redis就會用這個來存儲。

  1. 127.0.0.1:6379[2]> sadd number 1 2 3 4 5 6 
  2. (integer) 6 
  3. 127.0.0.1:6379[2]> object encoding number 
  4. "intset" 

源碼

intset數(shù)據(jù)結(jié)構(gòu)：

  1. typedef struct intset { 
  2.   
  3.  // 編碼方式 
  4.  uint32_t encoding; 
  5.   
  6.  // 集合包含的元素數(shù)量 
  7.  uint32_t length; 
  8.   
  9.  // 保存元素的數(shù)組 
  10.  int8_t contents[]; 
  11.   
  12. } intset; 

你肯定很好奇編碼方式(encoding)字段是干嘛用的呢?

  • 如果 encoding 屬性的值為 INTSET_ENC_INT16 ， 那么 contents 就是一個 int16_t 類型的數(shù)組， 數(shù)組里的每個項都是一個 int16_t 類型的整數(shù)值 (最小值為 -32,768 ，最大值為 32,767 )。
  • 如果 encoding 屬性的值為 INTSET_ENC_INT32 ， 那么 contents 就是一個 int32_t 類型的數(shù)組， 數(shù)組里的每個項都是一個 int32_t 類型的整數(shù)值 (最小值為 -2,147,483,648 ，最大值為 2,147,483,647 )。
  • 如果 encoding 屬性的值為 INTSET_ENC_INT64 ， 那么 contents 就是一個 int64_t 類型的數(shù)組， 數(shù)組里的每個項都是一個 int64_t 類型的整數(shù)值 (最小值為 -9,223,372,036,854,775,808 ，最大值為 9,223,372,036,854,775,807 )。

說白了就是根據(jù)contents字段來判斷用哪個int類型更好，也就是對int存儲作了優(yōu)化。

說到優(yōu)化，那redis如何作的呢?就涉及到了升級。

5.1 encoding升級

如果我們有個Int16類型的整數(shù)集合，現(xiàn)在要將65535(int32)加進(jìn)這個集合，int16是存儲不下的，所以就要對整數(shù)集合進(jìn)行升級。

它是怎么升級的呢(過程)?

假如現(xiàn)在有2個int16的元素:1和2，新加入1個int32位的元素65535。

內(nèi)存重分配，新加入后應(yīng)該是3個元素，所以分配3*32-1=95位。

選擇最大的數(shù)65535, 放到(95-32+1, 95)位這個內(nèi)存段中，然后2放到(95-32-32+1+1, 95-32)位...依次類推。

升級的好處是什么呢?

  • 提高了整數(shù)集合的靈活性。
  • 盡可能節(jié)約內(nèi)存(能用小的就不用大的)。

5.2 不支持降級

按照上面的例子，如果我把65535又刪掉，encoding會不會又回到Int16呢，答案是不會的。官方?jīng)]有給出理由，我覺得應(yīng)該是降低性能消耗吧，畢竟調(diào)整一次是O(N)的時間復(fù)雜度。

6. 壓縮列表(ziplist)

ziplist是redis為了節(jié)約內(nèi)存而開發(fā)的順序型數(shù)據(jù)結(jié)構(gòu)。它被用在列表鍵和哈希鍵中。一般用于小數(shù)據(jù)存儲。

引用https://segmentfault.com/a/1190000016901154中的兩個圖：

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

6.1 源碼

ziplist沒有明確定義結(jié)構(gòu)體，這里只作大概的演示。

  1. typedef struct entry { 
  2.  /*前一個元素長度需要空間和前一個元素長度*/ 
  3.  unsigned int prevlengh; 
  4.  /*元素內(nèi)容編碼*/ 
  5.  unsigned char encoding; 
  6.  /*元素實際內(nèi)容*/ 
  7.  unsigned char *data; 
  8. }zlentry; 
  9. tpedef struct ziplist{ 
  10.  /*ziplist分配的內(nèi)存大小*/ 
  11.  uint32_t zlbytes; 
  12.  /*達(dá)到尾部的偏移量*/ 
  13.  uint32_t zltail; 
  14.  /*存儲元素實體個數(shù)*/ 
  15.  uint16_t zllen; 
  16.  /*存儲內(nèi)容實體元素*/ 
  17.  unsigned char* entry[]; 
  18.  /*尾部標(biāo)識*/ 
  19.  unsigned char zlend; 
  20. }ziplist; 

第一次看可能會特別蒙蔽，你細(xì)細(xì)的把我這段話看完就一定能懂。

Entry的分析

entry結(jié)構(gòu)體里面有三個重要的字段：

  • previous_entry_length: 這個字段記錄了ziplist中前一個節(jié)點(diǎn)的長度，什么意思?就是說通過該屬性可以進(jìn)行指針運(yùn)算達(dá)到表尾向表頭遍歷，這個字段還有一個大問題下面會講。
  • encoding:記錄了數(shù)據(jù)類型(int16? string?)和長度。
  • data/content: 記錄數(shù)據(jù)。

連鎖更新

previous_entry_length字段的分析

上面有說到，previous_entry_length這個字段存放上個節(jié)點(diǎn)的長度，那默認(rèn)長度給分配多少呢?redis是這樣分的，如果前節(jié)點(diǎn)長度小于254,就分配1字節(jié)，大于的話分配5字節(jié)，那問題就來了。

如果前一個節(jié)點(diǎn)的長度剛開始小于254字節(jié)，后來大于254,那不就存放不下了嗎?這就涉及到previous_entry_length的更新，但是改一個肯定不行阿，后面的節(jié)點(diǎn)內(nèi)存信息都需要改。所以就需要重新分配內(nèi)存，然后連鎖更新包括該受影響節(jié)點(diǎn)后面的所有節(jié)點(diǎn)。

除了增加新節(jié)點(diǎn)會引發(fā)連鎖更新、刪除節(jié)點(diǎn)也會觸發(fā)。

7. 快速列表(quicklist)

一個由ziplist組成的雙向鏈表。但是一個quicklist可以有多個quicklist節(jié)點(diǎn)，它很像B樹的存儲方式。是在redis3.2版本中新加的數(shù)據(jù)結(jié)構(gòu)，用在列表的底層實現(xiàn)。

 

你知道 Redis數(shù)據(jù)結(jié)構(gòu)底層實現(xiàn)嗎？一文詳解，徹底弄懂

 

結(jié)構(gòu)體源碼

表頭結(jié)構(gòu)：

  1. typedef struct quicklist { 
  2.  //指向頭部(最左邊)quicklist節(jié)點(diǎn)的指針 
  3.  quicklistNode *head; 
  4.   
  5.  //指向尾部(最右邊)quicklist節(jié)點(diǎn)的指針 
  6.  quicklistNode *tail; 
  7.   
  8.  //ziplist中的entry節(jié)點(diǎn)計數(shù)器 
  9.  unsigned long count; /* total count of all entries in all ziplists */ 
  10.   
  11.  //quicklist的quicklistNode節(jié)點(diǎn)計數(shù)器 
  12.  unsigned int len; /* number of quicklistNodes */ 
  13.   
  14.  //保存ziplist的大小，配置文件設(shè)定，占16bits 
  15.  int fill : 16; /* fill factor for individual nodes */ 
  16.   
  17.  //保存壓縮程度值，配置文件設(shè)定，占16bits，0表示不壓縮 
  18.  unsigned int compress : 16; /* depth of end nodes not to compress;0=off */ 
  19. } quicklist; 

quicklist節(jié)點(diǎn)結(jié)構(gòu):

  1. typedef struct quicklistNode { 
  2.  struct quicklistNode *prev; //前驅(qū)節(jié)點(diǎn)指針 
  3.  struct quicklistNode *next; //后繼節(jié)點(diǎn)指針 
  4.   
  5.  //不設(shè)置壓縮數(shù)據(jù)參數(shù)recompress時指向一個ziplist結(jié)構(gòu) 
  6.  //設(shè)置壓縮數(shù)據(jù)參數(shù)recompress指向quicklistLZF結(jié)構(gòu) 
  7.  unsigned char *zl; 
  8.   
  9.  //壓縮列表ziplist的總長度 
  10.  unsigned int sz; /* ziplist size in bytes */ 
  11.   
  12.  //ziplist中包的節(jié)點(diǎn)數(shù)，占16 bits長度 
  13.  unsigned int count : 16; /* count of items in ziplist */ 
  14.   
  15.  //表示是否采用了LZF壓縮算法壓縮quicklist節(jié)點(diǎn)，1表示壓縮過，2表示沒壓縮，占2 bits長度 
  16.  unsigned int encoding : 2; /* RAW==1 or LZF==2 */ 
  17.   
  18.  //表示一個quicklistNode節(jié)點(diǎn)是否采用ziplist結(jié)構(gòu)保存數(shù)據(jù)，2表示壓縮了，1表示沒壓縮，默認(rèn)是2，占2bits長度 
  19.  unsigned int container : 2; /* NONE==1 or ZIPLIST==2 */ 
  20.   
  21.  //標(biāo)記quicklist節(jié)點(diǎn)的ziplist之前是否被解壓縮過，占1bit長度 
  22.  //如果recompress為1，則等待被再次壓縮 
  23.  unsigned int recompress : 1; /* was this node previous compressed? */ 
  24.   
  25.  //測試時使用 
  26.  unsigned int attempted_compress : 1; /* node can't compress; too small */ 
  27.   
  28.  //額外擴(kuò)展位，占10bits長度 
  29.  unsigned int extra : 10; /* more bits to steal for future usage */ 
  30. } quicklistNode; 

相關(guān)配置

在redis.conf中的ADVANCED CONFIG部分：

  1. list-max-ziplist-size -2 
  2. list-compress-depth 0 

list-max-ziplist-size參數(shù)

我們來詳細(xì)解釋一下list-max-ziplist-size這個參數(shù)的含義。它可以取正值，也可以取負(fù)值。

當(dāng)取正值的時候，表示按照數(shù)據(jù)項個數(shù)來限定每個quicklist節(jié)點(diǎn)上的ziplist長度。比如，當(dāng)這個參數(shù)配置成5的時候，表示每個quicklist節(jié)點(diǎn)的ziplist最多包含5個數(shù)據(jù)項。

當(dāng)取負(fù)值的時候，表示按照占用字節(jié)數(shù)來限定每個quicklist節(jié)點(diǎn)上的ziplist長度。這時，它只能取-1到-5這五個值，每個值含義如下：

-5: 每個quicklist節(jié)點(diǎn)上的ziplist大小不能超過64 Kb。(注：1kb => 1024 bytes)

-4: 每個quicklist節(jié)點(diǎn)上的ziplist大小不能超過32 Kb。

-3: 每個quicklist節(jié)點(diǎn)上的ziplist大小不能超過16 Kb。

-2: 每個quicklist節(jié)點(diǎn)上的ziplist大小不能超過8 Kb。(-2是Redis給出的默認(rèn)值)

list-compress-depth參數(shù)

這個參數(shù)表示一個quicklist兩端不被壓縮的節(jié)點(diǎn)個數(shù)。注：這里的節(jié)點(diǎn)個數(shù)是指quicklist雙向鏈表的節(jié)點(diǎn)個數(shù)，而不是指ziplist里面的數(shù)據(jù)項個數(shù)。實際上，一個quicklist節(jié)點(diǎn)上的ziplist，如果被壓縮，就是整體被壓縮的。

參數(shù)list-compress-depth的取值含義如下：

0: 是個特殊值，表示都不壓縮。這是Redis的默認(rèn)值。 1: 表示quicklist兩端各有1個節(jié)點(diǎn)不壓縮，中間的節(jié)點(diǎn)壓縮。 2: 表示quicklist兩端各有2個節(jié)點(diǎn)不壓縮，中間的節(jié)點(diǎn)壓縮。 3: 表示quicklist兩端各有3個節(jié)點(diǎn)不壓縮，中間的節(jié)點(diǎn)壓縮。 依此類推…

Redis對于quicklist內(nèi)部節(jié)點(diǎn)的壓縮算法，采用的LZF——一種無損壓縮算法。

責(zé)任編輯：武曉燕 來源： 博客園
Redis數(shù)據(jù)C語言
相關(guān)推薦

2023-12-12 07:31:51

Executors工具開發(fā)者

2019-06-21 15:20:05

Redis數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)庫

2020-05-13 09:14:16

哈希表數(shù)據(jù)結(jié)構(gòu)

2020-05-20 09:55:42

Git底層數(shù)據(jù)

2024-10-16 10:11:52

2023-11-08 07:56:38

單鏈表雙鏈表

2021-08-29 07:41:48

數(shù)據(jù)HashMap底層

2022-01-04 08:54:32

Redis數(shù)據(jù)庫數(shù)據(jù)類型

2020-11-10 10:26:16

串口打印工具

2021-12-20 07:59:07

Go語言結(jié)構(gòu)體

2019-10-29 08:59:16

Redis底層數(shù)據(jù)

2021-08-31 07:36:22

LinkedListAndroid數(shù)據(jù)結(jié)構(gòu)

2024-11-07 15:36:34

2022-08-09 09:10:43

Kubernetes容器

2023-11-28 09:31:55

MySQL算法

2019-06-12 22:51:57

Redis軟件開發(fā)

2019-04-17 15:35:37

Redis數(shù)據(jù)庫數(shù)據(jù)結(jié)構(gòu)

2023-02-23 19:32:03

DOMJavascript開發(fā)

2023-09-18 08:02:45

CSS布局屬性

2023-10-26 16:27:50

前端 WebCSS開發(fā)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號