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

Redis專題(2):Redis數(shù)據(jù)結(jié)構(gòu)底層探秘

開發(fā) 開發(fā)工具 Redis
Redis的底層數(shù)據(jù)結(jié)構(gòu)到底是什么樣的呢,為什么它能做這么多的事情?本文將探秘Redis的底層數(shù)據(jù)結(jié)構(gòu)以及常用的命令。

前言

上篇文章Redis閑談(1):構(gòu)建知識圖譜介紹了Redis的基本概念、優(yōu)缺點(diǎn)以及它的內(nèi)存淘汰機(jī)制,相信大家對Redis有了初步的認(rèn)識。互聯(lián)網(wǎng)的很多應(yīng)用場景都有著Redis的身影,它能做的事情遠(yuǎn)遠(yuǎn)超出了我們的想像。Redis的底層數(shù)據(jù)結(jié)構(gòu)到底是什么樣的呢,為什么它能做這么多的事情?本文將探秘Redis的底層數(shù)據(jù)結(jié)構(gòu)以及常用的命令。

本文知識腦圖如下:

一、Redis的數(shù)據(jù)模型

用 鍵值對 name:"小明"來展示Redis的數(shù)據(jù)模型如下:

Redis的數(shù)據(jù)模型

  • dictEntry:在一些編程語言中,鍵值對的數(shù)據(jù)結(jié)構(gòu)被稱為字典,而在Redis中,會給每一個key-value鍵值對分配一個字典實(shí)體,就是“dicEntry”。dicEntry包含三部分: key的指針、val的指針、next指針,next指針指向下一個dicteEntry形成鏈表,這個next指針可以將多個哈希值相同的鍵值對鏈接在一起,通過鏈地址法來解決哈希沖突的問題
  • sds :Simple Dynamic String,簡單動態(tài)字符串,存儲字符串?dāng)?shù)據(jù)。
  • redisObject:Redis的5種常用類型都是以RedisObject來存儲的,redisObject中的type字段指明了值的數(shù)據(jù)類型(也就是5種基本類型)。ptr字段指向?qū)ο笏诘牡刂贰?/li>

RedisObject對象很重要,Redis對象的類型、內(nèi)部編碼、內(nèi)存回收、共享對象等功能,都是基于RedisObject對象來實(shí)現(xiàn)的。

這樣設(shè)計的好處是:可以針對不同的使用場景,對5種常用類型設(shè)置多種不同的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn),從而優(yōu)化對象在不同場景下的使用效率。

Redis將jemalloc作為默認(rèn)內(nèi)存分配器,減小內(nèi)存碎片。jemalloc在64位系統(tǒng)中,將內(nèi)存空間劃分為小、大、巨大三個范圍;每個范圍內(nèi)又劃分了許多小的內(nèi)存塊單位;當(dāng)Redis存儲數(shù)據(jù)時,會選擇大小最合適的內(nèi)存塊進(jìn)行存儲。

二、Redis支持的數(shù)據(jù)結(jié)構(gòu)

Redis支持的數(shù)據(jù)結(jié)構(gòu)有哪些?

如果回答是String、List、Hash、Set、Zset就不對了,這5種是Redis的常用基本數(shù)據(jù)類型,每一種數(shù)據(jù)類型內(nèi)部還包含著多種數(shù)據(jù)結(jié)構(gòu)。

用encoding指令來看一個值的數(shù)據(jù)結(jié)構(gòu)。比如:

  1. 127.0.0.1:6379> set name tom 
  2. OK 
  3. 127.0.0.1:6379> object encoding name 
  4. "embstr 

此處設(shè)置了name值是tom,它的數(shù)據(jù)結(jié)構(gòu)是embstr,下文介紹字符串時會詳解說明。

  1. 127.0.0.1:6379> set age 18 
  2. OK 
  3. 127.0.0.1:6379> object encoding age 
  4. "int" 

如下表格總結(jié)Redis中所有的數(shù)據(jù)結(jié)構(gòu)類型:

補(bǔ)充說明:

假如面試官問:Redis的數(shù)據(jù)類型有哪些?

回答:String、list、hash、set、zet

一般情況下這樣回答是正確的,前文也提到Redis的數(shù)據(jù)類型確實(shí)是包含這5種,但細(xì)心的同學(xué)肯定發(fā)現(xiàn)了之前說的是“常用”的5種數(shù)據(jù)類型。其實(shí),隨著Redis的不斷更新和完善,Redis的數(shù)據(jù)類型早已不止5種了。

登錄Redis的官方網(wǎng)站打開官方的數(shù)據(jù)類型介紹(https://redis.io/topics/data-types-intro):

發(fā)現(xiàn)Redis支持的數(shù)據(jù)結(jié)構(gòu)不止5種,而是8種,后三種類型分別是:

  • 位數(shù)組(或簡稱位圖):使用特殊命令可以處理字符串值,如位數(shù)組:您可以設(shè)置和清除各個位,將所有位設(shè)置為1,查找第一個位或未設(shè)置位,等等。
  • HyperLogLogs:這是一個概率數(shù)據(jù)結(jié)構(gòu),用于估計集合的基數(shù)。不要害怕,它比看起來更簡單。
  • Streams:僅附加的類似于地圖的條目集合,提供抽象日志數(shù)據(jù)類型。

本文主要介紹5種常用的數(shù)據(jù)類型,上述三種以后再共同探索。

1. string字符串

字符串類型是Redis最常用的數(shù)據(jù)類型,在Redis中,字符串是可以修改的,在底層它是以字節(jié)數(shù)組的形式存在的。

Redis中的字符串被稱為簡單動態(tài)字符串「SDS」,這種結(jié)構(gòu)很像Java中的ArrayList,其長度是動態(tài)可變的。

  1. struct SDS<T> { 
  2.   T capacity; // 數(shù)組容量 
  3.   T len; // 數(shù)組長度 
  4.   byte[] content; // 數(shù)組內(nèi)容 

content[] 存儲的是字符串的內(nèi)容,capacity表示數(shù)組分配的長度,len表示字符串的實(shí)際長度。

字符串的編碼類型有int、embstr和raw三種,如上表所示,那么這三種編碼類型有什么不同呢?

  • int 編碼:保存的是可以用 long 類型表示的整數(shù)值。
  • raw 編碼:保存長度大于44字節(jié)的字符串(redis3.2版本之前是39字節(jié),之后是44字節(jié))。
  • embstr 編碼:保存長度小于44字節(jié)的字符串(redis3.2版本之前是39字節(jié),之后是44字節(jié))。

設(shè)置一個值測試一下:

  1. 127.0.0.1:6379> set num 300 
  2. 127.0.0.1:6379> object encoding num 
  3. "int" 
  4. 127.0.0.1:6379> set key1 wealwaysbyhappyhahaha 
  5. OK 
  6. 127.0.0.1:6379> object encoding key1 
  7. "embstr" 
  8. 127.0.0.1:6379> set key2 hahahahahahahaahahahahahahahahahahahaha 
  9. OK 
  10. 127.0.0.1:6379> strlen key2 
  11. (integer) 39 
  12. 127.0.0.1:6379> object encoding key2 
  13. "embstr" 
  14. 127.0.0.1:6379> set key2 hahahahahahahaahahahahahahahahahahahahahahaha 
  15. OK 
  16. 127.0.0.1:6379> object encoding key2 
  17. "raw" 
  18. 127.0.0.1:6379> strlen key2 
  19. (integer) 45 

aw類型和embstr類型對比:

embstr編碼的結(jié)構(gòu):

raw編碼的結(jié)構(gòu):

  • embstr和raw都是由redisObject和sds組成的。不同的是:embstr的redisObject和sds是連續(xù)的,只需要使用malloc分配一次內(nèi)存;而raw需要為redisObject和sds分別分配內(nèi)存,即需要分配兩次內(nèi)存。
  • 所有相比較而言,embstr少分配一次內(nèi)存,更方便。但embstr也有明顯的缺點(diǎn):如要增加長度,redisObject和sds都需要重新分配內(nèi)存。

上文介紹了embstr和raw結(jié)構(gòu)上的不同。重點(diǎn)來了~ 為什么會選擇44作為兩種編碼的分界點(diǎn)?在3.2版本之前為什么是39?這兩個值是怎么得出來的呢?

(1) 計算RedisObject占用的字節(jié)大小

  1. struct RedisObject { 
  2.     int4 type; // 4bits 
  3.     int4 encoding; // 4bits 
  4.     int24 lru; // 24bits 
  5.     int32 refcount; // 4bytes = 32bits 
  6.     void *ptr; // 8bytes,64-bit system 
  • type:不同的redis對象會有不同的數(shù)據(jù)類型(string、list、hash等),type記錄類型,會用到4bits。
  • encoding:存儲編碼形式,用4bits。
  • lru:用24bits記錄對象的LRU信息。
  • refcount:引用計數(shù)器,用到32bits。
  • *ptr:指針指向?qū)ο蟮木唧w內(nèi)容,需要64bits。

計算: 4 + 4 + 24 + 32 + 64 = 128bits = 16bytes

第一步就完成了,RedisObject對象頭信息會占用16字節(jié)的大小,這個大小通常是固定不變的.

(2) sds占用字節(jié)大小計算

舊版本:

  1. struct SDS { 
  2.     unsigned int capacity; // 4byte 
  3.     unsigned int len; // 4byte 
  4.     byte[] content; // 內(nèi)聯(lián)數(shù)組,長度為 capacity 

這里的unsigned int 一個4字節(jié),加起來是8字節(jié).

內(nèi)存分配器jemalloc分配的內(nèi)存如果超出了64個字節(jié)就認(rèn)為是一個大字符串,就會用到embstr編碼。

前面提到 SDS 結(jié)構(gòu)體中的 content 的字符串是以字節(jié)\0結(jié)尾的字符串,之所以多出這樣一個字節(jié),是為了便于直接使用 glibc 的字符串處理函數(shù),以及為了便于字符串的調(diào)試打印輸出。所以我們還要減去1字節(jié) 64byte - 16byte - 8byte - 1byte = 39byte

新版本:

  1. struct SDS { 
  2.     int8 capacity; // 1byte 
  3.     int8 len; // 1byte 
  4.     int8 flags; // 1byte 
  5.     byte[] content; // 內(nèi)聯(lián)數(shù)組,長度為 capacity 

這里unsigned int 變成了uint8_t、uint16_t.的形式,還加了一個char flags標(biāo)識,總共只用了3個字節(jié)的大小。相當(dāng)于優(yōu)化了sds的內(nèi)存使用,相應(yīng)的用于存儲字符串的內(nèi)存就會變大。

然后進(jìn)行計算:

64byte - 16byte -3byte -1byte = 44byte。

總結(jié):所以,Redis 3.2版本之后embstr最大能容納的字符串長度是44,之前是39。長度變化的原因是SDS中內(nèi)存的優(yōu)化。

2. List

Redis中List對象的底層是由quicklist(快速列表)實(shí)現(xiàn)的,快速列表支持從鏈表頭和尾添加元素,并且可以獲取指定位置的元素內(nèi)容。

那么,快速列表的底層是如何實(shí)現(xiàn)的呢?為什么能夠達(dá)到如此快的性能?

羅馬不是一日建成的,quicklist也不是一日實(shí)現(xiàn)的,起初redis的list的底層是ziplist(壓縮列表)或者是 linkedlist(雙端列表)。先分別介紹這兩種數(shù)據(jù)結(jié)構(gòu)。

(1) ziplist 壓縮列表

當(dāng)一個列表中只包含少量列表項(xiàng),且是小整數(shù)值或長度比較短的字符串時,redis就使用ziplist(壓縮列表)來做列表鍵的底層實(shí)現(xiàn)。

測試:

  1. 127.0.0.1:6379> rpush dotahero sf qop doom 
  2. (integer) 3 
  3. 127.0.0.1:6379> object encoding dotahero 
  4. "ziplist" 

此處使用老版本Redis進(jìn)行測試,向dota英雄列表中加入了qop痛苦女王、sf影魔、doom末日使者三個英雄,數(shù)據(jù)結(jié)構(gòu)編碼使用的是ziplist。

壓縮列表顧名思義是進(jìn)行了壓縮,每一個節(jié)點(diǎn)之間沒有指針的指向,而是多個元素相鄰,沒有縫隙。所以 ziplist是Redis為了節(jié)約內(nèi)存而開發(fā)的,是由一系列特殊編碼的連續(xù)內(nèi)存塊組成的順序型數(shù)據(jù)結(jié)構(gòu)。具體結(jié)構(gòu)相對比較復(fù)雜,大家有興趣地話可以深入了解。

  1. struct ziplist<T> { 
  2.     int32 zlbytes; // 整個壓縮列表占用字節(jié)數(shù) 
  3.     int32 zltail_offset; // 最后一個元素距離壓縮列表起始位置的偏移量,用于快速定位到最后一個節(jié)點(diǎn) 
  4.     int16 zllength; // 元素個數(shù) 
  5.     T[] entries; // 元素內(nèi)容列表,挨個挨個緊湊存儲 
  6.     int8 zlend; // 標(biāo)志壓縮列表的結(jié)束,值恒為 0xFF 

 

(2) 雙端列表(linkedlist)

雙端列表大家都很熟悉,這里的雙端列表和java中的linkedlist很類似。

從圖中可以看出Redis的linkedlist雙端鏈表有以下特性:節(jié)點(diǎn)帶有prev、next指針、head指針和tail指針,獲取前置節(jié)點(diǎn)、后置節(jié)點(diǎn)、表頭節(jié)點(diǎn)和表尾節(jié)點(diǎn)、獲取長度的復(fù)雜度都是O(1)。

壓縮列表占用內(nèi)存少,但是是順序型的數(shù)據(jù)結(jié)構(gòu),插入刪除元素的操作比較復(fù)雜,所以壓縮列表適合數(shù)據(jù)比較小的情況,當(dāng)數(shù)據(jù)比較多的時候,雙端列表的高效插入刪除還是更好的選擇

在Redis開發(fā)者的眼中,數(shù)據(jù)結(jié)構(gòu)的選擇,時間上、空間上都要達(dá)到極致,所以,他們將壓縮列表和雙端列表合二為一,創(chuàng)建了快速列表(quicklist)。和java中的hashmap一樣,結(jié)合了數(shù)組和鏈表的優(yōu)點(diǎn)。

(3) 快速列表(quicklist)

  • rpush: listAddNodeHead ---O(1)
  • lpush: listAddNodeTail ---O(1)
  • push:listInsertNode ---O(1)
  • index : listIndex ---O(N)
  • pop:ListFirst/listLast ---O(1)
  • llen:listLength ---O(N)

  1. struct ziplist { 
  2.     ... 
  3. struct ziplist_compressed { 
  4.     int32 size; 
  5.     byte[] compressed_data; 
  6. struct quicklistNode { 
  7.     quicklistNode* prev; 
  8.     quicklistNode* next; 
  9.     ziplist* zl; // 指向壓縮列表 
  10.     int32 size; // ziplist 的字節(jié)總數(shù) 
  11.     int16 count; // ziplist 中的元素數(shù)量 
  12.     int2 encoding; // 存儲形式 2bit,原生字節(jié)數(shù)組還是 LZF 壓縮存儲 
  13.     ... 
  14. struct quicklist { 
  15.     quicklistNode* head; 
  16.     quicklistNode* tail; 
  17.     long count; // 元素總數(shù) 
  18.     int nodes; // ziplist 節(jié)點(diǎn)的個數(shù) 
  19.     int compressDepth; // LZF 算法壓縮深度 
  20.     ... 

quicklist 默認(rèn)的壓縮深度是 0,也就是不壓縮。壓縮的實(shí)際深度由配置參數(shù)list-compress-depth決定。為了支持快速的 push/pop 操作,quicklist 的首尾兩個 ziplist 不壓縮,此時深度就是 1。如果深度為 2,表示 quicklist 的首尾第一個 ziplist 以及首尾第二個 ziplist 都不壓縮。

3. Hash

Hash數(shù)據(jù)類型的底層實(shí)現(xiàn)是ziplist(壓縮列表)或字典(也稱為hashtable或散列表)。這里壓縮列表或者字典的選擇,也是根據(jù)元素的數(shù)量大小決定的。

如圖hset了三個鍵值對,每個值的字節(jié)數(shù)不超過64的時候,默認(rèn)使用的數(shù)據(jù)結(jié)構(gòu)是ziplist。

當(dāng)我們加入了字節(jié)數(shù)超過64的值的數(shù)據(jù)時,默認(rèn)的數(shù)據(jù)結(jié)構(gòu)已經(jīng)成為了hashtable。

Hash對象只有同時滿足下面兩個條件時,才會使用ziplist(壓縮列表):

  • 哈希中元素數(shù)量小于512個;
  • 哈希中所有鍵值對的鍵和值字符串長度都小于64字節(jié)。

壓縮列表剛才已經(jīng)了解了,hashtables類似于jdk1.7以前的hashmap。hashmap采用了鏈地址法的方法解決了哈希沖突的問題。想要深入了解的話可以參考之前寫的一篇博客: hashmap你真的了解嗎?

(https://blog.csdn.net/qq_32519415/article/details/87006982)

Redis中的字典:

Redis中的dict 結(jié)構(gòu)內(nèi)部包含兩個 hashtable,通常情況下只有一個 hashtable 是有值的。但是在 dict 擴(kuò)容縮容時,需要分配新的 hashtable,然后進(jìn)行漸進(jìn)式搬遷,這時兩個 hashtable 存儲的分別是舊的 hashtable 和新的 hashtable。待搬遷結(jié)束后,舊的 hashtable 被刪除,新的 hashtable 取而代之。

4. Set

Set數(shù)據(jù)類型的底層可以是intset(整數(shù)集)或者是hashtable(散列表也叫哈希表)。

當(dāng)數(shù)據(jù)都是整數(shù)并且數(shù)量不多時,使用intset作為底層數(shù)據(jù)結(jié)構(gòu);當(dāng)有除整數(shù)以外的數(shù)據(jù)或者數(shù)據(jù)量增多時,使用hashtable作為底層數(shù)據(jù)結(jié)構(gòu)。

  1. 127.0.0.1:6379> sadd myset 111 222 333 
  2. (integer) 3 
  3. 127.0.0.1:6379> object encoding myset 
  4. "intset" 
  5. 127.0.0.1:6379> sadd myset hahaha 
  6. (integer) 1 
  7. 127.0.0.1:6379> object encoding myset 
  8. "hashtable" 

inset的數(shù)據(jù)結(jié)構(gòu)為:

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

intset底層實(shí)現(xiàn)為有序、無重復(fù)數(shù)的數(shù)組。 intset的整數(shù)類型可以是16位的、32位的、64位的。如果數(shù)組里所有的整數(shù)都是16位長度的,新加入一個32位的整數(shù),那么整個16的數(shù)組將升級成一個32位的數(shù)組。升級可以提升intset的靈活性,又可以節(jié)約內(nèi)存,但不可逆。

5.  Zset

Redis中的Zset,也叫做有序集合。它的底層是ziplist(壓縮列表)或 skiplist(跳躍表)。

壓縮列表前文已經(jīng)介紹過了,同理是在元素數(shù)量比較少的時候使用。此處主要介紹跳躍列表。

跳表:

跳躍列表,顧名思義是可以跳的,跳著查詢自己想要查到的元素。大家可能對這種數(shù)據(jù)結(jié)構(gòu)比較陌生,雖然平時接觸的少,但它確實(shí)是一個各方面性能都很好的數(shù)據(jù)結(jié)構(gòu),可以支持快速的查詢、插入、刪除操作,開發(fā)難度也比紅黑樹要容易的多。

為什么跳表有如此高的性能呢?它究竟是如何“跳”的呢?跳表利用了二分的思想,在數(shù)組中可以用二分法來快速進(jìn)行查找,在鏈表中也是可以的。

舉個例子,鏈表如下:

假設(shè)要找到10這個節(jié)點(diǎn),需要一個一個去遍歷,判斷是不是要找的節(jié)點(diǎn)。那如何提高效率呢?mysql索引相信大家都很熟悉,可以提高效率,這里也可以使用索引。抽出一個索引層來:

這樣只需要找到9然后再找10就可以了,大大節(jié)省了查找的時間。

還可以再抽出來一層索引,可以更好地節(jié)約時間:

這樣基于鏈表的“二分查找”支持快速的插入、刪除,時間復(fù)雜度都是O(logn)。

由于跳表的快速查找效率,以及實(shí)現(xiàn)的簡單、易讀。所以Redis放棄了紅黑樹而選擇了更為簡單的跳表。

Redis中的跳躍表:

  1. typedef struct zskiplist { 
  2.      // 表頭節(jié)點(diǎn)和表尾節(jié)點(diǎn) 
  3.     struct zskiplistNode *header, *tail; 
  4.     // 表中節(jié)點(diǎn)的數(shù)量 
  5.     unsigned long length; 
  6.     // 表中層數(shù)最大的節(jié)點(diǎn)的層數(shù) 
  7.     int level; 
  8.  } zskiplist; 
  9. typedef struct zskiplistNode { 
  10.     // 成員對象 
  11.     robj *obj; 
  12.     // 分值 
  13.     double score; 
  14.      // 后退指針 
  15.     struct zskiplistNode *backward; 
  16.     // 層 
  17.     struct zskiplistLevel { 
  18.         // 前進(jìn)指針 
  19.         struct zskiplistNode *forward; 
  20.          // 跨度---前進(jìn)指針?biāo)赶蚬?jié)點(diǎn)與當(dāng)前節(jié)點(diǎn)的距離 
  21.         unsigned int span; 
  22.     } level[]; 
  23. } zskiplistNode; 
  • zadd---zslinsert---平均O(logN), 最壞O(N)
  • zrem---zsldelete---平均O(logN), 最壞O(N)
  • zrank--zslGetRank---平均O(logN), 最壞O(N)

總結(jié)

本文大概介紹了Redis的5種常用數(shù)據(jù)類型的底層實(shí)現(xiàn),希望大家結(jié)合源碼和資料更深入地了解。

數(shù)據(jù)結(jié)構(gòu)之美在Redis中體現(xiàn)得淋漓盡致,從String到壓縮列表、快速列表、散列表、跳表,這些數(shù)據(jù)結(jié)構(gòu)都適用在了不同的地方,各司其職。

不僅如此,Redis將這些數(shù)據(jù)結(jié)構(gòu)加以升級、結(jié)合,將內(nèi)存存儲的效率性能達(dá)到了極致,正因?yàn)槿绱?,Redis才能成為眾多互聯(lián)網(wǎng)公司不可缺少的高性能、秒級的key-value內(nèi)存數(shù)據(jù)庫。

【本文是51CTO專欄機(jī)構(gòu)宜信技術(shù)學(xué)院的原創(chuàng)文章,微信公眾號“宜信技術(shù)學(xué)院( id: CE_TECH)”】

戳這里,看該作者更多好文

責(zé)任編輯:趙寧寧 來源: 51CTO專欄
相關(guān)推薦

2019-04-17 15:35:37

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

2019-10-29 08:59:16

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

2023-11-12 21:49:10

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

2025-01-14 08:00:00

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

2025-01-15 12:20:41

2022-05-23 08:19:19

Redis數(shù)據(jù)結(jié)構(gòu)內(nèi)存

2019-06-21 15:20:05

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

2020-03-20 10:47:51

Redis數(shù)據(jù)庫字符串

2023-03-06 08:40:43

RedisListJava

2024-01-26 06:42:05

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

2020-06-29 07:44:36

Redis

2023-01-09 08:42:04

String數(shù)據(jù)類型

2019-09-02 09:48:39

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

2019-09-27 08:53:47

Redis數(shù)據(jù)C語言

2020-10-21 12:45:12

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

2023-09-15 08:14:48

HashMap負(fù)載因子

2023-09-13 08:08:41

Redis消息隊(duì)列

2020-03-02 13:45:18

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

2021-02-07 22:24:59

Redis數(shù)據(jù)存儲

2025-01-13 06:10:00

點(diǎn)贊
收藏

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