全程用AJAX下載文件，并顯示下載進度，之后保存文件。
HTML5文件：
<!DOCTYPE html>
<html>
<head>
<title>XMLHttpRequest Download Progress</title>
</head>
<body>
<progress id="p"></progress>
<input type="button" onclick="downloadAndSave();" value="Download"/>
<script>
function downloadAndSave()
{
var progressBar = document.getElementById('p'), xhr = new XMLHttpRequest();
xhr.open('GET', '2');
xhr.responseType = "arraybuffer";
xhr.onprogress = function(event) {
if(event.lengthComputable) {
progressBar.max = event.total;
progressBar.value = event.loaded;
}
};
xhr.onloadend = function(event) {
progressBar.value = event.loaded;
saveByeToFile('2', xhr.response);
};
xhr.send();
}
function saveByeToFile(name, arrayBuffer) {
var byteArray = new Uint8Array(arrayBuffer);
var a = window.document.createElement('a');
a.href = window.URL.createObjectURL(new Blob([ byteArray ], {
type : 'application/octet-stream'
}));
a.download = name;
// Append anchor to body.
document.body.appendChild(a)
a.click();
// Remove anchor from body
document.body.removeChild(a)
}
</script>
</body>
<html>
員工激勵機制
俗話說 “水不激不揚，人不激不奮” 是我國古代典型的激勵思想。中國古代在激勵方面有頗多論述和實踐，我認為中國儒家思想博大精深，但不太好操作。
什么是激勵？
激勵過程可以看作是外部刺激、個體內部條件、行為表現和行為結果的共同作用過程。 激勵是一個動態變化循環的過程：獎勵目標→努力→績效→獎勵→滿意→努力，這其中還有個人完成目標的能力，獲得獎勵的期望值，覺察到的公平，消耗力量、能力等一系列因素。只有綜合考慮到各個方面，才能取得滿意的激勵效果。
為什么要激勵？
我們將“付出”，“回報”放在一架天枰上：
- 當天枰兩側相等時，員工感到公平；
-
當天枰左側大于（〉）右側時，員工感到占了便宜，行為有： ——員工產生歉疚感，從而更努力工作。 ——員工心安理得。
-
當天枰左側小于（〈）右側時，員工感到吃了虧，行為有： ——員工爭取更多的獎酬、待遇。 ——員工減少自己投入努力，如遲到早退、怠工、出廢品、浪費原料、放棄責任。 ——員工想方設法把參照者的獎酬待遇拉下來。 ——員工想要參照者工作干得更多。 ——參照者心理上調節對這些變量的認識（類似于用阿Q精神），使之平衡。 ——改變參照對象，求得“比上不足、比下有余”的自慰效果。 ——在企業沒法達到公平感覺時，員工辭職，另謀高就。
公平感覺純粹是主觀、心理上的反應。在現實中，人們常常高估自己的投入貢獻，低估別人的投入貢獻，從而造成觀察問題的系統偏差。
何時激勵員工
員工激勵是無時無刻的，伴隨整個職業生涯，而非需要的時候激勵一把。
在哪激勵員工
同樣員工激勵可以是任何時間任何地點。
誰來激勵員工
很多企業認為激勵員工是人力資源的工作，人力資源部門職能確實包此項工作，但人力資源部門實施起來也有很多不足的地方。 首先人力資源部門并不熟悉每個部門的工作細節，如果各部門或小組能夠內部激勵員工效果遠遠好于由人力資源部門主導的相關工作。
激勵的誤區
畫餅方法，很多企業采用這種方法，這種激勵在當下已經失去了作用或收效甚微。先不說畫餅是否能兌現，畫餅法設置的目標太遙遠，而到達目標途中每步細節是缺失的。
最常見的例子就是大會上老板說“大家好好干，達到業績，年底發獎金”，會議結束老板回到自己的辦公室，員工回到自己的位置上該干什么干什么。 因為公司的業績就像股市一樣不可預測，這個年終獎就像買彩票或是場賭博，且風險很大，員工都默認放棄，順其自然，能拿到獎金也好，拿不到也沒有什么付出。
當員工得到獎勵，可能熱情狀態能保持幾天，幾周，一兩個月，這種熱情狀態不可能持續保持，在這個期間員工的工作狀態是有顯著提升的。高潮過去隨后熱情就會消退，慢慢回到正常的工作狀態。 所以激勵是持續的，漸進的，激勵密度也很有講究，“密”與“疏”都會影響激勵的效果。
怎樣激勵員工
從上面的天枰法則我們可以看到，激勵就是不停地調整法碼。有哪些激勵方法呢：
- 表率激勵
- 榮譽激勵
- 獎懲激勵
- 目標激勵
- 物質激勵
- 情感激勵
- 公平激勵
- 信任激勵
- 賞識激勵
- 尊重激勵
- 參與激勵
- 榮譽激勵
- 關心激勵
- 相互激勵
- 股票增值
- 股票期權
- 虛擬股票
- 員工持股
激勵方式太多了，無法依依列舉，你可以參考相關管理學的書籍，近代管理學有很成熟激勵方法，以及很多成熟的案例參考。
我想談的是“激勵圖”，這是我多年總結出來的圖表。供大家參考。 
從激勵圖中我們可以看到：
- 從不激勵的企業，員工永遠是常態工作，偶爾還會產生負面情緒。
- 如果激勵與下一次激勵間隔過長效果就不明顯
- 當激勵后間隔太長或者停止激勵，員工在經過一段常態的工作后，會出現負能量增長的情況
- 最不好的結果是一旦激勵完后直接進入消極階段
- 正能量常態的團隊，這種團隊最常見的就是直銷，保險行業，激勵后的結果我們無法預知，已經上升到精神層面。
- 讓激勵成為常態，持續不斷激勵這是每個企業需要思考的一個問題。
http://my.oschina.net/neochen/blog/479169
摘要: 前言每一種該語言在某些極限情況下的表現一般都不太一樣，那么我常用的Java語言，在達到100萬個并發連接情況下，會怎么樣呢，有些好奇，更有些期盼。這次使用經常使用的順手的netty NIO框架（netty-3.6.5.Final），封裝的很好，接口很全面，就像它現在的域名 netty.io，專注于網絡IO。整個過程沒有什么技術含量，淺顯分析過就更顯得有些枯燥無聊，準備好，硬著頭...
閱讀全文
一個在線2k的游戲，每秒鐘并發都嚇死人。傳統的hibernate直接插庫基本上是不可行的。我就一步步推導出一個無鎖的數據庫操作。 1. 并發中如何無鎖。 一個很簡單的思路，把并發轉化成為單線程。Java的Disruptor就是一個很好的例子。如果用java的concurrentCollection類去做，原理就是啟動一個線程，跑一個Queue，并發的時候，任務壓入Queue，線程輪訓讀取這個Queue，然后一個個順序執行。 在這個設計模式下，任何并發都會變成了單線程操作，而且速度非常快。現在的node.js, 或者比較普通的ARPG服務端都是這個設計，“大循環”架構。 這樣，我們原來的系統就有了2個環境：并發環境 + ”大循環“環境 并發環境就是我們傳統的有鎖環境，性能低下。 ”大循環“環境是我們使用Disruptor開辟出來的單線程無鎖環境，性能強大。 2. ”大循環“環境 中如何提升處理性能。 一旦并發轉成單線程，那么其中一個線程一旦出現性能問題，必然整個處理都會放慢。所以在單線程中的任何操作絕對不能涉及到IO處理。那數據庫操作怎么辦？ 增加緩存。這個思路很簡單，直接從內存讀取，必然會快。至于寫、更新操作，采用類似的思路，把操作提交給一個Queue，然后單獨跑一個Thread去一個個獲取插庫。這樣保證了“大循環”中不涉及到IO操作。 問題再次出現： 如果我們的游戲只有個大循環還容易解決，因為里面提供了完美的同步無鎖。 但是實際上的游戲環境是并發和“大循環”并存的，即上文的2種環境。那么無論我們怎么設計，必然會發現在緩存這塊上要出現鎖。 3. 并發與“大循環”如何共處，消除鎖？ 我們知道如果在“大循環”中要避免鎖操作，那么就用“異步”，把操作交給線程處理。結合這2個特點，我稍微改下數據庫架構。 原本的緩存層，必然會存在著鎖，例如：public TableCache
{
private HashMap<String, Object> caches = new ConcurrentHashMap<String, Object>();
}
這個結構是必然的了，保證了在并發的環境下能夠準確的操作緩存。但是”大循環“卻不能直接操作這個緩存進行修改，所以必須啟動一個線程去更新緩存，例如： private static final ExecutorService EXECUTOR = Executors.newSingleThreadExecutor();
EXECUTOR.execute(new LatencyProcessor(logs));
class LatencyProcessor implements Runnable
{
public void run()
{
// 這里可以任意的去修改內存數據。采用了異步。
}
}
OK，看起來很漂亮。但是又有個問題出現了。在高速存取的過程中，非常有可能緩存還沒有被更新，就被其他請求再次獲取，得到了舊的數據。 4. 如何保證并發環境下緩存數據的唯一正確？ 我們知道，如果只有讀操作，沒有寫操作，那么這個行為是不需要加鎖的。 我使用這個技巧，在緩存的上層，再加一層緩存，成為”一級緩存“，原來的就自然成為”二級緩存“。有點像CPU了對不？ 一級緩存只能被”大循環“修改，但是可以被并發、”大循環“同時獲取，所以是不需要鎖的。 當發生數據庫變動，分2種情況： 1）并發環境下的數據庫變動，我們是允許有鎖的存在，所以直接操作二級緩存，沒有問題。 2）”大循環“環境下數據庫變動，首先我們把變動數據存儲在一級緩存，然后交給異步修正二級緩存，修正后刪除一級緩存。 這樣，無論在哪個環境下讀取數據，首先判斷一級緩存，沒有再判斷二級緩存。 這個架構就保證了內存數據的絕對準確。 而且重要的是：我們有了一個高效的無鎖空間，去實現我們任意的業務邏輯。 最后，還有一些小技巧提升性能。 1. 既然我們的數據庫操作已經被異步處理，那么某個時間，需要插庫的數據可能很多，通過對表、主鍵、操作類型的排序，我們可以刪除一些無效操作。例如： a）同一個表同一個主鍵的多次UPdate，取最后一次。 b）同一個表同一個主鍵，只要出現Delete，前面所有操作無效。 2. 既然我們要對操作排序，必然會存在一個根據時間排序，如何保證無鎖呢？使用 private final static AtomicLong _seq = new AtomicLong(0);
即可保證無鎖又全局唯一自增，作為時間序列。
摘要: 正式環境，4臺機器+一臺定時任務的機器。 服務器是阿里云的ECS， 負載均衡用的是阿里云的SLB， mysql用阿里云的RDS， 緩存用阿里云的OCS， 運維基本上是都不需要擔心了， 現在的云服務已經非常完善了， 其實我們用阿里云的服務非常多， 大概有20多個類型的服務， 感謝阿里云。 而我的技術棧是nodejs + mongodb，而阿里云有k-v兼容redis協議的nosql，無mongodb...
閱讀全文
#!/bin/bash
#tomcat start script
# ./tomcat_start.sh start|restart|stop
RETVAL=
0start() {
echo -n
"Tomcat Starting
" echo
/root/java/apache-tomcat-
7.0.
47/bin/startup.sh
}
stop() {
echo -n
"Tomcat Stop" echo
" port "$
1 if [ !
"$1" ];then
echo
"Usage port " exit 1 fi
pid=`netstat -tpln|
grep $
1 | awk
'{print $7}' | awk -F/
'{print $1}'`
if [ -n
"$pid" ];then
echo
$pid echo
"kill -9 pid "$pid kill -
9 $pid fi
}
restart() {
echo -n
"Tomcat restart" echo
stop $
1 start
}
case
"$1" in
start)
start;;
stop)
stop
"$2";;
restart)
restart
"$2";;
*)
echo $
"Usage: $0 {start|stop|restart}" exit 1esac
exit $RETVAL
1.Spark生態圈
如下圖所示為Spark的整個生態圈，最底層為資源管理器，采用Mesos、Yarn等資源管理集群或者Spark 自帶的Standalone模式，底層存儲為文件系統或者其他格式的存儲系統如HBase。Spark作為計算框架，為上層多種應用提供服務。 Graphx和MLBase提供數據挖掘服務，如圖計算和挖掘迭代計算等。Shark提供SQL查詢服務，兼容Hive語法，性能比Hive快3-50 倍，BlinkDB是一個通過權衡數據精確度來提升查詢晌應時間的交互SQL查詢引擎，二者都可作為交互式查詢使用。Spark Streaming將流式計算分解成一系列短小的批處理計算，并且提供高可靠和吞吐量服務。
2.Spark基本原理
Spark運行框架如下圖所示，首先有集群資源管理服務（Cluster Manager）和運行作業任務的結點（Worker Node），然后就是每個應用的任務控制結點Driver和每個機器節點上有具體任務的執行進程（Executor）。
與MR計算框架相比，Executor有二個優點：一個是多線程來執行具體的任務，而不是像MR那樣采用進程模型， 減少了任務的啟動開稍。二個是Executor上會有一個BlockManager存儲模塊，類似于KV系統（內存和磁盤共同作為存儲設備），當需要迭代 多輪時，可以將中間過程的數據先放到這個存儲系統上，下次需要時直接讀該存儲上數據，而不需要讀寫到hdfs等相關的文件系統里，或者在交互式查詢場景 下，事先將表Cache到該存儲系統上，提高讀寫IO性能。另外Spark在做Shuffle時，在Groupby，Join等場景下去掉了不必要的 Sort操作，相比于MapReduce只有Map和Reduce二種模式，Spark還提供了更加豐富全面的運算操作如 filter,groupby,join等。
Notes: 在集群(cluster)方式下, Cluster Manager運行在一個jvm進程之中，而worker運行在另一個jvm進程中。在local cluster中，這些jvm進程都在同一臺機器中，如果是真正的standalone或Mesos及Yarn集群，worker與master或分布于不同的主機之上。
JOB的生成和運行
job生成的簡單流程如下
1.首先應用程序創建SparkContext的實例，如實例為sc
2.利用SparkContext的實例來創建生成RDD
3.經過一連串的transformation操作，原始的RDD轉換成為其它類型的RDD
4.當action作用于轉換之后RDD時，會調用SparkContext的runJob方法
5.sc.runJob的調用是后面一連串反應的起點，關鍵性的躍變就發生在此處
調用路徑大致如下
1.sc.runJob->dagScheduler.runJob->submitJob
2.DAGScheduler::submitJob會創建JobSummitted的event發送給內嵌類eventProcessActor
3.eventProcessActor在接收到JobSubmmitted之后調用processEvent處理函數
4.job到stage的轉換，生成finalStage并提交運行，關鍵是調用submitStage
5.在submitStage中會計算stage之間的依賴關系，依賴關系分為寬依賴和窄依賴兩種
6.如果計算中發現當前的stage沒有任何依賴或者所有的依賴都已經準備完畢，則提交task
7.提交task是調用函數submitMissingTasks來完成
8.task真正運行在哪個worker上面是由TaskScheduler來管理，也就是上面的submitMissingTasks會調用TaskScheduler::submitTasks
9.TaskSchedulerImpl中會根據Spark的當前運行模式來創建相應的backend,如果是在單機運行則創建LocalBackend
10.LocalBackend收到TaskSchedulerImpl傳遞進來的ReceiveOffers事件
11.receiveOffers->executor.launchTask->TaskRunner.run
Spark采用了Scala來編寫，在函數表達上Scala有天然的優勢，因此在表達復雜的機器學習算法能力比其他 語言更強且簡單易懂。提供各種操作函數來建立起RDD的DAG計算模型。把每一個操作都看成構建一個RDD來對待，而RDD則表示的是分布在多臺機器上的 數據集合，并且可以帶上各種操作函數。如下圖所示：
首先從hdfs文件里讀取文本內容構建成一個RDD，然后使用filter（）操作來對上次的RDD進行過濾，再使 用map（）操作取得記錄的第一個字段，最后將其cache在內存上，后面就可以對之前cache過的數據做其他的操作。整個過程都將形成一個DAG計算 圖，每個操作步驟都有容錯機制，同時還可以將需要多次使用的數據cache起來，供后續迭代使用.
3.Shark的工作原理
Shark是基于Spark計算框架之上且兼容Hive語法的SQL執行引擎，由于底層的計算采用了Spark，性 能比MapReduce的Hive普遍快2倍以上，如果是純內存計算的SQL，要快5倍以上，當數據全部load在內存的話，將快10倍以上，因此 Shark可以作為交互式查詢應用服務來使用。
上圖就是整個Shark的框架圖，與其他的SQL引擎相比，除了基于Spark的特性外，Shark是完全兼容Hive的語法，表結構以及UDF函數等，已有的HiveSql可以直接進行遷移至Shark上。
與Hive相比，Shark的特性如下：
1.以在線服務的方式執行任務，避免任務進程的啟動和銷毀開稍，通常MapReduce里的每個任務都是啟動和關閉進程的方式來運行的，而在Shark中，Server運行后，所有的工作節點也隨之啟動，隨后以常駐服務的形式不斷的接受Server發來的任務。
2.Groupby和Join操作不需要Sort工作，當數據量內存能裝下時，一邊接收數據一邊執行計算操作。在Hive中，不管任何操作在Map到Reduce的過程都需要對Key進行Sort操作。
3.對于性能要求更高的表，提供分布式Cache系統將表數據事先Cache至內存中，后續的查詢將直接訪問內存數據，不再需要磁盤開稍。
4.還有很多Spark的特性，如可以采用Torrent來廣播變量和小數據，將執行計劃直接傳送給Task，DAG過程中的中間數據不需要落地到Hdfs文件系統。