#
AngularJS 是一個 Web 應用框架，它實現了前端的 MVC 架構，能讓開發人員很方便地實現業務邏輯。
舉個栗子，要做到下面的效果，以前可能需要寫一連串的 JavaScript 代碼綁定 N 多事件。而使用 AngularJS 框架，一句 JavaScript 都不用寫就能實現了，神奇吧？查看演示。
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script> <div data-ng-app> 單價： <input type="number" min=0 ng-model="price" ng-init="price = 299"> <br> 數量： <input type="number" min=0 ng-model="quantity" ng-init="quantity = 1"> <br> 總價： {{ quantity * price }} </div> |
這得益于 AngularJS 中的雙向數據綁定特性(Two Way Data-Binding)，將 Model 和 View 自動關聯了起來，在更復雜的業務場景下，還有代碼分離的好處，將 DOM 操作和應用邏輯解耦，非常實用。
不過沒有銀彈，和其他框架一樣，AngularJS 也有它的局限。CRUD 類型的操作是它所擅長的，想想看以前寫過的管理后臺，幾乎大部分都是從數據庫中讀取數據，然后呈現在頁面上，進行各種增刪改查。AngularJS 約定了一套規范（約定優于配置），于是你可以很便捷地操作數據。而在其他方面，例如開發復雜的 Web 游戲，AngularJS 則是無用武之地了。
一、AngularJS 中的精美特性
雙向綁定
上面的例子已經說明了，我們可以像 PHP Smarty 模板一樣在 HTML 中寫表達式，用 {{ 和 }} 包起來。在 AngularJS 里，View 和 Model 是在 Controller 里面綁定的，所以無論你在 View 的表單中修改了內容，還是在 Controller 里通過代碼修改了 Model 值，兩邊都會即時發生變化，同步更新。因為 AngularJS 會監控 （watch） Model 對象的變化，隨時反映到 View 中。
Filter
Filter 類似 Unix 里面的 | 管道概念，AngularJS 把它搬到了前端。還是舉個例子，你們感受一下——
<div>{{ 9999 | number }}</div> <div>{{ 9999+1 | number:2 }}</div> <div>{{ 9*9 | currency }}</div> <div>{{ 'Hello World' | uppercase }}</div> |
輸出結果：
9,999 10,000.00 $81.00 HELLO WORLD
二、AngularJS 中的一些“坑”
由于過去寫 JavaScript 的習慣使然，人們很容易掉進一些 AngularJS 的陷阱里。下面的內容假設你已經了解前端 MVC 概念，并對 AngularJS 有了一定經驗，初學者讀起來可能比較艱深晦澀。
DOM 操作
避免使用 jQuery 來操作 DOM，包括增加元素節點，移除元素節點，獲取元素內容，隱藏或顯示元素。你應該使用 directives 來實現這些動作，有必要的話你還要編寫自己的 directives。
如果你感到很難改變習慣，那么考慮從你的網頁中移除 jQuery 吧。真的，AngularJS 中的 $http 服務非常強大，基本可以替代 jQuery 的 ajax 函數，而且 AngularJS 內嵌了 jQLite —— 它內部實現的一個 jQuery 子集，包含了常用的 jQuery DOM 操作方法，事件綁定等等。但這并不是說用了AngularJS 就不能用 jQuery 了。如果你的網頁有載入 jQuery 那么 AngularJS 會優先采用你的 jQuery，否則它會 fall back 到 jQLite。
需要自己編寫 directives 的情況通常是當你使用了第三方的 jQuery 插件。因為插件在 AngularJS 之外對表單值進行更改，并不能即時反應到 Model 中。例如我們用得比較多的 jQueryUI datepicker 插件，當你選中一個日期后，插件會將日期字符串填到 input 輸入框中。View 改變了，卻并沒有更新 Model，因為$('.datepicker').datepicker(); 這段代碼不屬于 AngularJS 的管理范圍。我們需要編寫一個directive 來讓 DOM 的改變即時更新到 Model 里。
var directives = angular.module('directives', []); directives.directive('datepicker', function() { return function(scope, element, attrs) { element.datepicker({ inline: true, dateFormat: 'dd.mm.yy', onSelect: function(dateText) { var modelPath = $(this).attr('ng-model'); putObject(modelPath, scope, dateText); scope.$apply(); } }); } }); |
然后在 HTML 中引入這個 direcitve
<input type="text" datepicker ng-model="myObject.myDateValue" /> |
說白了 directive 就是在 HTML 里寫自定義的標簽屬性，達到插件的作用。這種聲明式的語法擴展了 HTML。
需要說明的是，有一個 AngularUI 項目提供了大量的 directive 給我們使用，包括 Bootstrap 框架中的插件以及基于 jQuery 的其他很熱門的 UI 組件。我之前說過 AngularJS 的社區很活躍嘛，生態系統健全。
ngOption 中的 value
這是個大坑。如果你去查看 ngOption 生成的 <select> 中的 <option> 的選項值（每個 <option value="xxx"> 的 value 部分），那絕對是枉費心機。因為這里的值永遠都會是 AngularJS 內部元素的索引，并不是你所指定的表單選項值。
還是要轉變觀念，AngularJS 已經不再用表單進行數據交互了，而是用 Model。使用 $http 來提交 Model，在 php 中則使用 file_get_contents('php://input') 來獲取前端提交的數據。
{{ }} 的問題
在頁面初始化的時候，用戶可能會看到 {{ }}，然后閃爍一下才出現真正的內容。
解決辦法：
- 使用 ng-cloak directive 來隱藏它
- 使用 ng-bind 替代 {{ }}
將界面與業務邏輯分離
Controller 不應該直接引用 DOM，而應該控制 view 的行為。例如“如果用戶操作了 X，應該發生什么事情”，“我從哪里可以獲得 X？”
Service 在大部分情況下也不應該直接引用 DOM，它應該是一個單例（singletons），獨立于界面，與 view 的邏輯無關。它的角色只是“做 X 操作”。
DOM 操作應該放在 directives 里面。
盡量復用已有功能
你所寫的功能很可能 AngularJS 已經實現了，有一些代碼是可以抽象出來復用的，使用更 Angular 的方式。總之就是很多 jQuery 的繁瑣代碼可以被替代。
1. ng-repeat
ng-repeat 很有用。當 Ajax 從服務器獲得數據后，我們經常使用 jQuery （比如上面講過的例子） 向某些 HTML 容器節點中添加更多的元素，這在 AngularJS 里是不好的做法。有了 ng-repeat 一切就變得非常簡單了。在你的 $scope 中定義一個數組 （model） 來保存從服務器拉取的數據，然后使用 ng-repeat 將它與 DOM 綁定即可。下面的例子初始化定義了 friends 這個 model
<div ng-init="friends = [{name:'John', age:25}, {name:'Mary', age:28}]"> I have {{friends.length}} friends. They are: <ul> <li ng-repeat="friend in friends"> [{{$index + 1}}] {{friend.name}} who is {{friend.age}} years old. </li> </ul> </div> |
顯示結果
I have 2 friends. They are: [1] John who is 25 years old. [2] Mary who is 28 years old.
2. ng-show
ng-show 也很有用。使用 jQuery 來根據條件控制界面元素的顯示隱藏，這很常見。但是 Angular 有更好的方式來做到這一點。ng-show （以及 ng-hide） 可以根據布爾表達式來決定隱藏和顯示。在 $scope 中定義一個變量：
<div ng-show="!loggedIn"> 點擊 <a href="#/login">這里</a> 登錄 </div> |
類似的內置 directives 還有 ng-disabled， ng-switch 等等，用于條件控制，語法簡潔，都很強大。
3. ng-class
ng-class 用于條件性地給元素添加 class，以前我們也經常用 jQuery 來實現。Angular 中的 ng-class 當然更好用了，例子：
<div ng-class="{ errorClass: isError, warningClass: isWarning, okClass: !isError && !isWarning }">...</div> |
在這里 ng-class 接受一個 object 對象，key 為 CSS class 名，值為 $scope 變量控制的條件表達式，其他類似的內置 directives 還有 ng-class-even 和 ng-class-odd，很實用。
$watch 和 $apply
AngularJS 的雙向數據綁定是最令人興奮的特性了，然而它也不是全能的魔法，在某些情況下你需要做一些小小的修正。
當你使用 ng-model， ng-repeat 等等來綁定一個元素的值時， AngularJS 為那個值創建了一個 $watch，只要這個值在 AngularJS 的范圍內有任何改變，所有的地方都會同步更新。而你在寫自定義的 directive 時，你需要定義你自己的 $watch 來實現這種自動同步。
有時候你在代碼中改變了 model 的值，view 卻沒有更新，這在自定義事件綁定中經常遇到。這時你就需要手動調用 scope.$apply() 來觸發界面更新。上面 datepicker 的例子已經說明了這一點。第三方插件可能會有 call back，我們也可以把回調函數寫成匿名函數作為參數傳入$apply()中。
將 ng-repeat 和其他 directives 結合起來
ng-repeat 很有用，不過它和 DOM 綁定了，很難在同一個元素上使用其他 directives （比如 ng-show， ng-controller 等等）。
如果你想對整個循環使用某個 directive，你可以在 repeat 外再包一層父元素把 directive 寫在那兒；如果你想對循環內部的每一個元素使用某個 directive，那么把它放到 ng-repeat 的一個子節點上即可。
Scope
Scope 在 templates 模板中應該是 read-only 的，而在 controller 里應該是 write-only 的。Scope 的目的是引用 model，而不是成為 model。model 就是我們定義的 JavaScript 對象。
$rootScope 是可以用的，不過很可能被濫用
Scopes 在 AngularJS 中形成一定的層級關系，樹狀結構必然有一個根節點。通常我們用不到它，因為幾乎每個 view 都有一個 controller 以及相對應的自己的 scope。
但偶爾有一些數據我們希望全局應用在整個 app 中，這時我們可以將數據注入 $rootScope。因為其他 scope 都會繼承 root scope，所以那些注入的數據對于 ng-show 這類 directive 都是可用的，就像是在本地 $scope 中的變量一樣。
當然，全局變量是邪惡的，你必須很小心地使用 $rootScope。特別是不要用于代碼，而僅僅用于注入數據。如果你非常希望在 $rootScope 寫一個函數，那最好把它寫到 service 里，這樣只有用到的時候它才會被注入，測試起來也方便些。
相反，如果一個函數的功能僅僅是存儲和返回一些數據，就不要把它創建成一個 service。
三、AngularJS 項目的目錄結構
怎樣組織代碼文件和目錄？這恐怕是初學者一開始就會遇到的問題。AngularJS 應用開發的官方入門項目angular-seed，其文件結構是這樣的：
- css/
- img/
- js/
- app.js
- controllers.js
- directives.js
- filters.js
- services.js
- lib/
- partials/
這種結構對于一個簡單的單頁 app 來說是可行的，只是一旦代碼中存在多個 Controller 或者 Service，就很難找到想要尋找的對象了。我們可以對文件按照業務邏輯進行拆分，就像下面這樣：
- controllers/
- LoginController.js
- RegistrationController.js
- ProductDetailController.js
- SearchResultsController.js
- directives.js
- filters.js
- models/
- CartModel.js
- ProductModel.js
- SearchResultsModel.js
- UserModel.js
- services/
- CartService.js
- UserService.js
- ProductService.js
這種結構把不同的業務功能拆分為獨立的文件，條理清晰，但是仍有一定的局限性。最大的問題是一個業務功能的代碼分布在controllers, models, servers 三個不同目錄下，要從中挑出正確的文件，建立起代碼關聯，還是有些麻煩。按照功能進行模塊化劃分目錄結構，應該要更為合理一些：
- cart/
- CartModel.js
- CartService.js
- common/
- product/
- search/
- SearchResultsController.js
- SearchResultsModel.js
- ProductDetailController.js
- ProductModel.js
- ProductService.js
- user/
- LoginController.js
- RegistrationController.js
- UserModel.js
- UserService.js
這樣也是適合 RequireJS 等模塊加載器的自然直觀的代碼組織方式。
參考鏈接：
摘要: Apache Camel是一個非常實用的規則引擎庫，能夠用來處理來自于不同源的事件和信息。你可以在使用不同的協議比如VM，HTTP，FTP，JMS甚至是文件系統中來傳遞消息，并且讓你的操作邏輯和傳遞邏輯保持分離，這能夠讓你更專注于消息的內容。在這篇文章中，我將提供一個Java語言（非Groovy）的Apache Camel入門演示。首先創建一個Maven項目的pom.xml。<?xml&nb...
閱讀全文
Ctrl+1 快速修復(最經典的快捷鍵,就不用多說了)
Ctrl+D: 刪除當前行
Ctrl+Alt+↓ 復制當前行到下一行(復制增加)
Ctrl+Alt+↑ 復制當前行到上一行(復制增加)
Alt+↓ 當前行和下面一行交互位置(特別實用,可以省去先剪切,再粘貼了)
Alt+↑ 當前行和上面一行交互位置(同上)
Alt+← 前一個編輯的頁面
Alt+→ 下一個編輯的頁面(當然是針對上面那條來說了)
Alt+Enter 顯示當前選擇資源(工程,or 文件 or文件)的屬性
Shift+Enter 在當前行的下一行插入空行(這時鼠標可以在當前行的任一位置,不一定是最后)
Shift+Ctrl+Enter 在當前行插入空行(原理同上條)
Ctrl+Q 定位到最后編輯的地方
Ctrl+L 定位在某行 (對于程序超過100的人就有福音了)
Ctrl+M 最大化當前的Edit或View (再按則反之)
Ctrl+/ 注釋當前行,再按則取消注釋
Ctrl+O 快速顯示 OutLine
Ctrl+T 快速顯示當前類的繼承結構
Ctrl+W 關閉當前Editer
Ctrl+K 參照選中的Word快速定位到下一個
Ctrl+E 快速顯示當前Editer的下拉列表(如果當前頁面沒有顯示的用黑體表示)
Ctrl+/(小鍵盤) 折疊當前類中的所有代碼
Ctrl+×(小鍵盤) 展開當前類中的所有代碼
Ctrl+Space 代碼助手完成一些代碼的插入(但一般和輸入法有沖突,可以修改輸入法的熱鍵,也可以暫用Alt+/來代替)
Ctrl+Shift+E 顯示管理當前打開的所有的View的管理器(可以選擇關閉,激活等操作)
Ctrl+J 正向增量查找(按下Ctrl+J后,你所輸入的每個字母編輯器都提供快速匹配定位到某個單詞,如果沒有,則在stutes line中顯示沒有找到了,查一個單詞時,特別實用,這個功能Idea兩年前就有了)
Ctrl+Shift+J 反向增量查找(和上條相同,只不過是從后往前查)
Ctrl+Shift+F4 關閉所有打開的Editer
Ctrl+Shift+X 把當前選中的文本全部變味小寫
Ctrl+Shift+Y 把當前選中的文本全部變為小寫
Ctrl+Shift+F 格式化當前代碼
Ctrl+Shift+P 定位到對于的匹配符(譬如{}) (從前面定位后面時,光標要在匹配符里面,后面到前面,則反之)
最近接項目要求，要在svn主干上創建分支，用分支來進行程序的bug修改，而主干上進行新功能的開發。分支上的bug修改完，發布后，可以合并到主干上。項目程序可以在主干和分支之間進行切換，來實現主干和分支的同時維護。
1.創建分支
創建分支實際上就是將程序copy一份到指定的分支目錄，如下圖示：
在項目名稱上點擊右鍵，彈出菜單，選擇“Team”，再選擇“Branch/Tag”，彈出下面的頁面：
上圖中的“Copy to URL”填寫創建新分支的路徑地址，后面會將程序copy到該目錄下，形成新的分支。點擊“Next”:
選擇當前最新的版本，點擊“Next”
如果勾選了上圖下面的switch working copy to new branch/tag，eclipse的程序項目會自動切換到分支下。這里我們不選擇，待會自己切換。
這樣就創建了一個1.0的分支
2.合并
可以從主干合并到分支，也可以從分支合并到主干，根據需要可以選擇合適的選項，如下圖：
上圖中的選項：
1) 從主干合并到分支
2) 從分支合并到主干
3) 將主干上的修改合并到分支
4) 合并2個分支到主干
5) 從主干到分支，手工指定不需要合并的修改
6) 從主干到分支，手工指定要合并的修改
上圖顯示沒有任何修改，所以不用進行合并。
3.切換
在項目名稱上點擊右鍵，選擇“Team” –> “switch to another Branch/Tag/Revision”。
選擇需要切換的目的地址，點擊ok即可。
這樣，在項目里就可以在主干和若干分支間進行任意切換，來實現對不同版本/分支的程序進行修改提交操作。
參考：
Overview of CollabNet Merge Client
https://desktop-eclipse.open.collab.net/servlets/ProjectProcess?pageID=MEuUjb&freeformpage=Merge%20Client
eclipse中將SVN分支合并到主干的方法
http://www.darrenfang.com/merge-branches-to-trunk-in-eclipse.html
世界杯（FIFA World Cup）即國際足聯世界杯，是世界上最高榮譽、最高規格、最高水平、最高含金量、最高知名度的足球比賽，與奧運會并稱為全球體育兩大最頂級賽事，甚至是轉播覆蓋率超過奧運會的全球最大體育盛事。
本屆世界杯由巴西舉辦，時間：6月13日至7月4日，為(shua)期(ping)一個月。五次奪冠的巴西向著第六顆星進擊，據說集齊七顆星即可召喚出神龍，五星天朝方顯高瞻遠矚，美帝星條旗表示你們統統弱爆了。
這是一個激情澎湃的時刻
這是一個心潮涌動的瞬間
但又是一個bī格漫天的年代
別問我怎么梅西轉會去了阿根廷
別問我為什么世界杯只有32只球隊
也別問我為什么喬丹沒有入選美國大名單
更別問我為什么沒有中國隊，這TM2018年世界杯預選賽都還沒開始呢
說到這里，我想我有必要先向大家普及一下本次本次杯賽的相關情況
首先是本次杯賽的32強賽程安排：
那么，稍后我將逐一為大家介紹各個參賽隊做一個民間分析。
既然是盛宴，其實我們大家都心知“肚”明，大部分球迷都是去……
那么，作為一個有素質，有教養的攻略，我不得不提醒大家：
看球第一，猛吃第二；
美食再美，且吃且珍；
體型若重，心寒……心寒……寒……
謹慎起見，請各位女性觀眾仔細閱讀如下注意事項！！！
注意事項：本屆世界杯沒有貝克漢姆也沒有卡卡，更沒有巴薩和皇馬，來自地球的韓國隊也沒有李敏鎬和都敏俊。
那么，請各位系好身邊的安全帶，我們即將起航。
五星巴西永遠是奪冠熱門，這次加上天時地利人和，他們擁有最大的機會奪取巴西世界杯，也承受著最大的關注和最大的壓力。
直接晉級世界杯缺乏強對抗的比賽沒有阻礙他們的前進，聯合會杯出色的發揮讓人眼前一亮，最后讓西班牙恥辱性的輸掉了決賽。他們在比賽中顯示出的凝聚力讓人驚嘆不已。斯科拉里的執教能力毋庸置疑，他奪取世界杯的經驗將對這支年輕的巴西給予很大的幫助。在關鍵位置的陣容深度不亞于德國，他們是世界杯上所有球隊都希望擊敗的對手。
別忘了他們還有最火熱的球迷！
德國隊的陣容深度讓人感覺十分可怕，即使有幾個人受傷完全不影響球隊的整體實力，特別是赫迪拉令人惋惜的傷病，如果是其他國家，那么這樣一名有實力的球員受傷的確會給教練帶來很大的苦惱，特別是在世界杯之前，而對于德國來說，找到同樣實力的球員似乎不是問題。赫迪拉的受傷給了本德兄弟很大的機會，而且他兩也完全有能力填補他的缺席，京多安，克洛斯也能打拖后組織核心。如果穆勒和格策受傷，他們還有羅伊斯，德拉克斯勒和波多爾斯基頂上。
整支球隊的能力，陣容深度只會給勒夫帶來幸福的煩惱，最后帶哪11個人上場估計是勒夫頭疼的問題。
他們應該是四支最有希望奪得大力神杯的球隊，如果低于四強的成績，那么德國人一定不會滿意的。紀錄不會說謊，36年來德國隊從未跌出8強，世界杯是他們明年唯一的目標。
PS：為什么世界杯不跟助攻王發一個類似金靴獎的東東！
西班牙作為衛冕冠軍，理應是奪冠大熱門，已經連續獲得了三屆大賽的冠軍(不算聯合會杯)。西班牙不缺球星，不缺頂級球員，不缺經驗，不缺信心，他們有可能成為巴西之后第二個連續兩屆獲得世界杯冠軍的國家。不過鋒無力的情況是否會被迭戈科斯塔的加盟改變呢？催眠戰術是否會有改變？低迷的伊涅斯塔和老去的哈維還能創造奇跡么？德國和巴西的強勢會是他們奪冠的最大敵人。
如果阿根廷在巴西奪世界杯，那估計全巴西人都要瘋了。
即使沒有煤球王，阿根廷的陣容在紙面上也不錯，狀態火熱的阿圭羅，拉維奇和迪瑪利亞的攻擊前場能夠給球隊提供足夠的火力，不過不可否認的是自從1990年以來，阿根廷都是讓球迷心碎的那支球隊。
8強應該是他們最低的目標，過去四屆世界杯他們有三次完成了這個目標。不過煤球王的榮譽簿上還缺一個大力神杯，布拉特打臉的發言是否會在世界杯幫煤球王一把呢，讓我們拭目以待吧！
PS：就煤球王那水平，打世界杯，阿奎羅甩他幾條街，你們說是不是？
哥倫比亞以南美區第二的身份強勢殺入世界杯，這是16年來他們第一次回到世界杯決賽圈。他們只有一次小組出線的經歷，但是這不能妨礙這支匯集了年輕，速度，力量和超強個人能力的球隊在世界杯上帶來驚喜。
晉級8強是他們的目標，如果法爾考和羅德里格斯有著最佳狀態的話他們能走的更遠。
在蹂躪完約旦以后，烏拉圭終于舒舒服服地進入了世界杯。
烏拉圭在世界杯預選賽中的狀態來的有點完，他們在最后5場比賽比賽中贏了4場，將他們帶到了第五的位置獲得了附加賽資格，最后僅僅以凈勝球劣勢排在厄瓜多爾之后。要知道他們在前11場比賽中僅僅只贏了3場。
補充：
首先今年的世界杯在南美比賽這對烏拉圭是很大的優勢，其次這支球隊有很豐富的大賽經驗，自從2011年美洲杯奪冠以來主力陣容沒有很大的變動。整個球隊技戰術很成熟，并且作風頑強，還有一個不錯的主教練，還擁有全世界最好的兩個前鋒。
綜上所述，烏拉圭如果進入大賽狀態是一支十分難擊敗的球隊，特別進入大賽模式的烏拉圭更加可怕。他們有可能無法擁有最佳陣容出戰，老將和傷病都無法避免，但是依然是一支很有韌性的球隊。如果全隊保持健康，晉級四強希望很大。
每一屆大賽，意大利總是很有威脅的那支球隊，即便是在不被看好的情況下。
他們的鋒線看上去很美，年輕，充滿活力與激情，盡管他們在世界杯預選賽期間略顯掙扎在10場比賽中贏了6場平了4場。
他們是四強的有利競爭者，但是他們似乎在中場缺一個明星球員，有時候進攻上欠缺節奏，對于最后的冠軍爭奪希望還不是那么大。
比利時已經被世界各大足球專家看成是今年世界杯的最大的黑馬，而且有可能爆冷拿下世界杯，如果你在玩fifa或者fm的話這個陣容的確相當搶眼，不過現實是殘酷的。
哈球王，盧卡庫，本特克，梅騰斯……等等擁有這超強天賦的攻擊球員充斥著整個比利時的陣容，光看到名字就讓你感到興奮，但是整支球隊還沒有經歷大賽的考驗，壓力和韌性是這支球隊最大的問題。防守端他們有世界上最好的兩個門將，也有個人能力最強的中后衛之一，看上去整個球隊攻守平衡。心理和戰術紀律性是這支群星璀璨的比利時最大的敵人，如果發揮不錯，有可能進入四強。
在世界杯南美區預選賽上智利以第三名的身份殺入世界杯，但是和厄瓜多爾不同的是，他們的主客場戰績都相當均衡。
在16場比賽中他們打入了29球，攻擊力排在南美區預選賽第二位，這說明進攻是他們的強項，但是同時防守是他們的弱點16場比賽也被打入了25球，攻守相當不平衡。
智利球員的個人技術都相當不錯，出眾的個人能力能在膠著的比賽中幫他們打開局面。在溫布利的勝利應該對智利整個球隊都是很大的激勵，如果再16強階段不碰到前四的強隊，很有可能進入最后的8強。如果他們最后殺入8強，那么這是自從62年以來他們最好的成績，不過在此之前他們需要大大改善自己的防守，如果改變不了，那最大的冷門可能就要出現在他們身上了。
10年世界杯沒有拿到冠軍，這支球隊的氣數已經走到了盡頭，前場還是那么幾個老人再苦苦支撐，后場依然不堪一擊。無冕之王要想再今年改變無冠的命運只能是癡人做夢了。
雖然荷蘭在世界杯預選賽表現不俗，但是看看他們的分組，幾乎沒有遇到有難度的抵抗，雖然在10場預選賽中只被進了5球，看看對陣的球隊，就不想多說什么了。他們的進攻依然可以很犀利很華麗，但是要想走的更遠，對比其他頂級球隊實在差的太多，不過8強應該沒問題。
雖然英格蘭最終以小組第一的身份晉級了世界杯，但是過程絕對不如結果看到的那么容易。
當人們對他們寄予厚望重新沖刺世界杯的時候，智利和德國給這支歐洲中國隊澆了一盆冷水。毋庸置疑的是，英格蘭的確有一些個人能力很強的球員，并且也不缺精氣神。但是無可否認的是，他們失敗的大賽歷史證明這一切很難被改變，如果最后進入了4強絕對需要舉國歡慶。進入8強算是比較正常的目標，如果低于8強基本沒臉回國了，英國小報罵死你，如果高于8強，那就謝天謝地謝亞龍吧！
哎，回頭看看日韓的陣容就算是有再多的仇恨，也不得不佩服他們在國際足壇的成長。
在亞洲杯十強賽B組以超強的統治力小組出線，僅僅輸了一場比賽，在8場比賽中只被打入了5個進球。今年的世界杯16強絕對不是癡人做夢。
日本有很多富有才華的技術型中場，本田圭佑，香川真司和長谷部誠已經是歐洲成名的中場大將，他們的對球都有著很強的控制力，而且傳球和想象力也相當出色，在扎切羅尼的指導下整支球隊的戰術組織紀律也令人刮目相看。在進攻線上，他們有很多富有潛力的年輕球員，23歲的前鋒大迫勇也將有可能給人帶來驚喜。
總體來說他們的最佳11人陣容能和世界很多強隊匹敵，不過一旦碰上比他們更加強壯，更加善于控球的球隊，他們能更好的打出高質量的防守和反擊么，防守將決定日本最終能走的多遠。如果一切順利，8強對日本來說絕對是有可能的，就算無法取得佳績，他們也是一支充滿觀賞性的球隊。
俄羅斯再一次回到了世界杯的舞臺，這一次率領他們的是金牌教頭卡佩羅。
這支俄羅斯進攻火力十足，并且有能力應付各種強隊，防守也游刃有余。但是壓力也許是他們最大的敵人，他們必須從小組出線為這個國家重新帶來失去的榮譽，要知道上一次他們能從世界杯小組出線還要追溯到1986年。
大多數在這支國家隊的球員來自本國聯賽，主要由澤尼特和莫斯科兩大俱樂部組成。
對于這支俄羅斯來說最大的敵人就是自己，如果能更好的把握住進球機會，8強絕對不是夢。
雖然在去年的非洲杯又沒有奪冠，但是科特迪瓦依然是是這個大洲最強的球隊。
在擊敗塞內加爾進軍世界杯以后，他們已經將目光瞄準了世界杯淘汰賽階段的比賽。上一次他們僅僅以微弱優勢被淘汰出局。
科特迪瓦的陣容群星云集，球隊傳奇亞亞圖雷和德羅巴是當仁不讓的老大，再輔以熱爾維尼奧，敦比亞，卡勞伯尼，克洛圖雷這些歐洲名將，科特迪瓦的值得期待。不過他們需要在球隊整體的技戰術水平上有所提高。
如果他們能保持自己的進攻火力，他們就能創造自己的奇跡。
如果硬要找個規律，這個法國還有可能打入今年的世界杯決賽，98年他們奪得世界杯冠軍，02年小組被淘汰，06年又拿到了亞軍，10年又被小組淘汰，那么14年很有可能進入世界杯決賽啦，不過這種情況只能說中大彩了。
雖然在世界杯預選賽中僅僅位于西班牙之后排名第二也不是那么讓人難以理解，但是關鍵問題在于他們沒有拿出任何讓人信服的比賽，特別到最后還要靠薩科這樣的球員來拯救擊敗烏克蘭，簡直不忍直視。
當然法國的實力毋庸置疑，全隊有很多技術出眾，創造力強并且讓人激情四射的球員，里貝里又是當今足壇的頂尖球員之一。不過一旦這些球星爆發，誰能知道這支不被看好的法國能走多遠呢！
在波黑短短幾年的建國歷史里，他們的國家第一次進入了世界杯的決賽圈。不過看看他們的陣容，他們應該對這次世界杯充滿了決心和目的。
他們有一個穩定的主力陣容，有一套成熟的攻防體系，看看他們的球員，守門員是英超門神貝戈維奇，兩大神鋒伊比舍維奇和哲科將為波黑的進攻提供火力，在中場擁有著很多創造力中場，現在在羅馬炙手可熱的皮亞尼奇將成為提供主要進攻組織者，前德甲助攻王米西莫維奇也是不容忽視的。皮亞尼奇定位球功力將會是決定比賽的關鍵人物，在世界杯這樣重大的比賽中，一個定位球將有可能改變整場比賽的走勢。
因為沒有以前世界杯經歷的對比，也沒有很豐富的對戰其他大州球隊的經驗，預測他們能走的多遠實在是十分困難。不過小組出線對他們來說應該不難，波黑是世界杯值得期待的一直球隊，有動力有激情有天賦！
瑞士可以稱的上各項大賽上的常客，他們有不錯的實力，但是離頂級球隊還是有那么點的差距。
對于很多頂級球隊來說瑞士的經常是他們的噩夢，他們有嚴密的戰術紀律，有天賦的球員，老道的主教練，他們的世界杯預選賽以不敗結束直接晉級32強，在希斯菲爾德掌舵的這幾年中，瑞士取得的進步有目共睹。
扎卡，沙奇里和因勒的崛起，在這支頑強的球隊中注入了才華和星味，不過他們缺乏一個中鋒和一個強力中后衛。
不過他們現在的世界排名讓他們在世界杯抽簽分組中占據了一個有力的位置，幾乎以他們現在的實力，出線不成問題，他們應該將目標放在8強才能算的上真正的成功。他們上一次進入8強還要追溯到1954年。
棒子的出線可以真正稱得上幸運，僅僅以凈勝球的優勢淘汰了烏茲別克斯坦。
不過他們的整體實力處在一個上升期，在德甲效力的孫興民和具滋哲將給棒子的進攻帶來很大的提升，并且他們都年輕還有很大的上升空間，后防線上剛剛贏得亞冠的廣州恒大主力中后衛金英權將是后防線上的領軍人物。在配以這賽季在卡迪夫狀態很好的金普炅，棒子的整體實力還是不容小覷的，再加上某些不確定因素(大家都懂的)。
在過去的三屆世界杯中他們有兩次從小組出線，不過最大極限也是16強，不會再走的更遠了。
字母羅和伊布的巔峰對決，終于以字母羅封神的表現，讓葡萄牙驚險晉級世界杯。葡萄牙也是真正意義上字母羅一個人的球隊。葡萄牙的球迷認為只要有字母羅一切皆有可能，但是世界杯可不是預選賽，他們要獲得好成績得把球隊的狀態調整到最佳。但是很遺憾的是，整支球隊沒有那樣的實力。不過葡萄牙的世界杯之旅很大程度上決定于他們的抽簽，估計他們可以贏得小組的頭兩場比賽，然后順利進入16強。不過看上去很簡單事實上不那么容易，在此之前球隊的戰術還得好好研究一番。
厄瓜多爾是一個很奇怪的球隊，他們在世界杯南美區預選賽高居第四位直接晉級了世界杯決賽圈，讓烏拉圭去打了附加賽。但是他們超強的主場戰斗力，在世界杯將不復存在。
在預選賽的8場主場比賽中7場取得了勝利，一場是平局，但是他們在客場一場未勝，平了3場輸了5場。
如果他們遇上壓迫型球隊，進攻犀利的強隊，那么他們羸弱的防守就會給他們帶來致命傷害。另外一個方面如果允許他們打出防守反擊，他們在兩翼的速度將是所有球隊的噩夢。
他們有可能進入16強，不過8強就不要奢望了。
尼日利亞令人信服地擊敗了埃塞俄比亞進入了世界杯決賽圈，不過如果他們想讓世人重新關注非洲雄獅，他們還得做的更好。
尼日利亞的陣容雖然不比從前，但也不少球星，像艾姆尼科，摩西，米克爾這樣歐洲的成名球星將是決定他們世界杯成敗的關鍵人物。雖然他們的比賽缺乏節奏的變化，不過Stephen Keshi執教下球隊技戰術漸漸成熟，如果他們發揮出應有的水平，小組出線可能還是很大的。
雖然在預選賽起步有點蹣跚，但是美國很快以小組頭名的身份強勢殺進世界杯。不過在中北美取得這樣的成績對于美國來說也是正常的，他們的陣容相當不錯，今年的世界杯是對他們最好的檢驗。1930的世界杯是美國第一次打入世界杯8強，也許這次他們想走的更遠。
墨西哥如愿搭上了末班車，不過他們總體表現是令人失望的。他們在預選賽最后兩場驚險拿到了附加賽的資格，有如此多富有天賦的攻擊球員，而整個預選賽10場比賽只打入了7個進球，進攻問題是最需要解決的問題。
當然如果能解決進攻的問題，墨西哥是一支相當不錯的球隊，但是缺乏真正的巨星級人物在關鍵場次為球隊挺身而出。
主教練Miguel Herrera的用人也匪夷所思，他的宗旨是不征召海外球員，只選本國聯賽的球員組成國家隊，他覺得這樣的球隊戰術凝聚力高。在過去5次的世界杯經歷中，墨西哥都進入了16強，這對他們來說是很大的激勵。
在附加賽中擊敗冰島，讓克羅地亞如愿來到巴西，不過他們的頭號射手曼朱基齊的停賽，對他們的世界杯之旅是一次致命打擊。他有可能錯過整個小組賽的比賽，由于第二回合對戰冰島被出示紅牌下場。
克羅地亞的中場是他們最引以為傲的地方，他們的中場才華橫溢，富有創造力，對任何球隊都是很大的威脅，問題在于主教練Niko Kovac的戰術能不能將這些球星融入在一起，發揮出最大的戰斗力。
雖然他們進入了世界杯，但是沒有曼朱基齊的克羅地亞得分能力將被放大，他們能否從小組出線也被打上了大大的問號。
在戰勝埃及以后，加納連續三屆進入了世界杯決賽圈。
全世界的目光都會關注這支非洲勁旅，要知道他們第一次參加世界杯就進入了16強，第二次就進入了8強!球隊中名將眾多武藝蒙，博阿滕，阿薩莫阿是領軍人物，還有在馬賽效力的阿尤兄弟，加納的中場堪稱強大，但是他們最大的問題在于防守，而且缺乏箭頭人物，雖然在對戰埃及的兩回合比賽中打入了7球。
如果無法提高他們的防守質量和鋒無力的問題，他們可能無法在小組中出線。
這是希臘第一次連續兩屆晉升世界杯決賽圈的比賽，不過這也僅僅是他們第三次世界杯之旅。
希臘的優點就是團隊戰術紀律好，意志力頑強，但是缺乏才華是他們最大的問題。他們如果要在世界杯中做的更好的話，必須從防守做起，伺機反擊，是他們最大的機會。
在10場預選賽中，希臘打入12球，只被進了4球，可見他們的策略依然沿用著防守反擊，即使在對陣列支敦士登這樣的業余級別球隊時他們也只是客場1-0，主場2-0小比分獲勝。不過觀眾應該很討厭他們吧，在世界杯中一共獲得過一場比賽勝利，小組出線不容樂觀。
喀麥隆輕松邁過了突尼斯這一關進軍了世界杯，但是很明顯他們已經不是昔日的非洲獵豹了。整個球隊的團隊氛圍相當的差，并且已經沒有了世界頂級球星，雖然有一些不錯的球員例如埃托奧，宋，恩庫魯和馬蒂普。
進球是他們最大的問題，在對陣利比亞，剛果和多哥的比賽中6場比賽僅僅打入8球，要知道這些都是公認的弱旅。在埃托奧身邊的鋒線搭檔是韋伯不過他也是僅有的國家隊進球達到兩位數的球員。
自從沒有了卡梅尼，2年半以來他只打了12場聯賽，喀麥隆的門將位置捉襟見肘。
自從他們上一次小組出線已經過去20年了，這一次賠率顯示他們可能要再加上4年了。
自從1982和1986年以來，這是阿爾及利亞第一次進入世界杯決賽圈，而且從來沒有從小組出線過。
阿爾及利亞應該是非洲參加世界杯最弱的球隊了，如果他們希望有所發揮就要寄希望于布拉希米，哈桑耶布和費古利的發揮了。
布拉希米應該是特別需要注意的那個，他的腳下技術相當出色，并且突破和傳球都能撕開對手的防線。但是全隊的攻防兩端都有很大的問題，注定是世界杯的過客。
哥斯達黎加在預選賽中有這十分強勢的表現，在中北美預選賽中有這最好的防守紀錄，在10場比賽中只被打入7球。
雖然沒有什么特別大牌的明星，但是布萊恩魯伊茲和喬爾坎貝爾的實力能大大提升他們的進球效率。
不過世界杯對于他們來說目標和洪都拉斯差不多，贏一場就能開心回家了，不過要是分到一個不錯的小組，哥斯達黎加也許能創造驚喜。
在這次世界杯預選賽中洪都拉斯表現出色，他們已經連續兩屆進軍世界杯決賽圈的比賽了，在次之前他們只有在1982年參加過世界杯。
但是要說事實的話，他們的晉級只能歸咎于墨西哥狀態太差，但是他們也的確有一些才華橫溢的球員增加了球隊的整體實力。
在中國聯賽效力的卡洛斯 科斯特利，英超球星帕拉西奧斯和埃斯皮諾薩是這支球隊的領軍人物，球隊也不乏一些擁有眾多國際比賽經驗的老隊員。
對于他們來說最現實的目標就是能在世界杯贏一場球，除非有什么奇跡發生，或者有什么令人震驚的分組……
澳大利亞在亞洲的實力僅次于韓日，獲得一個世界杯資格應該不成問題，但是他們在預選賽的表現十分掙扎，要知道十強賽b組僅僅只有日本一支強隊，而約旦隊在兩回合對戰烏拉圭的比賽中業余的表現，可見實力有多差。
澳大利亞的問題在于隊伍年齡老化，卡希爾，布雷西亞諾，尼爾這些高齡球員依然在陣中，只有極少數的25歲以下年輕球員能進入一線隊陣容。
這屆世界杯應該是這些老隊員的謝幕演出，但是鋒無力的情況可能比缺少年輕球員更加嚴重，如果澳大利亞能進入淘汰賽，估計更大博彩公司都要哭了。
伊朗在亞洲區十強賽A組力壓韓國和烏茲別克斯坦斯坦以小組頭名出線，實力可見一斑。
但是他們在世界杯的影響力有限，過往成績也不太理想沒有一次小組出線的經歷，最好的成績是98年世界杯在小組取的了他們在世界杯的唯一一場勝利。
現在球隊中有Masoud Shojaei，Javad Nekounam和Reza Ghoochannejhad在歐洲頂級聯賽效力，雖然不缺乏一些不錯的球員，但是總體實力還是不能給其他球隊造成麻煩。最弱一隊非伊朗莫屬。
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-Installation-Guide/cdh4ig_topic_4_4.html
http://www.cnblogs.com/xuesong/p/3604080.html
http://www.linuxidc.com/Linux/2013-12/94180.htm
卸載
http://www.cnblogs.com/shudonghe/articles/3133290.html
安裝文件：
http://www.cloudera.com/content/support/en/downloads/download-components/download-products.html?productID=4ZFrtT9ZQN
- change to no password
sudo chmod +w /etc/sudoers
sudo vi /etc/sudoers
ufuser ALL=(ALL) NOPASSWD: ALL
sudo chmod -w /etc/sudoers
- change disable
sudo vi /etc/selinux/config
SELINUX=disabled
sudo reboot
- add to /etc/hosts
sudo vi /etc/hosts
10.0.0.4 ufhdp001.cloudapp.net ufhdp001
10.0.0.5 ufhdp002.cloudapp.net ufhdp002
- download bin
wget http://archive.cloudera.com/cm4/installer/latest/cloudera-manager-installer.bin
- run the bin
chmod 755 cloudera-manager-installer.bin
sudo ./cloudera-manager-installer.bin
簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
例如：如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一臺服務器上執行改任務需10小時。
采用分布式方案，提供10臺服務器，每臺服務器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。
而采用集群方案，同樣提供10臺服務器，每臺服務器都能獨立處理這個任務。假設有10個任務同時到達，10個服務器將同時工作，10小后，10個任務同時完成，這樣，整身來看，還是1小時內完成一個任務!
集群概念
1. 兩大關鍵特性
集群是一組協同工作的服務實體，用以提供比單一服務實體更具擴展性與可用性的服務平臺。在客戶端看來，一個集群就象是一個服務實體，但事實上集群由一組服務實體組成。與單一服務實體相比較，集群提供了以下兩個關鍵特性：
· 可擴展性--集群的性能不限于單一的服務實體，新的服務實體可以動態地加入到集群，從而增強集群的性能。
· 高可用性--集 群通過服務實體冗余使客戶端免于輕易遇到out of service的警告。在集群中，同樣的服務可以由多個服務實體提供。如果一個服務實體失敗了，另一個服務實體會接管失敗的服務實體。集群提供的從一個出 錯的服務實體恢復到另一個服務實體的功能增強了應用的可用性。
2. 兩大能力
為了具有可擴展性和高可用性特點，集群的必須具備以下兩大能力：
· 負載均衡--負載均衡能把任務比較均衡地分布到集群環境下的計算和網絡資源。
· 錯誤恢復--由于某種原因，執行某個任務的資源出現故障，另一服務實體中執行同一任務的資源接著完成任務。這種由于一個實體中的資源不能工作，另一個實體中的資源透明的繼續完成任務的過程叫錯誤恢復。
負載均衡和錯誤恢復都要求各服務實體中有執行同一任務的資源存在，而且對于同一任務的各個資源來說，執行任務所需的信息視圖(信息上下文)必須是一樣的。
3. 兩大技術
實現集群務必要有以下兩大技術：
· 集群地址--集 群由多個服務實體組成，集群客戶端通過訪問集群的集群地址獲取集群內部各服務實體的功能。具有單一集群地址(也叫單一影像)是集群的一個基 本特征。維護集群地址的設置被稱為負載均衡器。負載均衡器內部負責管理各個服務實體的加入和退出，外部負責集群地址向內部服務實體地址的轉換。有的負載均 衡器實現真正的負載均衡算法，有的只支持任務的轉換。只實現任務轉換的負載均衡器適用于支持ACTIVE-STANDBY的集群環境，在那里，集群中只有 一個服務實體工作，當正在工作的服務實體發生故障時，負載均衡器把后來的任務轉向另外一個服務實體。
· 內部通信--為了能協同工作、實現負載均衡和錯誤恢復，集群各實體間必須時常通信，比如負載均衡器對服務實體心跳測試信息、服務實體間任務執行上下文信息的通信。
具有同一個集群地址使得客戶端能訪問集群提供的計算服務，一個集群地址下隱藏了各個服務實體的內部地址，使得客戶要求的計算服務能在各個服務實體之間分布。內部通信是集群能正常運轉的基礎，它使得集群具有均衡負載和錯誤恢復的能力。
集群分類
Linux集群主要分成三大類( 高可用集群， 負載均衡集群，科學計算集群)，高可用集群( High Availability Cluster)，負載均衡集群(Load Balance Cluster)，科學計算集群(High Performance Computing Cluster)
具體包括：
Linux High Availability 高可用集群：普通兩節點雙機熱備，多節點HA集群，RAC, shared, share-nothing集群等；Linux Load Balance 負載均衡集群：LVS等....；Linux High Performance Computing 高性能科學計算集群：Beowulf 類集群....；分布式存儲；其他類linux集群：如Openmosix, rendering farm 等..
詳細介紹
1. 高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如"雙機熱備", "雙機互備", "雙機".
高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟件/硬件/人為造成的故障對業務的影響降低到最小程度)。
2. 負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節點都處于活動狀態，它們分攤系統的工作負載。一般Web服務器集群、數據庫集群和應用服務器集群都屬于這種類型。
負載均衡集群一般用于相應網絡請求的網頁服務器，數據庫服務器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的服務器，并把請求轉到這些服務器上。從檢查其他服務器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3. 科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力于提供單個計算機所不能提供的強大的計算能力。
高性能計算分類
高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以并行的子任務，而且各個子任務彼此間沒有什么關聯。象在家搜尋外星人( SETI@HOME -- Search for Extraterrestrial Intelligence at Home )就是這一類型應用。這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的服務器將一組數據和數據模式發給Internet上 參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然后將搜索的結果發給服務器。服務器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特征是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。所謂的Internet計算都屬于這一類。按照 Flynn的分類，高吞吐計算屬于SIMD(Single Instruction/Multiple Data)的范疇。
分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干并行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬于MIMD(Multiple Instruction/Multiple Data)的范疇。
4. 分布式(集群)與集群的聯系與區別
分布式是指將不同的業務分布在不同的地方。而集群指的是將幾臺服務器集中在一起，實現同一業務。分布式中的每一個節點，都可以做集群。而集群并不一定就是分布式的。
舉例：就比如新浪網，訪問的人多了，他可以做一個群集，前面放一個響應服務器，后面幾臺服務器完成同一業務，如果有業務訪問的時候，響應服務器看哪臺服務器的負載不是很重，就將給哪一臺去完成。
而分布式，從窄意上理解，也跟集群差不多， 但是它的組織比較松散，不像集群，有一個組織性，一臺服務器垮了，其它的服務器可以頂上來。
分布式的每一個節點，都完成不同的業務，一個節點垮了，哪這個業務就不可訪問了。
傳統MySQL+ Memcached架構遇到的問題
實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據加載到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：
1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作占據大量開發時間。
2.Memcached與MySQL數據庫數據一致性問題。
3.Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。
4.跨機房cache同步問題。
眾多NoSQL百花齊放，如何選擇
最近幾年，業界不斷涌現出很多各種各樣的NoSQL產品，那么如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問題，實 際歸根結底最重要的是了解這些產品的定位，并且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用于解決以下幾 種問題
1.少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。
2.海量數據存儲，分布式系統支持，數據一致性保證，方便的集群節點添加/刪除。
3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，后者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然后定期compat歸并到磁盤上，將隨機寫優化為順序寫，提高寫入性能。
4.Schema free，auto-sharding等。比如目前常見的一些文檔數據庫都是支持schema-free的，直接存儲json格式數據，并且支持auto-sharding等功能，比如mongodb。
面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。
Redis適用場景，如何正確的使用
前面已經分析過，Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功 能，跟傳統意義上的持久化有比較大的差別，那么可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那么何時使用 Memcached,何時使用Redis呢?
如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：
1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
2 Redis支持數據的備份，即master-slave模式的數據備份。
3 Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。
拋開這些，可以深入到Redis內部構造去觀察更加本質的區別，理解Redis的設計。
在Redis中，并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。Redis只會緩存所有的 key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據“swappability = age*log(size_in_memory)”計 算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis可以 保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由于Redis將內存 中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個 操作，直到子線程完成swap操作后才可以進行修改。
使用Redis特有內存模型前后的情況對比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
當 從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數據，然后再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小，進行 批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程 池的大小，對需要從swap文件中加載相應數據的讀取請求進行并發操作，減少阻塞的時間。
如果希望在海量數據的環境中使用好Redis，我相信理解Redis的內存設計和阻塞的情況是不可缺少的。
補充的知識點：
memcached和redis的比較
1 網絡IO模型
Memcached是多線程，非阻塞IO復用的網絡模型，分為監聽主線程和worker子線程，監聽線程監聽網絡連接，接受請求后，將連接描述字 pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型可以發揮多核作用，但是引入了cache coherency和鎖的問題，比如，Memcached最常用的stats 命令，實際Memcached所有操作都要對這個全局變量加鎖，進行計數等工作，帶來了性能損耗。
(Memcached網絡IO模型)
Redis使用單線程的IO復用模型，自己封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對于單純 只有IO操作來說，單線程可以將速度優勢發揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對于這些操作，單線程模型實際會嚴重 影響整體吞吐量，CPU計算過程中，整個IO調度都是被阻塞住的。
2.內存管理方面
Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方 式可以省去申請/釋放內存的開銷，并且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，并且在內存仍然有很大空間時，新的數據也可能會被剔 除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現場申請內存的方式來存儲數據，并且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎片，Redis跟據存儲 命令參數，會把帶過期時間的數據單獨存放在一起，并把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致swap也不會剔除任何非 臨時數據(但會嘗試剔除部分臨時數據)，這點上Redis更適合作為存儲而不是cache。
3.數據一致性問題
Memcached提供了cas命令，可以保證多個并發訪問操作同一份數據的一致性問題。 Redis沒有提供cas 命令，并不能保證這點，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。
4.存儲方式及其它方面
Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和復制等功能
Redis除key/value之外，還支持list,set,sorted set,hash等眾多數據結構，提供了KEYS
進行枚舉操作，但不能在線上使用，如果需要枚舉線上數據，Redis提供了工具可以直接掃描其dump文件，枚舉出所有數據，Redis還同時提供了持久化和復制等功能。
5.關于不同語言的客戶端支持
在不同語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過因為Memcached發展的時間更久一些，目前看在客 戶端支持方面，Memcached的很多客戶端更加成熟穩定，而Redis由于其協議本身就比Memcached復雜，加上作者不斷增加新的功能等，對應 第三方客戶端跟進速度可能會趕不上，有時可能需要自己在第三方客戶端基礎上做些修改才能更好的使用。
根據以上比較不難看出，當我們不希望數據被踢出，或者需要除key/value之外的更多數據類型時，或者需要落地功能時，使用Redis比使用Memcached更合適。
關于Redis的一些周邊功能
Redis除了作為存儲之外還提供了一些其它方面的功能，比如聚合計算、pubsub、scripting等，對于此類功能需要了解其實現原理，清楚地 了解到它的局限性后，才能正確的使用，比如pubsub功能，這個實際是沒有任何持久化支持的，消費方連接閃斷或重連之間過來的消息是會全部丟失的，又比 如聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，需要謹慎使用。
總的來說Redis作者是一位非常勤奮的開發者，可以經常看到作者在嘗試著各種不同的新鮮想法和思路，針對這些方面的功能就要求我們需要深入了解后再使用。
總結：
1.Redis使用最佳方式是全部數據in-memory。
2.Redis更多場景是作為Memcached的替代者來使用。
3.當需要除key/value之外的更多數據類型支持時，使用Redis更合適。
4.當存儲的數據不能被剔除時，使用Redis更合適。