服務(wù)器
摘要: 對(duì)于服務(wù)器程序而言，尤其是云計(jì)算時(shí)代的服務(wù)器程序，三高標(biāo)準(zhǔn)(高可用、高性能、高擴(kuò)展)往往是衡量一個(gè)優(yōu)秀的服務(wù)器程序的重要指標(biāo)。本篇文章主要聊聊服務(wù)宕機(jī)恢復(fù)(高可用的重要內(nèi)容)、負(fù)載均衡(高擴(kuò)展、高可用的主要內(nèi)容)。以下內(nèi)容均屬個(gè)人工作中的見(jiàn)解，如有不妥之處，歡迎指正。 ----peakflys
閱讀全文
摘要: 項(xiàng)目終于上線了，伴隨著人數(shù)的逐步上升，最近查看日志，發(fā)現(xiàn)了大量連接超時(shí)的日志。項(xiàng)目中使用的是TCP長(zhǎng)連接，為了保證網(wǎng)絡(luò)資源及時(shí)有效的釋放，程序中是1分鐘一次心跳，3分鐘無(wú)心跳即認(rèn)為超時(shí)。此為本文的背景
相對(duì)于TCP連接建立時(shí)的三次握手，我想很多人對(duì)斷開(kāi)連接的四次招呼就不是那么熟了，這里先談一下TCP的斷開(kāi)，下面給出TCP斷開(kāi)連接的過(guò)程圖：
閱讀全文
摘要: 前段時(shí)間研究分布式時(shí)寫(xiě)了一個(gè)可擴(kuò)展的服務(wù)器組程序，服務(wù)器組之間通信時(shí)老是達(dá)不到想要的性能。后來(lái)抓包排查，原來(lái)是TCP滑動(dòng)窗口引起的問(wèn)題，本來(lái)是很基礎(chǔ)的東西，奈何當(dāng)初沒(méi)有太在意，導(dǎo)致錯(cuò)誤的產(chǎn)生，現(xiàn)在詳細(xì)寫(xiě)出來(lái)，忘不太清楚者警惕！
閱讀全文
摘要: 前段時(shí)間在寫(xiě)《段錯(cuò)誤造成的常見(jiàn)詭異宕機(jī)情況總結(jié)(中)》時(shí)，分析到 程序中數(shù)據(jù)寫(xiě)超時(shí)有可能寫(xiě)到this指針?biāo)诘牡刂防锩妫瑢?dǎo)致最終詭異的宕機(jī)。其實(shí)網(wǎng)絡(luò)攻防里常用的緩沖區(qū)溢出攻擊也是這個(gè)道理，除了使用戶(hù)程序甚至計(jì)算機(jī)掛掉外，還有可能執(zhí)行攻擊者想執(zhí)行的任何程序，這篇文章主要詳細(xì)剖析一下第二種攻擊的方法以及現(xiàn)在Linux(包括各種修改版本，例如Android)、Windows下常使用的防范措施。
閱讀全文
摘要: 國(guó)慶長(zhǎng)假終于結(jié)束了，從擁堵的噩夢(mèng)中醒來(lái)，該收收心重新回到工作中來(lái)了（順便吐槽一下鬧心的長(zhǎng)假，平時(shí)工作沒(méi)時(shí)間出去，放了長(zhǎng)假了 又不敢出去，路上耗費(fèi)大量的時(shí)間和金錢(qián)也算了，弄的整個(gè)人也身心疲憊的……）
言歸正傳，接著上回宕機(jī)情況說(shuō)。之前比較難找的宕機(jī)錯(cuò)誤已經(jīng)在前兩篇隨筆里說(shuō)過(guò)了，這次要說(shuō)的是前不久一個(gè)同事遇到的。他要做一個(gè)錄像功能，每次把客戶(hù)端的消息轉(zhuǎn)儲(chǔ)成文件時(shí)掛掉。大致代碼如下：
閱讀全文
摘要: 上面一種情況是自己內(nèi)存寫(xiě)超了，寫(xiě)到了用戶(hù)態(tài)別的結(jié)構(gòu)所在的內(nèi)存，特點(diǎn)就是core文件顯示 別處對(duì)象的內(nèi)容亂七八糟，且一般是在對(duì)象析構(gòu)時(shí)發(fā)生，這次講解一下，自己把自己寫(xiě)壞的情況。
閱讀全文
摘要: 因?yàn)閮?nèi)存問(wèn)題，程序崩潰對(duì)于每一個(gè)c++程序員而言是很常見(jiàn)的問(wèn)題，而段錯(cuò)誤引起的宕機(jī)，恐怕是平時(shí)遇到的最多的情況，除了常見(jiàn)的指針未判空和野指針問(wèn)題外，還有不少是比較頭疼的情況，空指針因?yàn)槎ㄎ缓苤苯臃奖悖@里就不說(shuō)了，野指針因?yàn)樗漠悤r(shí)異地特性，很難排查，這個(gè)以后我會(huì)詳細(xì)說(shuō)一下的，這里僅僅介紹一下其他也比較頭疼的段錯(cuò)誤宕機(jī)情況，這是之前自己總結(jié)的筆記，前段時(shí)間又看到了，感覺(jué)對(duì)很多人 應(yīng)該是有用的，于是總結(jié)出來(lái)供大家參考。
閱讀全文
摘要: 前幾天回答一個(gè)問(wèn)題，是關(guān)于我們項(xiàng)目中使用的epoll模式的，因?yàn)橛洸淮笄辶耍杏X(jué)應(yīng)該使用的就是epoll的高速模式，也就是ET(edge-trigger)模式。這兩天閑暇的時(shí)候，打開(kāi)代碼又看了一下，在epoll事件注冊(cè)時(shí)并未標(biāo)記ET模式，看來(lái)實(shí)際使用的是epoll默認(rèn)的LT(level-trigger )模式，為什么呢？使用LT意味著 只要 fd 處于 readable/writable 狀態(tài)，每次 epoll_wait 時(shí)都會(huì)返回該 fd，系統(tǒng)開(kāi)銷(xiāo)不說(shuō)，自己處理時(shí)每次都要把這些fd輪詢(xún)一遍，如果fd很多的話(huà)，不管這些fd有沒(méi)有事件發(fā)生，epoll_wait 都會(huì)觸發(fā)這些fd的輪詢(xún)判斷。
閱讀全文
摘要: 最近挺忙的，也沒(méi)時(shí)間寫(xiě)點(diǎn)東西，一直在忙下一個(gè)資料片的事情，前幾天在群里見(jiàn)有人問(wèn)關(guān)于大小端的事情，這里說(shuō)一下。
對(duì)于跨平臺(tái)的程序或者所用數(shù)據(jù)牽扯到不同平臺(tái)的程序(例如網(wǎng)絡(luò)編程)，大小端字節(jié)序是個(gè)值得考慮的事情。本文主要討論一下網(wǎng)絡(luò)編程方面的大小端問(wèn)題。(by peakflys)
閱讀全文