2. 程式人生 > >對Zebra的一點思考(Think of Zebra)

對Zebra的一點思考(Think of Zebra)

阿新 • • 發佈：2018-12-17

此文並不是針對Zebra的應用，甚至不是一個架構的分析，只是對於Zebra的一點兒思考。

Zebra設計得是如此簡潔明快，每一種資料結構均對應於一定的應用。它們之間以一種鬆耦合的方式共存，而多種資料結構組成的功能模組幾乎完美的結合在一起，完成了非常複雜的功能。它的設計思想就在於對C語言面向物件式的應用。

雖然很多程式均借鑑面向物件設計方式，但是Zebra的程式碼風格是易讀的，非常易於理解和學習。與此同時，Zebra使用了豐富的資料結構，比如連結串列、向量、表和佇列等。它的鬆耦合方式使得每一種資料結構封裝的功能模組很容易被精簡、剝離出來，以備我們特殊的應用。這就是我寫下《Think Of Zebra》非常重要的原因！

1 Zebra中的thread

提起thread就會讓人想起執行緒，Linux中的執行緒被稱為pthread，這裡的thread不是pthread，因為它只是對執行緒的應用層模擬。Zebra藉助自己的thread結構，將所有的事件（比如檔案描述符的讀寫事件、定時器事件等）和對應的處理函式封裝起來，並取名為struct thread。然後這些thread又被裝入不同的“執行緒”連結串列，掛載到名為thread_master的結構中。這樣所有的操作只需要面向thead_master。

/* Thread itself. */
struct thread
{
    unsigned char type;
 
   /* thread type */
    struct thread *next;  /* next pointer of the thread */
    struct thread *prev;  /* previous pointer of the thread */
    struct thread_master *master;  /* pointer to the struct thread_master. */
    int (*func) (struct thread *); /* event function */
    void *arg;  /* event argument */
 

    union {
        int val;    /* second argument of the event. */
        int fd;     /* file descriptor in case of read/write. */
        struct timeval sands;   /* rest of time sands value. */
    } u;
    RUSAGE_T ru;    /* Indepth usage info. */
};

/* Linked list of thread. */
struct thread_list
{
    struct thread *head;
    struct thread *tail;
    int count;
};

/* Master of the theads. */
struct thread_master
{
    struct thread_list read;
    struct thread_list write;
    struct thread_list timer;
    struct thread_list event;
    struct thread_list ready;
    struct thread_list unuse;
    fd_set readfd;
    fd_set writefd;
    fd_set exceptfd;
    unsigned long alloc;
};

thread_master執行緒管理者維護了6個“執行緒”佇列：read、write、timer、event、ready和unuse。

  • read佇列對應於描述符的讀事件。
  • write佇列對應於描述符的寫事件。
  • timer通常為定時器事件。
  • event為自定義事件，這些事件需要我們自己在適合的時候觸發，並且這類事件不需要對描述符操作，也不需要延時。
  • ready佇列通常只是在內部使用，比如read、write或event佇列中因事件觸發，就會把該“執行緒”移入ready佇列進行統一處理。
  • unuse是在一個“執行緒”執行完畢後被移入此佇列，並且在需要建立一個新的“執行緒”時，將從該佇列中取出，這樣就避免了再次申請記憶體。只有在取不到的情況下才進行新“執行緒”的記憶體申請。

1.2 執行緒管理者中的“執行緒”連結串列函式

struct thread_list是一個雙向連結串列，對應的操作有：

// 新增thread到指定的連結串列中的尾部
static void thread_list_add (struct thread_list *list, struct thread *thread);

// 新增thread到指定的連結串列中指定的point前部，它在需要對連結串列進行排序的時候很有用
static void thread_list_add_before (struct thread_list *list, 
                                    struct thread *point, 
                                    struct thread *thread);
// 在指定的連結串列中刪除制定的thread
static struct thread *thread_list_delete (struct thread_list *list, struct thread *thread);

// 釋放指定的連結串列list中所有的thread, m 中的alloc減去釋放的“執行緒”個數
static void thread_list_free (struct thread_master *m, struct thread_list *list);

// 移除list中的第一個thread 並返回
static struct thread *thread_trim_head (struct thread_list *list);

1.3 thread中的read佇列

考慮這樣的應用：建立一個socket，並且需要listen該socket，然後讀取資訊，那麼使用read佇列就是不二選擇。下面是一個例子，這個例子將對標準輸入檔案描述符進行處理：

static int do_accept (struct thread *thread)
{
    char buf[1024] = "";
    int len = 0;
        
    len = read(THREAD_FD(thread), buf, 1024);    
    printf("len:%d, %s", len, buf);
    return 0;
}

int main()
{
    struct thread thread;

    // 建立執行緒管理者
    struct thread_master *master = thread_master_create();    

    // 建立讀執行緒，讀執行緒處理的描述符是標準輸入0，處理函式為do_accept
    thread_add_read(master, do_accept, NULL, fileno(stdin));
    
    // 列印當前執行緒管理者中的所有執行緒
    thread_master_debug(master);
    
    // thread_fetch select所有的描述符，一旦偵聽的描述符需要處理就將對應的“執行緒” 的地址通過thread返回
    while(thread_fetch(master, &thread))
    {
        // 執行處理函式
        thread_call(&thread);
        thread_master_debug(master);

        // 這裡為什麼需要再次新增呢？
        thread_add_read(master, do_accept, NULL, fileno(stdin));
        thread_master_debug(master);
    }    
    
    return 0;
}

編譯執行，得到如下的結果：

// 這裡readlist連結串列中加入了一個"執行緒"，其他連結串列為空
-----------
readlist  : count [1] head [0x93241d8] tail [0x93241d8] 
writelist : count [0] head [(nil)] tail [(nil)]
timerlist : count [0] head [(nil)] tail [(nil)]
eventlist : count [0] head [(nil)] tail [(nil)]
unuselist : count [0] head [(nil)] tail [(nil)]
total alloc: [1]
-----------
// 輸入hello，回車
Hello

// thread_call呼叫do_accept進行了操作
len:6, hello

// 發現“執行緒”被移入了unuselist
-----------
readlist  : count [0] head [(nil)] tail [(nil)]
writelist : count [0] head [(nil)] tail [(nil)]
timerlist : count [0] head [(nil)] tail [(nil)]
eventlist : count [0] head [(nil)] tail [(nil)]
unuselist : count [1] head [0x93241d8] tail [0x93241d8]
total alloc: [1]
-----------

//再次呼叫thread_add_read發現unuselist被清空，並且“執行緒”再次加入readlist
-----------
readlist  : count [1] head [0x93241d8] tail [0x93241d8]
writelist : count [0] head [(nil)] tail [(nil)]
timerlist : count [0] head [(nil)] tail [(nil)]
eventlist : count [0] head [(nil)] tail [(nil)]
unuselist : count [0] head [(nil)] tail [(nil)]
total alloc: [1]
-----------

1.4 thread_fetch和thread_process_fd

顧名思義，thread_fetch是用來獲取需要執行的執行緒的，它是整個程式的核心。這裡需要對它進行重點的分析。

/* Fetch next ready thread. */
struct thread * thread_fetch (struct thread_master *m, struct thread *fetch)
{
    int num;
    int ready;
    struct thread *thread;
    fd_set readfd;
    fd_set writefd;
    fd_set exceptfd;
    struct timeval timer_now;
    struct timeval timer_val;
    struct timeval *timer_wait;
    struct timeval timer_nowait;

    timer_nowait.tv_sec = 0;
    timer_nowait.tv_usec = 0;

    while (1)
    {
        /* 最先處理event佇列 */
        if ((thread = thread_trim_head (&m->event)) != NULL)
            return thread_run (m, thread, fetch);

        /* 接著處理timer佇列 */
        gettimeofday (&timer_now, NULL);

        for (thread = m->timer.head; thread; thread = thread->next)
            /* 所有到時間的執行緒均將被處理 */
            if (timeval_cmp (timer_now, thread->u.sands) >= 0)
            {
                thread_list_delete (&m->timer, thread);
                return thread_run (m, thread, fetch);
            }

        /* 處理ready中的執行緒 */
        if ((thread = thread_trim_head (&m->ready)) != NULL)
            return thread_run (m, thread, fetch);

        /* Structure copy.  */
        readfd = m->readfd;
        writefd = m->writefd;
        exceptfd = m->exceptfd;

        /* Calculate select wait timer. */
        timer_wait = thread_timer_wait (m, &timer_val);

        /* 對所有描述符進行listen */
        num = select (FD_SETSIZE, &readfd, &writefd, &exceptfd, timer_wait);
        xprintf("select num:%d\n", num);

        if (num == 0)
            continue;

        if (num < 0)
        {
            if (errno == EINTR)
                continue;

            zlog_warn ("select() error: %s", strerror (errno));
                return NULL;
        }

        /* 處理read中執行緒 */
        ready = thread_process_fd (m, &m->read, &readfd, &m->readfd);

        /* 處理write中執行緒 */
        ready = thread_process_fd (m, &m->write, &writefd, &m->writefd);

        if ((thread = thread_trim_head (&m->ready)) != NULL)
            return thread_run (m, thread, fetch);
    }
}

顯然，Zebra中的thread機制並沒有真正的優先順序，而只是在處理的時候優先處理一些佇列。他們的次序是：event、timer、ready、read和write。後面程式碼分析會得出read和write並沒有明顯的先後，因為它們最終都將被移入ready然後再被依次執行。而select同時收到多個描述符事件的概率是很低的。

thread_process_fd對於read和write執行緒來說是另一個關鍵的函式。

int thread_process_fd (struct thread_master *m, struct thread_list *list,
                       fd_set *fdset, fd_set *mfdset)
{
    struct thread *thread;
    struct thread *next;
    int ready = 0;

    for (thread = list->head; thread; thread = next)
    {
        next = thread->next;

        if (FD_ISSET (THREAD_FD (thread), fdset))
        {
            assert (FD_ISSET (THREAD_FD (thread), mfdset));
            FD_CLR(THREAD_FD (thread), mfdset);
            // 將偵聽到的描述符對應的執行緒移到ready連結串列中
            thread_list_delete (list, thread);
            thread_list_add (&m->ready, thread);
            thread->type = THREAD_READY;
            ready++;
        }
    }
    return ready;
}

thread_process_fd將偵聽到的描述符對應的執行緒移到ready連結串列中，並且進行檔案描述的清除操作，檔案描述符的新增在thread_add_read和thread_add_write中進行。

1.5 thread中的其他連結串列

write連結串列的操作類似於read連結串列，而event連結串列是直接操作的，timer連結串列只是新增對時間的比對操作。

在加入對應的連結串列時，使用不同的新增函式。

struct thread *thread_add_read (struct thread_master *m, int (*func) (struct thread *), void *arg, int fd);
struct thread *thread_add_write (struct thread_master *m, int (*func) (struct thread *), void *arg, int fd);
struct thread *thread_add_event (struct thread_master *m, int (*func) (struct thread *), void *arg, int fd);
struct thread *thread_add_timer (struct thread_master *m, int (*func) (struct thread *), void *arg, int fd);

1.6 thread機制中的其他函式

// 執行thread
void thread_call (struct thread *thread);

// 直接建立並執行，m引數可以為NULL
struct thread *thread_execute (struct thread_master *m,
                               int (*func)(struct thread *),
                               void *arg,
                               int val);

// 取消一個執行緒，thread中的master指標不可為空
void thread_cancel (struct thread *thread);

// 取消所有event連結串列中的引數為arg的執行緒
void thread_cancel_event (struct thread_master *m, void *arg);

// 類似於thread_call，區別是thread_call只是執行，不將其加入unuse連結串列。thread_run執行後會將其加入unuse連結串列。
struct thread *thread_run (struct thread_master *m,
                           struct thread *thread,
                           struct thread *fetch);

// 釋放m及其中的執行緒連結串列
void thread_master_free (struct thread_master *m);

1.7 一些時間相關的函式

static struct timeval timeval_subtract (struct timeval a, struct timeval b);

static int timeval_cmp (struct timeval a, struct timeval b);

當然也提供了簡單的DEBUG函式thread_master_debug。

2 對Zebra中thread的應用

對thread的應用的探討是最重要的，也是最根本的。Zebra的thread機制，模擬了執行緒，便於平臺間的移植，使流水線式的程式編碼模組化，結構化。

執行緒列表間的組合很容易實現狀態機的功能，可以自定義應用層通訊協議。比如我們定義一個sysstat的遠端監控協議。Client請求Server，請求Code可以為SYS_MEM、SYS_RUNTIME、SYS_LOG等資訊獲取動作，也可以是SYS_REBOOT、SYS_SETTIME等動作請求，Server迴應這個SYS_MEM等的結果。通常這很簡單，但是如果我們需要新增一些步驟，比如使用者驗證過程呢？

ClientServerRequest AuthResponse PWD?Provide PWDAuth ResultSYS_LOGSYS_LOG_INFOClientServer

再考慮三次認證錯誤觸發黑名單事件！狀態機就是在處理完上一事件後，新增不同的事件執行緒。

3 對Zebra的思考

Zebra由Kunihiro Ishiguro開發於15年前，Kunihiro Ishiguro離開了Zebra，而後它的名字被改成了Quagga，以至於在因特網上輸入Zebra後，你得到只有斑馬的註釋。Zebra提供了一整套基於TCP/IP網路的路由協議的支援，如RIPv1、RIPv2、RIPng、OSPFv2、OSPFv3、BGP等，然而它的亮點並不在於此，而在於它對程式架構的組織。你可以容易的剝離它，使它成為專用的CLI程式；也可以輕易的提取其中的一類資料結構；也可以借用它的thread機制實現複雜的狀態機。

編碼的價值往往不在於寫了多少，而在於對他們的組織！好的組織體現美好的架構、設計的藝術，可以給人啟迪，並在此基礎上激發出更多的靈感。如果一個初學者想學習程式設計的架構，無疑選擇Zebra是一個明智的選擇，你不僅可以學到各種資料結構，基於C的面向物件設計，還有CLI，以及各種網路路由協議，最重要是的Zebra條理清晰，程式碼緊湊，至少不會讓你焦頭爛額。

如果你不知道程式碼中的xprintf是怎麼一回事，那麼看看另一篇文章《一個通用的debug系統》！

相關推薦

對Zebra的一點思考(Think of Zebra)

此文並不是針對Zebra的應用，甚至不是一個架構的分析，只是對於Zebra的一點兒思考。 Zebra設計得是如此簡潔明快，每一種資料結構均對應於一定的應用。它們之間以一種鬆耦合的方式共存，而多種資料結構組成的功能模組幾乎完美的結合在一起，完成了非常複雜的功能。

對C#調用C++的dll的一點思考

今天 def byte lag har 調用 一段時間 總結 unsigned 　　最近在對接C++程序的時候碰到了一些問題，然後花了一段時間才解決，今天就這些小問題來做一個總結，很多時候由於對另外一種開發語言的不熟悉，會在使用的過程中遇到很多的問題，這些問題看似簡單但是背

對消費主義的陷阱以及脫離人的動物性本能的一點思考

黑洞 給人 手機app 意義 快手 接受 利用 還在 流量 　　今天在圖書館時，偶然想到了一點問題，於是就想趁著這個余熱未盡時，把自己的一點思考及時用文字表達出來，第一次寫，語言難免淺薄，還望見諒。 　　首先，我想講一下消費主義的問題。其實，在很多創業的MOOC中，我常常聽

設計表的時候，對變長字段長度選擇的一點思考

eight CA serve 可能 執行 滿足 ide ont val 不管是在MSSQL還是MySQL或者Oracle，變長字段的長度衡量都是要經常面對的。對於一個變長的字段，在滿足業務的情況下（其實所謂的滿足業務是一個比較模糊的東西），到底是選擇varchar(50)還

對ThreadLocal實現原理的一點思考

前言 在《透徹理解Spring事務設計思想之手寫實現》中，已經向大家揭示了Spring就是利用ThreadLocal來實現一個執行緒中的Connection是同一個，從而保證了事務。本篇部落格將帶大家來深入分析ThreadLocal的實現原理。   ThreadLocal是

對“機器視覺”的一點思考

從小孔成像到凸透鏡成像，原理其實是一樣的，就是光的直線傳輸，從而在視網膜上成像，並通過神經元傳遞到大腦，進行進一步的影象處理與分析。如上圖所示，物理世界是一個巨大的世界，由無數個原子構成，而視網膜是如此的小，如果要1:1呈現在小小的視網膜上是不現實也是根本不可能的，所以人的視網膜精度是有限的，對於遠處的事

對快取擊穿的一點思考

前言 快取（記憶體 or Memcached or Redis.....）在網際網路專案中廣泛應用，本篇部落格將討論下快取擊穿這一個話題，涵蓋快取擊穿的現象、解決的思路、以及通過程式碼抽象方式來處理快取擊穿。   什麼是快取擊穿？

對glPushAttrib和glPopAttrib的一點思考

 先把今天遇到的問題描述下吧，本來有兩個影像圖層，我對第一個圖層設定了裁剪範圍，然後再繪製第二個圖層，此時第二個圖層不顯示，此問題僅出現在NVIDIA顯示卡上，AMD顯示卡正常，讓我鬱悶了好久。  後來通過glPushAttrib和glPopAttrib解決了此問題，在渲染前

設計表的時候，對變長欄位長度選擇的一點思考

設計表時，不管是在MSSQL還是MySQL或者Oracle，變長欄位的長度衡量都是要經常面對的。對於一個變長的欄位，在滿足業務的情況下（其實所謂的滿足業務是一個比較模糊的東西），到底是選擇varchar(50)還是varchar(200)亦或是varchar(500)？對於保守型選擇，往往是選擇一個較大的長度

對分散式儲存和平行計算的一點思考

分散式儲存： 首先是檔案在HDFS上面以128M塊大小儲存（3份），這三塊是在不同節點的（機架感知），我覺的好處是容錯還有當計算是這個節點資源不夠可以去塊所在的另一節點執行，不用拉取資料。 可以通過fs.getfileblocklocation()獲取塊位置 平行計算： 1、MR使用預設的輸

重新開博，對自己的一點思考

前段時間我寫了一篇:《那些我們被百度權重矇蔽的日子裡》，這篇文章的確是純軟文性質的文章。很多朋友指正錯誤，最後seowhy刪除了這篇文章。在網際網路上我第一次感到一種孤獨。但同時也認識到了自己的錯誤，再次感謝那些指正我的錯誤的朋友。讓我能夠重新對自己思考一下！ 百度百科上對軟文

對巨集定義的作用域的一點思考

一、前言     在C語言程式碼或C++程式碼中巨集定義#ifndef……#define……#endif主要是為了避免標頭檔案重複引用，那它是怎麼一個避免機制呢？這就與巨集定義的作用域有關了。 二、巨集定義作用域     首先，C語言標準中巨集定義的作用域是，從定義位置開

對TCP埠和連線數的一點思考

先來看看一些約定俗成的內容。 一個網絡卡對應一個IP地址 一個IP地址對應65535個埠 一個socket(addr, port)可以接受多個socket連線(accept) 一個埠只能被一個socket監聽(listen)

對臨時物件的一點思考

在一個塊作用域或者函式體內的臨時變數(非指標),例如C1 f(){  C1 c;  return c; }此時返回值是個臨時變數,不是c,而是C1(c)構建的一個臨時變數C1& f(){  C1 c;  return c; }此時返回值是一個refernce故非臨時變

對軟體測試教育的一點思考

當你進入任何一個領域學習時，終究會被它的龐大所折服。當你越學越深，則越敬畏。尤其在IT行業，每日如新層出不窮的各種開發測試技巧、分析理論、知識框架的變化擴充、大資料人工智慧等等各種理論與實踐的不斷推陳出新，各種商業或開源工具軟體的花樣翻新。而在這一領域暢遊，則精神必須高度

對Tapestry的一點思考。

Tapestry5已經開發了蠻久了。 聽說最近要釋出T5.0.7了， 會加上Ajax的功能。 我覺得Tapestry5丟掉了Tapestry的一個非常重要的優點和特色， 那就是把jwcid換成了用xml namespac

關於使用原生Javascript的一點思考

jquery script 打開 效應 ani 思維 速度 java 我想 前端很大，大到那些連類都不知道的僅僅上了培訓班的人都會用jquery寫網頁。。。 當一個行業的從業人數出現爆發性增長時，基於規模效應，真正有用的有思想的技術就會出現。。。 這也是我推崇用原生

一點思考

他能 輸出 視野 事情 好奇心 3年 態度 來看 解決 1.很多事，有可能，我們現在看是對的，將來看是錯的，3年很短，但是三十年很長，足夠我們做很多事情，目光長遠一點，視野開闊一點。2.保持一顆好奇心，好奇心，能讓你更細致的觀察，感受這個世界，發現問題、缺陷、美。3.世界上

關於ugc的一點思考

創作 微博 ugc 一個 一點 nbsp 多人 關於 更多 ugc會使互聯網繁榮，但依賴大眾用戶創造的內容質量上會存在參差不齊，這是ugc本身存在的問題。 就拿技術論壇或社區來說，好的內容不少，但質量不好的內容也很多。社區在引導用戶發言的同時，也應

個性化推薦系統（三）---推薦系統意義一點思考

進展 這樣的 es2017 意見 推廣 移動 付出 技術 com 個性化推薦是隨著移動互聯網發展不斷發展起來的，國內應用個性化推薦技術最早應該是豆瓣，在web2.0興起時做了很多嘗試，給網民帶來很多新鮮感覺、體驗。後來是國外電影租賃網站netflex推波助瀾