分布式帶來編程復雜度

㈠ 如何破解4G時代室內用戶體驗難題

1室內覆蓋：運營商面臨的最大挑戰

對於移動通信網路而言，信號的室內覆蓋水平一直是市場競爭力高低的重要體現。2G時代，電梯里那些「信號已覆蓋」的標志很好地說明了這一點。到了3G和4G時代，室內覆蓋則變得更加重要，更加具有戰略意義，在某種程度上甚至可以說，室內覆蓋的好壞決定著4G的成敗。

4G時代是數據的時代，而數據業務更多地發生在室內。研究表明，80%～90%的移動數據業務是在室內發生的，尤其是學校、商場、辦公大樓、會議中心等公共場所。這些高業務區域的信號覆蓋對於運營商而言就是收入的來源，如果不能在這些區域提供良好的網路覆蓋，無法有效地吸收業務，滿足需求，其網路投資必然會受到損害。

4G時代也是體驗的時代，全球運營商都開始高度重視用戶的體驗。2013年，在華為用戶大會上，來自全球103個電信運營商和相關組織的300位嘉賓中，有43%的嘉賓認為未來兩年移動寬頻的最重要問題是「用戶體驗」。更有78.9%的嘉賓認為「業務體驗」是用戶最重要的體驗。要保證用戶體驗質量，作為高話務區的室內覆蓋便不可忽視。另有調研顯示，70%的用戶投訴也發生在室內，因此，為保證用戶獲得更好的體驗，運營商必須提供質量更高的室內連續深度覆蓋，杜絕有信號而無法上網的現象發生。

然而，移動寬頻的深度覆蓋卻是當前網路建設最大的難題之一。

第一，由外而內的覆蓋方式難以為繼。作為傳統的室內覆蓋方式之一，通過室外基站將信號直接「打入」室內的解決方案在4G時代已經難以奏效。一方面是因為當4G使用高頻段時，信號穿透能力差，損耗嚴重，如果利用室外宏站解決室內的接入問題，將大大增加宏站的數量，不僅大幅增加建網成本，且站址獲得困難。有實驗表明，宏站如果要向室內滲透兩米以上，宏基站數量則要相應增加60%以上才能實現。另一方面，基於高階調制的數據業務對信號的強度和信噪比提出了更高的要求，依靠室外宏站難以保證用戶獲得良好體驗。

第二，傳統室內覆蓋解決方案已經力不從心。為了解決移動網路的室內覆蓋問題，特別是大型公共場所的室內覆蓋問題，傳統的解決方案是採用分布式天線系統（DAS），這種解決方案將網路信號通過信號電纜引入室內，並分配至不同區域，實現網路的深度覆蓋。但這一解決方案除了具有網路結構復雜、施工煩瑣、無法平滑升級支持LTE多天線技術等種種不足外，難以滿足4G網路的容量需求成為其難以克服的短板。

在移動寬頻時代，隨著移動終端設備種類的增多、屏幕的增大以及解析度的提高，其所需的帶寬也在不斷增加。2004年，移動終端屏幕解析度只有416×234，帶寬只需200kbps以下，到2014年，移動終端解析度已經達到1920×1080的高清標准，所需帶寬也上升至8Mbps，這大大促進了移動帶寬需求的增加，因此，在人員密集的室內熱點區域，DAS系統已經完全無法滿足用戶容量的需求，這也是造成「雖有網路覆蓋卻無法上網」現象的重要原因。

第三，簡單引入小基站並不能解決問題。小基站（Small Cell）作為一種基站形態在2G和3G時代主要發揮「補盲」和「補熱」等輔助作用，尚未在室內覆蓋中大規模使用，調查顯示，目前運營商部署的室內小基站數量在基站總量中所佔的比例尚不到10%.4G時代，小基站因部署靈活等優勢日益被看好，已經被認為是一種技術趨勢，有機構預測，今年全球小基站規模會爆發，局部地區將遠遠高於傳統宏站。但是，目前不同形態的小基站產品並不適合簡單地大規模用於室內深度覆蓋，簡單引入將帶來包括網路協調以及基站管理等一系列問題。要解決4G深度覆蓋問題，運營商期待的是一種可以做到大容量、大覆蓋、易管理、短施工的小基站解決方案。

2 MBB時代，獨一無二的室內小基站解決方案

LampSite競爭力對比

2013年2月27日，在西班牙巴塞羅那舉行的世界移動通信大會上，華為發布了一款全新的室內覆蓋解決方案——LampSite.這是一款獨一無二的小基站解決方案，具備高效部署、大容量、多頻多模和運維可視化等特點，其目標就是幫助運營商以最快、最有效的方式解決室內深度覆蓋問題，因此，受到全球的廣泛關注。

LampSite解決方案主要由PicoRRU（pRRU）、RemoteHUB（RHUB）以及BBU三個網元組成。其中，pRRU支持多頻多模，可同時承載LTE TDD/LTE FDD/UMTS等多個制式，集成Wi-Fi，外觀小巧，安裝便捷，配合華為SingleRAN解決方案，可部署多制式的室內網路。BBU則具有基帶資源共享功能，通過一根光纖與RHUB相連就能承載多個小區。pRRU通過網線與RHUB連接，即可實現為pRRU供電和數據傳輸功能，可有效降低施工難度和部署成本。

由於多種新技術的採用，LampSite具有了普通小基站產品所沒有的許多新特性和新能力。

第一就是支持多頻多模以及支持載波聚合的能力。據介紹，通過插卡組合，LampSite可以根據網路需要靈活地調整網路制式和頻率，2G、3G、4G都可支持，部署一次可解決所有網路的室內覆蓋問題，並且可以平滑地進行軟體升級，未來不必進行重新部署室內覆蓋系統。

第二是靈活高效的擴容能力。在網路建設初期，通過pRRU聚合可減少小區邊緣面積，降低干擾。當網路負載較高時，通過小區分裂技術，形成多個小區，等同於加站，再採用自適應單頻點組網技術，實現干擾與容量的平衡，小區間可無縫切換，可以說，無需任何工程改造，僅升級軟體就能提升網路容量，增加站點。

第三是強大的協同自動化處理和管理能力。通過多種創新技術，LampSite實現了室內外網路之間的協同自動化。同時，配合華為的統一網管和檢測評估工具，可以對室內熱點區域進行精確管理和分析，協同運維，實施多維度、精細化的智能監測和評估優化。

第四是強大的多天線系統，具有巨大的性能潛力。LampSite pRRU堪稱是一根乙太網線纜的LTE多天線設備。由於支持多天線，小區總吞吐量可增加100%，小區邊緣用戶吞吐量增加40%以上。

總之，全新架構的LampSite是室內覆蓋系統的一次革新。與傳統的分布式天線系統相比，LampSite具有巨大的優勢：

第一，DAS操作維護復雜度高，網路架構復雜，需要部署合路器、饋線保護、遠端單元以及天線等，並需要兩套網管系統，DAS系統沒有操作維護能力，而LampSite解決方案只需用光纖連接BBU和RHUB，再用五類線將pRRU連接至RHUB，架構簡潔，施工極為容易，相比雙信道室內無源DAS系統，LampSite的部署周期可縮短86%，同時還實現了網管系統的共享。

第二，DAS系統具有較高的底噪，包括RRU的底噪以及不同信號共信道產生的無法消除的底噪，上行鏈路的等效雜訊系數增加了約20dB.而LampSite可消除RRU雜訊，獨立解調消除了上行鏈路RRU之間的干擾。

第三，DAS系統擴容成本高，由於是宏基站覆蓋的延伸，其擴容高度依賴遠端機和基站。而LampSite可根據需求實現pRRU級別的小區分裂，加之基於軟體的升級，實現了空中介面的無縫擴容。具體而言，單獨解調實現了4~8倍的上行擴容，虛擬小區可實現4~8倍的下行擴容，小區分裂可實現6~12倍擴容。

第四，DAS系統由於重疊干擾以及室內網路和室外宏網無法協同等原因，用戶體驗較差，而LampSite可實現pRRU之間的協同，未來還可實現與室外宏網路之間的協同，可使小區邊緣用戶的上下行數據速率增加90%，掉話率減少30%，接入失敗率減少20%，用戶體驗大大提高。
3華為「Service Anchor」：創新「小基站網路」的商業模式
在移動寬頻時代，運營商通過建設小基站進行熱點容量提升、室內深度覆蓋已成趨勢，但是傳統建設模式卻日益受到站點和傳輸獲取困難、收益模式單一等難題的影響，運營商的進入成本也越來越高。怎樣才能幫助運營商加快小基站的部署呢？在2014年的世界移動通信大會上，華為發布了一款名為「眾包小基站」（Crowd-sourcing Small Cell）的解決方案，力圖解決這一難題。

「眾包」本是一種從互聯網衍生而來的生產組織形式，特點是能夠最大化地整合參與者的資源和能力。通過「眾包小基站」方式，華為創造性地在LampSite解決方案中引入了可編程的業務新網元——Service Anchor（業務錨點），業務錨點基於開放架構，擁有開放的API，可以和企業業務平台對接，從而吸引公共設施管理者、大型建築業主、網路集成商、企業等參與到「小基站」的建設和運營中來。運營商既可以整合企業應用，也可以面向企業就近提供最佳體驗的企業雲業務，幫助運營商集成眾包合作夥伴以場所為中心的資源優勢和應用優勢，形成差異化的應用平台，由傳統的大眾市場進入企業市場。

基於LampSite網路和業務錨點，通過第三方應用開發商的引入，為諸如實景導航、室內地圖和定位、高精度的廣告推送、大數據支持以及物聯網應用創造了條件。據華為Small Cell產品線總裁周躍峰介紹，依靠華為的專利技術，能夠實現精確到3米的室內導航，可以開發多種應用。周躍峰表示，華為鼓勵第三方開發商在業務錨點上開發應用，從而為場館、運營商提供增值服務。通過這一平台還可引入大數據分析和雲服務，華為已經與業界多家雲業務提供商展開合作，實現企業業務與小基站解決方案的融合。

這一商業模式可以概括為，運營商向站址業主支付租金，業主則向第三方應用開發商支付相關費用，第三方應用開發商向運營商支付信息和流量費用，形成良性循環。從運營商的角度看，第三方應用的引入，增加了收入，實現了價值的轉移，運營商的投資回報率得到提高。

周躍峰認為，未來，運營商傳統的投資回報率（ROI）公式將被改寫。將從傳統凈收入與總成本的比值轉變為運營商凈收入與價值轉移之和與總成本與成本轉移之和的比值。

價值轉移將包括企業應用、廣告收入、數據分析等相關服務。而成本轉移將包括和站址業主之間的成本分擔以及電子商務與遠程管理帶來的運營成本降低等。周躍峰認為，在移動寬頻時代，室內深度覆蓋問題不解決，消費者的需求就會被壓制，運營商的投資回報率將受到嚴重影響。

華為LampSite將有效解決運營商室內深度覆蓋問題，釋放用戶需求。同時，通過「眾包小基站」解決方案進一步降低運營商的部署成本，提高收入，必然帶來投資回報率的明顯改善。可以說，華為LampSite是一款能帶來商業模式改變的室內深度覆蓋解決方案。

4華為LampSite：市場認可商用持續領先

在法國依雲皇家酒店部署LampSite

LampSite發布之後，因其創新的網路架構、便捷的部署方式引起了全球移動通信界的廣泛關注，其商用進程也迅速推進。2013年12月9日，華為正式宣布，LampSite室內覆蓋解決方案在英國沃達豐現網成功部署，拉開了LampSite規模商用的序幕。

在這一商用案例中，華為為沃達豐某辦公樓四個樓層提供室內3G覆蓋，總計12000平方米，為近1100名員工和訪客提供高速移動寬頻服務，使該區域移動用戶即使在話務繁忙的辦公時間，也能享有隨時隨地不低於10Mb/s的數據傳輸速度以及更好的語音通話質量，並達到零掉話率。在部署過程中充分展示了LampSite解決方案的高擴展性、高靈活性以及易於部署和管理的特點。

此後不久，在2014年的巴塞羅那世界移動通信大會上，挪威Telenor也宣布選擇華為LampSite解決方案提升室內覆蓋質量，加速LTE商用進程，從而成為全球第一個LTE LampSite商用網路。

挪威首都奧斯陸，Telenor選擇在其6層樓高的總部大樓率先部署華為LampSite解決方案。僅用了3個小時就完成了一個pRRU從室內區域網路規劃、站點勘測到安裝、調測等全部過程，在增強網路覆蓋的同時，為用戶帶來全新的應用體驗，現場測試用戶實際體驗到的最高下行速率達46Mbps.據華為無線網路營銷工程部高級市場總監婁志強介紹，到目前為止，華為已經在泰國、北歐、英國倫敦、法國巴黎等地部署了LampSite系統。

LampSite在國內的商用也在不斷推進。婁志強介紹說，華為已經在鄭州火車站部署了上百個LampSite接入點，統計顯示，下行數據流量增加了60%以上，上行增加了50%以上，有效釋放了原來依靠宏基站以及DAS系統所壓制的用戶需求，用戶體驗也大大提高。此外，全國許多機場，包括重慶機場、首都國際機場等也開始部署LampSite.在首都國際機場，華為部署了幾千個LampSite接入點，相當於把機場分成幾千個小蜂窩區域，每個蜂窩容量非常高，完全可以滿足密集人群的應用需求，在提升用戶體驗的同時，運營商也將獲得應有的回報。婁志強還表示，華為LampSite目前已經獲得了超過180個全球運營商合同，其中商用合同超過120個，獲得了全球運營商的高度認可。

應當說，LampSite的市場表現超出了人們的預期，其大容量、高速率、易管理、短施工的特點在我國進入4G時代之際無疑將大有用武之地，有望成為致力於為用戶提供最佳移動寬頻體驗的運營商的必然之選。

展望未來，待到LampSite大規模普及之時，人們或許再也不會有「明明有網路信號卻無法上網」的糟糕體驗了！

㈡ 一個標準的MapRece系統架構通常包括多個主控節點和一個數據節點其中數據節

摘要 一、MapRece概念

㈢ Cocoa如何應用設計模式求解答

Cocoa經常把自己與眾不同的工作機制建立在模式上，它的設計受到諸如語言能力或現有架構這樣因素的影響。 本部分包含設計模式：可重用的面向對象軟體的元素一書中編目的大多數設計模式的介紹。每個設計模式都有一個總結性的描述，以及該模式的Cocoa實現的討論。文中列出的都是Cocoa實現的模式，每個模式的討論都發生在特定的Cocoa環境中。我們推薦您熟悉這些模式，您會發現這些模式在Cocoa軟體開發中非常有用。 Cocoa中設計模式的實現有不同的形式。下面部分中描述的一些設計—比如協議和范疇—是Objective-C語言的特性；在另外一些場合中，「模式的實例」被實現為一個類或一組相關的類（比如類簇和單件類）；還有一些場合下，模式表現為一個大的框架結構，比如響應者鏈模式。對於某些基於模式的機制，您幾乎可以「免費」使用；而另外一些機制則要求您做一些工作。即使對於Cocoa沒有實現的模式，我們也鼓勵您在條件許可的情況下自行實現，比如在擴展類的行為時，對象合成（裝飾模式）技術通常就比生成子類更好。 有兩個設計模式沒有在下面的內容中進行討論，即模型-視圖-控制器（MVC）模式和對象建模。MVC是一種復合或聚合模式，就是說它基於幾種不同類型的模式。對象建模在四人組的分類目錄中沒有對應類別，它源自關系資料庫領域。然而，MVC和對象建模在Cocoa中可能是最重要和最普遍的設計模式或用語，而且它們在很大程度上是相關的。它們在幾個技術的設計中發揮關鍵的作用，包括綁定、撤消管理、腳本控制、和文檔架構。要了解更多有關這些模式的信息，請參見"模型-視圖-控制器設計模式"和"對象建模"部分。 本部分包含如下主要內容：抽象工廠模式適配器模式責任鏈模式命令模式合成模式裝飾模式表觀模式跌代器模式仲裁者模式備忘錄模式觀察者模式代理模式單件模式模板方法模式 抽象工廠模式提供一個介面，用於創建與某些對象相關或依賴於某些對象的類家族，而又不需要指定它們的具體類。通過這種模式可以去除客戶代碼和來自工廠的具體對象細節之間的耦合關系。 類簇類簇是一種把一個公共的抽象超類下的一些私有的具體子類組合在一起的架構。抽象超類負責聲明創建私有子類實例的方法，會根據被調用方法的不同分配恰當的具體子類，每個返回的對象都可能屬於不同的私有子類。 Cocoa將類簇限制在數據存儲可能因環境而變的對象生成上。Foundation框架為NSString、NSData、NSDictionary、NSSet、和NSArray對象定義了類簇。公共超類包括上述的不可變類和與其相互補充的可變類NSMutableString、NSMutableData、NSMutableDictionary、NSMutableSet、和NSMutableArray。 使用和限制 當您希望創建類簇代表的類型的可變或不可變對象時，可以使用類簇中的某個公共類來實現。使用類簇是在簡潔性和擴展性之間進行折衷。類簇可以簡化類介面，因此使其更易於學習和使用，但是創建類簇抽象類的定製子類則會變得更加困難。進一步閱讀： "類簇" 部分提供有關Cocoa類簇的更多信息。 適配器模式將一個類介面轉化為客戶代碼需要的另一個介面。適配器使原本由於兼容性而不能協同工作的類可以工作在一起，消除了客戶代碼和目標對象的類之間的耦合性。 協議協議是一個編程語言級別（Objective-C）的特性，它使定義適配器模式的實例成為可能（在 java中的「介面」和「協議」是同義的）。如果您希望一個客戶對象和另一個對象進行交流，但由於它們的介面不兼容而導致困難，您就可以定義一個協議，它本質上是一系列和類不相關聯的方法聲明。這樣，其它對象的類就可以正式採納該協議，並通過實現協議中的全部方法來「遵循」該協議。結果，客戶對象就可以通過協議介面向其它對象發送消息。 協議是一組獨立於類層次的方法聲明，這樣就有可能象類的繼承那樣，根據對象遵循的協議對其進行分組。您可以通過NSObject的conformsToProtocol:方法來確認一個對象的協議關系。 除了正式協議之外，Cocoa還有一個非正式協議的概念。這種類型的協議是NSObject類中的一個范疇（category），這樣就使所有的對象都成為范疇方法的潛在實現者（參見"范疇"部分）。非正式協議的方法可以選擇性地實現。非正式協議是委託機制實現的一部分（參見"委託"部分。 請注意，協議的設計和適配器模式並不完全匹配。但它是使介面不兼容的類在得以協同工作的手段。 使用和限制 協議主要用於聲明層次結構上不相關的類為了互相通訊而需要遵循的介面。但是，您也可以將協議用於聲明對象的介面，而隱藏相應的類。Cocoa框架包括很多正式協議，這些協議使定製子類可以和框架進行特定目的的通訊。舉例來說，Foundation框架中包含NSObject、NSCopying、和NSCoding協議，都非常重要。Application Kit中的協議包括NSDraggingInfo、NSTextInput、和NSChangeSpelling。 正式協議要求遵循者實現協議聲明的所有方法。它們也是零碎的，一旦您定義一個協議並將它提供給其它類，將來對協議的修改會使那些類不能工作。進一步閱讀：有關正式協議的更多信息請參見Objective-C編程語言文檔中「擴展類」部分的討論。 責任鏈模式通過為多個對象提供處理請求的機會，避免請求的發送者和接收者產生耦合。將接收對象串成鏈，並將請求沿著接收者鏈進行傳遞，直到某個對象對其進行處理。對象或者處理該請求，或者將它傳遞給鏈中的下一個對象。 響應者鏈Application Kit框架中包含一個稱為響應者鏈的架構。該鏈由一系列響應者對象（就是從NSResponder繼承下來的對象）組成，事件（比如滑鼠點擊）或者動作消息沿著鏈進行傳遞並（通常情況下）最終被處理。如果給定的響應者對象不處理特定的消息，就將消息傳遞給鏈中的下一個響應者。響應者在鏈中的順序通常由視圖的層次結構來決定，從層次較低的響應者對象向層次較高的對象傳遞，頂點是管理視圖層次結構的窗口對象，窗口對象的委託對象，或者全局的應用程序對象。事件和動作消息在響應者鏈中的確切傳遞路徑是不盡相同的。一個應用程序擁有的響應者鏈可能和它擁有的窗口（甚至是局部層次結構中的視圖對象）一樣多，但每次只能有一個響應者鏈是活動的—也就是與當前活動窗口相關聯的那個響應鏈。 還有一個與響應者鏈相類似的鏈，用於應用程序的錯誤處理。 視圖層次的設計應用的是合成模式（參見"合成模式"部分），它和響應者鏈密切相關。動作消息—源自控制項對象的消息—基於目標-動作機制，是命令模式（參見"命令模式"部分）的一個實例。 使用和限制 當您通過Interface Builder或以編程的方式為程序構造用戶界面時，可以「免費」得到一個或多個響應者鏈。響應者鏈和視圖層次結構一起出現，當您使一個視圖對象成為窗口內容視圖的子視圖時，視圖層次結構就自動生成了。如果您將一個定製視圖加入到一個視圖層次結構中，它就變成響應者鏈的一部分；如果您實現了恰當的NSResponder方法，就可以接收和處理事件及動作消息。定製對象是窗口對象或全局應用程序對象NSApp的委託對象，也可以接收和處理那些消息。 您也可以用編程的方式將定製的響應者對象注入到響應者鏈中，以及通過編程操作響應者在鏈中的順序。進一步閱讀： 處理事件和動作消息及程序錯誤的的響應者鏈在Cocoa事件處理指南和Cocoa的錯誤處理編程指南文檔中進行描述。本文檔在"合成模式"部分對視圖層次結構有總結性的介紹，在"核心應用程序架構"部分有更全面的描述。 命令模式這種模式將請求封裝為對象，使您可以用不同的請求來對客戶代碼進行參數化；對請求進行排隊和記錄，並支持可撤消（undoable）的操作。請求對象將一或多個動作綁定在特定的接收者上。命令模式將發出請求的對象和接收及執行請求的對象區分開來。 調用對象NSInvocation類的實例用於封裝Objective-C消息。一個調用對象中含有一個目標對象、一個方法選擇器、以及方法參數。您可以動態地改變調用對象中消息的目標及其參數，一旦消息被執行，您就可以從該對象得到返回值。通過一個調用對象可以多次調用目標或參數不同的消息。 創建NSInvocation對象需要使用NSMethodSignature對象，該對象負責封裝與方法參數和返回值有關系的信息。NSMethodSignature對象的創建又需要用到一個方法選擇器。NSInvocation的實現還用到Objective-C運行環境的一些函數。 使用和限制NSInvocation對象是分布式、撤消管理、消息傳遞、和定時器對象編程介面的一部分。在需要去除消息發送對象和接收對象之間的耦合關系的類似場合下，您也可以使用。 分布式對象是一種進程間通訊技術，關於這個主題的更多信息請參見"代理模式"部分。進一步閱讀：調用對象的細節請閱讀NSInvocation的類參考文檔。您也可以從下面的文檔中獲取相關技術的信息：Objective-C編程語言文檔中的分布式對象、撤消架構、定時器以及之後的部分。 目標-動作目標-動作機制使控制項對象—也就是象按鍵或文本輸入框這樣的對象—可以將消息發送給另一個可以對消息進行解釋並將它處理為具體應用程序指令的對象。接收對象，或者說是目標，通常是一個定製的控制器對象。消息—也被稱為動作消息—由一個選擇器來確定，選擇器是一個方法的唯一運行時標識。典型情況下，控制項擁有的單元對象會對目標和動作進行封裝，以便在用戶點擊或激活控制項時發送消息（菜單項也封裝了目標和動作，以便在用戶選擇時發送動作消息）。目標-動作機制之所以能夠基於選擇器（而不是方法簽名），是因為Cocoa規定動作方法的簽名和選擇器名稱總是一樣的。 使用和限制 當您用Interface Builder構建程序的用戶界面時，可以對控制項的動作和目標進行設置。您因此可以讓控制項具有定製的行為，而又不必為控制項本身書寫任何的代碼。動作選擇器和目標連接被歸檔在nib文件中，並在nib文件被解檔時復活。您也可以通過向控制項或它的單元對象發送setTarget:和setAction:消息來動態地改變目標和動作。 目標-動作機制經常用於通知定製控制器對象將數據從用戶界面傳遞給模型對象，或者將模型對象的數據顯示出來。Cocoa綁定技術則可以避免這種用法，有關這種技術的更多信息請參見Cocoa綁定編程主題文檔。 Application Kit中的控制項和單元並不保持它們的目標。相反，它們維護一個對目標的弱引用。進一步的信息請參見"委託、觀察者、和目標的所有權" 部分。進一步閱讀：更多信息請參見"目標-動作機制"部分。 合成模式這種模式將互相關聯的對象合成為樹結構，以表現部分-全部的層次結構。它使客戶代碼可以統一地處理單獨的對象和多個對象的合成結果。 合成對象是模型-視圖-控制器聚集模式的一部分。 視圖層次結構 一個窗口包含的視圖對象（NSView對象）在內部構成了一個視圖層次結構。層次結構的根是窗口對象（NSWindow對象）和它的內容視圖。內容視圖就是填充到窗口內容方框中的透明視圖，添加到內容視圖中的視圖都是它的子視圖，而這些子視圖又會成為下一級視圖的父視圖。一個視圖有一個（且只有一個）父視圖，可以有零或多個子視圖。在視覺上，您可以將這個結構理解為包含關系：父視圖包含它的子視圖。圖4-2顯示視圖層次的結構以及在視覺上的關系。 圖4-2 視圖層次的結構及其在視覺上的關系 視圖層次是一個結構方面的架構，在圖形描畫和事件處理上都扮演一定的角色。一個視圖有兩個影響圖形操作位置的邊界框，即邊框（frame）和邊界（bound）。邊框是外部邊界，表示視圖在其父視圖坐標系統中的位置，它負責定義視圖的尺寸，並根據視圖邊界對圖形進行裁減。邊界則是內部的邊界框，負責定義視圖對象自身描畫表面的內部坐標系統。 當窗口系統要求一個窗口做好顯示准備時，父視圖會在其子視圖之前被要求進行渲染。當您向一個視圖發送消息時—比如發送一個重畫視圖的消息—該消息就會被傳播到子視圖。因此，您可以將視圖層次結構中的一個分支當成一個統一的視圖來處理。 響應者鏈也把視圖層次用於處理事件和動作消息。請參見責任鏈模式部分中（"責任鏈模式"）關於響應者鏈的總結描述。 使用和限制 無論以編程的方式，還是通過Interface Builder，當您將一個視圖加入到另一個視圖中時，都需要創建或修改視圖層次結構。Application Kit框架自動處理與視圖層次結構相關聯的所有關系。進一步閱讀：如果需要了解更多視圖層次結構的信息，請閱讀本文檔的"視圖層次結構"部分。Cocoa描畫指南文檔中也對視圖層次結構進行討論。 裝飾模式這種模式動態地將額外的責任附加到一個對象上。在進行功能擴展時，裝飾是子類化之外的一種靈活的備選方法。和子類化一樣，採納裝飾模式可以加入新的行為，而又不必修改已有的代碼。裝飾將需要擴展的類的對象進行包裝，實現與該對象相同的介面，並在將任務傳遞給被包裝對象之前或之後加入自己的行為。裝飾模式表達了這樣的設計原則：類應該接納擴展，但避免修改。 一般性的說明 裝飾是用於對象合成的模式。在您自己的代碼中應該鼓勵使用對象的合成（參見"什麼時候需要生成子類"部分）。然而，Cocoa自己提供了一些基於這種模式的類和機制（在下面的部分進行討論）。在這些實現中，擴展對象並不完全復制它所包裝的對象的介面，雖然具體實現中可以使用不同的技術來進行介面共享。 Cocoa在實現某些類時用到了裝飾模式，包括NSAttributedString、NSScrollView、和NSTableView。後面兩個類是復合視圖的例子，它們將其它一些視圖類的對象組合在一起，然後協調它們之間的交互。 委託委託是在宿主對象中嵌入一個指向另一對象（也就是委託對象）的弱引用（一個未保持的插座變數），並不時地向該委託對象發送消息，使其對有關的任務進行輸入的機制。宿主對象一般是一個「復活」的框架對象（比如一個NSWindow或NSXMLParser對象），它尋求完成某項工作，但又只能以一般的方式來進行。委託幾乎總是一個定製類的實例，它負責配合宿主對象，在有關任務的特定點（參見圖4-3）上提供與具體程序有關的行為。這樣，委託機制使我們可以對另一個對象的行為進行修改或者擴展，而不需要生成子類。 圖4-3 框架對象向它的委託對象發送消息 簡而言之，委託就是一個對象將任務委託給另一個對象，它是面向對象編程的常用技術。然而，Cocoa以獨特的方式實現委託機制。宿主類用非正式協議—即NSObject中的范疇—來定義委託對象可能選擇實現的介面。委託對象不必象採納正式協議那樣實現所有的協議方法。在向委託對象發送消息之前，宿主對象可以首先確定相應的方法是否實現（通過respondsToSelector:消息），以避免運行時例外。有關正式協議和非正式協議的更多信息，請參見"協議"部分。 Cocoa框架中的一些類也向它們的數據源發送消息。數據源在各個方面都和委託一樣，除了它的目的是為宿主對象提供數據，以傳遞給瀏覽器、表視圖、或者類似的用戶界面視圖。和委託不同的是，數據源還必須實現某些協議方法。 委託不是裝飾模式的嚴格實現。宿主（委託）對象並沒有包裝它希望擴展的類的實例。相反，委託是對委託框架類的行為進行特殊化。除了框架類聲明的委託方法之外，它們也沒有公共的介面。 Cocoa中的委託也是模板方法模式（"模板方法模式"）的一部分。 使用和限制 委託是Cocoa框架中的一種常用的設計。Application Kit框架中的很多類都向它們的委託發送消息，包括NSApplication、NSWindow、和NSView的幾個子類。Foundation框架中的一些類，比如NSXMLParser和NSStream，也維護自己的委託。您應該總是使用類的委託機制，而不是生成類的子類，除非委託方法不能完成您的目標。 雖然您可以動態地改變委託，但是同時只能有一個對象可以成為委託。因此，如果您希望當特定的程序事件發生時，有多個對象可以同時得到通知，則不能使用委託。在這種情況下您可以使用通告機制。如果委託對象實現了一或多個框架類聲明的通告方法，就會自動接收到其委託框架對象的通告。請參考觀察者模式（ "觀察者模式"）中有關通告的討論。 Application Kit框架中的向外委託任務的對象並不保持它們的委託或數據源，而是維護一個弱引用，更多信息請參見"委託、觀察者、和目標的所有權"部分。進一步閱讀：關於委託的進一步信息請參見"委託和數據源"部分。 范疇范疇是Objective-C語言的一個特性，用於為一個類增加方法（介面和實現），而不必生成子類。類原始聲明的方法和通過范疇添加的方法在運行時沒有區別—在您的程序的作用范圍內。范疇中的方法成為類類型的一部分，並被所有的子類繼承。 和委託一樣，范疇並沒有嚴格適配裝飾模式。它實現了該模式的目的，但採用不同的實現方式。范疇加入的行為是在編譯時生成的，而不是動態得到的。而且，范疇並沒有封裝被擴展的類的實例。 使用和限制 Cocoa框架中定義了很多范疇，大多數都是非正式協議（在"協議"部分中進行總結）。它們通常使用范疇來對相關的方法進行分組。您也可以在代碼中實現范疇，以在不生成子類的情況下對類進行擴展，或者對相關的方法進行分組。但是您需要注意如下兩點： 您不能為類添加實例變數。 如果您對現有的方法進行重載，則應用程序可能產生預料之外的行為。進一步閱讀: 更多有關范疇的信息請參見Objective-C編程語言一文中的「類的擴展」部分。 表觀模式這種模式為子系統中的一組介面提供統一的介面。表觀模式定義一個更高級別的介面，通過減少復雜度和隱藏子系統之間的通訊和依賴性，使子系統更加易於使用。 NSImageNSImage類為裝載和使用基於點陣圖（比如JPEG、PNG、或者TIFF格式）或向量（EPS或PDF格式）的圖像提供統一的介面。NSImage可以為同一個圖像保持多個表示，不同的表示對應於不同類型的NSImageRep對象。NSImage可以自動選擇適合於特定數據類型和顯示設備的表示。同時，它隱藏了圖像操作和選擇的細節，使客戶代碼可以交替使用很多不同的表示。 使用和限制 由於NSImage支持幾種不同的圖像表示，因此某些屬性可能不能適用。舉例來說，您可能不能取得圖像中一個像素的顏色，如果潛在的圖像表示使基於向量且與設備無關的話。請注意：NSImage和圖像表示的討論請參見Cocoa描畫指南。 迭代器模式這種模式提供一種順序訪問聚合對象（也就是一個集合）中的元素，而又不必暴露潛在表示的方法。迭代器模式將訪問和遍歷集合元素的責任從集合對象轉移到迭代器對象。迭代器定義一個訪問集合元素的介面，並對當前元素進行跟蹤。不同的迭代器可以執行不同的遍歷策略。 NSEnumerator Foundation框架中的NSEnumerator類實現了迭代器模式。NSEnumerator抽象類的私有具體子類返回的枚舉器對象可以順序遍歷不同類型的集合—數組、集合、字典（值和鍵）—並將集合中的對象返回給客戶代碼。NSDirectoryEnumerator是一個不緊密相關的類，它的實例可以遞歸地枚舉文件系統中目錄的內容。 使用和限制 象NSArray、NSSet、和NSDictionary這樣的集合類都包含相應的方法，可以返回與集合的類型相適用的枚舉器。所有的枚舉器的工作方式都一樣。您可以在循環中向枚舉器發送nextObject消息，如果該消息返回nil，而不是集合中的下一個對象，則退出循環。 仲裁者模式這種模式定義的對象用於封裝一組對象的交互機制。仲裁者模式可以避免對象之間顯式的互相引用，使對象之間的耦合變得寬松，也使您可以獨立地改變它們的交互方式。這些對象也因此可以更具重用性。 仲裁者對象集中了系統中的對象之間的復雜通訊和控制邏輯。這些對象在狀態發生改變時會告訴仲裁者對象，反過來，也對仲裁者對象的請求進行響應。 控制器類模型-視圖-控制器設計模式為一個面向對象的系統（比如一個應用程序）中的對象分配不同的角色。它們可以是模型對象，包含應用程序的數據及對那些數據進行操作；可以是視圖對象，負責表示數據及響應用戶動作；也可以是控制器對象，負責協調模型和視圖對象。控制器對象適合於仲裁者模式。 在Cocoa中，控制器對象一般有兩個類型：仲裁控制器或者協調控制器。仲裁控制器負責仲裁應用程序中視圖對象和模型對象之間的數據流。仲裁控制器通常是NSController對象。協調控制器則負責實現應用程序的集中化通訊和控制邏輯，作為框架對象的委託和動作消息的目標。它們通常是NSWindowController對象或定製NSObject子類的實例。由於協調控制器高度專用於特定的程序，因此不考慮重用。 Application Kit框架中的NSController抽象類和它的具體子類是Cocoa綁定技術的一部分，該技術可以自動同步模型對象包含的數據和視圖對象中顯示及編輯的數據。舉例來說，如果用戶在一個文本框中編輯一個字元串，綁定技術會將文本框中的變化（通過仲裁控制器）傳遞給綁定了的模型對象中合適的屬性。編程者需要做的就是正確設計自己的模型對象，並通過Interface Builder在程序的視圖、控制器、和模型對象之間建立綁定關系。 具體的公共控制器類的實例可以在Interface Builder的控制項選盤上得到，因此是高度可重用的。它們提供一些服務，比如選擇和佔位符值的管理。這些對象執行下面這些特定的功能：NSObjectController 管理一個單獨的模型對象。NSArrayController 管理一個模型對象數組，以及維護一個選擇；還可以在數組中加入或刪除模型對象。NSTreeController 使您可以在一個具有層次的樹結構中添加、刪除、和管理模型對象。NSUserDefaultsController 為預置（用戶預設值）系統提供一個便利的介面。 使用和限制 您通常可用將NSController對象用作仲裁控制器，因為這些對象的設計目的是在應用程序的視圖對象和模型對象之間傳遞數據。在使用仲裁控制器時，您通常是從Interface Builder選盤中拖出對象，指定模型對象的屬性鍵，並通過Interface Builder Info 窗口中的Bindings面板建立視圖和模型對象之間的綁定關系。您也可以生成NSController或其子類的子類，以獲得更具具體行為的子類。 幾乎任何一對對象之間都可以建立綁定關系，只要它們遵循NSKeyValueCoding和NSKeyValueObserving這兩個非正式協議。但是，我們推薦您通過仲裁控制器來建立綁定，以得到NSController及其子類為您提供的各種好處。 協調控制器通過下面的方式集中實現一個應用程序的通訊和控制邏輯： 維護指向模型和視圖對象的插座變數（插座變數是指向其它被保持為實例變數的連接或引用）。 通過目標-動作機制響應用戶在視圖對象上的操作（參見"目標-動作"部分）。 作為委託對象，處理從框架對象發出的消息（參見"委託"部分）。 您通常可以在Interface Builder中建立上述的連接—插座變數、目標-動作、和委託，它將這些連接歸檔到應用程序的nib文件中。進一步閱讀: 有關仲裁控制器、協調控制器、和與控制器有關的設計決定的討論，請參見"模型-視圖-控制器設計模式"部分。 備忘錄模式這種模式在不破壞封裝的情況下，捕捉和外部化對象的內部狀態，使對象在之後可以回復到該狀態。備忘錄模式使關鍵對象的重要狀態外部化，同時保持對象的內聚性。 歸檔歸檔將一個程序中的對象以及對象的屬性（包括屬性和關系）存儲到檔案上，使之可以保存到文件系統中，或者在不同的處理器和網路間傳遞。檔案將程序的對象圖保存為獨立於架構的位元組流，對象的標識和對象之間的關系都會被保留。由於對象的類型和它的數據一起被存儲，從歸檔的位元組流解碼出來的對象會被正常實例化，實例化所用的類與原來編碼的類相同。 使用和限制 通常情況下，您希望將程序中需要保存狀態的對象歸檔。模型對象幾乎總是屬於這個范疇。您通過編碼將對象寫入到檔案中，而通過解碼將對象從檔案中讀取出來。通過NSCoder對象可以執行編解碼操作，在編解碼過程中最好使用鍵化的歸檔技術（需要調用NSKeyedArchiver和NSKeyedUnarchiver類的方法）。被編解碼的對象必須遵循NSCoding協議；該協議的方法在歸檔過程中會被調用。進一步閱讀: 有關歸檔的進一步信息。 屬性列表的序列化屬性列表是一個簡單的、具有一定結構的對象圖序列，它僅使用下面這些類的對象：NSDictionary、NSArray、NSString、NSData、NSDate、和NSNumber。這些對象通常也被稱為屬性列表對象。Cocoa中有幾個框架類提供了序列化屬性列表對象，以及定義錄寫對象內容及其層次關系的特殊數據流格式的方法。NSPropertyListSerialization類就提供了將屬性列表對象序列化為XML或其它優化的二進制格式的類方法。 使用和限制 如果對象圖中包含的是簡單對象，則在捕捉和外部化對象及其狀態時，屬性列表序列化是一種靈活的、可移植的、而又非常適當的工具。然而，這種形式的序列化有它的限制，它不保留對象的全部類標識，而只保留一些一般的類型（數組、字典、字元串、等等）。這樣，從屬性列表恢復出來的對象可能和原來的類不同，特別是當對象的可變性可能發生變化時，這就會帶來問題。屬性列表序列化也不跟蹤在同一對象中被多次引用的對象，這可能導致反向序列化時產生多個實例，而在原來的對象圖中卻只有一個實例。進一步閱讀: 有關屬性列表序列化的更多信息。 Core DataCore Data是一個管理對象圖，並使其留存的框架和架構。正是第二種能力—對象的留存能力—使Core Data成為備忘錄模式的一種適配形式。 在Core Data架構中，中心的對象稱為被管理對象上下文，負責管理應用程序對象圖中的模型對象。在被管理對象上下文下面是該對象圖的持久棧，也就是一個框架對象的集合，負責協調模型對象和外部數據存儲，比如XML文件或關系資料庫。持久棧對象負責建立存儲中的數據和被管理對象上下文中的對象之間的映射關系，在

㈣ 什麼是機器學習

機器學習(Machine Learning, ML)是一門多領域交叉學科，涉及概率論、統計學、逼近論、凸分析、演算法復雜度理論等多門學科。專門研究計算機怎樣模擬或實現人類的學習行為，以獲取新的知識或技能，重新組織已有的知識結構使之不斷改善自身的性能。

它是人工智慧的核心，是使計算機具有智能的根本途徑，其應用遍及人工智慧的各個領域，它主要使用歸納、綜合而不是演繹。

㈤ 管理中間件層和soa構建層是雲計算技術的最關鍵部分對嗎

雲計算關鍵技術 雲計算是分布式處理、並行計算和網格計算等概念的發展和商業實現，其技術實質是計算、存儲、伺服器、應用軟體等IT軟硬體資源的虛擬化，雲計算在虛擬化、數據存儲、數據管理、編程模式等方面具有自身獨特的技術。雲計算的關鍵技術包括以下幾個方向： 虛擬機技術 虛擬機，即伺服器虛擬化是雲計算底層架構的重要基石。在伺服器虛擬化中，虛擬化軟體需要實現對硬體的抽象，資源的分配、調度和管理，虛擬機與宿主操作系統及多個虛擬機間的隔離等功能，目前典型的實現（基本成為事實標准）有Citrix Xen、VMware ESX Server 和Microsoft Hype-V等。 數據存儲技術 雲計算系統需要同時滿足大量用戶的需求，並行地為大量用戶提供服務。因此，雲計算的數據存儲技術必須具有分布式、高吞吐率和高傳輸率的特點。目前數據存儲技術主要有Google的GFS（Google File System，非開源）以及HDFS（Hadoop Distributed File System，開源），目前這兩種技術已經成為事實標准。 數據管理技術 雲計算的特點是對海量的數據存儲、讀取後進行大量的分析，如何提高數據的更新速率以及進一步提高隨機讀速率是未來的數據管理技術必須解決的問題。雲計算的數據管理技術最著名的是谷歌的BigTable數據管理技術，同時Hadoop開發團隊正在開發類似BigTable的開源數據管理模塊。 分布式編程與計算 為了使用戶能更輕松的享受雲計算帶來的服務，讓用戶能利用該編程模型編寫簡單的程序來實現特定的目的，雲計算上的編程模型必須十分簡單。必須保證後台復雜的並行執行和任務調度向用戶和編程人員透明。當前各IT廠商提出的雲計劃的編程工具均基於Map-Rece的編程模型。 虛擬資源的管理與調度 雲計算區別於單機虛擬化技術的重要特徵是通過整合物理資源形成資源池，並通過資源管理層（管理中間件）實現對資源池中虛擬資源的調度。雲計算的資源管理需要負責資源管理、任務管理、用戶管理和安全管理等工作，實現節點故障的屏蔽，資源狀況監視，用戶任務調度，用戶身份管理等多重功能。 雲計算的業務介面 為了方便用戶業務由傳統IT系統向雲計算環境的遷移，雲計算應對用戶提供統一的業務介面。業務介面的統一不僅方便用戶業務向雲端的遷移，也會使用戶業務在雲與雲之間的遷移更加容易。在雲計算時代，SOA架構和以Web Service為特徵的業務模式仍是業務發展的主要路線。 雲計算相關的安全技術 雲計算模式帶來一系列的安全問題，包括用戶隱私的保護、用戶數據的備份、雲計算基礎設施的防護等，這些問題都需要更強的技術手段，乃至法律手段去解決。

㈥ 網路安全就業難度大不大

未邀自答。本來我都關機、躺下、准備睡覺了，結果手賤點了知乎，看到了這么一個問題，又看到好朋友 @scalers回答了這個問題，忍不住又把電腦打開，准備花一點時間認真回答一下這個問題。這可能不僅是對問題本身的回答，也是差不多這一年來我對信息安全這個領域的理解和體會吧。=============================利益相關：信息安全方向博士生，主攻Public Key Encryption，主要方向是Predicate Encryption。1-2年之內就要就業，方向應該就是數據安全了。這一年認識了不少領域內的前輩和朋友，了解到不少現狀。=============================0. 總體感受：人才既飽和，又匱乏現在安全行業的現狀基本是：上層人才極度匱乏，下層人才極度飽和。大概半年多前和一位領域內的人士聊天，對方說了這么一句話：我們招人要求真的不高啊，只要領域相關，7年以上工作經驗就好了。當時，幼稚的我心想，我靠你逗我呢，這還要求不高？哪兒找安全領域干7年以上的人去？經過半年的折騰，我現在的感覺是：這個要求真的不高，一點都不高，可能太低了…為什麼？因為信息安全這個領域太大了，大到什麼程度呢？大到做這個領域的人可能需要把幾乎計算機科學的所有領域全理解（注意，不是了解，是理解）以後，才能集大成，然後把這個領域做好。=============================1. 數學和計算機理論基礎要求信息安全中最理論的基礎是密碼學。密碼學誰提出來的？圖靈提出來的。為什麼是他提出的密碼學？因為密碼學的實現基礎是圖靈機，或者說是有限自動機原理。密碼學的理論基礎是抽象代數和資訊理論。想要比較深入的學習密碼學裡面的知識，至少要明白計算機領域的歸約（Rection），計算復雜性理論；至少要明白抽象代數裡面的群（Group）、環（Ring）、域（Field）；至少要了解資訊理論中信息熵的概念；這些如果不理解的話，安全證明估計就過不去了…要是追新，看看密碼學界的發展，起碼說提出一個名字能明白是什麼意思，估計得了解了解橢圓曲線（Elliptic Curve），雙線性對（Bilinear Pairing）或者多線性對（Multilinear Pairing），格（Lattice）等等。=============================2. 編程能力要求有人說了，我不用學密碼學理論，我能看懂論文，把方案實現了就行了啊。因為實現的方案從理論上是否安全，要考察參數的選擇。參數選擇的話，就得看懂安全性證明了。我個人只是做了Java Pairing-Based Cryptography Library（jPBC）的一些實現，幾乎時常會收到很多郵件，詢問這個庫怎麼用，為什麼自己實現的不對。多數情況都是因為對根上的東西沒理解，導致用起來不對。有人說了，我也不用看懂論文，我能寫最經典的密碼學演算法，能正確調用就好了。很遺憾，就算是最經典的密碼學演算法，即使是有經驗的開發人員，絕大多數都不能正確實現。僅以RSA為例，請移步我的專欄文章：RSA有多安全，有多不安全？Black Hat 2014 - The Matasano Crypto Challenges解析 - 第一部分 - 劉學酥的密碼學與信息安全專欄 - 知乎專欄看看裡面有多少坑吧。=============================3. 計算機相關技術能力要求有人說了，我不用寫密碼學演算法，我能正確用就行了。提到網路通信，就有計算機網路的相關知識了。我個人感覺計算機網路知識的復雜度現在和操作系統都差不多了。尤其是現在分布式系統，比如分布式計算和分布式存儲技術的普及，分布式計算機網路本身就構成了一個比操作系統還要復雜的總系統。做安全的話，沒有計算機網路和操作系統的知識幾乎只能做點皮毛工作。提到網路和操作系統，就會想到這本身就需要比較強的編程能力。舉個簡單的例子，Java優秀的網路通信框架Netty和MINA（感謝 @Edsger Lin 的指正，這里打錯了），是不是需要了解一下？HDFS，MapRece是不是了解一下？要不要看看源代碼… 來吧，這相關的資料、書籍，可以放滿一個書櫃了。=============================4. 網路安全技術要求有人說了，我也不用懂這些，我是做技術的，了解網路知識以後，找漏洞挖漏洞，直接走向人生巔峰！怎麼說呢，漏洞這個東西雖然知識本身要求的不深入，但是非常考驗廣度。比如資料庫的了解，網路得了解，各種Web語言得了解，裡面有什麼坑得了解。而且，很多時候漏洞檢測和網路滲透會涉及到語言本身上去。舉個例子，Black Hat 2014中有個視頻，所在的公司開發了一套漏洞檢測工具Ravage（為什麼我知道，我聽譯的…逆天漏洞檢測及滲透生成工具——RAVAGE課程詳情）。這個工具的製作已經深入到JVM的匯編層了。=============================5. 文檔能力和與人交流的能力信息安全領域，不光是技術層面的，還有人員層面的。軟體開發過程中出現的漏洞，絕大多數都是開發人員沒有遵守安全軟體開發要求而導致的。同時，各個公司、各個產品的安全架構，安全技術都不太一樣。這種時候，為了保證產品的安全特性，就需要文檔撰寫和閱讀能力，以及交流能力了。我和某位領域內人士交流的時候，總聽到一種抱怨：我靠，這安全機制不是瞎搞么，這怎麼評估，怎麼實現？很遺憾，互聯網發展太快了，很多東西都沒有模塊化體系化，現實就是這樣。想要解決這個問題，就需要一群在計算機各個領域內都精通，或者退一步，都了解的人，將各種安全技術和產品抽象，從而提出並設計架構。這樣才能提出一種比較通用的方法，從架構上去解決大部分的安全問題。不過這對一個人的要求可是有點高啊。安全又僅僅是技術問題嗎？非也。信息安全中，技術佔3成，管理佔7成。技術再好，密鑰管理不成熟，開發流程不成熟，訪問控制機制設計的不成熟，甚至私下交易，從內部泄露用戶隱私，也會導致嚴重的安全問題。這並不是聳人聽聞。CSDN密碼資料庫泄露可能僅僅是冰山一角。要我看，用戶的密碼早就被泄露光了… 當然現在已經好了很多。這就意味著，管理也是個很困難的問題。說到管理，交流能力也是必不可少的。=============================6. 其他能力信息安全和通信技術是密不可分的。通信技術的發展必然會導致信息安全技術的發展。舉例來說，枚舉法是最沒創意的攻擊方法了。但是現在有了高性能計算機，分布式計算機系統，對於幾年前的數據，用枚舉法可能反而比其他方法更快。另一個例子，量子計算領域現在蓬勃發展，沒准幾年，十幾年或者幾十年後量子計算機就普及了。這並不是不可能，想想計算機從剛出現到現在人手幾台一共花費了多長時間？那個時候，現有的體制全部推翻重來，作為安全人員就要更新自己的知識庫了。當然了，這個例子有點極端，量子計算機真的來了，所有計算機科學相關的從業人員就要洗牌了。總的來說，信息安全領域要求從業人員隨時學習，隨時更新知識庫。而且這種更新速度是依賴於計算機科學這門學科的發展而來的。2008年DDoS攻擊還沒影子呢，現在DDoS幾乎就是家常便飯了。網路的迅速發展，特別是後面雲計算雲存儲的發展，給安全從業人員又帶來了更多的問題。這必須要求從業人員隨時更新自己的知識，持之以恆的站在最前沿思考問題。=============================7. 有人能做到嗎？密碼學精通，可以到安全研究院。比如很多著名密碼學家，Gentry，Shoup什麼的就在IBM，進行全同態加密的理論研究和具體實現。而且，理解密碼學的人學其他方面也比較快。但是需要到領域內快速積累。編程能力強，計算機相關技術強，就可以不光做安全了。但安全領域絕對歡迎這樣的人才。網路安全技術能力強，可以到任何一家互聯網公司做安全。知乎上的幾位技術派大牛們，大多是這方面的佼佼者。文檔能力和與人交流的能力強，可以做安全咨詢。這是個比較有意思的領域。這個領域更需要廣泛了解安全的相關知識。不僅從技術角度，也要從管理角度。我自己只是在公鑰密碼學中的一個很小的領域有一點點很小的成績。因為計算機基礎知識不足，接下來的一年我估計要各種補基礎知識了，而且估計還補不完。上面說的這些對人才的需求，基本上只要精通一點，就是領域內的佼佼者了。所以，信息安全領域是一個集大成的領域。而且幾乎任何一個分領域對於領域內知識的要求，都高於本身的要求。因為基礎不夠的話，想做安全就有點痴人說夢了。=============================8. 回到主題：會飽和嗎？回到問題上面來，安全人才會達到飽和嗎？我認為有生之年能把上面說的起碼都做過一遍，幾乎都是不可能的。信息安全的人才要求很高。能力強，哪怕是一方面能力強，都可以從茫茫人海中脫穎而出。一個直接的體現就是信息安全周圍配套內容的普及。我在做Black Hat，包括密碼學一些視頻的聽譯時，就嘗試過讓別人幫忙聽寫，我來翻譯。結果，即使是專業聽譯人員，拿到這些視頻也都瞎了。因為專業詞彙太多，幾乎是中文都不知道什麼意思。Black Hat系列這么好，為什麼一直以來沒人做字幕，聽寫翻譯？因為確實對聽譯人員要求很高。我自己水平有限，只能聽譯密碼學、Java、以及部分資料庫、網路通信相關主題的Black Hat，而且也會遇到各種問題，遇到從來沒聽說過的技術、開源代碼、工具、或者思想。當然這個過程也是收獲的過程。所以，從高層看，信息安全人才應該一直會保持匱乏的狀態，等待新鮮血液的注入。另一方面，由於門檻太高，不少人會在門外徘徊。門外的人多了，飽和一詞也就來了。對於我自己，雖然得到了領域內人士的部分認可。但是，越往裡面走，越發現裡面的坑有多深。唯一的辦法就是不停的學習和更新知識。畢竟，學習要比提出新方法簡單多了，大家說對嗎？=============================9. 只有信息安全領域是這樣？就如同事物都是螺旋向上發展的一樣，正像其他回答說的那樣，任何領域都是：水平不高，哪裡都飽和；水平高了，哪裡都會要。什麼叫水平高，高到什麼程度就夠了？我認為沒有盡頭。一個領域，越是鑽研，越是往深了看，就越發現自己的渺小和無能。這會反過來導致更強的求知慾和更強的動力。等覺得自己小到只是一個沙子的時候，抬頭一看，可能就會明白，絕大多數人，可能連分子大小都沒到，但他們認為自己內部的原子和電子，就是整個世界。希望我們都能成為一粒沙子，看著大海的波濤洶涌，而毫無意識的，為這個世界的組成貢獻自己的一份力量。以上。

㈦ 分布式編程技術中事務的原子性是指Cristian和Berkley時間同步演算法的伺服器工+

摘要 定義：由一組操作構成的 可靠 、 獨立 的工作單元，要麼全部成功，要麼全部失敗

㈧ 誰有11年9月計算機2級JAVA筆試答案,最好是帶題目，[email protected]

2006年9月全國計算機等級考試二級Java程序設計筆試試卷
發布時間：2007-03-13 10:31:04 作者：極秀 極秀 字體選擇：

一、選擇題（每小題2 分，共70 分）
下列各題A）、B）、C）、D）四個選項中，只有一個選項是正確的，請將正確選項塗寫
在答題卡相應位置上，答在試卷上不得分。
（1）下列選項中不符合良好程序設計風格的是_____。
A）源程序要文檔化 B）數據說明的次序要規范化
C）避免濫用goto 語句 D）模塊設計要保證高耦合、高內聚
（2）從工程管理角度，軟體設計一般分為兩步完成，它們是_____。
A）概要設計與詳細設計 B）數據設計與介面設計
C）軟體結構設計與數據設計 D）過程設計與數據設計
（3）下列選項中不屬於軟體生命周期開發階段任務的是_____。
A）軟體測試 B）概要設計 C）軟體維護 D）詳細設計
（4）在資料庫系統中，用戶所見的數據模式為_____。
A）概念模式 B）外模式 C）內模式 D）物理模式
（5）資料庫設計的四個階段是：需求分析、概念設計、邏輯設計和_____。
A）編碼設計 B）測試階段 C）運行階段 D）物理設計
（6）設有如下三個關系表

下列操作中正確的是_____。
A）T R S = ∩ B）T R S = ∪
C）T R S = × D） / T R S =
（7）下列敘述中正確的是_____。
A）一個演算法的空間復雜度大，則其時間復雜度也必定大
B）一個演算法的空間復雜度大，則其時間復雜度必定不
C）一個演算法的時間復雜度大，則其空間復雜度必定小
D）上述三種說法都不對
（8）在長度為64 的有序線性表中進行順序查找，最壞情況下需要比較的次數為_____。
A）63 B）64 C）6 D）7
（9）資料庫技術的根本目標是要解決數據的_____。
A）存儲問題 B）共享問題 C）安全問題 D）保護問題
（10）對下列二叉樹

進行中序遍歷的結果是_____。
A）ACBDFEG B）ACBDFGE C）ABDCGEF D）FCADBEG
（11）進行Java 程序需要的工具軟體所在的目錄是_____。
A）JDK 的bin 目錄 B）JDK 的demo 目錄
C）JDK 的lib 目錄 D）JDKR 的jre 目錄
(12)下列關於JAVA 語言特點的敘述中,錯誤的是_____。
A）Java 是面向過程的編程語言
B）Java 支持分布式計算
C）Java 是跨平台的編程語言
D）Java 支持多線程
（13）Java 的核心包中，提供編程應用的基本類的包是_____。
A）Java.Jang B）Java.util C）Java.applet D）Java.rmi
（14）下列關於Java 對import 語句規定的敘述中，錯誤的是_____。
A）在Java 程序中import 語句可以有多個
B）在Java 程序中import 語句可以沒有
C）在Java 程序中import 語句必須有一個
D）在Java 程序中import 語句必須引入在所有類定義之前
（15）在編譯Java 程序時，用於指定生成class 文件位置的選項是_____。
A）-g B）-d C）-verbose D）-nowarn
（16）閱讀下面程序
import java.io.*;
public class TypeTransition{
public static void main(String args[]){
char a = 『h』;
int i=100;
int j=97;
int aa=a+i;
System.out.println(「aa=」+aa);
Char bb=(char)j;
System.out.println(「bb=」+bb);
}
}
如果輸出結果的第二行為bb=a，那麼第一行的輸出是_____。
A）aa=1 B）aa=204 C）aa=v D）aa=156
（17）閱讀下面程序
public class OperatorsAndExpressions{
void equalsMethodl(){
String s1=new String(「how are you」)
String s2=new String(「how are you」)
System.out.println(s1=s2)
}
public static void main(String args[]){
OperatorsAndExpressions OperAndExp=new OperatorsAndExpressions();
//用於復合類型數據的「= =」運算符
OperAndExp.equalsMethod1();
}
}
程序運行結果是_____。
A）== B）true C）false D）equal
（18）閱讀下面代碼
if(x==0)
else if(x>-3)
else
若要求列印字元串「季軍」，則變數x 的取值范圍是_____。
A）x=0&x<=-3 B）x>0 C）x>-3 D）x<=-3
（19）下列關於構造方法的敘述中，錯誤的是_____。
A）Java 語言規定構造方法名與類名必須相同
B）Java 語言規定構造方法沒有返回值，但不用void 聲明
C）Java 語言規定構造方法不可以重載
D）Java 語言規定構造方法只能通過new 自動調用
（20）閱讀下面程序
import javax.swing.JOptionPane;
public class Comparison{
public static void main(String args[]){
String firstNumber, //用戶輸入第1 個數據變數
secondNumber, //用戶輸入第2 個數據變數
result; //輸出結果變數
int number1, //用於比較的第1 個數
number2; //用於比較的第2 個數
//用戶輸入第1 個數據的字元串
firstNumber=JOptionPane.showInputDialob(「輸入第1 個整數:」);
//用戶輸入第2 個數據的字元串
secondNumber=JOptionPane.showInputDialog(「輸入第2 個整數:」);
//將字元串轉換為整數類型
number1=Integer.parseInt(firstNumber);
number2=Integer.parseInt(secondNumber);
//初始化結果變數
；
//比較兩個數據
if(number1=number2)
result+=number1+ 「==」+number2;
if(number1!=number2)
result+=number1+ 「!=」+number2;
if(number1 <number2)
result=result+ 「n」+number1+ 「<」 +number2;
if(number1>number2)
result=result+ 「\n」+number1+ 「>」 +number2;
if(number1<=number2)
result=result+ 「\n」+number1+ 「<=」 +number2;
if(number1>=number2)
result=result+ 「\n」+number1+ 「>=」 +number2;
//顯示結果
JOptionPane.showMessageDialog(null.result, 「比較結果」,
JOptionPane.INFORMATION MESSAGE);
System.exit( 0 );
}
}
為使程序能正確運行並得到合理的輸出結果，初始化結果變數語句（下劃線處）應是
A）result=」」 B）result=null
C）result=number1 D）result=number2
（21）閱讀下面程序
public class Increment{
public static void main(String args[]{
int c;
c=5;
System.out.println(c);
System.out. println(c++);
System.out.println(c);
}
}
程序運行結果是_____。
A）5
6
6
B）5
5
6
C）6
7
7
D）6
6
6
（22）下列敘述中，錯誤的是_____。
A）JavaApplication 與Applet 所用編譯命令相同
B）通常情況下Java Application 只能有一個main()方法
C）JavaApplet 必須有HTML 文件才能運行
D）JavaApplet 程序的.class 文件可用java 命令運行
（23）下列關於Java 語言中線程的敘述中，正確的是_____。
A）線程是由代碼、數據、內核狀態和一組寄存器組成
B）線程間的數據是不共享的
C）用戶只能通過創建Thread 類的實例或定義，創建Thread 子類的實例建立和控制
自己的線程
D）因多線程並發執行而引起的執行順序的不同定性可能造成執行結果的不穩定
（24）閱讀下面程序_____。
import javax.swing.JOptionPang;
public class BreakLabelTest{
publicstatic void main(String args[]){
String output=」」 ;
stop:{
for(int row=1;row<=10;row++){
for(int column=1;column<=5;column++){
if(row==5)
break stop;
output+=」」;
}
output += 「n」;
}
output+= 「\nLoops terminated normally」;
}
JOptionPane.showMessageDialog(
Null,output, 「用一個標志測試break 語句」,
JOptionPane.INFORMATION_MESSAGE);
System.exit( 0 );
}
}
程序運行結果是
A）窗口中有5 行·····
B）窗口中有5 行····
C）窗口中有4 行·····
D）窗口中有6 行·····
（25）處理對象傳輸的介面是_____。
A）Serializable B）Cloneable C）ItemListener D）ActionListener
（26）在讀取二進制數據文件的記錄時，為了提高效率常常使用一種輔助類_____。
A）InputStream B）FileInputStream C）StringBuffer D）BufferedReader
（27）可以使當前同級線程重新獲得運行機會的方法是_____。
A）sleep() B）join() C）yield() D）interrupt()
（28）閱讀下面程序
1 public class Try extends Thread{
2 Public static void main (String args[]){
3 Try t = new Try();
4 t.start( );
5 }
6
7 Public void run(int j) {
8 int i=0;
9 while(i<5){
10 System.out.println(「祝你成功！」);
11 i++;
12 }
13 }
14 }
該程序要求列印5 行「祝你成功！」，必須改正程序中的某行代碼，程序才能完成，選擇正
確的修改是_____。
A）將第1 行的extends Thread 改為implements Runnable
B）將第3 行的new Try()改為new Thread()
C）將第4 行t.start()改為start(t)
D）將第7 行的public void run( int j)改為public void run()
（29）下列事件監聽器中，無法對TextField 對象進行事件監聽和處理的是_____。
A）ActionListener B）cuslistener
C）MouseMotionListener D）ChangeListener
（30）Swing 的選項面板是_____。
A）JTabbedPane B）JLayeredpane C）JScrollPane D）JSplitPane
（31）每個Java 小應用程序必須定義為_____。
A）Applet 類或JApplet 類的子類 B）JFrame 類的子類
C）Frame 的子類 D）Window 的子類
（32）在Applet 的init()方法被調用後，接下來最先調用的方法是_____。
A）run() B）start() C）stop() D）destroy()
（33）下列關於Applet 的安全限制的敘棕中，錯誤的是_____。
A）通常情況下，禁止Applet 讀，寫本地文件系統
B）通常情況下，禁止Applet 讀Applet 源主機之外的任何主機建立網路連接
C）通常情況下，禁止Applet 讀取系統信息
D）通常情況下，禁止Applet 載入本地庫或方法
（34）下列標識符（名字）命名原則中，正確的是_____。
A）類名的首字母小寫 B）變數和方法名的首字母大寫
C）介面名的首字母小寫 D）常量完全大寫
（35）提供showDocument()方法，使Applet 能夠請求瀏覽器訪問特定URL 的類是
A）Applet B）AppletContext C）JApplet D）URL
二、填空題（每空2 分，共30 分）
請將每一個空的正確答案寫在答題卡[1]-[15]序號的橫線上，答在試卷上不得分。注意：
以命令關鍵字填空的必須拼寫完整。
（1）下列軟體系統結構圖

的寬度為 [1] 。
（2） [2] 的任務是診斷和改正程序中的錯誤。
（3）一個關系表的行稱為 [3] 。
（4）按「先進後出」原則組織根據的數據結構是 [4] 。
（5）數據結構分為線性結構和非線性結構，帶鏈的隊列屬於 [5] 。
（6）若想在程序中使用JLabel 類，則該程序可以使用import [6] JLabel；語句引入JLabel
類。
（7）在Java 中，3.14156D 表示的是 [7] 。
（8）閱讀下列代碼
public class Test2{
public static voidm cn(String args[]){
System.out.println(5/2);}
}
其執行結果是 [8]
（9）閱讀下列代碼段
int x=3;
while (x<9)
x+=2;
x++;
while 語句成功執行的次數是 [9] 。
（10）Java 不直接支持多繼承，但可以通過 [10] 實現多繼承。
（11）在下列程序的下劃線處，填入適當語句使程序能正確執行並輸出異常棧信息。
Public class ThrowableException{
Public static void main(String args[]){
try{
throw new Throwable(「這里是本人定義的異常」);
{catch(Throwable e){
System.out.println(「Caught Throwable」);
System.out.println(「e.getMessage():」+e.getMessage());
System.out.println(「e.toString():」+e.toString());
System.out.printin(「e.printStackTrace():」);
[11] ;}}}
（12）在java.io 包中有某個類同時實現了Datainput 介面和DataOutput 介面，這個類是
[12] 。
（13）在Java 程序中，主線程一般具有 [13] 優先順序。
（14）當實現Runnable 介面時，要實現的方法是 [14] 。
（15）mouseDragged()方法是MouseMotionListener 介面中的抽象方法，該方法的參數是
[15] 類。

㈨ gfs採用了哪些容錯措施來確保整個系統的可靠性

GFS的精彩在於它採用了多種方法，從多個角度，使用不同的容錯措施來確保整個系統的可靠性。
2.1.1 系統架構
GFS的系統架構如圖2-1[1]所示。GFS將整個系統的節點分為三類角色：Client（客戶端）、Master（主伺服器）和Chunk Server（數據塊伺服器）。Client是GFS提供給應用程序的訪問介面，它是一組專用介面，不遵守POSIX規范，以庫文件的形式提供。應用程序直接調用這些庫函數，並與該庫鏈接在一起。Master是GFS的管理節點，在邏輯上只有一個，它保存系統的元數據，負責整個文件系統的管理，是GFS文件系統中的「大腦」。Chunk Server負責具體的存儲工作。數據以文件的形式存儲在Chunk Server上，Chunk Server的個數可以有多個，它的數目直接決定了GFS的規模。GFS將文件按照固定大小進行分塊，默認是64MB，每一塊稱為一個Chunk（數據塊），每個Chunk都有一個對應的索引號（Index）。

客戶端在訪問GFS時，首先訪問Master節點，獲取將要與之進行交互的Chunk Server信息，然後直接訪問這些Chunk Server完成數據存取。GFS的這種設計方法實現了控制流和數據流的分離。Client與Master之間只有控制流，而無數據流，這樣就極大地降低了Master的負載，使之不成為系統性能的一個瓶頸。Client與Chunk Server之間直接傳輸數據流，同時由於文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使得整個系統的I/O高度並行，系統整體性能得到提高。

相對於傳統的分布式文件系統，GFS針對Google應用的特點從多個方面進行了簡化，從而在一定規模下達到成本、可靠性和性能的最佳平衡。具體來說，它具有以下幾個特點。
1．採用中心伺服器模式
GFS採用中心伺服器模式來管理整個文件系統，可以大大簡化設計，從而降低實現難度。Master管理了分布式文件系統中的所有元數據。文件劃分為Chunk進行存儲，對於Master來說，每個Chunk Server只是一個存儲空間。Client發起的所有操作都需要先通過Master才能執行。這樣做有許多好處，增加新的Chunk Server是一件十分容易的事情，Chunk Server只需要注冊到Master上即可，Chunk Server之間無任何關系。如果採用完全對等的、無中心的模式，那麼如何將Chunk Server的更新信息通知到每一個Chunk Server，會是設計的一個難點，而這也將在一定程度上影響系統的擴展性。Master維護了一個統一的命名空間，同時掌握整個系統內Chunk Server的情況，據此可以實現整個系統范圍內數據存儲的負載均衡。由於只有一個中心伺服器，元數據的一致性問題自然解決。當然，中心伺服器模式也帶來一些固有的缺點，比如極易成為整個系統的瓶頸等。GFS採用多種機制來避免Master成為系統性能和可靠性上的瓶頸，如盡量控制元數據的規模、對Master進行遠程備份、控制信息和數據分流等。
2．不緩存數據
緩存（Cache）機制是提升文件系統性能的一個重要手段，通用文件系統為了提高性能，一般需要實現復雜的緩存機制。GFS文件系統根據應用的特點，沒有實現緩存，這是從必要性和可行性兩方面考慮的。從必要性上講，客戶端大部分是流式順序讀寫，並不存在大量的重復讀寫，緩存這部分數據對系統整體性能的提高作用不大；而對於Chunk Server，由於GFS的數據在Chunk Server上以文件的形式存儲，如果對某塊數據讀取頻繁，本地的文件系統自然會將其緩存。從可行性上講，如何維護緩存與實際數據之間的一致性是一個極其復雜的問題，在GFS中各個Chunk Server的穩定性都無法確保，加之網路等多種不確定因素，一致性問題尤為復雜。此外由於讀取的數據量巨大，以當前的內存容量無法完全緩存。對於存儲在Master中的元數據，GFS採取了緩存策略，GFS中Client發起的所有操作都需要先經過Master。Master需要對其元數據進行頻繁操作，為了提高操作的效率，Master的元數據都是直接保存在內存中進行操作。同時採用相應的壓縮機制降低元數據佔用空間的大小，提高內存的利用率。
3．在用戶態下實現
文件系統作為操作系統的重要組成部分，其實現通常位於操作系統底層。以Linux為例，無論是本地文件系統如Ext3文件系統，還是分布式文件系統如Lustre等，都是在內核態實現的。在內核態實現文件系統，可以更好地和操作系統本身結合，向上提供兼容的POSIX介面。然而，GFS卻選擇在用戶態下實現，主要基於以下考慮。
在用戶態下實現，直接利用操作系統提供的POSIX編程介面就可以存取數據，無需了解操作系統的內部實現機制和介面，從而降低了實現的難度，並提高了通用性。


POSIX介面提供的功能更為豐富，在實現過程中可以利用更多的特性，而不像內核編程那樣受限。
用戶態下有多種調試工具，而在內核態中調試相對比較困難。
用戶態下，Master和Chunk Server都以進程的方式運行，單個進程不會影響到整個操作系統，從而可以對其進行充分優化。在內核態下，如果不能很 好地掌握其特性，效率不但不會高，甚至還會影響到整個系統運行的穩定性。
用戶態下，GFS和操作系統運行在不同的空間，兩者耦合性降低，從而方便GFS自身和內核的單獨升級。


4．只提供專用介面
通常的分布式文件系統一般都會提供一組與POSIX規范兼容的介面。其優點是應用程序可以通過操作系統的統一介面來透明地訪問文件系統，而不需要重新編譯程序。GFS在設計之初，是完全面向Google的應用的，採用了專用的文件系統訪問介面。介面以庫文件的形式提供，應用程序與庫文件一起編譯，Google應用程序在代碼中通過調用這些庫文件的API，完成對GFS文件系統的訪問。採用專用介面有以下好處。


降低了實現的難度。通常與POSIX兼容的介面需要在操作系統內核一級實現，而GFS是在應用層實現的。
採用專用介面可以根據應用的特點對應用提供一些特殊支持，如支持多個文件並發追加的介面等。
專用介面直接和Client、Master、Chunk Server交互，減少了操作系統之間上下文的切換，降低了復雜度，提高了效率。