2. 程式人生 > >深入剖析 Redis5.0 全新資料結構 Streams（訊息佇列的新選擇）

深入剖析 Redis5.0 全新資料結構 Streams（訊息佇列的新選擇）

阿新 • • 發佈：2019-02-17

點選上方“芋道原始碼”，選擇“置頂公眾號”

技術文章第一時間送達！

原始碼精品專欄

 

來源：阿飛的部落格

Redis 5.0 全新的資料型別：streams，官方把它定義為：以更抽象的方式建模日誌的資料結構。Redis的streams主要是一個append only的資料結構，至少在概念上它是一種在記憶體中表示的抽象資料型別，只不過它們實現了更強大的操作，以克服日誌檔案本身的限制。

如果你瞭解MQ，那麼可以把streams當做MQ。如果你還了解kafka，那麼甚至可以把streams當做kafka。

另外，這個功能有點類似於redis以前的Pub/Sub，但是也有基本的不同：

  • streams支援多個客戶端（消費者）等待資料（Linux環境開多個視窗執行XREAD即可模擬），並且每個客戶端得到的是完全相同的資料。

  • Pub/Sub是傳送忘記的方式，並且不儲存任何資料；而streams模式下，所有訊息被無限期追加在streams中，除非用於顯示執行刪除（XDEL）。

  • streams的Consumer Groups也是Pub/Sub無法實現的控制方式。

streams資料結構

streams資料結構本身非常簡單，但是streams依然是Redis到目前為止最複雜的型別，其原因是實現的一些額外的功能：一系列的阻塞操作允許消費者等待生產者加入到streams的新資料。另外還有一個稱為Consumer Groups的概念，這個概念最先由kafka提出，Redis有一個類似實現，和kafka的Consumer Groups的目的是一樣的：允許一組客戶端協調消費相同的資訊流！

redis原始碼中定義streams結構的原始碼如下，由原始碼可知，stream的核心資料結構是radix tree：

typedef struct stream {
    rax *rax;               /* The radix tree holding the stream. */
    uint64_t length;        /* Number of elements inside this stream. */
    streamID last_id;       /* Zero if there are yet no items. */
    rax *cgroups;           /* Consumer groups dictionary: name -> streamCG */
 

} stream;

原始碼參考：https://github.com/antirez/redis/blob/5.0.0/src/stream.h；

至於redis對radix tree的實現，參考原始碼：https://github.com/antirez/redis/blob/5.0.0/src/rax.c 和 https://github.com/antirez/redis/blob/5.0.0/src/rax.h 。網上也有很多radix tree的文章，本篇文章就不做過多的介紹了。下面給出一張從官方原始碼中的部分截圖：

640?wx_fmt=png
radix tree

radix tree

streams基礎

為了理解streams的目的，以及如何使用它，我們先忽略掉所有高階特性，只把注意力放在資料結構本身，以及那些操作和訪問streams的命令。這基本上也是大多數其他Redis資料型別共有的部分，例如Lists，Sets，Sorted Sets等。然而需要注意的是，Lists也有一個更復雜的阻塞式的API，例如BLPOP，BRPOP等。streams這方便的API也沒什麼不同，只是更復雜，更強大（更牛逼，哈）！

streams命令

廢話不多說，先上手玩玩這個全新的資料型別。streams這個資料型別對應有如下13個操作命令，所有命令都以"X"開頭：

XADD

用法：XADD key ID field string [field string …]
正如其名，這個命令就是用來新增的，給streams追加（append，前面提到過：streams主要是一個append only的資料結構）一個新的entry（和Java裡的Map類似，Redis裡的streams中的資料也稱為entry）。

key：的含義就是同一型別streams的名稱；
ID: streams中entry的唯一識別符號，如果執行XADD命令時，傳入星號（*），那麼，ID會自動生成，且自動生成的ID會在執行XADD後返回，預設生成的ID格式為millisecondsTime+sequenceNumber，即當前毫秒級別的時間戳加上一個自增序號值，例如"1540013735401-0"。並且執行XADD時，不接受少於或等於上一次執行XADD的ID，否則會報錯：ERR The ID specified in XADD is equal or smaller than the target stream top item；
field&string：接下來就是若干組field string。可以把它理解為表示屬性的json中的key-value。例如，某一streams的key命名為userInfo，且某個使用者資訊為{"username":"afei", "password":"123456"}，那麼執行XADD命令如下：

127.0.0.1:6379> xadd userInfo * username afei password 123456
"1540014082060-0"

由於命令中ID欄位的值是星號，所以自定生成ID，1540014082060-0就是自動生成的ID。 XADD命令也支援顯示指定ID，例如：XADD streamname 0-2 foo bar。

  • 時鐘回撥

需要注意的是，ID的時間戳部分是部署Redis伺服器的本地時間，如果發生時鐘回撥會怎麼樣？如果發生始終回撥，生成的ID的時間戳部分就是回撥後的時間，然後加上這個時間的遞增序列號。例如當前時間戳1540014082060，然後這時候發生了時鐘回撥，且回撥5ms，那麼時間戳就是1540014082055。假設以前已經生成了1540014082055-0，1540014082055-1，那麼這次由於時鐘回撥，生成的ID就是1540014082055-2。所以允許自動生成的ID在發生時鐘回撥時少於上次的ID，但是不允許顯示指定一個少於上次的ID。

XDEL

用法：XDEL key ID [ID …]
和XADD相反，這是命令用來從streams中刪除若干個entry，並且會返回實際刪除數，這個刪除數可能和引數ID個數不等，因為某些ID表示的訊息可能不存在。執行命令如下，第二個引數ID是不存在的，所以XDEL的返回結果是1：

127.0.0.1:6379> XDEL userInfo "1540014379642-0" "1540014379642-1"
(integer) 1

XLEN

用法：XLEN key
很好理解，這個命令就是用來返回streams中有多少個entry。執行如下：

127.0.0.1:6379> XLEN userInfo
(integer) 2

streams三種查詢模式

redis提供了三種查詢streams資料的模式：

  1. 範圍查詢：因為streams的每個entry，其預設生成的ID是基於時間且遞增的；

  2. 監聽模式：類比linux中的tailf命令，實時接收新增加到streams中的entry（也有點像一個訊息系統，事實上筆者認為它就是借鑑了kafka）；

  3. 消費者組：即Consumer Groups，特殊的監聽模式。從一個消費者的角度來看streams，一個streams能被分割槽到多個處理訊息的消費者，對於任意一條訊息，同一個消費者組中只有一個消費者可以處理（和kafka的消費者組完全一樣）。這樣還能夠橫向擴容消費者，從而提升處理訊息的能力，而不需要只讓把讓一個消費者處理所有訊息。

接下里分別介紹這三種模式。

XRANGE

用法：XRANGE key start end [COUNT count]
這個命令屬於第1種模式，即基於範圍查詢。這個命令用來返回streams某個順序範圍下的元素，start引數是更小的ID，end引數是更大的ID。有兩個特殊的ID用符號"-"和"+"表示，符號"-"表示最小的ID，符號"+"表示最大的ID：

127.0.0.1:6379> XRANGE userInfo "1540014096298-0" "1540014477236-0"
1) 1) "1540014096298-0"
   2) 1) "username"
      2) "root"
      3) "password"
      4) "666666"
2) 1) "1540014477236-0"
   2) 1) "username"
      2) "test"
      3) "password"
      4) "111111"
127.0.0.1:6379> 
127.0.0.1:6379> XRANGE userInfo - +
1) 1) "1540014082060-0"
   2) 1) "username"
      2) "afei"
      3) "password"
      4) "123456"
2) 1) "1540014096298-0"
   2) 1) "username"
      2) "root"
      3) "password"
      4) "666666"
3) 1) "1540014477236-0"
   2) 1) "username"
      2) "test"
      3) "password"
      4) "111111"
4) 1) "1540014493402-0"
   2) 1) "username"
      2) "u1"
      3) "password"
      4) "111111"

XRANGE還能實現遍歷某個範圍區間的功能，例如我想遍歷2018-10-20號新增的使用者資訊。首先得到2018-10-20 00:00:00對應的時間戳為1539964800000，再得到2018-10-20 23:59:59對應的時間戳為1540051199000，然後執行如下命令：

127.0.0.1:6379> XRANGE userInfo 1539964800000-0  1540051199000-0 COUNT 5
1) 1) "1540014082060-0"
   2) 1) "username"
      2) "afei"
      3) "password"
      4) "123456"
... ...
5) 1) "1540014496505-0"
   2) 1) "username"
      2) "u2"
      3) "password"
      4) "111111"
127.0.0.1:6379> 
# 需要注意的是，接下來再遍歷的start引數是上一次遍歷結果最大的ID加1，即"1540014496505-0"加1就是"1540014496505-1"。
127.0.0.1:6379> XRANGE userInfo 1540014496505-1  1540051199000-0 COUNT 5
1) 1) "1540014499863-0"
   2) 1) "username"
      2) "u3"
      3) "password"
      4) "111111"

XREVRANGE

用法：XREVRANGE key end start [COUNT count]
這個命令也屬於第1種模式，且和XRANGE相反，返回一個逆序範圍。end引數是更大的ID，start引數是更小的ID。執行示例如下：

XREVRANGE userInfo "1540014477236-0" "1540014096298-0"

XREAD

用法：XREAD [COUNT count][BLOCK milliseconds] STREAMS key [key …] ID [ID …]
很明顯，這個命令就是用來實現第2個模式，即監聽模式。其作用是返回streams中從來沒有讀取的，且比引數ID更大的元素。

這個命令的使用方式如下：

127.0.0.1:6379> XREAD COUNT 10 BLOCK 60000 STREAMS userInfo "1540041139268-0"
1) 1) "userInfo"
   2) 1) 1) "1540041264182-0"
         2) 1) "u2"
            2) "p2"
(9.26s)
# "1540041264182-0"這條訊息時通過XADD新增的然後被XREAD監聽到的訊息。
127.0.0.1:6379> XREAD COUNT 2 STREAMS userInfo 0
1) 1) "userInfo"
   2) 1) 1) "1540014082060-0"
         2) 1) "username"
            2) "afei"
            3) "password"
            4) "123456"
      2) 1) "1540014096298-0"
         2) 1) "username"
            2) "root"
            3) "password"
            4) "666666"
# 這條命令實現類似XRANGE的功能。

127.0.0.1:6379> XREAD BLOCK 0 STREAMS userInfo $
1) 1) "userInfo"
   2) 1) 1) "1540042613437-0"
         2) 1) "u7"
            2) "p7"
# 說明BLOCK為0表示一致等待知道有新的資料，否則永遠不會超時。並且ID的值我們用特殊字元`$`表示，這個特殊字元表示我們只獲取最新新增的訊息。

此外，XREAD還支援同時監聽多個streams，用法如下所示：

127.0.0.1:6379> XREAD BLOCK 0 STREAMS userInfo_01 userInfo_02 userInfo_03 userInfo_04  $ $ $ $
1) 1) "userInfo_03"
   2) 1) 1) "1540043348287-0"
         2) 1) "u1"
            2) "p1"
(3.49s)
# 監聽userInfo_01~userInfo_04這4個streams的新的訊息。

XREAD除了COUNT和BLOCK，沒有其他選項了。所有XREAD是一個非常基本的命令。更多高階特性可以往下看接下來要介紹的XREADGROUP。

XREADGROUP

用法：XREADGROUP GROUP group consumer [COUNT count][BLOCK milliseconds] STREAMS key [key …] ID [ID …]
很明顯，這就是第三種模式：消費者組模式。

如果你瞭解kafka的消費者組，那麼你就也瞭解了streams的消費者組。如果不瞭解也沒關係，筆者簡單解釋一下，假設有三個消費者C1，C2，C3。在streams中總計有7條訊息：1， 2， 3， 4， 5， 6， 7，那麼消費關係如下所示：

1 -> C1
2 -> C2
3 -> C3
4 -> C1
5 -> C2
6 -> C3
7 -> C1

消費者組具備如下幾個特點：

  1. 同一個訊息不會被投遞到一個消費者組下的多個消費者，只可能是一個消費者。

  2. 同一個消費者組下，每個消費者都是唯一的，通過大小寫敏感的名字區分。

  3. 消費者組中的消費者請求的訊息，一定是新的，從來沒有投遞過的訊息。

  4. 消費一個訊息後，需要用命令（XACK）確認，意思是說：這條訊息已經給成功處理。正因為如此，當訪問streams的歷史訊息時，每個消費者只能看到投遞給它自己的訊息。

消費者組抽象的想象成如下這個樣子：

+----------------------------------------+
| consumer_group_name: afeigroup         |
| consumer_group_stream: somekey         |
| last_delivered_id: 1292309234234-92    |
|                                        |
| consumers:                             |
|    "consumer-1" with pending messages  |
|       1292309234234-4                  |
|       1292309234232-8                  |
|    "consumer-42" with pending messages |
|       ... (and so forth)               |
+----------------------------------------+

XACK

用法：XACK key group ID [ID …]
這是消費者組相關的另一個重要的命令。標記一個處理中的訊息為已被正確處理，如此一來，這條訊息就會被從消費者組的pending訊息集合中刪除，類似MQ中的ack。

XGROUP

用法：XGROUP [CREATE key groupname id-or-$][SETID key id-or-$] [DESTROY key groupname][DELCONSUMER key groupname consumername]

這也是消費者組的一個重要命令，這個命令用來管理消費者組，例如建立，刪除等。

XREADGROUP，XACK，XGROUP三種命令構成了消費者組相關的操作命令，下面是消費者組一些操作示例：

# 建立一個消費者組
127.0.0.1:6379> XGROUP CREATE userInfo GRP-AFEI $
OK
# 需要注意的是，目前XGROUP CREATE的streams必須是一個存在的streams，否則會報錯：
127.0.0.1:6379> XGROUP CREATE userinfo GRP-AFEI $
(error) ERR The XGROUP subcommand requires the key to exist. Note that for CREATE you may want to use the MKSTREAM option to create an empty stream automatically.

# 名為zhangsan的消費者，需要注意的是streams名稱userInfo後面的特殊符號`>`表示這個消費者只接收從來沒有被投遞給其他消費者的訊息，即新的訊息。當然我們也可以指定具體的ID，例如指定0表示訪問所有投遞給該消費者的歷史訊息，指定1540081890919-1表示投遞給該消費者且大於這個ID的歷史訊息：
127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 1 BLOCK 0 STREAMS userInfo >
# 名為lisi的消費者：
127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 1 BLOCK 0 STREAMS userInfo >

# 接下來分別新增兩條資訊，一條就會被zhangsan消費，另一條被lisi消費：
127.0.0.1:6379> XADD userInfo * username u102102 password p102102
"1540081873370-0"
127.0.0.1:6379> XADD userInfo * username u102103 password p102103
"1540081890919-0"

#現在消費者lisi有一條訊息：
127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 5 BLOCK 0 STREAMS userInfo 0
1) 1) "userInfo"
   2) 1) 1) "1540081890919-0"
         2) 1) "username"
            2) "u102103"
            3) "password"
            4) "p102103"
#然後通過命令ack這條訊息：
127.0.0.1:6379> XACK userInfo mygroup 1540081890919-0
(integer) 1
# 再看消費者lisi的pending佇列，已經為空：
127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 5 BLOCK 0 STREAMS userInfo 0
1) 1) "userInfo"
   2) (empty list or set)

XPENDING

用法：XPENDING key group [start end count][consumer]
返回streams中消費者組的pending訊息，即消費者接收到但是還沒有ack的訊息，用法參考：

# 檢視消費者組下總計最多10條pending訊息
127.0.0.1:6379> XPENDING userInfo mygroup - + 10
1) 1) "1540083260408-0"
   2) "zhangsan"
   3) (integer) 183551
   4) (integer) 1
2) 1) "1540083266293-0"
   2) "lisi"
   3) (integer) 177666
   4) (integer) 1
# 檢視消費者組下zhangsan這個消費者總計最多10條pending訊息
127.0.0.1:6379> XPENDING userInfo mygroup - + 10 zhangsan
1) 1) "1540083260408-0"
   2) "zhangsan"
   3) (integer) 187006
   4) (integer) 1

XCLAIM

用法：XCLAIM key group consumer min-idle-time ID [ID …][IDLE ms] [TIME ms-unix-time][RETRYCOUNT count] [FORCE][JUSTID]
作用是改變消費者組中訊息的所有權，用法參考：

127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 5 BLOCK 0 STREAMS userInfo 0
1) 1) "userInfo"
   2) 1) 1) "1540083260408-0"
         2) 1) "username"
            2) "u102106"
            3) "password"
            4) "p102106"
# zhangsan本來有1條訊息，現在將另一條本來屬於lisi的訊息的所有權轉給它：
127.0.0.1:6379> XCLAIM userInfo mygroup zhangsan 360 1540083266293-0
1) 1) "1540083266293-0"
   2) 1) "username"
      2) "u102107"
      3) "password"
      4) "p102107"
# 現在zhangsan有兩條訊息了
127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 5 BLOCK 0 STREAMS userInfo 0
1) 1) "userInfo"
   2) 1) 1) "1540083260408-0"
         2) 1) "username"
            2) "u102106"
            3) "password"
            4) "p102106"
      2) 1) "1540083266293-0"
         2) 1) "username"
            2) "u102107"
            3) "password"
            4) "p102107"

XINFO

用法：XINFO [CONSUMERS key groupname][GROUPS key] [STREAM key][HELP]
其作用是得到streams和消費者組的一些資訊，使用參考：

127.0.0.1:6379> XINFO CONSUMERS userInfo mygroup 
1) 1) "name"
   2) "lisi"
   3) "pending"
   4) (integer) 0
   5) "idle"
   6) (integer) 201086
2) 1) "name"
   2) "zhangsan"
   3) "pending"
   4) (integer) 2
   5) "idle"
   6) (integer) 701954
127.0.0.1:6379> XINFO STREAM userInfo
 1) "length"
 2) (integer) 22
 3) "radix-tree-keys"
 4) (integer) 1
 5) "radix-tree-nodes"
 6) (integer) 2
 7) "groups"
 8) (integer) 2
 9) "last-generated-id"
10) "1540082298051-0"
11) "first-entry"
12) 1) "1540014082060-0"
    2) 1) "username"
       2) "afei"
       3) "password"
       4) "123456"
13) "last-entry"
14) 1) "1540082298051-0"
    2) 1) "username"
       2) "u102105"
       3) "password"
       4) "p102105"

XTRIM

用法：XTRIM key MAXLEN [~] count
修剪streams到一個確定的size。Trims the stream to (approximately if '~' is passed) a certain size，用法參考：

# streams只保留10條訊息，其返回結果表示被剪去多少條訊息：
127.0.0.1:6379> XTRIM userInfo MAXLEN 10
(integer) 14

說明：streams目前的修剪策略比較簡單，比如連根據ID範圍修剪都沒有實現。根據具體某一個ID刪除，可以通過XDEL實現。

持久化，複製以及訊息安全性

和其他資料型別一樣，streams也會非同步複製到slave，並也會持久化到AOF和RDB檔案中。然而，消費者

相關推薦

深入剖析 Redis5.0 全新資料結構 Streams（訊息佇列的新選擇）

點選上方“芋道原始碼”，選擇“置頂公眾號”技術文章第一時間送達！原始碼精品專欄 來源：阿飛的部落

資料結構---棧（C語言陣列實現）

https://blog.csdn.net/morixinguan/article/details/51374184 資料結構---棧（C語言陣列實現）   棧的全名稱為堆疊，棧其實就是與佇列相反的過程，佇列是先進先出，而棧便是先進後出了，如下圖：  

用js來實現那些資料結構14（樹02-AVL樹）

在使用二叉搜尋樹的時候會出現 一個問題，就是樹的一條分支會有很多層，而其他的分支卻只有幾層，就像下面這樣：　　如果資料量夠大，那麼我們在某條邊上進行增刪改查的操作時，就會消耗大量的時間。我們花費精力去構造一個可以提高效率的結構，反而事與願違。這不是我們想要的。所以，我們需要另

java資料結構——BinarySearchTree（二叉查詢樹）

package com.tig.tree; /** * 二叉查詢樹 * @author Tig * @param <E> * */ public class BinarySearchTree<E extends Comparable<?

算法系列 圖資料結構探索（無向圖搜尋）

演算法是基礎，小藍同學準備些總結一系列演算法分享給大家，這是第10篇《無向圖搜尋》，非常贊！希望

[資料結構].堆（優先佇列）

堆（優先佇列） 堆的定義 一種樹形資料結構，分大根堆，小根堆。 大根堆(max heap)滿足所有父節點不小於其任意子節點。 小根堆(min heap)滿足所有父節點不大於其任意子節點。 在這裡，我們只考慮二叉堆。二叉堆是一棵完全二叉樹。 堆

深入剖析 RabbitMQ —— Spring 框架下實現 AMQP 高階訊息佇列協議

前言 訊息佇列在現今資料量超大，併發量超高的系統中是十分常用的。本文將會對現時最常用到的幾款訊息佇列框架 ActiveMQ、RabbitMQ、Kafka 進行分析對比。詳細介紹 RabbitMQ 在 Sprinig 框架下的結構及實現原理，從Producer 端的事務、回撥函式（ConfirmCa

Streams：深入理解Redis5.0新特性

概述 相較於Redis4.0，Redis5.0增加了很多新的特性，而streams是其中最重要的特性之一。streams是redis 的一種基本資料結構，它是一個新的強大的支援多播的可持久化的訊息佇列，在設計上借鑑了kafaka。streams的資料型別本身非常簡單，有點類似於hash結構，但是它的額外特性異

資料結構——圖（6）——深入分析BFS演算法

DFS的不足和BFS演算法 雖然我們知道根據DFS演算法我們可以找到所有的，由起始節點到目標節點的所有路徑，但並不代表那條路是最短的或者是最佳的。就像我們上篇文章所說的一樣，對於同一幅圖，非遞迴演算法找到的路徑就明顯比遞迴演算法找的要短。 回顧我們之前提到的BFS的基本思想：從起始頂

資料結構——圖（5）——深入分析DFS演算法

對DFS的過程分析 在前面的文章中我們提到了這樣的一幅圖： 我們知道，在DFS中，我們採用的是遞迴的方式進行實現的，並且給每一個遍歷過的點都做上了標記，目的是為了防止程式進入死迴圈。（為什麼樹可以不需要呢？因為樹沒有環） 利用之前專欄提到的遞迴模式，我們可以寫出下面的虛擬碼：

深入理解MySQL索引底層資料結構與演算法

一 理解索引的特性 索引是幫助MySQL高效獲取資料的排好序的資料結構 索引儲存在檔案裡 二 索引的各種儲存結構及其優缺點 在開始講這一小節之前，我們先來看一下在資料庫沒有加索引的情況下，SQL中

深入理解系列之JAVA資料結構（4）——Hashtable

1、Hashtable和HashMap，從儲存結構和實現來講基本上都是相同的， Hashtable繼承自Dictionary類，而HashMap繼承自AbstractMap類，但二者都實現了Map介面。 2、它和HashMap的最大的不同是它是

深入理解系列之JAVA資料結構（2）——LinkedList

1、LinkedList 是一個繼承於AbstractSequentialList的雙向連結串列。它也可以被當作堆疊、佇列或雙端佇列進行操作。 2、LinkedList相對於ArrayList來說，是可以快速新增，刪除元素，ArrayList新增刪除

資料結構排序（一）

插入排序：直接插入排序，希爾排序 直接插入排序： 穩定性：不改變相同關鍵字序列，穩定 ASL： ： 解釋說明： 序 號：0 1 2 3 4 5 6 7 8 監視哨： 34 12 49 28 31 52 51 49* 第一趟： 34 第二趟： 12 34 第三趟： 12 3

字串資料結構實現（連結串列方式）

相較於陣列方式的實現，C語言我採用了單鏈表的方式實現，C++採用了雙鏈表的方式。毫無疑問，雙鏈表的效率肯定是要遠高於單鏈表的。這次支援中文字元的操作，這個實現的思路是，在節點類中新增兩個成員變數，一個用來存放char字元，一個用來存放wchar_t字元。關於兩者的相互轉換及輸出請參考 C語言

資料結構-順序表(java)萌新寫的希望各位大佬提提意見

package bh.shy.list; import bh.shy.listconst.ListConst; public class MyList { // 定義一個數組T private T[] t; private int length; private int list

最後一次資料結構上機（11.7）

第一題單鏈表 1）建立n個元素的單鏈表  void  create（） 2）計算連結串列中大於x的節點個數int countx（int x） 3）建立兩個連結串列，然後取交集 以下原始碼： head.h #pragma once #include<i

資料結構 筆記：程式演算法的選擇

如果兩個演算法都滿足功能性需求，那工程中最關心的其他特性是什麼？如何比較評判呢？ ps：價效比（效率）是工程中最關注的演算法附加特性！ 事後統計法 -比較不同演算法對同一組輸入資料的執行處理時間 -缺陷 ·為了獲得不同演算法的執行時間必須編寫相應程式 ·執行時間嚴重依賴硬體以

Python資料結構之: 棧與佇列

棧(stacks) 是一種只能通過訪問其一端來實現資料儲存與檢索的線性資料結構，具有後進先出(last in first out，LIFO)的特徵 stack = [] stack.append("A") #A入棧 stack.append("B") #B入棧 st

資料結構——圖（2）——圖的儲存和表示方式.md

圖的儲存方式 在實踐中，圖最常見的策略是： 將每個節點的連線儲存在鄰接列表中。 將整個圖形的連線儲存在鄰接矩陣中。 用鄰接連結串列來表示圖之間的關係 在圖中表示連線的最簡單方法是在每個節點的資料結構中儲存與其連線的節點的列表。該結構稱為鄰接列表。 例如