原创 disuz 7.2文字常量定義文件messages.lang.php

當需要對disuz做一些修改時,可能會涉及到這個文件。   D:\hadoop\backup\20120619221410\templates\default\messages.lang.php   <?php   // Message P

原创 MOOON-agent系統設計與使用說明

MOOON-agent系統設計與使用說明 易劍 2012/6/16   目錄 1. 設計目標 1 2. 應用場景 2 3. 主要功能 2 4. 系統骨架 3 5. 資源接口 3 6. 內置CommandProcessor 3 7. 編程接口

原创 MOOON-scheduler核心設計圖(初稿)

按以下思路進行設計,非最終設計圖,有等進一步思考,以發現問題,需要達到以下目的: 同時支持線程和進程模式(做了抽象) Service不和線程綁定 Service獨佔線程池或進程(進程下再劃分線程池) Session和線程綁定,不跨線程

原创 使用valgrind檢查cache命中率,提高程序性能

原文地址:使用valgrind檢查cache命中率,提高程序性能 作者:GFree_Wind     作者:[email protected] 博客:blog.focus-linux.net   linuxfocus.blo

原创 爲何有着良好設計的系統代碼反而不容易看懂?

在實踐中遇到一個問題,就是經過良好設計而實現的代碼,大家會覺得不容易看懂,而平鋪直述的反而易看。   我分析這是一個很正常的現象,原因是未設計而出的代碼是按人的正常思維平鋪直述的,所以大家容易看,這些代碼常有些共性:即冗長、重複的現象常

原创 簡單的主備切換方案

 主備切換是很多高可用性系統都必須解決的問題,方法有很多,象基於ZooKeeper的主備切換就是一個很好的選擇。   在這裏提供一種更簡單但不完美的主備切換方法: 1) 假設A和B是集羣中的主控(Master)節點 2) 1~7是工作節點(

原创 養成良好的編程習慣

  良好的編程有習慣的意義在於: 1.猶如面子,給人好的好象 2.猶如在找東西,容易找到 3.不給人添麻煩,讓人接手得舒舒服服 4.從源頭避免版本不一致問題(當同一個文件在不同目錄下出現拷貝時,容易出現其中某個未同步更新的問題) 5.提升

原创 設計mooon調度器遇到的難題

mooon的設計進入關鍵時刻,有幾個決策點還沒有定下來,如下: 1.是否同時支持進程和線程模型 進程模型是指內核爲一個獨立的進程,而每個業務又爲獨立的一個進程,業務可以爲多線程,同時內核會產生相應個數的內核線程與業務線程一一對應,內核線

原创 什麼樣的命名纔是合理的?談命名的原則

寫代碼,少不了各種命名,那如何纔是最合理的命名,或者沒有好壞之分了?如果有了理論基礎,這事就好辦。   mooon中的命名採用的理論依據: 1.簡單性,拒絕畫蛇添足,如類成員變量僅以“_”打頭,前面的字母“m”純是多餘的 2.易讀性,

原创 undefined reference to `clock_gettime'

  下面這個錯誤通常是因爲鏈接選項裏漏了-lrt,但有時發現即使加了-lrt仍出現這個問題,使用nm命令一直,會發現-lrt最終指向的文件沒有包含任何symbol,這個時候,可以找相應的靜態庫版本librt.a,看看它裏面是否存在`clo

原创 優雅的讓一個類在線程安全和線程非安全間切換

一個良好的多線程庫,不應當一刀切的全加鎖。因爲有些時候,雖然是多線程環境,但可能依照設計一個類只會被一個線程操作,這個時候加鎖是多餘的,純浪費性能,但另一些場景又需要它是線程安全的。   假設有一個類X: class X { public:

原创 全局變量相互依賴和初始化順序的解決辦法

  如果是定義一個全局的map,會出現如下core:   Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b449ea in std::_Rb_tree

原创 軟件技術發展的幾個階段

軟件技術經歷也如下幾個發展階段: 1.純屬科學家的玩意 2.個人英雄者的世界,比如我們常說的第一代程序員 3.純軟件公司,產生了大批純軟件公司,而且活得很好,如當年的四大軟件園 4.軟硬結合,純軟件的死了大半,象華爲軟硬結合活得很好 5.

原创 名詞:topology、architecture和struct,究竟什麼纔是架構?

在技術文檔中,發現很多時候並沒有對topology、architecture和struct進行嚴格區分,有時可以見到一個topology成了architechure,有時一個struct成了architechure。   從嚴謹的角度出發,

原创 怎麼做自動化

 在做系統時,不應當盲目地去做自動化,原因有兩點: 1.有些自動化的代價非常高,反不如人工簡單實在 2.有些自動化不能保證系統的正確性,它需要人工確認   不過,這些也並不應當成爲推進自動化的理由,自動化它可以帶來兩方面巨大的好處: 1.大