近日，互联网工程任务组（Internet Engineering Task Force ，IETF）对HTTP/2做了最后修整，并准备正式发布HTTP/2。HTTP/2是新一代的HTTP协议，它是由IETF的httpbis工作组开发，基于SPDY协议，目标是在保持与HTTP 1.1语义向后兼容性的情况下，减小网络传输延迟，并简化服务器向浏览器传输内容的过程。

目前，工作组已经发布了 最终草案，并广泛征求社区建议。开源的Servlet容器软件Jetty的开发负责人 Greg Wilkins在其博客中谈了他对 HTTP/2的看法，他认为HTTP/2有很多值得称赞的地方，比如保持了HTTP/1.1的语义、支持服务器推送。但它也有很多糟糕的地方，比如在 WebSocket与HTTP/2.0草案中提到的很多新特性都未得到支持。此外，Nginx的产品负责人Owen Garrett称他们的很多用户都对此协议进行了测试使用，普遍都认为性能得到了较大提升。

第一代的Web站点都相对比较简单并且静态资源也相对比较少，而现在的Web动辄就是几兆的图片而且对实时性也要求比较高。为了适应新的需求，HTTP/2通过多种方式来加速HTTP。比如HTTP/2允许服务器一次发送所请求的Web页面的所有元素，以减少HTTP的负荷。

另外，HTTP/2对于那些拥有复杂的Web站点的组织更有用，特别是当其用户分布在全球或者用户网络不好的情况，比如手机用户。关于HTTP/2的更多信息读者可以参考 此文档。

via InfoQ

著名的麦肯锡信任公式：信任=可靠性×资质能力×亲近程度/自我取向。拼搏职场的同学，建议好好琢磨。

如何取得别人的信任？

这个题目乍一看太过功利，会被一部分有原则的人，痛斥为沉迷于各种墙头草两边倒技术的左右逢源主义信奉者，可是我要问那些所谓有原则的人，如何坚持自己的原则，要分步骤或是分要点吗？坚持原则也要有抓手有技术的对吧，所以看这篇文章以及相信其本身带给你的东西，不影响你去做一个堂堂正正的有原则的人。

开门见山的讲，我认为的信任可以用下边的公式来表示，即 信任=可靠性×资质能力×亲近程度/自我取向，总共包含了4个要素，一个一个的讲。

可靠性

简单的讲就是你做事情的靠谱程度，和事情的大小复杂程度无关，最为简单的就是，如果让你拿公司门的钥匙，你是否能坚持每天第一个到公司准时准点开门，不出现迟到或是忘带钥匙等低级错误，或许一天可以，如果是一年十年或是更长时间呢？如果你能将一件事情持续不断的做好，就是一种可靠性或是靠谱的表现，也就是张瑞敏所说的，把简单的事情做好就是不简单，平凡的事情做好就是不平凡。

资质能力

可以分为两个部分看待，一部分是资质，也就是你的经验和头衔的总称，如果你有十年的管理经验，加上一张沧桑的脸和稳重的肚腩，以及一个企业GM的名片，也就是一个典型的中年成熟稳重男人的形象，别人就很容易对你产生信任感。当然这只能说是一个前提吧，如果你一张嘴说出的都是不靠谱的话，办的都是蠢事，外在这套东西瞬间都会成为浮云，所以自然而然就联系到了第二部分，能力。

能力也可以大体分为两类，一类是专业能力，一类是可以理解为比较普遍的工作能力和方法。专业能力容易理解为你所专业擅长的领域，术业有专攻，李逵善于拿斧头砍人，诸葛亮善于运筹帷幄，李师师善于房中术，等等，至于朱元璋放弃自己和尚的专业当起了皇帝，这就另当别论了。

第二类工作能力和工作方法，可以理解为作为一个职场中人的应该具有的职业操守，诸如被说烂了的执行力理论，诸如穿衣谈吐，诸如从计划到执行到改进的PDCA方法，等等都是我们做工作的最基本的方法，这些可以凝结在日常工作中去反映出你的职业操守。

亲近程度

亲近程度最为简单，就是你和你要取得信任的对象亲近程度。如果你对某人总是敬而远之，你的能力可靠性再强也无济于事，要取得别人的信任，就要能和其称兄道弟，一个鼻孔出气。但是警告一点的就是，职场中永远没有真正的朋友，不要把亲近当做是真亲近，你和别人掏心窝子，只能让别人觉得你不专业。

自我取向

最后一项就是自我取向，这个是一个分母，与信任程度呈反比，说白了别太把自己当回事。眼里有客户，心里有别人，在和别人面对面坐着的时候，要好好想想别人的想法是什么，别人有什么需要，眼前的这个人是不是累了是不是口渴需要休息等等。如果能考虑到这种程度，那么你自然就达到心中无我了，别人就会发现和你相处是一件很愉快的事情。

以上就是如何取得别人信任的方法，四个要素，各有各的含义，各有各的特点，细细揣摩，慢慢实践，终有一天你会悟道。（ 来源）

佳人专注精品阅读6年，多谢佳友们的支持，请记得在QQ邮件底部评分处打5颗星噢~~

佳人微信

佳人推荐：

最无果故事：炮友终成眷属？呵呵

最混乱故事：那些年，我滚过的床单，挥霍过的身体

70后忏悔录：16岁失身17岁卖淫我那不堪回首的岁月

古风玄幻小说：烟雨倚重楼

古风小说：皇后无德

时隔十余年，才懂得小青和法海到底发生过什么

为什么有那么多人喜欢克洛泽？

八一八我身边的两个高级外围，毁三观！

每日一笑：陆毅这坐姿，GAY一脸！

成人漫画：大学看A片记（18不禁哦）

八一八，那些年，我们一起遇到的小三

早安心语：我们笑着说再见，却深知再见遥遥无期

佳人猜您也喜欢：
马云卸任阿里CEO演讲：因为信任，所以简单	我们很少信任比我们好的人	梁文道：犬儒时代的信任	有时送出信任，会让你觉得自己是个好人	第一次结婚，请多关照
无觅

  介绍：

InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风 格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB 也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。 Innodb 的创始人：Heikki Tuuri Heikki Tuuri在Innodb的bug社区里也是很活跃的，如果遇到bug也可以直接提到社区，得到作者的解答。

为什么要学习Innodb的调优： 目前来说：InnoDB是为Mysql处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。 另一方面，在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。

参数调优内容： 1. 内存利用方面 2. 日值控制方面 3. 文件IO分配，空间占用方面 4. 其它相关参数 １.内存利用方面： 首先介绍一个Innodb最重要的参数： innodb_buffer_pool_size 这个参数和MyISAM的key_buffer_size有相似之处，但也是有差别的。这个参数主要缓存innodb表的索引，数据，插入数据时的缓冲。为Innodb加速优化首要参数。 该参数分配内存的原则：这个参数默认分配只有8M，可以说是非常小的一个值。如果是一个专用ＤＢ服务器，那么他可以占到内存的70%-80%。这个参数不 能动态更改，所以分配需多考虑。分配过大，会使Swap占用过多，致使Mysql的查询特慢。如果你的数据比较小，那么可分配是你的数据大小＋１０％左右 做为这个参数的值。例如：数据大小为５０Ｍ,那么给这个值分配innodb_buffer_pool_size＝６４Ｍ 设置方法： innodb_buffer_pool_size=4G 这个参数分配值的使用情况可以根据 show innodb statusG;中的 ———————- BUFFER POOL AND MEMORY ———————- Total memory allocated 4668764894; 去确认使用情况。 第二个： innodb_additional_mem_pool： 作用：用来存放Innodb的内部目录 这个值不用分配太大，系统可以自动调。不用设置太高。通常比较大数据设置16Ｍ够用了，如果表比较多，可以适当的增大。如果这个值自动增加，会在error log有中显示的。 分配原则： 用 show innodb statusG;去查看运行中的ＤＢ是什么状态（参考BUFFER POOL AND MEMORY段中），然后可以调整到适当的值。 ———————- BUFFER POOL AND MEMORY ———————- Total memory allocated 4668764894; in additional pool allocated 16777216 参考：in additional pool allocated 16777216 根据你的参数情况，可以适当的调整。 设置方法： innodb_additional_mem_pool=16M ２.关于日值方面： innodb_log_file_size 作用：指定日值的大小 分配原则：几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个ＬＯＧ文件相加大小在２Ｇ以内为佳。具体情况还需要看你的事务大小，数据大小为依据。 说明：这个值分配的大小和数据库的写入速度，事务大小，异常重启后的恢复有很大的关系。 设置方法： innodb_log_file_size=256Minnodb_log_files_in_group作用：指定你有几个日值组。 分配原则：　一般我们可以用２－３个日值组。默认为两个。 设置方法： innodb_log_files_in_group=3innodb_log_buffer_size： 作用：事务在内存中的缓冲。 分配原则：控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Ｏｒａｃｌｅ等数据库了解这个，一般最大指定为３Ｍ比较合适。 参考：Innodb_os_log_written(show global status 可以拿到) 如果这个值增长过快，可以适当的增加innodb_log_buffer_size 另外如果你需要处理大理的ＴＥＸＴ，或是ＢＬＯＢ字段，可以考虑增加这个参数的值。 设置方法： innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit 作用：控制事务的提交方式 分配原则：这个参数只有３个值，０，１，２请确认一下自已能接受的级别。默认为１，主库请不要更改了。 性能更高的可以设置为０或是２，但会丢失一秒钟的事务。 说明： 这个参数的设置对Innodb的性能有很大的影响，所以在这里给多说明一下。 当这个值为1时：innodb 的事务LOG在每次提交后写入日值文件，并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。 当这个值为2时：在每个提交，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的 是，由于进程调用方面的问题，并不能保证每秒１００％的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。 当这个值为0时：日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

从以上分析，当这个值不为１时，可以取得较好的性能，但遇到异常会有损失，所以需要根据自已的情况去衡量。 设置方法： innodb_flush_logs_at_trx_commit=1

3.　文件IO分配，空间占用方面 innodb_file_per_table 作用：使每个Innodb的表，有自已独立的表空间。如删除文件后可以回收那部分空间。 分配原则：只有使用不使用。但ＤＢ还需要有一个公共的表空间。 设置方法： innodb_file_per_table=1

innodb_file_io_threads 作用：文件读写ＩＯ数，这个参数只在Windows上起作用。在 linux上只会等于４ 设置方法： innodb_file_io_threads=4

innodb_open_files 作用：限制Innodb能打开的表的数据。 分配原则：如果库里的表特别多的情况，请增加这个。这个值默认是３００。 设置方法： innodb_open_files=800请适当的增加table_cache 4. 其它相关参数 这里说明一个比较重要的参数： innodb_flush_method 作用：Innodb和系统打交道的一个ＩＯ模型 分配原则：Windows不用设置。 Unix可以设置：fsync() or O_SYNC/O_DSYNC 如果系统可以禁止系统的Cache那就把他禁了。 Linux可以选择：O_DIRECT 直接写入磁盘，禁止系统Cache了 设置方法： innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct 作用：控制Innodb的脏页在缓冲中在那个百分比之下，值在范围1-100,默认为90. 这个参数的另一个用处：当Innodb的内存分配过大，致使Ｓｗａｐ占用严重时，可以适当的减小调整这个值，使达到Ｓｗａｐ空间释放出来。建义：这个值最大在９０％，最小在１５％。太大，缓存中每次更新需要致换数据页太多，太小，放的数据页太小，更新操作太慢。 设置方法： innodb_max_dirty_pages_pct＝90 动态更改需要有Super权限： set global innodb_max_dirty_pages_pct=50;

总结： 这里只算是列出了Innodb部分的重要参数，不能认为是对MySQL的整体调优。MySQL的参数一般分为：全局参数，具体引擎的参数。

转自：http://www.lvtao.net/database/mysql_innodb.html

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

手机长时间充电会降低电池寿命，平板电脑和手机充电器不能混用，屏幕分辨率越高约好，镜头像素越高越好，这些有关电子产品的说法一传十十传百，你是否就信以为真了呢？普通用户不了解电子产品的设计原理，难以判断对错，下来就来看看流传最广的几个科技产品谎言。

苹果Mac电脑百毒不侵

苹果号称 Mac 电脑感染病毒的机率非常低，让不少用户误以为苹果电脑就不会遭受恶意攻击和感染病毒，事实上在 2012 年就有上万台 Mac 电脑感染了恶意程序，随后苹果公司便不再将高安全性最为产品的主要宣传信息。

隐身模式在线浏览等于匿名浏览

许多浏览器都有隐身模式，但这并不意味着用户浏览网页就不会留下蛛丝马迹，Google Chrome 和 Safari 浏览器的隐身模式只是让用户的浏览记录对该软件隐身，浏览器不记录网页或者不登陆用户的账户，但不会让用户以匿名的形式查看某个网站，隐身模式更准确的说法是无痕迹浏览。

长时间充电会缩短电池寿命

不少用户会利用休息时间让手机充电，可能一次充电就是一整个晚上，直到第二天早上才断电，电池容量充满后继续充电对手机电池有没有影响呢？目前还没有什么数据显示长时间充电对电池的寿命产生影响，手机配置的锂电池在充满后会自动断电，不存在过度充电的可能。

像素越高手机镜头越好

手机厂商都喜欢镜头像素更高一些，这样在宣传时能够吸引更好消费者，即使在现实生活中使用不到如此高像素的手机，消费者还是乐意为此买单。事实上像素只能影响拍摄照片的大小，照片画质并不完全取决于像素，最重要的因素是感光元件的大小，感光元件越大，每单位像素接受的光线越多，画质就越出众，同样是尺寸的传感器理论上800万像素的照片实际尺寸更小画质更高，1200万像素则是实际尺寸更大，画质略低。

电量没用完不能充电

电量没用完就开始充电，这样短时间的电量浮动会影响电池寿命吗？每一块锂电池都有一定的充电周期极限，即电量完全耗完到再充满，如果每次都等电量耗完再充电，这样就消耗了一充电周期，实际上降低了电池的使用寿命，在手机电量低于 50% 的时候就开始充电。

屏幕显示精度越高越好

在屏幕解析率较低的时候，自然是数值越高越好，高到一定程度时就超过了人眼的识别范围，大约在 300 ppi 以上人的眼睛就分别不出显示效果的差别，比如 LG 首款 QuadHD 屏幕智能手机 G3 的显示精度比三星 Galaxy S5 高出了 300 多 ppi，实际使用时两款手机的屏幕清晰度很难看出差别，苹果iPhone的屏幕显示精度并不高显示效果却非常出众，苹果更注重屏幕的亮点不是一味提高 ppi。

Phoenix(sql on hbase)简介

介绍：

Phoenix is a SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows.

部署：

相关文档：

wiki主页（文档很详细）：
https://github.com/forcedotcom/phoenix/wiki
Quick Start
https://github.com/forcedotcom/phoenix/wiki/Phoenix-in-15-minutes-or-less
Recently Implemented Features
https://github.com/forcedotcom/phoenix/wiki/Recently-Implemented-Features
Phoenix Performance vs Hive,Impala
https://github.com/forcedotcom/phoenix/wiki/Performance#salting
官方实时性能测试结果：
http://phoenix-bin.github.io/client/performance/latest.htm
语法：
http://forcedotcom.github.io/phoenix/index.html

二级索引相关（索引的使用需要调用Phoenix API）：

二级索引（多列时）使用需要在hbase-site.xml中加入如下配置

创建索引例子：

explain的相关说明：

• 主键索引：主键索引要按创建时的顺序引用。如primary key（id,name,add），那么会隐式的创建(id),(id,name),(id,name,add)三个索引，如果在where中用这三个条件会用到索引，其他组合则无法使用索引（FULL SCAN）。
• 二级索引：除了要按创建时的顺序引用外，如果查询的列不全在索引或者覆盖索引中则无法使用索引。
  
  举例：

  DDL：create table usertable (id varchar primary key, firstname varchar, lastname varchar);

       create index idx_name on usertable (firstname);

  DML：select id, firstname, lastname from usertable where firstname = 'foo';

  此查询不会使用到索引，因为lastname不再索引中。

   

  执行DDL：create idx_name on usertable (firstname) include (lastname)后该查询语句才能使用索引。

   

  遗留问题：include和on在Phoenix中具体有什么区别？
• 查询条件中主键索引+二级索引同时存在的话，Phoenix会自己选择最优索引。

Phoenix的SQL表结构与Hbase结构的映射实验

结论：
1：Phoenix会把“CONSTRAINT PK PRIMARY KEY (id,firstname)”这样定义的列拼起来加入到Hbase主键中（用\x00进行分割），同时将联合主键涉及到的列合并默认名为"_0"的一列。其值为空。其他列放入Hbase的同名列中存储
2：Phoenix在Hbase中维护了一张系统表（SYSTEM TABLE）来存储相关Phoenix表的scheme元数据。
3：创建二级索引（create index）操作不会影响表结构
4：如果建表时不指定列族，则列族以_0、_1的方式命名
5：如果有多列时value值通过HBase接口获取的并不是直接可用的值（只能通过Phoenix接口获取正常值）

动态scheme相关

1：支持修改列

2：支持修改二级索引

3：应该是不支持修改主键索引（没找到相关信息。理论上也不好支持，因为主键索引就是rowkey的值。）

Java客户端示例代码(直接面向JDBC接口编程)：

单节点测试：

集群(5*RegionServer)测试：

优点：

1：命令行和java客户端使用都很简单。尤其是java客户端直接面向JDBC接口编程，封装且优化了Hbase很多细节。
2：在单表操作上性能比Hive Handler好很多（但是handler也有可能会升级加入斜处理器相关聚合等特性）
3：支持多列的二级索引，列数不限。其中可变索引时列数越多写入速度越慢，不可变索引不影响写入速度（参考： https://github.com/forcedotcom/phoenix/wiki/Secondary-Indexing#mutable-indexing）。
4：对Top-N查询速度远超Hive（参考： https://github.com/forcedotcom/phoenix/wiki/Performance#top-n）
5：提供对rowkey分桶的特性，可以实现数据在各个region的均匀分布（参考： https://github.com/forcedotcom/phoenix/wiki/Performance#salting）
6：低侵入性，基本对原Hbase的使用没什么影响
7：提供的函数基本都能cover住绝大多数需求了
8：与Hive不同的是，Phoenix的sql语句更接近标准sql规范。

缺点：

1：Phoenix创建的表Hbase可以识别并使用，但是使用Hbase创建的表，Phoenix不能识别，因为Phoenix对每张表都有其相应的元数据信息。
2：硬伤：多表join操作当前不支持（官方文档对当前2.2.3版本的说法不一致，但3.0应该会支持，有可能会引入Apache Drill把大表join分割成小任务的特性）。
3：目前只支持hbase0.94系列（这个应该问题不大）

其他

1：Phoenix对所有数据都是基于内存进行统计。因此从sql语句复杂程度以及java各数据结构的性能，基本能对其消耗的时间有一个大概的估计。

功能扩展（impala不太熟，主要针对Hive说了）

如果将Hive和Phoenix集成的话，还是很不错的，两者刚好互补。Hive并没使用coprocesser，只是通过把数据取出来做MR，而Phoenix刚好是在单表取数据方面做了很多优化。集成后可以享受到Phoenix的单表操作优势，同时可以解决多表join的问题（在Phoenix估计短时间难做出来大表join的方案，说是要模仿Drill，但是现在Drill本身救处于Alpha阶段）。

如果集成的话主要工作是需要在Hive-hbase-handler中适配Hive相关单表操作到Phoenix的java客户端接口。

不太成熟的问题：

1：是把Phoenix的单表操作移植到Hive中还是把Hive的join移植到Phoenix中？
2：是只对外提供Hive的接口还是同时对外提供Hive和Phoenix两种接口呢？
3：适配的过程还有很多细节

尝试调研了下Phoenix二级索引是否可以达到像华为一样创建完可以无需修改HBase任何代码就享受到二级索引的效果

扩展阅读：

sql for hbase(Phoenix、Impala、Drill):  http://www.orzota.com/sql-for-hbase/
SQL on Hadoop的最新进展及7项相关技术分享： http://www.csdn.net/article/2013-10-18/2817214-big-data-hadoop

对比华为HBase二级索引：

缺点：华为二级索引需要在建表时指定列（及不支持动态修改），同时华为代码对Hbase本身侵入性太大（比如balancer要用华为的），难以升级维护。

优点：但是索引建好后，在对Hbase的scan、Puts、Deletes操作时使用Hbase原生代码（无需任何改动）即可享受到索引的效果。也不需要指定使用哪个索引，它会自己使用最优索引。

性能对比：暂未测试，估计差不太多

综合看移植phoenix比移植华为更靠谱，phoenix侵入性小，功能更强大，且升级维护方面也比华为要靠谱。但是移植phoenix难度也相对比较大。

但是如果只是想短期起效果，可以尝试下华为索引。

淘宝开源项目Lealone：

是一个可用于HBase的分布式SQL引擎，主要功能就是能用SQL方式（JDBC）查询Hbase，避免了HBase使用的繁琐操作。相对与Phoenix的功能弱多了。

• 支持高性能的分布式事务，
• 使用一个非常新颖的基于局部时间戳的多版本冲突与有效性检测的分布式事务模型
• 是对H2关系数据库SQL引擎的改进和扩展
• HBase建的表Lealone只能读；Lealone建的表Lealone可以读写。

基于Solr的HBase多条件查询：

介绍：ApacheSolr 是一个开源的搜索服务器，Solr 使用 Java 语言开发，主要基于 HTTP 和Apache Lucene 实现。

原理：基于Solr的HBase多条件查询原理很简单，将HBase表中涉及条件过滤的字段和rowkey在Solr中建立索引，通过Solr的多条件查询快速获得符合过滤条件的rowkey值，拿到这些rowkey之后在HBASE中通过指定rowkey进行查询。

缺点：
1：ApacheSolr本身并不是专为HBase设计的。需要专门针对ApacheSolr写Hbase的相关应用，比如HBase写数据时同步更新索引的过程需要我们自己写协处理器。
2：ApacheSolr本身是一个WebService服务，需要额外维护一个或多个ApacheSolr服务器。

参考：
1：基于Solr的HBase多条件查询 http://www.cnblogs.com/chenz/articles/3229997.html
2： http://blog.csdn.net/chenjia3615349/article/details/8112289#t40

中文wiki： https://github.com/codefollower/Lealone

个人感觉Phoenix是这些sql for hbase项目里最合适、最有前景一个。

最近配置了Jenkins服务器，记录下基本过程。（当然还遇到了若干小问题，兵来将挡水来土掩就是了）

Jenkins安装

1. 安装Tomcat
2. 从Jenkins官网下载jenkins.war文件。官网地址:http://jenkins-ci.org/，注意选择最新版本的Long-Term Support Release
3. 把war文件部署到Tomcat中
4. 启动Tomcat
5. 在浏览器中配置Jenkins，浏览器地址：http://{Tomcat IP}:{Tomcat port}/jenkins/

Jenkins系统设置

菜单路径：系统管理—管理Jenkins—系统设置

1. 设置主目录
2. 设置Maven。注意要预先在操作系统中安装好Maven3.1.1版本。注意不能用更Maven3.2.X版本，否则运行会出错。
3. 设置SubVersion
4. 设置邮件通知。要预先在操作系统中搭建好邮件服务器

Jenkins插件

菜单路径：系统管理—管理Jenkins—管理插件。

安装以下插件：

1.      Maven Project Plugin

2.      Subversion Plugin

3.      Checkstyle Plugin

4.      Findbugs Plugin

5.      PMD Plugin

6.      Warnings Plugin

Maven工程配置

Jenkins支持两种工程：FreeStyle工程和Maven工程。如果代码是用Maven构造的，可以直接建立Maven工程。

新建一个Maven工程后，需要设置以下条目：

1. 设置svn代码的下载路径
2. 设置自动构造的日期
3. 设置pom文件的路径
4. 设置mvn命令的参数
5. 设置post-build的动作

　　 英文链接：Writing Fast, Memory-Efficient JavaScript

　　很多JavaScript引擎，如Google的 V8引擎（被Chrome和Node所用），是专门为需要 快速执行的大型JavaScript应用所设计的。如果你是一个开发者，并且关心内存使用情况与页面性能，你应该了解用户浏览器中的JavaScript引擎是如何运作的。无论是V8， SpiderMonkey的（Firefox）的 Carakan（Opera）， Chakra（IE）或其他引擎，这样做可以帮助你 更好地优化你的应用程序。这并不是说应该专门为某一浏览器或引擎做优化，千万别这么做。

　　但是，你应该问自己几个问题：

• 在我的代码里，是否可以使代码更高效一些
• 主流的JavaScript引擎都做了哪些优化
• 什么是引擎无法优化的，垃圾回收器（GC）是否能回收我所期望的东西

加载快速的网站就像是一辆快速的跑车，需要用到特别定制的零件. 图片来源:  dHybridcars.

　　编写高性能代码时有一些常见的陷阱，在这篇文章中，我们将展示一些经过验证的、更好的编写代码方式。

　　 那么，JavaScript在V8里是如何工作的？

　　如果你对JS引擎没有较深的了解，开发一个大型Web应用也没啥问题，就好比会开车的人也只是看过引擎盖而没有看过车盖内的引擎一样。鉴于Chrome是我的浏览器首选，所以谈一下它的JavaScript引擎。V8是由以下几个核心部分组成：

• 一个基本的编译器，它会在代码执行前解析JavaScript代码并生成本地机器码，而不是执行字节码或简单地解释它。这些代码最开始并不是高度优化的。
• V8将对象构建为 对象模型。在JavaScript中对象表现为关联数组，但是在V8中对象被看作是隐藏的类，一个为了优化查询的内部类型系统。
• 运行时分析器监视正在运行的系统，并标识了“hot”的函数（例如花费很长时间运行的代码）。
• 优化编译器重新编译和优化那些被运行时分析器标识为“hot”的代码，并进行“内联”等优化（例如用被调用者的主体替换函数调用的位置）。
• V8支持 去优化，这意味着优化编译器如果发现对于代码优化的假设过于乐观，它会舍弃优化过的代码。
• V8有个 垃圾收集器，了解它是如何工作的和优化JavaScript一样重要。

　　 垃圾回收

　　垃圾回收是 内存管理的一种形式，其实就是一个收集器的概念，尝试回收不再被使用的对象所占用的内存。在JavaScript这种垃圾回收语言中，应用程序中仍在被引用的对象不会被清除。

　　手动消除对象引用在大多数情况下是没有必要的。通过简单地把变量放在需要它们的地方（理想情况下，尽可能是局部作用域，即它们被使用的函数里而不是函数外层），一切将运作地很好。

垃圾回收器尝试回收内存. 图片来源:  Valtteri Mäki.

　　在JavaScript中，是不可能强制进行垃圾回收的。你不应该这么做，因为垃圾收集过程是由运行时控制的，它知道什么是最好的清理时机。

　　 “消除引用”的误解

　　网上有许多关于JavaScript内存回收的讨论都谈到delete这个关键字，虽然它可以被用来删除对象（map）中的属性（key），但有部分开发者认为它可以用来强制“消除引用”。建议尽可能避免使用delete，在下面的例子中 delete o.x 的弊大于利，因为它改变了o的隐藏类，并使它成为一个"慢对象"。

　　你会很容易地在流行的JS库中找到引用删除——这是具有语言目的性的。这里需要注意的是避免在运行时修改”hot”对象的结构。JavaScript引擎可以检测出这种“hot”的对象，并尝试对其进行优化。如果对象在生命周期中其结构没有较大的改变，引擎将会更容易优化对象，而delete操作实际上会触发这种较大的结构改变，因此不利于引擎的优化。

　　对于null是如何工作也是有误解的。将一个对象引用设置为null，并没有使对象变“空”，只是将它的引用设置为空而已。使用o.x= null比使用delete会更好些，但可能也不是很必要。

　　如果此引用是当前对象的最后引用，那么该对象将被作为垃圾回收。如果此引用不是当前对象的最后引用，则该对象是可访问的且不会被垃圾回收。

　　另外需要注意的是，全局变量在页面的生命周期里是不被垃圾回收器清理的。无论页面打开多久，JavaScript运行时全局对象作用域中的变量会一直存在。

　　全局对象只会在刷新页面、导航到其他页面、关闭标签页或退出浏览器时才会被清理。函数作用域的变量将在超出作用域时被清理，即退出函数时，已经没有任何引用，这样的变量就被清理了。

　　 经验法则

　　为了使垃圾回收器尽早收集尽可能多的对象， 不要hold着不再使用的对象。这里有几件事需要记住：

• 正如前面提到的，在合适的范围内使用变量是手动消除引用的更好选择。即一个变量只在一个函数作用域中使用，就不要在全局作用域声明它。这意味着更干净省心的代码。
• 确保解绑那些不再需要的事件监听器，尤其是那些即将被销毁的DOM对象所绑定的事件监听器。
• 如果使用的数据缓存在本地，确保清理一下缓存或使用老化机制，以避免大量不被重用的数据被存储。

　　 函数

　　接下来，我们谈谈函数。正如我们已经说过，垃圾收集的工作原理，是通过回收不再是访问的内存块（对象）。为了更好地说明这一点，这里有一些例子。

　　当foo返回时，bar指向的对象将会被垃圾收集器自动回收，因为它已没有任何存在的引用了。

　　对比一下：

　　现在我们有一个引用指向bar对象，这样bar对象的生存周期就从foo的调用一直持续到调用者指定别的变量b（或b超出范围）。

　　 闭包（CLOSURES）

　　当你看到一个函数，返回一个内部函数，该内部函数将获得范围外的访问权，即使在外部函数执行之后。这是一个基本的 闭包—— 可以在特定的上下文中设置的变量的表达式。例如：

　　在sum调用上下文中生成的函数对象（sumIt）是无法被回收的，它被全局变量（sumA）所引用，并且可以通过sumA(n)调用。

　　让我们来看看另外一个例子，这里我们可以访问变量largeStr吗？

　　是的，我们可以通过a()访问largeStr，所以它没有被回收。下面这个呢？

　　我们不能再访问largeStr了，它已经是垃圾回收候选人了。【译者注：因为largeStr已不存在外部引用了】

　　 定时器

　　最糟的内存泄漏地方之一是在循环中，或者在setTimeout()/ setInterval()中，但这是相当常见的。思考下面的例子:

　　如果我们运行myObj.callMeMaybe();来启动定时器，可以看到控制台每秒打印出“Time is running out!”。如果接着运行 myObj = null，定时器依旧处于激活状态。为了能够持续执行，闭包将myObj传递给setTimeout，这样myObj是无法被回收的。相反，它引用到myObj的因为它捕获了myRef。这跟我们为了保持引用将闭包传给其他的函数是一样的。

　　同样值得牢记的是，setTimeout/setInterval调用(如函数)中的引用，将需要执行和完成，才可以被垃圾收集。

　　 当心性能陷阱

　　永远不要优化代码，直到你真正需要。现在经常可以看到一些基准测试，显示N比M在V8中更为优化，但是在模块代码或应用中测试一下会发现，这些优化真正的效果比你期望的要小的多。

做的过多还不如什么都不做. 图片来源:  Tim Sheerman-Chase.

　　比如我们想要创建这样一个模块：

• 需要一个本地的数据源包含数字ID
• 绘制包含这些数据的表格
• 添加事件处理程序，当用户点击的任何单元格时切换单元格的css class

　　这个问题有几个不同的因素，虽然也很容易解决。我们如何存储数据，如何高效地绘制表格并且append到DOM中，如何更优地处理表格事件？

　　面对这些问题最开始（天真）的做法是使用对象存储数据并放入数组中，使用jQuery遍历数据绘制表格并append到DOM中，最后使用事件绑定我们期望地点击行为。

　　 注意：这不是你应该做的

　　这段代码简单有效地完成了任务。

　　但在这种情况下，我们遍历的数据只是本应该简单地存放在数组中的数字型属性ID。有趣的是，直接使用DocumentFragment和本地DOM方法比使用jQuery（以这种方式）来生成表格是更优的选择，当然，事件代理比单独绑定每个td具有更高的性能。

　　要注意虽然jQuery在内部使用DocumentFragment，但是在我们的例子中，代码在循环内调用append并且这些调用涉及到一些其他的小知识，因此在这里起到的优化作用不大。希望这不会是一个痛点，但请务必进行基准测试，以确保自己代码ok。

　　对于我们的例子，上述的做法带来了（期望的）性能提升。事件代理对简单的绑定是一种改进，可选的DocumentFragment也起到了助推作用。

　　接下来看看其他提升性能的方式。你也许曾经在哪读到过使用原型模式比模块模式更优，或听说过使用JS模版框架性能更好。有时的确如此，不过使用它们其实是为了代码更具可读性。对了，还有预编译！让我们看看在实践中表现的如何？

　　事实证明，在这种情况下的带来的性能提升可以忽略不计。 模板和原型的选择并没有真正提供更多的东西。也就是说，性能并不是开发者使用它们的原因，给代码带来的可读性、继承模型和可维护性才是真正的原因。

　　更复杂的问题包括 高效地在canvas上绘制图片和操作带或不带类型数组的像素数据。

　　在将一些方法用在你自己的应用之前，一定要多了解这些方案的基准测试。也许有人还记得 JS模版的shoot-off和 随后的扩展版。你要搞清楚基准测试不是存在于你看不到的那些虚拟应用，而是应该在你的实际代码中去测试带来的优化。

　　 V8优化技巧

　　详细介绍了每个V8引擎的优化点在本文讨论范围之外，当然这里也有许多值得一提的技巧。记住这些技巧你就能减少那些性能低下的代码了。

• 特定模式可以使V8摆脱优化的困境，比如说try-catch。欲了解更多有关哪些函数能或不能进行优化，你可以在V8的脚本工具d8中使用–trace-opt file.js命令。
• 如果你关心速度，尽量使你的函数职责单一，即确保变量（包括属性，数组，函数参数）只使用相同隐藏类包含的对象。举个例子，别这么干：

• 不要加载未初始化或已删除的元素。如果这么做也不会出现什么错误，但是这样会使速度变慢。
• 不要使函数体过大，这样会使得优化更加困难。

　　更多内容可以去看Daniel Clifford在Google I/O的分享  Breaking the JavaScript Speed Limit with V8。  Optimizing For V8 — A Series也非常值得一读。

　　 对象VS数组：我应该用哪个？

• 如果你想存储一串数字，或者一些相同类型的对象，使用一个数组。
• 如果你语义上需要的是一堆的对象的属性（不同类型的），使用一个对象和属性。这在内存方面非常高效，速度也相当快。
• 整数索引的元素，无论存储在一个数组或对象中，都要 比遍历对象的属性快得多。
• 对象的属性比较复杂：它们可以被setter们创建，具有不同的枚举性和可写性。数组中则不具有如此的定制性，而只存在有和无这两种状态。在引擎层面，这允许更多存储结构方面的优化。特别是当数组中存在数字时，例如当你需要容器时，不用定义具有x，y，z属性的类，而只用数组就可以了。

　　JavaScript中对象和数组之间只有一个的主要区别，那就是数组神奇的length属性。如果你自己来维护这个属性，那么V8中对象和数组的速度是一样快的。

　　 使用对象时的技巧

• 使用一个构造函数来创建对象。这将确保它创建的所有对象具有相同的隐藏类，并有助于避免更改这些类。作为一个额外的好处，它也 略快于Object.create()
• 你的应用中，对于使用不同类型的对象和其复杂度（在合理的范围内：长原型链往往是有害的，呈现只有一个极少数属性的对象比大对象会快一点）是有没限制的。对于“hot”对象，尽量保持短原型链，并且少属性。

　　 对象克隆

　　对于应用程序开发人员，对象克隆是一个常见的问题。虽然各种基准测试可以证明V8对这个问题处理得很好，但仍要小心。复制大的东西通常是较慢的——不要这么做。JS中的for..in循环尤其糟糕，因为它有着恶魔般的规范，并且无论是在哪个引擎中，都可能永远不会比任何对象快。

　　当你一定要在关键性能代码路径上复制对象时，使用数组或一个自定义的“拷贝构造函数”功能明确地复制每个属性。这可能是最快的方式：

　　 模块模式中缓存函数

　　使用模块模式时缓存函数，可能会导致性能方面的提升。参阅下面的例子，因为它总是创建成员函数的新副本，你看到的变化可能会比较慢。

　　另外请注意，使用这种方法明显更优，不仅仅是依靠原型模式（经过jsPerf测试确认）。

使用模块模式或原型模式时的性能提升

　　这是一个 原型模式与模块模式的性能对比测试：

　　 使用数组时的技巧

　　接下来说说数组相关的技巧。在一般情况下， 不要删除数组元素，这样将使数组过渡到较慢的内部表示。当索引变得稀疏，V8将会使元素转为更慢的字典模式。

　　 数组字面量

　　数组字面量非常有用，它可以暗示VM数组的大小和类型。它通常用在体积不大的数组中。

　　 存储单一类型VS多类型

　　将混合类型（比如数字、字符串、undefined、true/false）的数据存在数组中绝不是一个好想法。例如var arr = [1, “1”， undefined, true, “true”]

　　 类型推断的性能测试

　　正如我们所看到的结果，整数的数组是最快的。

　　 稀疏数组与满数组

　　当你使用稀疏数组时，要注意访问元素将远远慢于满数组。因为V8不会分配一整块空间给只用到部分空间的数组。取而代之的是，它被管理在字典中，既节约了空间，但花费访问的时间。

　　 稀疏数组与满数组的测试

　　 预分配空间VS动态分配

　　不要预分配大数组（如大于64K的元素），其最大的大小，而应该动态分配。在我们这篇文章的性能测试之前，请记住这只适用部分JavaScript引擎。

空字面量与预分配数组在不同的浏览器进行测试

　　Nitro (Safari)对预分配的数组更有利。而在其他引擎（V8，SpiderMonkey）中，预先分配并不是高效的。

　　 预分配数组测试

　　 优化你的应用

　　在Web应用的世界中，速度就是一切。没有用户希望用一个要花几秒钟计算某列总数或花几分钟汇总信息的表格应用。这是为什么你要在代码中压榨每一点性能的重要原因。

图片来源:  Per Olof Forsberg.

　　理解和提高应用程序的性能是非常有用的同时，它也是困难的。我们推荐以下的步骤来解决性能的痛点：

• 测量：在您的应用程序中找到慢的地方（约45％）
• 理解：找出实际的问题是什么（约45％）
• 修复它！ （约10％）

　　下面推荐的一些工具和技术可以协助你。

　　 基准化（BENCHMARKING）

　　有很多方式来运行JavaScript代码片段的基准测试其性能——一般的假设是，基准简单地比较两个时间戳。这中模式被 jsPerf团队指出，并在 SunSpider和 Kraken的基准套件中使用：

　　在这里，要测试的代码被放置在一个循环中，并运行一个设定的次数（例如6次）。在此之后，开始日期减去结束日期，就得出在循环中执行操作所花费的时间。

　　然而，这种基准测试做的事情过于简单了，特别是如果你想运行在多个浏览器和环境的基准。垃圾收集器本身对结果是有一定影响的。即使你使用window.performance这样的解决方案，也必须考虑到这些缺陷。

　　不管你是否只运行基准部分的代码，编写一个测试套件或编码基准库，JavaScript基准其实比你想象的更多。如需更详细的指南基准，我强烈建议你阅读由Mathias Bynens和John-David Dalton提供的 Javascript基准测试。

　　 分析（PROFILING）

　　Chrome开发者工具为 JavaScript分析有很好的支持。可以使用此功能检测哪些函数占用了大部分时间，这样你就可以去优化它们。这很重要，即使是代码很小的改变会对整体表现产生重要的影响。

Chrome开发者工具的分析面板

　　分析过程开始获取代码性能基线，然后以时间线的形式体现。这将告诉我们代码需要多长时间运行。“Profiles”选项卡给了我们一个更好的视角来了解应用程序中发生了什么。JavaScript CPU分析文件展示了多少CPU时间被用于我们的代码，CSS选择器分析文件展示了多少时间花费在处理选择器上，堆快照显示多少内存正被用于我们的对象。

　　利用这些工具，我们可以分离、调整和重新分析来衡量我们的功能或操作性能优化是否真的起到了效果。

“Profile”选项卡展示了代码性能信息。

　　一个很好的分析介绍，阅读Zack Grossbart的  JavaScript Profiling With The Chrome Developer Tools。

　　提示：在理想情况下，若想确保你的分析并未受到已安装的应用程序或扩展的任何影响，可以使用 --user-data-dir <empty_directory>标志来启动Chrome。在大多数情况下，这种方法优化测试应该是足够的，但也需要你更多的时间。这是V8标志能有所帮助的。

　　 避免内存泄漏——3快照技术

　　在谷歌内部，Chrome开发者工具被Gmail等团队大量使用，用来帮助发现和排除内存泄漏。

Chrome开发者工具中的内存统计

　　内存统计出我们团队所关心的私有内存使用、JavaScript堆的大小、DOM节点数量、存储清理、事件监听计数器和垃圾收集器正要回收的东西。推荐阅读Loreena Lee的 “3快照”技术。该技术的要点是，在你的应用程序中记录一些行为，强制垃圾回收，检查DOM节点的数量有没有恢复到预期的基线，然后分析三个堆的快照来确定是否有内存泄漏。

　　 单页面应用的内存管理

　　单页面应用程序（例如AngularJS，Backbone，Ember）的内存管理是非常重要的，它们几乎永远不会刷新页面。这意味着内存泄漏可能相当明显。移动终端上的单页面应用充满了陷阱，因为设备的内存有限，并在长期运行Email客户端或社交网络等应用程序。 能力愈大责任愈重。

　　有很多办法解决这个问题。在Backbone中，确保使用dispose()来处理旧视图和引用（目前在 Backbone(Edge)中可用）。这个函数是最近加上的，移除添加到视图“event”对象中的处理函数，以及通过传给view的第三个参数（回调上下文）的model或collection的事件监听器。dispose()也会被视图的remove()调用，处理当元素被移除时的主要清理工作。Ember 等其他的库当检测到元素被移除时，会清理监听器以避免内存泄漏。

　　Derick Bailey的一些明智的建议：

与其了解事件与引用是如何工作的，不如遵循的标准规则来管理JavaScript中的内存。如果你想加载数据到的一个存满用户对象的Backbone集合中，你要清空这个集合使它不再占用内存，那必须这个集合的所有引用以及集合内对象的引用。一旦清楚了所用的引用，资源就会被回收。这就是标准的JavaScript垃圾回收规则。

　　在文章中，Derick涵盖了许多使用Backbone.js时的常见 内存缺陷，以及如何解决这些问题。

　　Felix Geisendörfer的 在Node中调试内存泄漏的教程也值得一读，尤其是当它形成了更广泛SPA堆栈的一部分。

　　 减少回流（REFLOWS）

　　当浏览器重新渲染文档中的元素时需要 重新计算它们的位置和几何形状，我们称之为 回流。回流会阻塞用户在浏览器中的操作，因此理解提升回流时间是非常有帮助的。

回流时间图表

　　你应该批量地触发回流或重绘，但是要节制地使用这些方法。尽量不处理DOM也很重要。可以使用 DocumentFragment，一个轻量级的文档对象。你可以把它作为一种方法来提取文档树的一部分，或创建一个新的文档“片段”。与其不断地添加DOM节点，不如使用文档片段后只执行一次DOM插入操作，以避免过多的回流。

　　例如，我们写一个函数给一个元素添加20个div。如果只是简单地每次append一个div到元素中，这会触发20次回流。

　　要解决这个问题，可以使用DocumentFragment来代替，我们可以每次添加一个新的div到里面。完成后将DocumentFragment添加到DOM中只会触发一次回流。

　　可以参阅  Make the Web Faster， JavaScript Memory Optimization 和  Finding Memory Leaks。

　　 JS内存泄漏探测器

　　为了帮助发现JavaScript内存泄漏，谷歌的开发人员（(Marja Hölttä和Jochen Eisinger）开发了一种工具，它与Chrome开发人员工具结合使用，检索堆的快照并检测出是什么对象导致了内存泄漏。

一个JavaScript内存泄漏检测工具

　　有完整的文章介绍了 如何使用这个工具，建议你自己到 内存泄漏探测器项目页面看看。

　　如果你想知道为什么这样的工具还没集成到我们的开发工具，其原因有二。它最初是在Closure库中帮助我们捕捉一些特定的内存场景，它更适合作为一个外部工具。

　　 V8优化调试和垃圾回收的标志位

　　Chrome支持直接通过传递一些标志给V8，以获得更详细的引擎优化输出结果。例如，这样可以追踪V8的优化：

　　Windows用户可以这样运行 chrome.exe –js-flags=”–trace-opt –trace-deopt”

　　在开发应用程序时，下面的V8标志都可以使用。

• trace-opt —— 记录优化函数的名称，并显示跳过的代码，因为优化器不知道如何优化。
• trace-deopt —— 记录运行时将要“去优化”的代码。
• trace-gc —— 记录每次的垃圾回收。

　　V8的处理脚本用*（星号）标识优化过的函数，用~（波浪号）表示未优化的函数。

　　如果你有兴趣了解更多关于V8的标志和V8的内部是如何工作的，强烈建议 阅读Vyacheslav Egorov的 excellent post on V8 internals。

　　 HIGH-RESOLUTION TIME 和 NAVIGATION TIMING API

　　 高精度时间（HRT）是一个提供不受系统时间和用户调整影响的亚毫秒级高精度时间接口，可以把它当做是比 new Date 和 Date.now()更精准的度量方法。这对我们编写基准测试帮助很大。

高精度时间（HRT）提供了当前亚毫秒级的时间精度

　　目前HRT在Chrome（稳定版）中是以window.performance.webkitNow()方式使用，但在Chrome Canary中前缀被丢弃了，这使得它可以通过window.performance.now()方式调用。Paul Irish在HTML5Rocks上了 关于HRT更多内容的文章。

　　现在我们知道当前的精准时间，那有可以准确测量页面性能的API吗？好吧，现在有个 Navigation Timing API可以使用，这个API提供了一种简单的方式，来获取网页在加载呈现给用户时，精确和详细的时间测量记录。可以在console中使用window.performance.timing来获取时间信息：

显示在控制台中的时间信息

　　我们可以从上面的数据获取很多有用的信息，例如网络延时为responseEnd – fetchStart，页面加载时间为loadEventEnd – responseEnd，处理导航和页面加载的时间为loadEventEnd – navigationStart。

　　正如你所看到的，perfomance.memory的属性也能显示JavaScript的内存数据使用情况，如总的堆大小。

　　更多Navigation Timing API的细节，阅读 Sam Dutton的  Measuring Page Load Speed With Navigation Timing。

　　 ABOUT:MEMORY 和 ABOUT:TRACING

　　Chrome中的about:tracing提供了浏览器的性能视图，记录了Chrome的所有线程、tab页和进程。

About:Tracing提供了浏览器的性能视图

　　这个工具的真正用处是允许你捕获Chrome的运行数据，这样你就可以适当地调整JavaScript执行，或优化资源加载。

　　Lilli Thompson有一篇 写给游戏开发者的使用about:tracing分析WebGL游戏的文章，同时也适合JavaScript的开发者。

　　在Chrome的导航栏里可以输入about:memory，同样十分实用，可以获得每个tab页的内存使用情况，对定位内存泄漏很有帮助。

　　 总结

　　我们看到， JavaScript的世界中有很多隐藏的陷阱，且并没有提升性能的银弹。只有把一些优化方案综合使用到（现实世界）测试环境，才能获得最大的性能收益。即便如此，了解引擎是如何解释和优化代码，可以帮助你调整应用程序。

　　 测量，理解，修复。不断重复这个过程。

图片来源:  Sally Hunter

　　谨记关注优化，但为了便利可以舍弃一些很小的优化。例如，有些开发者选择.forEach和Object.keys代替for和for..in循环，尽管这会更慢但使用更方便。要保证清醒的头脑，知道什么优化是需要的，什么优化是不需要的。

　　同时注意，虽然JavaScript引擎越来越快，但下一个真正的瓶颈是DOM。回流和重绘的减少也是重要的，所以必要时再去动DOM。还有就是要关注网络，HTTP请求是珍贵的，特别是移动终端上，因此要使用HTTP的缓存去减少资源的加载。

　　记住这几点可以保证你获取了本文的大部分信息，希望对你有所帮助！

死锁对于DBA或是数据库开发人员而言并不陌生,它的引发多种多样,一般而言,数据库应用的开发者在设计时都会有一定的考量进而尽量避免死锁的产生.但有时因为一些特殊应用场景如高频查询,高并发查询下由于数据库设计的潜在问题,一些不易捕捉的死锁可能出现从而影响业务.这里为大家介绍由于设计问题引起的键查找死锁及相关的解决办法.

这里我们在测试的同时开启trace profiler跟踪死锁视图(locks:deadlock graph).(当然也可以开启跟踪标记,或者应用扩展事件(xevents)等捕捉死锁)

创建测试对象code

开启会话1 模拟高频update操作

开启会话2 模拟高频select操作

此时开启会话2执行一小段时间时我们就可以看到类似错误信息:图1-1

                                                     图1-1

而在我们开启的跟踪中捕捉到了如下的死锁图.图1-2

                                                                              图1-2

死锁分析:可以看出由于读进程(108)请求写进程(79)持有的X锁被阻塞的同时,写进程(79)又申请读进程(108)锁持有的S锁.读执行计划图1-3,写执行计划图1-4

(由于在默认隔离级别下(读提交)读申请S锁只是瞬间过程,读完立即释放,不会等待事务完成),所以在并发,执行频率不高的情形下不易出现.但我们模拟的高频情况使得S锁获得频率非常高,此时就出现了仅仅两个会话,一个读,一个写就造成了死锁现象.

                                                                            图1-3

                                                                              图1-4

死锁原因:读操作中的键查找造成的额外锁(聚集索引)需求

解决方案:在了解了死锁产生的原因后,解决起来就比较简单了.

我们可以从以下几个方面入手.

a 消除额外的键查找锁需的锁

b 读操作时取消获取锁

a.1我们可以创建覆盖索引使select语句中的查询列包含在指定索引中

a.2 根据查询需求,分布执行,通过聚集索引获取查询列,避免键查找.

b 通过改变隔离级别,使用乐观并发模式,读操作时源行无需锁

结束语.我们在解决问题时,最好弄清问题的本质原因,通过问题点寻找出适合自己的环境的解决方案再实施.

本文链接： Sql Server 高频,高并发访问中的键查找死锁解析，转载请注明。

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=4296

一、我想写一篇长篇小说

我想写一篇长篇小说，每天上下班地铁的几个小时写写。不过还没完全构思好。据说，人在实现伟大的计划之前最好不要跟别人讲，等大米差不多煮熟的时候，再普照四方。但是呢，一直憋在心里也慌得很，实在忍不住了，这里一吐为快，反正是个小嘎吱角的地方，吐个火星（星星之火）没人发现的，(*^__^*) 嘻嘻……

我琢磨着，每周写一段，像周刊一样，写个10年，恩，差不多了。说不定会火，哈哈！！

二、rgbaster.js小介绍

rgbaster.js是段小脚本，可以获得（具有访问权限的）图片的主色，次色等，然后，发挥我们的创意，实现一些精彩的Web交互效果。

rgbaster.js的Github项目地址是： https://github.com/briangonzalez/rgbaster.js

如何使用？
如何让妹子为你下厨？首先，你得有一个厨房。同样的，要使用 rgbaster.js，首先，你得先调用之：

<script src="http://rawgit.com/briangonzalez/rgbaster.js/master/rgbaster.js"></script>

然后，你得有个菜谱，知道该如何对妹子下手：

var img = document.getElementById('image');
// 或者
var img = 'http://example.com/path-to-image.jpg'

RGBaster.colors(img, {
  success: function(payload) {
    // payload.dominant是主色，RGB形式表示
    // payload.secondary是次色，RGB形式表示
    // payload.palette是调色板，含多个主要颜色，数组
    console.log(payload.dominant);
    console.log(payload.secondary);
    console.log(payload.palette);
  }
});

看来，这个妹子很好下手啊！

就一个方法， RGBaster.colors就可以了，第1个参数 img可以是图片DOM也可以是图片的URL地址。后面就是可选参数，说到可选参数，不只 success这一个，还有下面这几位兄弟：

RGBaster.colors(img, {
  paletteSize: 30, // 调色板大小
  exclude: [ 'rgb(255,255,255)' ],  // 不包括白色
  success: function(payload){
    // 包含一些颜色信息(payload)的回调
  }
})

paletteSize为 30, 则 payload.palette就是个包含前 30主要颜色值的数组。
exclude表示数组中的颜色不参与，剔除。例如，一个小龙女舞剑的图片，我们可能需要的是其舞剑的背景。但是，由于小龙女长年古墓，缺少阳光，面色白皙，加上总是一袭白衣，这大大的白色虽是主色，但却我们想要的，于是需要剔除。

success就是我们下厨的主要内容了，回调中的 payload参数，包含，主色、次色以及调色板信息，绝对可以满足我们绝大多数的需求。

三、rgbaster.js小使用

下面看看妹子是如何下厨的。

您可以狠狠地点击这里： rgbaster.js与slide图片背景变变变demo

点击下面的四个圆点按钮走起：

可以看到，图片slide的同时，容器的背景色也随着一起改变，而容器的背景色就是美女图片的主色。

截个图让大家感受下：

相关JS代码为：

$("#index a").powerSwitch({
    animation: "translate",
    classAdd: "active",
    onSwitch: function(target) {
        RGBaster.colors(target.find("img").get(0), {
          exclude: [ 'rgb(255,255,255)', 'rgb(0,0,0)' ],
          success: function(payload) {
            // 容器的背景色变成图片的主色 - payload.dominant
            $("#box").css("background-color", payload.dominant);
          }
        });    
    }    
}).eq(0).trigger("click");

powerSwitch为 自己的万能切换插件中的方法， onSwitch是slide切换的回调，回调执行的就是 rgbaster.js的 RGBaster.colors方法，不考虑黑白两色，让 box的背景色变成图片的主色，哈，很简单吧~

四、rgbaster.js的使用限制

1. 浏览器支持
由于使用Canvas的 getImageData获得图片颜色信息（我之前的 box-shadow图片生成工具也是用的这个）, 因此，需要IE9+浏览器支持；同时，使用了XMLHttpRequest2.0, 貌似要IE10+可以畅快使用（据说IE8/IE9可以使用 XDomainRequest对象实现类似功能，未研究，具体不详）；

2. 跨域限制
XMLHttpRequest2.0获得图片数据，本地数据自然无障碍，对于跨域的数据，需要设置。宗旨就是，控制 Access-Control-Allow-Origin，例如，你希望你站点的图片只有我站点可以访问，则想办法通过设置，使得请求信息中包含：

Access-Control-Allow-Origin: http://www.zhangxinxu.com

如果是所有站点，则：

Access-Control-Allow-Origin: *

不同的服务器设置是不一样的，大家自行百之谷之。

五、我想写一篇长篇小说

//zxx: 接开头。

面向的群体是，应该是同龄人。走搞笑风格还是严肃风格，应该带有搞笑，主旨但高大上。最好带点热血。恩~~

还有就是………………哎呀呀，好像很难的样子……按照这个节奏，估计还要再构思个半年~~

在此之前，还是多盘出点技术文章吧。

以上~~

本文为原创文章，会经常更新知识点以及修正一些错误，因此转载请保留原出处，方便溯源，避免陈旧错误知识的误导，同时有更好的阅读体验。
本文地址： http://www.zhangxinxu.com/wordpress/?p=4296

（本篇完）

<property><name>dfs.nameservices</name><value>hadoop-ha,hadoop-federation</value></property>

<property><name>dfs.ha.namenodes.hadoop-ha</name><value>nn1,nn2</value></property>

<property><name>dfs.namenode.rpc-address.hadoop-ha.nn1</name><value>machine1.example.com:8020</value></property><property><name>dfs.namenode.rpc-address.hadoop-ha.nn2</name><value>machine2.example.com:8020</value></property>

<property><name>dfs.namenode.http-address.hadoop-ha.nn1</name><value>machine1.example.com:50070</value></property><property><name>dfs.namenode.http-address.hadoop-ha.nn2</name><value>machine2.example.com:50070</value></property>

<property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/hadoop-ha</value></property>

<property><name>dfs.journalnode.rpc-address</name><value>0.0.0.0:8485</value></property><property><name>dfs.journalnode.http-address</name><value>0.0.0.0:8480</value></property>

<property><name>dfs.client.failover.proxy.provider.hadoop-ha</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property>

<property><name>dfs.ha.fencing.methods</name><value>shell(/path/to/my/script.sh arg1 arg2 ...)</value></property>

<property><name>fs.defaultFS</name><value>hdfs://hadoop-ha</value></property>

<property><name>dfs.ha.automatic-failover.enabled</name><value>true</value></property>

<property><name>ha.zookeeper.quorum</name><value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value></property>

• —软件人才免语言低担保 赴美带薪读研！—

http://tcc.taobao.com/cc/json/mobile_tel_segment.htm?tel=15850781443 

http://virtual.paipai.com/extinfo/GetMobileProductInfo?mobile=15850781443&amount=10000&callname=getPhoneNumInfoExtCallback 
参数： 
mobile：手机号码 
callname：回调函数 
amount：未知（必须） 
返回：JSON 

http://life.tenpay.com/cgi-bin/mobile/MobileQueryAttribution.cgi?chgmobile=15850781443 
参数： 
chgmobile：手机号码 
返回：xml 

https://www.baifubao.com/callback?cmd=1059&callback=phone&phone=15850781443 
参数： 
phone：手机号码 
callback：回调函数 
cmd：未知（必须） 
返回：JSON 

http://cz.115.com/?ct=index&ac=get_mobile_local&callback=jsonp1333962541001&mobile=15850781443 
参数： 
mobile：手机号码 
callback：回调函数 
返回：JSON 

http://www.youdao.com/smartresult-xml/search.s?type=mobile&q=13892101112 
参数说明： 
type ： 参数手机归属地固定为mobile 
q ： 手机号码 
返回XML格式： 
<?xml version="1.0" encoding="gbk"?> <smartresult> <product type="mobile"> <phonenum>13892101112</phonenum> <location>陕西 延安</location> </product> </smartresult> 
或者 
http://www.youdao.com/smartresult-xml/search.s?jsFlag=true&type=mobile&q=手机号码 
返回JSON格式： 
fYodaoCallBack(1, {‘product':'mobile','phonenum':'13892101112′,'location':'陕西 延安'} , ”);

• —软件人才免语言低担保 赴美带薪读研！—

基本步骤可以参考 这篇文章, 但这篇文章有一个致命错误, 就是没有安装 INTERMEDIATE CA, 照样会被浏览器显示证书不可信.

1. 生成 server.key.orig

sudo openssl genrsa -des3 -out server.key.orig 2048

2. 生成 server.csr 和 server.key

sudo openssl req -new -key server.key.orig -out server.csr
sudo openssl rsa -in server.key.orig -out server.key

3. 拿着 server.csr 去证书厂商买证书

4. 买完后, 厂商会给你发两个证书 server.crt 和 server.intermediate.crt

5. 生成最终的 server.chained.crt

cat server.crt server.intermediate.crt > server.chained.crt

6. 配置 nginx

ssl_certificate server.chained.crt;
ssl_certificate_key server.key;

Related posts:

1. 初学者的 Linux 安装 Nginx PHP fpm 配置教程
2. Nginx + PHP 配置和启动脚本
3. lighttpd配置HTTPS(SSL)
4. Nginx 499 错误码以及 AJAX 调用失败
5. nginx-push-stream-module 笔记

<link rel="apple-touch-icon-precomposed" sizes="114x114" href="icons/apple-touch-icon-114x114-precomposed.png"> # iphone4<link rel="apple-touch-icon-precomposed" sizes="72x72" href="icons/apple-touch-icon-72x72-precomposed.png"> # ipad<link rel="apple-touch-icon-precomposed" href="icons/apple-touch-icon-precomposed.png"> # android<link rel="shortcut icon" href="icons/apple-touch-icon.png"> # symbian60

var metas = document.getElementByTagName("meta");
var i;
if(navigator.userAgent.match("/iPhone/i)) {
  for(i=0; i<metas.length; i++) {
    if(meta[i].name == "viewport") {
      metas[i].content = "width=device-width, maximum-scale=1.0, minimum-scale=1.0";
    }
  }
  document.addEventListener("gesturestart", gestureStart, false);
}

function gestureStart() {
  for(i=0; i<metas.length; i++) {
    if(meta[i].name == "viewport") {
      metas[i].content = "width=device-width, maximum-scale=1.6, minimum-scale=0.25";
    }
  }
}

• —软件人才免语言低担保 赴美带薪读研！—

　　日前一款被称为“超级手机病毒”的木马再一次引爆了人们对Android系统安全性的担忧。而在这个二维码多的都闪瞎眼的时代，什么扫一下二维码支付宝钱就被转走了、扫一下二维码支付宝钱就立马被盗的消息比比皆是。

　　通过N多个例子，咱说下扫二维码支付宝钱被盗的流程：

　　扫描二维码→程序识别结果为链接→程序询问用户是否打开→打开链接后自动下载(自动下载是因为链接后缀为.apk)→下载完成→弹出APP安装界面→询问用户是否安装→用户选择安装→安装完成→点击打开或点击APP图标启动→手机中毒。

　　木马运行读取用户手机号码并发送到木马制作者→木马作者用手机号进行支付宝登陆→选择忘记密码→发送验证码到用户手机→木马拦截掉验证码短信并发送到木马制作者→密码修改成功→登陆支付宝→进行转账操作→选择忘记支付密码→发送验证码到用户手机→木马拦截掉验证码短信并发送到木马制作者→密码修改成功→转账成功。

　　步骤很多？其实真操作起来也就分分钟的事儿，红色标注的均为用户的操作，好几个步骤呢？谁把自己卖了？还是用户自己..

　　在此，我们并不去谈涉及到Android系统本身漏洞的问题，毕竟大部分病毒只是简单的利用用户安全意识低这方面。

　　所以说到底还是用户自己的安全意识低了，所以各大媒体各种报道如上图那种资讯还是很有用的，提醒用户一定得谨慎扫码。

　　不过支付宝现在已经在修改密码环节增加了需要输入身份证号的验证，那么你可能会想，木马作者又怎么知道用户的身份证号的呢？方法很多，比如那个“超级木马病毒”的流程里有这么一个注册环节，要求用户输入帐号、密码、身份证号和姓名。

　　身份证号是如何泄露的呢？如何泄露的呢？泄露的呢？的呢？病毒作者还是很用心的…输入姓名、身份证号、账号、密码点击注册后，悲剧了，信息发到木马制作者那了。

　　至此，木马作者获得了修改支付宝密码、支付密码的所有需要的东西，于是…开工干活，转账…

　　账号有修改密码时、转账操作后，支付宝均会通过“95188”这个号码发送短信到用户手机，不过估计用户也看不到短信了，木马全给拦截了..

　　这里还有一点，就是账号和密码问题，如果你习惯性用相同的账号和密码去注册N个网站，那么泄露的就不止支付宝了，所以网上有专家也不止一次的提醒尽量不要使用相同的账号去注册各种账号，不然一个泄露，所有的网站信息全部可以被窃取了。

　　基本上木马都是如上述的工作流程，来窃取用户的信息。

　　为什么哭晕在厕所的总是支付宝？因为用的人多呀，支付宝一类的在线支付工具，如支付宝、财付通，基本上都可以通过上述操作来获取用户的信息。

　　那么网银呢？网银为什么也中招？网银不是需要网银盾口令校验么？

　　对呀，是需要呀，所以安全性相对来说也高了不少呀（至少在手机上是的..），但是别忘了支付宝绑定了银行卡，同样可以进行充值操作。

　　另外网银也有手机支付，比如去12306买个火车票，选择建行支付，其中有一项就是通过发送个手机验证码完成支付宝的，当然，这还需要卡号、密码等等，如何泄露的，这个就得您自个想想了。

　　上面的一堆分（fei）析（hua）到此结束了，下面笔者说说如何防范此类事情的发生。

　　 如何防范此类事情：

　　1、首先最好给手机安装一个安全软件，比如360手机卫士、腾讯手机管家、金山毒霸、百度手机卫士、Avast!等，这些安全软件基本都能在下载和安装阶段拦截掉病毒。

　　2、还可以安装一些如LBE安全大师一类的APP，APP在发送短信的时候弹出提醒，会弹出询问用户是否发送的提示；

　　3、专家的话：不要随意扫描二维码、下载apk文件，更不要随意安装您不认识的APP；

　　4、不要主动下载那些具有诱惑性的名字的APP，比如什么XX神器、看X神器、快X神器，这类一般多出现在某些你懂得小网站上面，多半不是病毒就是流氓软件；

　　 如果发现异常如何处理：

　　1、安装了一个app，安装完却没有图标，怎么打开呢？不用找了，多半是中毒了，立马把手机开启飞行模式，并关闭Wlan，这样可以阻止病毒通过短信或联网方式发送用户信息到木马制作者那；当然，关机也行。

　　2、开启飞行模式 、断开网络、关机以后先不要忙着怎么处理手机，去支付宝官方网站把余额转入关联的银行卡并解除绑定的银行卡；

　　3、处理手机：断开网络（最好把手机卡拔了）没法下载安全软件怎么办，用数据线连接电脑去豌豆荚、360助手、腾讯助手之类的下载安装安全软件进行手机查杀；

　　4、查杀了还不放心？备份下重要资料，如通讯录、短信、通话记录、照片等，豌豆荚、360助手、腾讯助手之类的同样有这些功能，备份后把手机恢复出厂设置、格式化内存卡，或者直接通过刷机精灵、刷机大师一类的软件对手机进行刷机操作。

　　涉及到钱的问题，相信你不会嫌麻烦….

　　还有这个“超级手机病毒”的传播问题，相信大家都知道了作者为某高校大一学生，已经被抓。这个病毒很复杂么？不复杂，甚至有些媒体发文说这类所谓的“超级”病毒，简直就是几个小工具拼凑出来的，如此简陋没想到还会这么大规模传播。

　　笔者最早看到关于这个病毒的消息是在8月2日的下午13:15分，从知道创宇@余弦的微博上看到的，其中@余弦称这个病毒为半成品，在16:58分，@91ri_我的安全攻防发布了分析报告，包括传播方式、原理甚至最后连病毒作者的姓名、QQ、QQ密码、手机号码、住址和某高校学生的信息全部获得了。

　　但是这些信息并没有引起足够的关注，在随后的一天及8月4日，媒体才大规模报道，同时运营商也发微博说开始拦截了，不过相信这会儿已经传播规模到非常大的级别了吧？

　　嗯，所以，时常关注一下此类信息还是非常有用的，可以在第一时间获得这些信息，避免自己中招。

　　来源：蓝点网原创文章投稿，作者：山外的鸭子哥， 原文链接。

评论《Android手机真的那么容易中毒吗？》的内容...

相关文章:

• “超级手机病毒”凸显安卓安全隐患
• Google为什么要限制GMS
• Google公布2013年最佳Android应用和游戏名单
• Google Play发布年度精选榜单
• Android系统的五大误区

支持各种控件下拉刷新
ListView、ViewPager、WevView、ExpandableListView、GridView、(Horizontal

• —软件人才免语言低担保 赴美带薪读研！—

由于同源策略的限制，JavaScript跨域的问题，一直是一个比较棘手的问题，为了解决页面之间的跨域通信，大家煞费苦心，研究了各种跨域方案。之前也有小网同学分享过一篇“ 跨域，不再纠结” 开始照着尝试时还是有些不够明白的地方，深入了解之后，这里给大家补充一点更具体的做法。

先来看看哪些情况下才存在跨域的问题：

其中编号6、7两种情况同属于主域名相同的情况，可以设置domain来解决问题，今天就不讨论这种情况了。 对于其他跨域通信的问题，我想又可以分成两类， 其一（第一种情况）是a.com下面的a.js试图请求b.com下某个接口时产生的跨域问题。 其二（第二种情况）是当a.com与b.com下面的页面成父子页面关系时试图互相通信时产生的跨域问题，典型的应用场景如a.com/a.html使用iframe内嵌了b.com/b.html，大家都知道a.html内的js脚本试图访问b.html时是会被拒绝的，反之亦然。  第一种情况，目前主流的方案是JSONP，高版本浏览器支持html5的话，还可以使用XHR2支持跨域通信的新特性。  第二种情况，目前主要是通过代理页面或者使用postMessageAPI来做， 这也是今天要讨论的话题。 第二种情况，有这样一些类似的案例：a.com/a.html使用iframe内嵌了b.com/b.html，现在希望iframe的高度能自动适应 b.html的高度，使iframe不要出现滚动条。我们都知道跨域了，a.html是没办法直接读取到b.html的高度的，b.html也没办法把自 己的高度告诉a.html。 直接说可以用代理页面的方法搞定这个问题吧，但是怎么代理法，先来看下面这张图：

图1

b.html与a.html是不能直接通信的。我们可以在b.html下面再iframe内嵌一个proxy.html页面，因为这个页面是放在 a.com下面的，与a.html同域，所以它其实是可以和a.html直接通信的，假如a.html里面有定义一个方法_callback，在 proxy.html可以直接top._callback()调用它。但是b.html本身和proxy.html也是不能直接通信的，所谓代理页面的桥 梁作用怎么实现呢? b.html内嵌proxy.html是通过一段类似下面这样的代码： <iframe id=”proxy” src=”a.com/proxy.html” name=”proxy” frameborder=”0″ width=”0″ height=”0″></iframe> 这个iframe的src属性b.html是有权限控制的。如果它把src设置成a.com/proxy.html?args=XXX,也就是给url加 一个查询字符串，proxy.html内的js是可以读取到的。对的，这个url的查询字符串就是b.html和proxy.html之间通信的桥梁，美 中不足的是每次通信都要重写一次url造成一次网络请求，这有时会对服务器及页面的运行效率产生很大的影响。同时由于参数是通过url来传递的，会有长度 和数据类型的限制，搜集的资料显示：

• IE浏览器对URL的长度现限制为2048字节。
• 360极速浏览器对URL的长度限制为2118字节。
• Firefox(Browser)对URL的长度限制为65536字节。
• Safari(Browser)对URL的长度限制为80000字节。
• Opera(Browser)对URL的长度限制为190000字节。
• Google(chrome)对URL的长度限制为8182字节。

上面的方法，通过迂回战术实现了b.html跟a.html通信，但是倒过来，a.html怎么跟b.html通信呢?嵌入在b.html里面的 proxy.html可以用top快速的联系上a.html，但是要想让a.html找到proxy.html就不容易了，夹在中间的 b.html生生把它们分开了，a.html没法让b.html去找到proxy.html然后返回给它。只能采用更迂回的战术了。 顺着前面b.html到a.html的通信过程，逆向的想一下，虽然a.html没有办法主动找到proxy.html，但是proxy.html可以反 过来告诉a.html它在哪里： 在proxy.html加这么一段脚本：

var topWin = top;
function getMessage(data) {
    alert("messageFormTopWin:" + data);
}
function sendMessage(data) {
    topWin.proxyWin = window;
    topWin.getMessage(data);
}

在a.html加这么一段脚本：

var proxyWin = null;
function getMessage(data) {
    alert("messageFormProxyWin:"+data);
    sendMessage("top has receive data:"+data);
}

function sendMessage(data) {
    if (null != proxyWin) {
        proxyWin.getMessage(data);
    }
}

也就是必须由proxy.html先主动发送一个消息给a.html，a.html得到proxy.html页面window的引用，就可以反过来 向它发送请求了。 现在a.html可以把消息发给proxy.html了，但是proxy.html怎么把消息转送到b.html？似乎这才是难点，因为它们之间才真正有 着“跨域”这一道鸿沟。 这回我们不再用前面那个iframe内嵌代理页面的方法再在proxy.html内嵌一个b.com下面的代理页面了，这样实在会给人感觉嵌的太深了，四 层。但是为了跨越这道鸿沟，b.com下面也加一个代理页面是免不的。不过现在我们要利用一下window.name。window.name有一个特 性，就是页面在同一个浏览器窗口（标签页）中跳转时，它一直存在而且值不会改变。比如我们在a.html中设置了window.name=”a”,然后 location.href=” http://b.com/b.html”跳转 后，b.html可以读取window.name的值为”a”;而且window.name的值长度一般可以到达2M，ie和firefox甚至可以达到 32M，这样的存储容量，足够利用起来做跨域的数据传递了。好吧，我们现在要做的就是当proxy.html拿到a.html发送过来的数据后把这个数据 写入window.name中，然后跳转到b.com下面的代理页面，我们这里假设是bproxy.html。bproxy.html读取到 window.name值后，通知给它父页面b.html就简单了。我们再来看这个过程可以用图大概示意一下：

图2

图例中绿色的双向箭头表示可以通信，橙色的双向箭头表示不能直接通信。 最后我们简单看一下双向通信的实测效果：

图3

b.html每次加载的时候都先给a.html发一个”连接请求”，让a.html可以找到proxy.html。所以页面第一次加载的时候会产生三个请求：

图4

每次b.html向a.html发送消息的时候会产生一个请求：

图5

每次a.html向b.html发送消息的时候会产生两个请求，其中一个是a.com/proxy.html向b.com/bproxy.html跳转产生的，另一个是b.html重新向a.html发起“连接请求”时产生的：

图6

最后简单看一下实测的几个测试页面代码：  代码片段一，a.com/a.html:

<html xmlns="http://www.w3.org/1999/xhtml"><head><title>a.com</title></head><body><div id="Div1">
        A.com/a.html</div><input id="txt_msg" type="text" /><input id="Button1" type="button" value="向b.com/b.html发送一条消息" onclick="sendMessage(document.getElementById('txt_msg').value)" /><div id="div_msg"></div><iframe width="800" height="400" id="mainFrame" src="<a href="http://localhost:8091/b.com/b.htm">http://localhost:8091/b.com/b.htm</a>"></iframe><script type="text/javascript">
        var proxyWin = null;
        function showMsg(msg) {
            document.getElementById("div_msg").innerHTML = msg;
        }
        function getMessage(data) {
            showMsg("messageForm b.html to ProxyWin:" + data);
        }
        function sendMessage(data) {
            if (null != proxyWin) {
                proxyWin.getMessage(data);
            }
        }</script></body></html>

代码片段二，a.com/proxy.html:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>"><head><title>a.com</title></head><body><div id="Div1">A.com/proxy.html</div><div id="div_msg"></div><script type="text/javascript">
    var topWin = top;
    function showMsg(msg) {
        document.getElementById("div_msg").innerHTML = msg;
    }

    function getMessage(data) {
        showMsg("messageForm A.com/a.html:" + data + "<br/>两¢?秒?后¨®将?跳¬?转Áa到Ì?B.com/bproxy.html");
        window.name = data;
        setTimeout(function () { location.href = "<a href="http://localhost:8091/b.com/bproxy.htm">http://localhost:8091/b.com/bproxy.htm</a>" }, 2000);// 为了能让大家看到跳转的过程，所以加了个延时
    }

    function sendMessage(data) {
        topWin.proxyWin = window;
        topWin.getMessage(data);
    }

    var search = location.search.substring(1);
    showMsg("messageForm B.com/b.html:" + search);
    sendMessage(search);</script></body></html>

代码片段三，b.com/b.html:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>"><head><title>b.com</title></head><body><div id="Div1">
        B.com/b.html</div><input id="txt_msg" type="text" /><input id="Button1" type="button" value="向A.com/a.html发送一条消息" onclick="sendMessage(document.getElementById('txt_msg').value)" /><div id="div_msg"></div><iframe id="proxy" name="proxy" style="width: 600px; height: 300px"></iframe><script type="text/javascript">
        function showMsg(msg) {
            document.getElementById("div_msg").innerHTML = msg;
        }
        function sendMessage(data) {
            var proxy = document.getElementById("proxy");
            proxy.src="<a href="http://localhost:8090/a.com/proxy.htm?data">http://localhost:8090/a.com/proxy.htm?data</a>=" + data;
        }
        function connect() {
            sendMessage("connect");
        }
        function getMessage(data) {
            showMsg("messageForm a.html to ProxyWin:" + data);
            connect();
        }

        connect(); // 页面一加载，就执行一次连接
    </script></body></html>

码片段四，b.com/bproxy.html：

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>"><head><title>b.com</title></head><body><div id="Div1">
        B.com/bproxy.html</div><div id="div_msg"></div><script type="text/javascript">
        var parentWin = parent;
        var data = null;

        function getMessage() {
            if (window.name) {
                data = window.name;
                parentWin.getMessage(data);
            }
            document.getElementById("div_msg").innerHTML = "messageForm a.com/proxy.html:" + data;

        }
        getMessage();         
    </script></body></html>

好吧，现在我必须把话锋调转一下了。前面讲的这么多，也只是抛出来一些之前我们可能会采用的跨域通信方法，事实上代理页面、url传参数和 window.name、甚至还有一些利用url的hash值的跨域传值方法，都能百度到不少相关资料。但它们都逃不开代理页面，也就不可避免的要产生网 络请求，而事实上这并不是我们的本意，我们原本希望它们能够直接在客户端通信，避免不必要的网络请求开销——这些开销，在访问量超大的站点可能会对服务器 产生相当大的压力。那么，有没有更完美一点的替代方案呢？ 必须给大家推荐postMessage。postMessage 正是为了满足一些合理的、不同站点之间的内容能在浏览器端进行交互的需求而设计的。利用postMessage API实现跨域通信非常简单，我们直接看一下实例的代码：

代码片段五，A.com/a.html：

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>"><head runat="server"><title>A.com/a.html</title><script type="text/javascript">
        var trustedOrigin = "<a href="http://localhost:8091/">http://localhost:8091</a>";

        function messageHandler(e) {
            if (e.origin == trustedOrigin) {//接收消息的时候，判断消息是否来自可信的源，这个源是否可信则完全看自己的定义了。
                showMsg(e.data);//e.data才是真实要传递的数据
            } else {
                // ignore messages from other origins
            }
        }

        function sendString(s) {//发送消息
            document.getElementById("widget").contentWindow.postMessage(s, trustedOrigin);
        }

        function showMsg(message) {
            document.getElementById("status").innerHTML = message;
        }

        function sendStatus() {
            var statusText = document.getElementById("statusText").value;
            sendString(statusText);
        }

        function loadDemo() {
            addEvent(document.getElementById("sendButton"), "click", sendStatus);
            sendStatus();
        }

        function addEvent(obj, trigger, fun) {
            if (obj.addEventListener) obj.addEventListener(trigger, fun, false);
            else if (obj.attachEvent) obj.attachEvent('on' + trigger, fun);
            else obj['on' + trigger] = fun;
        }
        addEvent(window, "load", loadDemo);
        addEvent(window, "message", messageHandler);</script></head><body><h1>A.com/a.html</h1><p><b>源</b>: <a href="http://localhost:8090</p">http://localhost:8090</p</a>><input type="text" id="statusText" value="msg from a.com/a.html"><button id="sendButton">向b.com/b.html发送消息</button><p>接收到来自a.com/a.html的消息: <strong id="status"></strong>.<p><iframe id="widget" width="800" height="400" src="<a href="http://localhost:8091/PostMessage/Default.aspx%22%3E%3C/iframe">http://localhost:8091/PostMessage/Default.aspx"></iframe</a>></body></html>

代码片段六，B.com/b.html:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>"><head runat="server"><title>B.com/b.html</title><script type="text/javascript">
        //检查postMessage 是否可以用：window.postMessage===undefined
        //定义信任的消息源
        var trustedOrigin = "<a href="http://localhost:8090/">http://localhost:8090</a>";
        function messageHandler(e) {
            if (e.origin === "<a href="http://localhost:8090/">http://localhost:8090</a>") {
                showMsg(e.data);
            } else {
                // ignore messages from other origins
            }
        }

        function sendString(s) {
            window.top.postMessage(s, trustedOrigin); //第二个参数是消息传送的目的地
        }

        function loadDemo() {
            addEvent(document.getElementById("actionButton"), "click", function () {
                var messageText = document.getElementById("messageText").value;
                sendString(messageText);
            });
        }

        function showMsg(message) {
            document.getElementById("status").innerHTML = message;
        }

        function addEvent(obj, trigger, fun) {
            if (obj.addEventListener) obj.addEventListener(trigger, fun, false);
            else if (obj.attachEvent) obj.attachEvent('on' + trigger, fun);
            else obj['on' + trigger] = fun;
        }
        addEvent(window, "load", loadDemo);
        addEvent(window, "message", messageHandler);</script></head><body><h1>B.com/b.html</h1><p><b>源</b>: <a href="http://localhost:8091</p">http://localhost:8091</p</a>><p>接收到来自a.com/a.html的消息: <strong id="status"></strong>.<p><div><input type="text" id="messageText" value="msg from b.com/b.html"><button id="actionButton"> 向a.com/a.html发送一个消息</button></div></body></html>

代码的关键是message事件是一个拥有data（数据）和origin(来源)属性的DOM事件。data属性是发送的实际数据，origin 属性是发送来源。Origin属性很关键，有了这个属性，接收方可以轻易的忽略掉来自不可信源的消息，也就能有效避免跨域通信这个开口给我们的源安全带来 的隐患。接口很强大，所以代码很简单。我们可以抓包看一下，这个通信过程完全是在浏览器端的，没有产生任何的网络请求。同时这个接口目前已经得到了绝大多 数浏览器的支持，包括IE8及以上版本，参见下面的图表：

图7

但是为了覆盖ie6等低版本浏览器，我们完整的方案里面还是要包含一下兼容代码，就是最开始介绍的代理页面的方法了，但必须是以postMessage为主，这样即便最后会有某些浏览器因为这种通信产生一些网络请求，比例也是非常低的了。

转自：http://tid.tenpay.com/?p=4695