全程用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文件系统。