51CTO專家門診第196期 服務器并行開發基礎
在服務器集群開發、大型工程程序開發中,我們越來越多地碰到多線程、多任務模型的開發。這已經成為現代程序設計的一個重要特征。這其實已經是并行開發了,涉及到方方面面的知識儲備,如內存控制、IO控制、鎖的控制等,甚至包括全新的程序世界觀。 (專家門診鏈接:http://doctor.51cto.com/develop-210.html)
本期門診邀請分布式數據庫研發、數據傳輸工程師、無錯化程序設計專家肖舸先生,針對服務器并行開發基礎技術展開討論。歡迎網友積極提問,與專家一起交流學習!
Q:肖專家您好:
對于現在中小型企業,有沒有必要實施服務器群集?對于服務器上的網站數據備份和數據庫的備份,有沒有很好解決方案,另外O-bug是一項技術么?數據庫的開發和應用,就現在的技術而言,能不能完全解決企業的問題?
A:肖舸
這位朋友,你好:
我覺得你的問題有點見仁見智,現在是大規模數據時代,我們目前一個應用需要處理的數據規模,可能在10年,甚至5年前,想都不敢想的,因此,我認為即便是中小型企業,為了處理日益增長的數據使用需求,應該考慮使用服務器集群技術,另外,很可能在不久的將來,可能使用的是云技術,這個我個人理解,是服務器集群基于應用細分后,更高一層的抽象。
畢竟,即便是再小的企業,只要它不斷成長,成為百年老店也是有可能的,那,一百年的數據積累下來,你猜猜會怎么樣?呵呵。
數據庫備份我做得比較少,不好提太多意見,如果是程序員,我會建議他從并行角度,在后臺直接實現緩步備份技術,但一般應用型企業的網管,我的建議是可以考慮采購商用備份軟件。
0bug是我寫的一本書的名字,其實也是我作為程序員的一個夢想,很多年以前,我受困于bug,就想,以后如果寫出程序來就沒有bug,該多好啊。呵呵,這么多年一直努力,但是,可惜現在我也沒能寫出一個真正0bug的程序。
但是,我想作為程序員,有這個追求是最重要的。你說呢?
我書里面主要探討了很多無錯化程序設計的方法和原則,特別是近年來很多,但是程序員學習比較少的多線程、多任務、并行環境下,在增加了鎖的干擾之后,如何實現0bug的程序設計辦法,有興趣可以看看。
數據庫的開發和應用,我的理解是一門應用科學,需要結合具體應用場景、業務來考量,我認為這是一個永遠有發展前途的工作,我本人目前也在進行工業用實時數據庫的開發工作。
我認為,IT行業走到今天,已經不能僅僅是炒概念了,而是要為社會實實在在做點貢獻了,而最突出的貢獻無非兩個,一個是軟硬結合,提供全方位的完美用戶體驗,比如ipad,還有就是切實針對用戶實際數據需求的數據庫技術。
起碼到目前為止,我認為各個企業的數據庫需求,其實都有解決方案,無非是成本高低而已。我認為程序員以后的發展方向,更多的是在熟練掌握各項基本技能的基礎上,在掌握無錯化開發技巧上,以更低的成本,為用戶提供更高效的數據服務。
嗯,一家之言哈,僅供參考。
Q:舸哥,你好!
我現在一家大型企業從事網絡管理工作,對于服務器集群及負載均衡技術類的硬件產品你覺得使用哪個廠家的比較好呢;
A:肖舸
目前這方面其實可選擇余地并不多。因為真正的負載均衡,除非量身定制的開發,其實都差不多。
不過,如果是大型集群,我建議可以與IBM合作。
Q:老師您好:
如果是中小型事業集群,WindowsServer系列的DataCenter版,也不錯。
嗯,其實這么說我心里也沒底,我建議,具體問題具體分析,你可以email我你們具體的應用數據需求,我試試看,能不能給點具體的建議。
不好意思啊。
如果我要做一個操作,需要通過查詢得到數據結果,可是如果數據量大的話每次查詢勢必會耗費性能,怎么做才能既只要消耗小部分性能又能得到數據呢?
A: 肖舸
其實我們目前面臨的很多應用,都屬于數據中心型(Data Center),只要是數據中心,就免不了增改刪查四個基本動作。
所以數據查詢是永恒存在的。
而且,我發現近年來很多趨勢和過去不一樣了。
過去,IT業主要解決“有無”問題,即數據的有和沒有這個問題,因此,我們花了大量的功夫,來做數據的采集和存儲,包括工業現場的各種DCS系統等等。
但是,現在用戶口味“刁了”:“你能采集,能存儲,嗯,我承認你有這個本事,但是,這些采集和存儲的數據,對我有什么意義?怎么才能真正幫助我的工作和生活?你回答我?”
這是現在的用戶環境。
因此,我覺得現在IT業面臨的一個重大轉型,就是如何從數據的采集、存儲這類“計算機”界擅長的東東,轉為真正針對細分市場,針對用戶個性化需求的數據的“用”的技術。我想,這大概是今后幾十年,我們IT業面臨的一個巨大的問題。
能應對的,會笑到最后。
而這個問題,不可避免的,就是你說的“查詢”技術。
這包括很多,海量數據的挖掘、高效的數據分析。還得結合具體軟硬件環境構建的用戶使用環境,等等。
目前我做的工作,可以說就是在前期高效存儲的基礎上,研究如何更好提升查詢效率的辦法。
我的解決方案是從開發階段就做優化,比喻一些數據預處理技術,一些存儲優化技術,比如采用B+樹模型存儲,數據取模,多級定位等技術。嗯,還有就是Cache技術。
方法有很多啦,無一定之規,這個要針對具體需求來。
因此,對于你的問題,我唯一的建議就是基于“順序遍歷、平衡二叉樹管理、哈希型管理”這個順序來,逐一在符合成本需求的前提下,盡可能好地解決問題。
Q:舸哥
您好!我是企業的系統管理員,現在企業慢慢在擴大,有可能要實施服務器集群,我想問下具體應該注意哪些事項,感覺現在壓力很大!!!
A: 肖舸
你也說了企業慢慢在擴大,那說明這個服務器集群化,應該是一個循序漸進的過程,我覺得此時從心理上,還是不要焦急。
不過呢,既然有這個壓力,我認為針對這些東東,現在開始學習,做一些知識預儲備比較好。
你已經是網管員,基礎知識應該已經有了,下面就是針對應用需求開始做針對性的準備。
我建議你這段時間,可以多接觸一些大公司,比如hp、IBM、cisco、華為的技術人員和銷售人員,把自己的需求提出來,請教他們,并作為潛在的客戶和他們溝通,我想,在他們給你的方案建議和技術白皮書里面,你應該能學到很多東東。
還有就是多看一些書籍,多到網站提問哈,請大家幫忙解答。
我認為所有問題,都是可以細分拆解的,你的問題也類似,其實,這個拆解過程本身,就體現你的一個網絡拓撲設計能力。
因此,我建議你從現在開始,對企業未來3~5年的IT應用需求開始著手分析,要有一定前瞻性,然后還可以寫一些相關文檔,做一些方案建議,請你的主管點評,并且為主管申請預算留出足夠的時間,如何?
當把問題拆細了,比如公司有幾個分支機構,分支機構之間保密數據通信方案,VoIP語音方案甚至IP視頻會議方案等,企業總部的安全性問題,防火墻的設計,企業總的帶寬流量需求和管控,各個分支機構的管控等等,我覺得不難的。
另外,這里也說明一點,我是程序員,不是專業的網管人員,這方面的問題,我能提點建議,但是不是很專業,很多網管類的話題,還請咨詢更加專業的人士哈。
嗯,我說的分布式數據庫研發,可能和大家想的也不太一樣,別人可能是利用現成的數據庫,組建分布式服務器集群,來處理海量數據,屬于數據應用類開發。
我這邊稍稍有點不同,我是在研發一種能高效處理的海量數據的數據庫產品,這個產品是賣給別人后,別人在我的數據庫基礎上做上述事情的,嗯,可能我的更底層一點哈,希望大家不要誤會了。
Q:老師您好:
對于企業來說,什么樣的服務才需要的群集?
那么群集自然會提高服務的高可用性,怎么樣才能有效的管理呢?
A: 肖舸
這個問題很難講,因為服務種類太多了,需要細分,逐一分析來判定。
講點原則吧。
需要高安全性,高吞吐量,高穩定性的服務,大概需要集群服務。
這個看數據規模,以及用戶對數據安全性的敏感程度。這個安全性一個是數據被訪問的安全性,也有數據保存的安全性。
使用群集,只能說有可能提高可用性,但是還是要看設計,因此,群集服務可以說是研發者和使用者共同來完成的一項工作,僅僅有錢購買產品是不夠的,需要管理員仔細分析本企業的用戶需求,設計合適的方案,選擇合適的產品,來搭配合理的集群。
我想,這個群集服務,是最能體現網管員的技術實力的。
至于管理,很多群集軟件產品,都帶有自己的管理器,但是,往往不合用,因此,群集前端,一般需要企業定制,或者自主研發一套合適的UI,比如自己的ERP系統等,才能更好地利用數據。
Q:老師您好:
我是一名學校網管,我校教師用機基本上超過300臺,現在,服務器也有6臺,有學校的資源庫、web、教學ftp和視頻點播、直播服務器,請問如何維護才能保證數據不會因為服務器的損壞而丟失,謝謝您能回答我的問題!
A: 肖舸
感覺服務器少了。基本上每種應用一臺服務器,這肯定是有問題的。
建議先考慮鏡像,即再增加6臺服務器,與現有服務器做鏡像拷貝,一起服務,一來避免數據丟失,二來也分擔壓力。
對于高安全性數據,建議后臺再單獨建立一臺備份服務器,專門備份這部分數據。
Q:老師您好:
我是大一新生學軟件的,現在對學些什么感覺很迷漫,希望您能給點意見
A: 肖舸
呵呵,這類問題我博文中很多,你看看我博客吧。http://tonyxiaohome.blog.51cto.com/
總的來說,我建議剛上大學的學生,不要太早接觸語言,不要太早接觸商業化的設計模式、類庫之類的東東。
建議先從基礎學期,特別是數學、算法、數據結構,把這些基礎打牢了,后面學起來后勁足。
要是剛上大學,不學專業課,專門跑去學編程,也能學出來,不過,沒有基礎,在程序員道路上走不遠的。
下期專家門診預告:
①預告:下期門診將邀請中國綜合布線光纖及光纖測試領域的權威專家團隊,針對光纖布線系統的設計與測試等要點、難點問題給予解答,屆時歡迎網友積極提問,與專家一起討論!
②鏈接:http://doctor.51cto.com/develop-211.html