Tag Archives: Network

無停機服務遷移

一直以來在營運now.in都有一個令人困擾的問題,就是每當伺服器更新或是出現問題時,就得關掉重開,雖然說大部份的伺服器我在設計上都做成重開也沒有關係,但有少部份一但重啟就會造成使用者斷線,參考下面這張伺服器狀態的圖 圖中被切斷的山峰都是伺服器重啟的時候,無疑的這對使用者來說是不好的體驗,對於一般網頁HTTP這類stateless的伺服器來說重啟是無所謂,但串流伺服器就不一樣,因此最近我在思考如何解決這樣的問題,首先想到的是伺服器重開的原因,不外乎有幾種 部署新版的程式 為了修正BUG 記憶體用量過高 重新讀取執行環境,例如ulimit -n,也就是檔案數量的限制大小 從主機A移到主機B 以Python的伺服器來說,如果只是單單只是為了部署新版的程式,Python有個reload函數可以重讀整個module,因此可以設個管理用的後門用來重載模組,但是這樣做有個問題,就是已經產生的instance還是一樣,其實說穿了等於是重新執行那個module,如果只是簡單的改版還好,但複雜的改版就可能牽扯到太多因素難以透過這樣來更新,而除此之外,很多重開的因素像是記憶體用量過高,或著執行的環境參數改變,這些都無可避免的一定得建新的process,至於從A主機移到B主機,基本上是難以避免的一定得重啟伺服器,除非有某個前端的伺服器保持連線,後端的伺服器進行交移工作才有可能,而主機轉移的狀況其實很少出現,因此這篇文章要探討的是如何辦到同一臺機器內的服務轉移 方法 最大的問題就在於,連線中的socket該如保持住連線,最簡單的想法就是建立新的process,將目前的連線交給新的process,新的process接手完所有的連線開始運作後舊的process就能終止了,當然所謂的連線還包函了服務的狀態,我們在者裡稱之為 CSD (Connection State Descriptor),大致想法如下面圖片所示 首先Process A是正在運行的process,而Manager是負責控制遷移的process 此時Manager啟動了要負責接手的Process B 接著Manager通知A將連線狀態傳送給Process B,B接手後繼續提供服務,並且告知接收完成 在確定B能夠接手服務並且正確執行後,這時Manager就能將A中止,走到這裡服務就算是完整地移交了,中間沒有任何間斷 技術層面問題 – Socket的轉移 這樣的做法理論上看起來確實可行沒錯,但是最主要有技術上的問題得解決,就是如何將socket,或著是file descriptor轉移到另一個process,在我找過相關的資料後知道目前有兩個方法 child process 這個方法主要是因為child process在生成後會繼承parent process的file descriptor,但是缺點就是只限於child process,如果我們想將服務移交給另一個完整的獨立process這個方法就會行不通,因此使用上會有很多限制 sendmsg 另一個方法就是unix domain的socket有提供一個函數叫sendmsg,可以將file descriptor轉移到任何process,這樣一來實用性就比child process高很多,於是我決定採用此方法 簡易的實作 … Continue reading

Posted in Python, 中文文章, 分享 | Tagged , , , , , , , | 7 Comments

淺談coroutine與gevent

這篇文章是要大略介紹一下coroutine和Python的相關應用的函式庫gevent,在介紹coroutine前我們先來點情境,因為目前常見的coroutine應用都是在網路程式上,因此我們得先建立一些網路框架的模形再介紹coroutine會比較容易懂 不同的網路框架模型 網路隨著時代發展,已經成為現代生活中越來越重要的重要的基礎,而做為提供這些服務的伺服器,負載的連線也越來越多,因此網路程式的軟體、硬體架構也一直在演變,才有辦法承載越來越多的連線數量,有人希望在一台機器能夠同時處理1萬個連線以上,所以提出C10K問題,並且之後有不少新的的技術來達成這個目標,而在此我們只專注在於軟體的架構上,首先介紹最簡單的架構 阻塞式單一行程 這樣的網路程式非常的簡單,只有一個迴圈,單一個行程,處理完一個要求後才繼續處理下一個,理所當然這樣的效能非常差,因為連線在完成前其它的連線都無法被處理,現代的伺服器已經很少看見這樣的架構,但因為優點是簡單,如果沒有什麼大量同時連線要處理,其實這樣的架構就很足夠 阻塞式多行程 因為既然單一行程只能同時處理一個請求,那很簡單的想法就是每個請求開一個行程去處理,如此一來就能同時處理更多的請求,但是這樣做有缺點,行程的copy如果是fork的話,有os paging system在成本上其實還好,但是還是有,而且越多的連線就表示需要越多的context-switch,當連線量多到一定程度時,可能大部份的CPU時間都在忙著進行context-switch,如此一來這樣的架構在此情況下是沒有效率的,但是優點是寫伺服器的部份事實上和寫單一行程阻塞式不會差太多,一樣簡單好寫 阻塞式多行程多執行緒 除了多行程多阻塞式,有些程式為了減少process copy的成本,或是其它的考量,會在多個行程上開多個執行緒來處理請求,也有可能是單行程多執行緒,但是基本上和上面這幾種都沒有太大的差別,而引進了執行緒帶來了一些額外的問題,dead lock、race condition等等,當不同的執行緒如果在一起有共同的東西要處理,這些常見的同作問題就會出現,使得程式得寫得更小心 非阻塞式事件驅動 為了解決上面提到多行程和多執行緒等所帶來的問題,有一種做法是只有單一主要的迴圈來檢查有無網路IO的事件發生,再來決定要怎樣處理,這樣的好處在於省掉了context-switch、process copy等等成本,也不會有dead lock、race condition等問題,但缺點在於程式的部份會變複雜,因為當你一件事件被觸發,有事情還沒做完,你就得記下目前狀態,再下次事件觸發時再依先前的狀態來決定接下來要做什麼,不像上面是線性的程式執行那樣直觀,Twisted就是這樣的網路框架 非阻塞式Coroutine 那你或許會想,有沒有可能我們能有事件驅動的好處,和阻塞式那樣的直觀好處呢? 答案或許就是Coroutine,基本上它的本質也是事件驅動,只有單一的迴圈在檢查事件的發生,但是加上了coroutine的概念,而Gevent就是這樣的函式庫 Coroutine 講了這麼多次coroutine,我相信大部份的讀者可能還是不懂這到底是什麼鬼東西,對於大部份程式設計師而言這應該都算是較陌生的名字,對我而言,在一開始這也是個令人困惑的名詞,但事實上只要理解以後就會發現coroutine不是這麼的難懂,用簡單的一句話來說Coroutine,就是可以暫時中斷,之後再繼續執行的程序,我們來看一個例子,事實上Python就有最基礎的Coroutine,也就是generator # -*- coding: utf8 -*- def foo(): for i in range(10): # 丟資料並且把主控權交給呼叫者 yield i print … Continue reading

Posted in Python, 中文文章 | Tagged , , , | 19 Comments