html5计划上是可以录音和摄像的,见http://www.w3.org/TR/html-media-capture/

但这只是规划，还没有那个浏览器支持这个功能，而且api也可能会有很大改动。

另外google开源了webRTC,这个似乎比上面的api要实在些，起码chrome,firefox和opera是表明要支持的。

http://www.w3.org/TR/webrtc/

Continue reading html5 可以录音录像吗

转自:http://cloud.csdn.net/a/20120214/311806.html

导读：和许多新兴的网站一样，著名的轻博客服务Tumblr在急速发展中面临了系统架构的瓶颈。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，超过1000台服务器，这样的情况下如何保证老系统平稳运行，平稳过渡到新的系统，Tumblr正面临巨大的挑战。近日，HighScalability网站的Todd Hoff采访了该公司的分布式系统工程师Blake Matheny，撰文系统介绍了网站的架构，内容很有价值。我们也非常希望国内的公司和团队多做类似分享，贡献于社区的同时，更能提升自身的江湖地位，对招聘、业务发展都好处多多。欢迎通过@CSDN云计算的微博向我们投稿。

以下为译文的第一部分。第二部分点这里。（括号内小号字为CSDN编辑所注）：

Tumblr每月页面浏览量超过150亿次，已经成为火爆的博客社区。用户也许喜欢它的简约、美丽，对用户体验的强烈关注，或是友好而忙碌的沟通方式，总之，它深得人们的喜爱。

每月超过30%的增长当然不可能没有挑战，其中可靠性问题尤为艰巨。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，并运行于超过1000台服务器上，所有这些帮助Tumblr实现巨大的经营规模。

创业公司迈向成功，都要迈过危险的迅速发展期这道门槛。寻找人才，不断改造基础架构，维护旧的架构，同时要面对逐月大增的流量，而且曾经只有4位工程师。这意味着必须艰难地选择应该做什么，不该做什么。这就是Tumblr的状况。好在现在已经有20位工程师了，可以有精力解决问题，并开发一些有意思的解决方案。

Tumblr最开始是非常典型的LAMP应用。目前正在向分布式服务模型演进，该模型基于Scala、HBase、Redis（著名开源K-V存储方案）、Kafka（Apache项目，出自LinkedIn的分布式发布-订阅消息系统）、Finagle（由Twitter开源的容错、协议中立的RPC系统），此外还有一个有趣的基于Cell的架构，用来支持Dashboard（CSDN注：Tumblr富有特色的用户界面，类似于微博的时间轴）。

Tumblr目前的最大问题是如何改造为一个大规模网站。系统架构正在从LAMP演进为最先进的技术组合，同时团队也要从小的创业型发展为全副武装、随时待命的正规开发团队，不断创造出新的功能和基础设施。下面就是Blake Matheny对Tumblr系统架构情况的介绍。

网站地址

http://www.tumblr.com/

主要数据

•     每天5亿次PV（页面访问量）
•     每月超过150亿PV
•     约20名工程师
•     峰值请求每秒近4万次
•     每天超过1TB数据进入Hadoop集群
•     MySQL/HBase/Redis/memcache每天生成若干TB数据
•     每月增长30%
•     近1000硬件节点用于生产环境
•     平均每位工程师每月负责数以亿计的页面访问
•     每天上传大约50GB的文章，每天跟帖更新数据大约2.7TB（CSDN注：这两个数据的比例看上去不太合理，据Tumblr数据科学家Adam Laiacano在Twitter上解释，前一个数据应该指的是文章的文本内容和元数据，不包括存储在S3上的多媒体内容）

软件环境

•     开发使用OS X，生产环境使用Linux（CentOS/Scientific）
•     Apache
•     PHP, Scala, Ruby
•     Redis, HBase, MySQL
• Varnish, HAProxy, nginx
•     memcache, Gearman（支持多语言的任务分发应用框架）, Kafka, Kestrel（Twitter开源的分布式消息队列系统）, Finagle
•     Thrift, HTTP
• Func——一个安全、支持脚本的远程控制框架和API
•     Git, Capistrano（多服务器脚本部署工具）, Puppet, Jenkins

硬件环境

•     500台Web服务器
•     200台数据库服务器（47 pool，20 shard）
•     30台memcache服务器
•     22台Redis服务器
•     15台Varnish服务器
•     25台HAproxy节点
•     8台nginx服务器
•     14台工作队列服务器（Kestrel + Gearman）

架构

    1. 相对其他社交网站而言，Tumblr有其独特的使用模式：

•     每天有超过5千万篇文章更新，平均每篇文章的跟帖又数以百计。用户一般只有数百个粉丝。这与其他社会化网站里少数用户有几百万粉丝非常不同，使得Tumblr的扩展性极具挑战性。
•     按用户使用时间衡量，Tumblr已经是排名第二的社会化网站。内容的吸引力很强，有很多图片和视频，文章往往不短，一般也不会太长，但允许写得很长。文章内容往往比较深入，用户会花费更长的时间来阅读。
•     用户与其他用户建立联系后，可能会在Dashboard上往回翻几百页逐篇阅读，这与其他网站基本上只是部分信息流不同。
•     用户的数量庞大，用户的平均到达范围更广，用户较频繁的发帖，这些都意味着有巨量的更新需要处理。

    2. Tumblr目前运行在一个托管数据中心中，已在考虑地域上的分布性。

    3. Tumblr作为一个平台，由两个组件构成：公共Tumblelogs和Dashboard

•     公共Tumblelogs与博客类似（此句请Tumblr用户校正），并非动态，易于缓存
•     Dashboard是类似于Twitter的时间轴,用户由此可以看到自己关注的所有用户的实时更新。与博客的扩展性不同，缓存作用不大，因为每次请求都不同，尤其是活跃的关注者。而且需要实时而且一致，文章每天仅更新50GB，跟帖每天更新2.7TB，所有的多媒体数据都存储在S3上面。
•     大多数用户以Tumblr作为内容浏览工具，每天浏览超过5亿个页面，70%的浏览来自Dashboard。
•     Dashboard的可用性已经不错，但Tumblelog一直不够好，因为基础设施是老的，而且很难迁移。由于人手不足，一时半会儿还顾不上。

老的架构

Tumblr最开始是托管在Rackspace上的，每个自定义域名的博客都有一个A记录。当2007年Rackspace无法满足其发展速度不得不迁移时，大量的用户都需要同时迁移。所以他们不得不将自定义域名保留在Rackspace，然后再使用HAProxy和Varnish路由到新的数据中心。类似这样的遗留问题很多。

开始的架构演进是典型的LAMP路线：

• 最初用PHP开发，几乎所有程序员都用PHP
• 最初是三台服务器：一台Web，一台数据库，一台PHP
• 为了扩展，开始使用memcache，然后引入前端cache，然后在cache前再加HAProxy，然后是MySQL sharding（非常奏效）
• 采用“在单台服务器上榨出一切”的方式。过去一年已经用C开发了两个后端服务：ID生成程序和Staircar（用Redis支持Dashboard通知）

Dashboard采用了“扩散-收集”方式。当用户访问Dashboard时将显示事件，来自所关注的用户的事件是通过拉然后显示的。这样支撑了6个月。由于数据是按时间排序的，因此sharding模式不太管用。

新的架构

由于招人和开发速度等原因，改为以JVM为中心。目标是将一切从PHP应用改为服务，使应用变成请求鉴别、呈现等诸多服务之上的薄层。

这其中，非常重要的是选用了Scala和Finagle。

• 在团队内部有很多人具备Ruby和PHP经验，所以Scala很有吸引力。
• Finagle是选择Scala的重要因素之一。这个来自Twitter的库可以解决大多数分布式问题，比如分布式跟踪、服务发现、服务注册等。
• 转到JVM上之后，Finagle提供了团队所需的所有基本功能（Thrift, ZooKeeper等），无需再开发许多网络代码，另外，团队成员认识该项目的一些开发者。
• Foursquare和Twitter都在用Finagle，Meetup也在用Scala。
• 应用接口与Thrift类似，性能极佳。
• 团队本来很喜欢Netty（Java异步网络应用框架，2月4日刚刚发布3.3.1最终版），但不想用Java，Scala是不错的选择。
• 选择Finagle是因为它很酷，还认识几个开发者。

之所以没有选择Node.js，是因为以JVM为基础更容易扩展。Node的发展为时尚短，缺乏标准、最佳实践以及大量久经测试的代码。而用Scala的话，可以使用所有Java代码。虽然其中并没有多少可扩展的东西，也无法解决5毫秒响应时间、49秒HA、4万每秒请求甚至有时每秒40万次请求的问题。但是，Java的生态链要大得多，有很多资源可以利用。

内部服务从C/libevent为基础正在转向Scala/Finagle为基础。

开始采用新的NoSQL存储方案如HBase和Redis。但大量数据仍然存储在大量分区的MySQL架构中，并没有用HBase代替MySQL。HBase主要支持短地址生产程序（数以十亿计）还有历史数据和分析，非常结实。此外，HBase也用于高写入需求场景，比如Dashboard刷新时一秒上百万的写入。之所以还没有替换HBase，是因为不能冒业务上风险，目前还是依靠人来负责更保险，先在一些小的、不那么关键的项目中应用，以获得经验。MySQL和时间序列数据sharding（分片）的问题在于，总有一个分片太热。另外，由于要在slave上插入并发，也会遇到读复制延迟问题。

此外，还开发了一个公用服务框架：

• 花了很多时间解决分布式系统管理这个运维问题。
• 为服务开发了一种Rails scaffolding，内部用模板来启动服务。
• 所有服务从运维的角度来看都是一样的，所有服务检查统计数据、监控、启动和停止的方式都一样。
• 工具方面，构建过程围绕SBT（一个Scala构建工具），使用插件和辅助程序管理常见操作，包括在Git里打标签，发布到代码库等等。大多数程序员都不用再操心构建系统的细节了。

200台数据库服务器中，很多是为了提高可用性而设，使用的是常规硬件，但MTBF（平均故障间隔时间）极低。故障时，备用充足。

为了支持PHP应用有6个后端服务，并有一个小组专门开发后端服务。新服务的发布需要两到三周，包括Dashboard通知、Dashboard二级索引、短地址生成、处理透明分片的memcache代理。其中在MySQL分片上耗时很多。虽然在纽约本地非常热，但并没有使用MongoDB，他们认为MySQL的可扩展性足够了。

Gearman用于会长期运行无需人工干预的工作。

可用性是以达到范围（reach）衡量的。用户能够访问自定义域或者Dashboard吗？也会用错误率。

历史上总是解决那些最高优先级的问题，而现在会对故障模式系统地分析和解决，目的是从用户和应用的角度来定成功指标。（后一句原文似乎不全）

最开始Finagle是用于Actor模型的，但是后来放弃了。对于运行后无需人工干预的工作，使用任务队列。而且Twitter的util工具库中有Future实现，服务都是用Future（Scala中的无参数函数，在与函数关联的并行操作没有完成时，会阻塞调用方）实现的。当需要线程池的时候，就将Future传入Future池。一切都提交到Future池进行异步执行。

Scala提倡无共享状态。由于已经在Twitter生产环境中经过测试，Finagle这方面应该是没有问题的。使用Scala和Finagle中的结构需要避免可变状态，不使用长期运行的状态机。状态从数据库中拉出、使用再写回数据库。这样做的好处是，开发人员不需要操心线程和锁。

22台Redis服务器，每台的都有8-32个实例，因此线上同时使用了100多个Redis实例。

• Redis主要用于Dashboard通知的后端存储。
• 所谓通知就是指某个用户like了某篇文章这样的事件。通知会在用户的Dashboard中显示，告诉他其他用户对其内容做了哪些操作。
• 高写入率使MySQL无法应对。
• 通知转瞬即逝，所以即使遗漏也不会有严重问题，因此Redis是这一场景的合适选择。
• 这也给了开发团队了解Redis的机会。
• 使用中完全没有发现Redis有任何问题，社区也非常棒。
• 开发了一个基于Scala Futures的Redis接口，该功能现在已经并入了Cell架构。
• 短地址生成程序使用Redis作为一级Cache，HBase作为永久存储。
• Dashboard的二级索引是以Redis为基础开发的。
• Redis还用作Gearman的持久存储层，使用Finagle开发的memcache代理。
• 正在缓慢地从memcache转向Redis。希望最终只用一个cache服务。性能上Redis与memcache相当。

（先到这里吧，敬请期待下篇，包括如何用Kafaka、Scribe、Thrift实现内部活动流，Dashboard的Cell架构，开发流程和经验教训等精彩内容。）

翻译：包研，张志平，刘江；审校：刘江

---

内部的firehose(通信管道)

• 内部的应用需要活跃的信息流通道。这些信息包括用户创建/删除的信息，liking/unliking的提示，等等。挑战在于这些数据要实时的分布式处理。我们希望能够检测内部运行状况，应用的生态系统能够可靠的生长，同时还需要建设分布式系统的控制中心。
• 以前，这些信息是基于Scribe(Facebook开源的分布式日志系统。)/Hadoop的分布式系统。服务会先记录在Scribe中，并持续的长尾形式写入，然后将数据输送给应用。这种模式可以立即停止伸缩，尤其在峰值时每秒要创建数以千计的信息。不要指望人们会细水长流式的发布文件和grep。
• 内部的firehose就像装载着信息的大巴，各种服务和应用通过Thrift与消防管线沟通。(一个可伸缩的跨语言的服务开发框架。)
• LinkedIn的Kafka用于存储信息。内部人员通过HTTP链接firehose。经常面对巨大的数据冲击，采用MySQL显然不是一个好主意，分区实施越来越普遍。
• firehose的模型是非常灵活的，而不像Twitter的firehose那样数据被假定是丢失的。
•     firehose的信息流可以及时的回放。他保留一周内的数据，可以调出这期间任何时间点的数据。
•     支持多个客户端连接，而且不会看到重复的数据。每个客户端有一个ID。Kafka支持客户群，每个群中的客户都用同一个ID，他们不会读取重复的数据。可以创建多个客户端使用同一个ID，而且不会看到重复的数据。这将保证数据的独立性和并行处理。Kafka使用ZooKeeper(Apache推出的开源分布式应用程序协调服务。)定期检查用户阅读了多少。

为Dashboard收件箱设计的Cell架构

• 现在支持Dashboard的功能的分散-集中架构非常受限，这种状况不会持续很久。
•     解决方法是采用基于Cell架构的收件箱模型，与Facebook Messages非常相似。
•     收件箱与分散-集中架构是对立的。每一位用户的dashboard都是由其追随者的发言和行动组成的，并按照时间顺序存储。
•     就因为是收件箱就解决了分散-集中的问题。你可以会问到底在收件箱中放了些什么，让其如此廉价。这种方式将运行很长时间。

• 重写Dashboard非常困难。数据已经分布，但是用户局部升级产生的数据交换的质量还没有完全搞定。
•     数据量是非常惊人的。平均每条消息转发给上百个不同的用户，这比Facebook面对的困难还要大。大数据+高分布率+多个数据中心。
•     每秒钟上百万次写入，5万次读取。没有重复和压缩的数据增长为2.7TB，每秒百万次写入操作来自24字节行键。
•     已经流行的应用按此方法运行。

• cell
•     每个cell是独立的，并保存着一定数量用户的全部数据。在用户的Dashboard中显示的所有数据也在这个cell中。
•     用户映射到cell。一个数据中心有很多cell。
•     每个cell都有一个HBase的集群，服务集群，Redis的缓存集群。
•     用户归属到cell，所有cell的共同为用户发言提供支持。
•     每个cell都基于Finagle（Twitter推出的异步的远程过程调用库），建设在HBase上，Thrift用于开发与firehose和各种请求与数据库的链接。(请纠错)
•     一个用户进入Dashboard，其追随者归属到特定的cell，这个服务节点通过HBase读取他们的dashboard并返回数据。
•     后台将追随者的dashboard归入当前用户的table，并处理请求。
•     Redis的缓存层用于cell内部处理用户发言。

• 请求流：用户发布消息，消息将被写入firehose，所有的cell处理这条消息并把发言文本写入数据库，cell查找是否所有发布消息追随者都在本cell内，如果是的话，所有追随者的收件箱将更新用户的ID。（请纠错）

• cell设计的优点：
•     大规模的请求被并行处理，组件相互隔离不会产生干扰。 cell是一个并行的单位，因此可以任意调整规格以适应用户群的增长。
•     cell的故障是独立的。一个Cell的故障不会影响其他cell。
•     cell的表现非常好，能够进行各种升级测试，实施滚动升级，并测试不同版本的软件。

• 关键的思想是容易遗漏的：所有的发言都是可以复制到所有的cell。
•     每个cell中存储的所有发言的单一副本。 每个cell可以完全满足Dashboard呈现请求。应用不用请求所有发言者的ID，只需要请求那些用户的ID。(“那些用户”所指不清，请指正。)他可以在dashboard返回内容。每一个cell都可以满足Dashboard的所有需求，而不需要与其他cell进行通信。
•     用到两个HBase table ：一个table用于存储每个发言的副本，这个table相对较小。在cell内，这些数据将与存储每一个发言者ID。第二个table告诉我们用户的dashboard不需要显示所有的追随者。当用户通过不同的终端访问一个发言，并不代表阅读了两次。收件箱模型可以保证你阅读到。
•     发言并不会直接进入到收件箱，因为那实在太大了。所以，发言者的ID将被发送到收件箱，同时发言内容将进入cell。这个模式有效的减少了存储需求，只需要返回用户在收件箱中浏览发言的时间。而缺点是每一个cell保存所有的发言副本。令人惊奇的是，所有发言比收件箱中的镜像要小。(请纠错)每天每个cell的发言增长50GB，收件箱每天增长2.7TB。用户消耗的资源远远超过他们制造的。
•     用户的dashboard不包含发言的内容，只显示发言者的ID，主要的增长来自ID。(请Tumblr用户纠错)
•     当追随者改变时，这种设计方案也是安全的。因为所有的发言都保存在cell中了。如果只有追随者的发言保存在cell中，那么当追随者改变了，将需要一些回填工作。
•     另外一种设计方案是采用独立的发言存储集群。这种设计的缺点是，如果群集出现故障，它会影响整个网站。因此，使用cell的设计以及后复制到所有cell的方式，创建了一个非常强大的架构。

• 一个用户拥有上百万的追随者，这带来非常大的困难，有选择的处理用户的追随者以及他们的存取模式（见Feeding Frenzy）
•     不同的用户采用不同并且恰当的存取模式和分布模型，两个不同的分布模式包括：一个适合受欢迎的用户，一个使用大众。
•     依据用户的类型采用不同的数据处理方式，活跃用户的发言并不会被真正发布，发言将被有选择的体现。(果真如此？请Tumblr用户纠错)
•     追随了上百万用户的用户，将像拥有上百万追随者的用户那样对待。

• cell的大小非常难于决定。cell的大小直接影响网站的成败。每个cell归于的用户数量是影响力之一。需要权衡接受怎样的用户体验，以及为之付出多少投资。

• 从firehose中读取数据将是对网络最大的考验。在cell内部网络流量是可管理的。

• 当更多cell被增添到网络中来，他们可以进入到cell组中，并从firehose中读取数据。一个分层的数据复制计划。这可以帮助迁移到多个数据中心。

在纽约启动运作

• 纽约具有独特的环境，资金和广告充足。招聘极具挑战性，因为缺乏创业经验。
• 在过去的几年里，纽约一直致力于推动创业。纽约大学和哥伦比亚大学有一些项目，鼓励学生到初创企业实习，而不仅仅去华尔街。市长建立了一所学院，侧重于技术。

团队架构

• 团队：基础架构，平台，SRE，产品，web ops，服务；
• 基础架构：5层以下，IP地址和DNS，硬件配置；
• 平台：核心应用开发，SQL分片，服务，Web运营；
• SRE：在平台和产品之间，侧重于解决可靠性和扩展性的燃眉之急；
• 服务团队：相对而言更具战略性，
• Web ops：负责问题检测、响应和优化。

软件部署

• 开发了一套rsync脚本，可以随处部署PHP应用程序。一旦机器的数量超过200台，系统便开始出现问题，部署花费了很长时间才完成，机器处于部署进程中的各种状态。
• 接下来，使用Capistrano（一个开源工具，可以在多台服务器上运行脚本）在服务堆栈中构建部署进程（开发、分期、生产）。在几十台机器上部署可以正常工作，但当通过SSH部署到数百台服务器时，再次失败。
• 现在，所有的机器上运行一个协调软件。基于Redhat Func（一个安全的、脚本化的远程控制框架和接口）功能，一个轻量级的API用于向主机发送命令，以构建扩展性。
• 建立部署是在Func的基础上向主机发送命令，避免了使用SSH。比如，想在组A上部署软件，控制主机就可以找出隶属于组A的节点，并运行部署命令。
• 部署命令通过Capistrano实施。

      Func API可用于返回状态报告，报告哪些机器上有这些软件版本。

• 安全重启任何服务，因为它们会关闭连接，然后重启。
• 在激活前的黑暗模式下运行所有功能。

展望

• 从哲学上将，任何人都可以使用自己想要的任意工具。但随着团队的发展壮大，这些工具出现了问题。新员工想要更好地融入团队，快速地解决问题，必须以他们为中心，建立操作的标准化。
• 过程类似于Scrum（一种敏捷管理框架），非常敏捷。
• 每个开发人员都有一台预配置的开发机器，并按照控制更新。
• 开发机会出现变化，测试，分期，乃至用于生产。
• 开发者使用VIM和TextMate。
• 测试是对PHP程序进行代码审核。
• 在服务方面，他们已经实现了一个与提交相挂钩的测试基础架构，接下来将继承并内建通知机制。

招聘流程

• 面试通常避免数学、猜谜、脑筋急转弯等问题，而着重关注应聘者在工作中实际要做什么。
• 着重编程技能。
• 面试不是比较，只是要找对的人。
• 挑战在于找到具有可用性、扩展性经验的人才，以应对Tumblr面临的网络拥塞。
• 在Tumblr工程博客（Tumblr Engineering Blog），他们对已过世的Dennis Ritchie和John McCarthy予以纪念。

经验及教训

• 自动化无处不在
• MySQL（增加分片）规模，应用程序暂时还不行
• Redis总能带给人惊喜
• 基于Scala语言的应用执行效率是出色的
• 废弃项目——当你不确定将如何工作时
• 不顾用在他们发展经历中没经历过技术挑战的人，聘用有技术实力的人是因为他们能适合你的团队以 及工作。
• 选择正确的软件集合将会帮助你找到你需要的人
• 建立团队的技能
• 阅读文档和博客文章。
• 多与同行交流，可以接触一些领域中经验丰富的人，例如与在Facebook、Twitter、LinkedIn的工程师 多交流，从他们身上可以学到很多
• 对技术要循序渐进，在正式投入使用之前他们煞费苦心的学习HBase和Redis。同时在试点项目中使用 或将其控制在有限损害范围之内。

翻译：包研，张志平

Continue reading 【转】Tumblr：150亿月浏览量背后的架构挑战

转自 调用Sina股票数据

sina股票数据接口
以大秦铁路（股票代码：601006）为例，如果要获取它的最新行情，只需访问新浪的股票数据
接口：http://hq.sinajs.cn/list=sh601006这个url会返回一串文本，例如：
var hq_str_sh601006="大秦铁路, 27.55, 27.25, 26.91, 27.55, 26.20, 26.91, 26.92,
22114263, 589824680, 4695, 26.91, 57590, 26.90, 14700, 26.89, 14300,
26.88, 15100, 26.87, 3100, 26.92, 8900, 26.93, 14230, 26.94, 25150, 26.95,
15220, 26.96, 2008-01-11, 15:05:32";
这个字符串由许多数据拼接在一起，不同含义的数据用逗号隔开了，按照程序员的思路，顺序号从0开始。
0：”大秦铁路”，股票名字；
1：”27.55″，今日开盘价；
2：”27.25″，昨日收盘价；
3：”26.91″，当前价格；
4：”27.55″，今日最高价；
5：”26.20″，今日最低价；
6：”26.91″，竞买价，即“买一”报价；
7：”26.92″，竞卖价，即“卖一”报价；
8：”22114263″，成交的股票数，由于股票交易以一百股为基本单位，所以在使用时，通常把该值除以一百；
9：”589824680″，成交金额，单位为“元”，为了一目了然，通常以“万元”为成交金额的单位，所以通常把该值除以一万；
10：”4695″，“买一”申请4695股，即47手；
11：”26.91″，“买一”报价；
12：”57590″，“买二”
13：”26.90″，“买二”
14：”14700″，“买三”
15：”26.89″，“买三”
16：”14300″，“买四”
17：”26.88″，“买四”
18：”15100″，“买五”
19：”26.87″，“买五”
20：”3100″，“卖一”申报3100股，即31手；
21：”26.92″，“卖一”报价
(22, 23), (24, 25), (26,27), (28, 29)分别为“卖二”至“卖四的情况”
30：”2008-01-11″，日期；
31：”15:05:32″，时间；
这个接口对于JavaScript程序非常方便，通常的使用方式为，静态或动态地在页面中插入：
<script src="http://hq.sinajs.cn/list=sh601006" type="text/javascript"><!--mce:0--></script>
<script type="text/javascript"><!--mce:1--></script>
这段代码输出大秦铁路（股票代码：601006）的当前股价
current price:14.20
如果你要同时查询多个股票，那么在URL最后加上一个逗号，再加上股票代码就可以了；比如你要一次查询大秦铁路（601006）和大同煤业（601001）的行情，就这样使用URL：
http://hq.sinajs.cn/list=sh601003,sh601001
但如果你要查询大盘指数，情况会有不同，比如查询上证综合指数（000001），使用如下URL：
http://hq.sinajs.cn/list=s_sh000001 服务器返回的数据为：
var hq_str_s_sh000001=”上证指数,3094.668,-128.073,-3.97,436653,5458126″;
数据含义分别为：指数名称，当前点数，当前价格，涨跌率，成交量（手），成交额（万元）；
查询深圳成指的URL为：
http://hq.sinajs.cn/list=s_sz399001
对于股票的K线图，日线图等的获取可以通过请求http://image.sinajs.cn/…./…/*.gif此URL获取，其中*代表股票代码，详见如下：
查看日K线图：
http://image.sinajs.cn/newchart/daily/n/sh601006.gif
分时线的查询：
http://image.sinajs.cn/newchart/min/n/sh000001.gif
日K线查询：
http://image.sinajs.cn/newchart/daily/n/sh000001.gif
周K线查询：
http://image.sinajs.cn/newchart/weekly/n/sh000001.gif
月K线查询：
http://image.sinajs.cn/newchart/monthly/n/sh000001.gif

深成指：<script type="text/javascript" src="http://hq.sinajs.cn/list=sz399001" charset="gb2312"></script>
上证指：<script type="text/javascript" src="http://hq.sinajs.cn/list=sh000001" charset="gb2312"></script>
道琼斯：<script type="text/javascript" src="http://hq.sinajs.cn/list=int_dji" charset="gb2312"></script>
纳斯达克：<script type="text/javascript" src="http://hq.sinajs.cn/list=int_nasdaq" charset="gb2312"></script>
恒生指：<script type="text/javascript" src="http://hq.sinajs.cn/list=int_hangseng" charset="gb2312"></script>
日经指数：<script type="text/javascript" src="http://hq.sinajs.cn/list=int_nikkei" charset="gb2312"></script>
台湾加权：<script type="text/javascript" src="http://hq.sinajs.cn/list=b_TWSE" charset="gb2312"></script>
新加坡：<script type="text/javascript" src="http://hq.sinajs.cn/list=b_FSSTI" charset="gb2312"></script>
转自：http://nerrsoft.com/259.html

Continue reading 【转】调用Sina股票数据

之前使用wp-super-cache，后来改了服务器，问题就来了，要设置一大堆，很麻烦。

对于小站来说，如果经常换服务器，最好还是不要用wp-super-cache,后遗症较多。

比如我写个ajax请求，php返回后面加了wp-super-cache一段话，把json格式给破坏了。

怎么删除wp-super-cache还真是个学问：

见

http://cnzhx.net/blog/articles/you-need-to-re-config-wp_super_cache-after-changing-your-wordpress-host/

http://shandian.biz/98.html

我是直接删了文件的。后来发现控制面板插件页出现问题:

未启用： 在 wp-config.php 中需要 define('', true);

试试把define('WP_CACHE', true);

改为define('WP_CACHE', false);

还是不行。

偶然试试点击插件页的全部插件连接，竟然就好了，不得其解。

尝试其他的插件:

hyper cache+db cache reloaded fix http://help.laoxuehost.com/wp/wordpress-cache.html

效果不错。

注意，对于你不想缓存的页面，需要在hyver cache 配置中

Filters>拒绝的位址 中加入页面url,以此为开头的url将不会被缓存。例如/show/ 则www.ig2net.info/show/下所有页面不会缓存。

Continue reading wordpress 缓存插件

IE这个浏览器真是很头疼，有时你开发的网页，到稍微新一点的版本上就完全变了样。

对于IE8,它就使用了全新的渲染引擎，IE9更是变化大。

这里介绍使用X-UA-Compatible meta来让IE 跳转到某个版本来渲染。

方法1：

可使用meta 标签

<meta http-equiv="X-UA-Compatible" content="IE=8" />

方法2:

服务器返回头

X-UA-Compatible: IE=8;FF=3;OtherUA=4

其实X-UA-Compatible 虽不是个标准头，但是很多浏览器都支持它，然而最需要这个的恐怕是IE了，它的向前兼容性太差。

另外这样的写法:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

则是让浏览器使用最新的可能版本渲染。

这里顺便提一下Acid2测试, acid主要测试浏览器符合w3c标准的程度，这篇文章介绍较好:

http://www.bobopo.com/article/code/acid_w3c.htm

参见:

http://www.alistapart.com/articles/beyonddoctype

http://www.456bereastreet.com/archive/201103/x-ua-compatible_and_html5/

http://wange.im/x-ua-compatible-ie9-to-ie7.html

Continue reading X-UA-Compatible, IE向前兼容性

我使用 https://bitbucket.org 时知道了mercurial, 发现之前使用过tortoiseHG的。

我使用eclipse插件mercurialeclipse,可从

http://code.google.com/a/eclipselabs.org/p/mercurialeclipse/ 这里找到updatesite,这里是最新的，较之javaforge要新。

windows上这个插件需要安装hg客户端，一般是tortoisehg。

入门文档可看http://mercurial.selenic.com/wiki/ChineseTutorial

然后看看http://www.cnblogs.com/meetrice/archive/2010/07/12/1775707.html 这个文章有图有真相，非常值得一读。

基本步骤是:

在https://bitbucket.org上建立仓库

将仓库clone到本地，创建本地仓库。

添加文件等，向本地仓库commit.（这个可多次执行）

向https://bitbucket.org push本地仓库的tag.（将上一步多次commit到本地的全部push到web）

在国内的网络环境下，访问https://bitbucket.org的资源库还是很需要耐心的。

我之前用svn时喜欢将所有项目提交到一个仓库中，但是在hg里面还没发现怎样达到这个目的。仍然需要每个项目建个仓库。每个仓库的目录和项目目录相同，这里也许是我还没搞明白吧。

Continue reading mercurial入门

切片的经验:

先用参考线勾勒大体框架，在针对内部切片。注意应该从大到小的顺序来，例如，先将每个大部分切片划分，再对每个大部分划分里面的部分，这样每一部分的切片分割只会局限在这个部分以内，否则，一个切片影响整个划分，前面的功夫就会白做了。

ps切片用来切图还好，但是想通过它来直接生成div+css的html还是行不通的，因为ps虽然可以直接生成div的html,但是都是绝对定位，你最终还是要手写html来达到实际的效果。

基础课看看下面的教程:

网易公开课有这个教程:

http://tech.163.com/special/000915SN/Dreamweaver01.html

其中：

第三部分 网页制作实战

• 1.建立新站点
• 3.优化软件界面
• 5.Photoshop切片
• 7.检查与修改切片
• 9.修改设置表格

• 2.设置跟踪图像
• 4.配合Photoshop建立表格
• 6.设置与优化切片
• 8.输出切片图像
• 10.设置图像与收尾

转么针对ps的:

http://tech.163.com/special/000915SN/pscs3n.html

可以看看

跟踪图像是用于dreamweaver设计网页时比对原图的功能：修改/页面属性/跟踪图像

ps中经常发现面板无法拖动，空白处点击一下右键就可以了，再点击一下右键又不能拖，如此切换。

还有这些值得一看:

Photoshop把PSD网站模板切图为XHTML+CSS的网页

http://www.missyuan.com/thread-378347-1-7.html 

用photoshop設計網頁完全過程(这个是设计图，不是讲切片)

http://www.weekendhk.com/blog/index.php/35747/viewspace-41065.html 

另外: 其实标准的网制作完成的工作实际是：psd to html，一般情况下，我们会拿到美工的psd,这时候不同的人会有不同的做法： 


1.打开fireworks将图片切割导出为html。 

2.直接在dreamweaver之类的工具去拖拉布局，导入相关的图片,flash资源。 

3.先在ps中完成切图后，在文本编辑器中看着效果图一步步的制作。 


以上是大多被采用的方法，但都不好： 

第一种方法最为不好，这样的代码根本不具维护性和可读性。 

第二种方法也不好，代码难免会有冗余，做出来的东西基本需要排查一遍。 

第三种方法也不好，因为你需要看效果图一点点的拼，也就是说写html标签的时候，你在不断的假设这块要怎么去显示。 


正确的做法是： 

1.拿到psd后，先不要做别的，直接在文本编辑器中将网页的框架写出来，不要假设这块将来css要去怎么渲染，完全自然化的标签，不加任何的css。 

2.写完之后在各个浏览器运行之后确保大体定位都没有问题。 

3.书写总体css,这里的css只负责大块的定位及样式。 

4.切出需要的图片资源，在写好的框架中一点点的去构造，不断的调试，最终为成品。 

5.最后，为自己的代码添加注释，在css，html中都要合适的为自己的代码添加注释。 


要想做出能灵活切换皮肤，让css主导表现，还有很多要注意的地方，但大体的流程就是这样的，当然我们一开始不能直接就做到先写html，但起码要有这个意识，循序渐进。。。

参见:

http://kazge.com/archives/711.html

Continue reading photoshop,dreamweaver 切片教程

记性不好，还是要烂笔头。

终止线程用什么方法最好：答案是使用共享变量在while中判断。

那么Thread提供的stop interrupt, ExecutorService提供的shutdown, shutdownAll不行吗？答案是不行。

解释:

stop方法是过时的

interrupt:如果线程中没有sleep 、wait、Condition、定时锁等应用, interrupt()方法是无法中断当前的线程的。

shutdown, shutdownAll:它试图终止线程的方法是通过调用Thread.interrupt()方法来实现的。

另外在使用共享变量时也要注意：

多个线程访问共享变量时无论读或者写都要保证同步。(参见 effective java item 66.)

参见:http://kazge.com/archives/152.html

http://www.blogjava.net/jinfeng_wang/archive/2008/04/27/196477.html

Continue reading thread stop interrupt, ExecutorService shutdown shutdownnow,怎样终止线程

转自: http://www.liuzm.com/article/java/100318.htm

最近看一些关于JAVA的面试题,都是关于内存泄露与溢出。当时看到这个题目时，我自己也感觉有点糊。

然后查了下资料。结合自己总结下关于内存泄露与溢出的区别

内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存泄漏就是没有及时清理内存垃圾，导致系统无法再给你提供内存资源（内存资源耗尽）。

看到上面的解释，可能有些朋友还是不太理解吧。没问题，看以下例子
1.内存泄露是说程序逻辑问题,造成申请的内存无法释放.这样的话无论多少内存,早晚都会被占用光的.
最简单的例子就是死循环了.由于程序判断错误导经常发生此事

2.内存泄漏是指在堆上分配的内存没有被释放，从而失去对其控制。这样会造成程序能使用的内存越来越少，导致系统运行速度减慢，严重情况会使程序当掉。
3.关于内存溢出有点出入。比如说你申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
举个现实中的例子
4.比如有一个桶，装满了水.你丢个苹果进去。桶的水正常。
如果你放个大石头。水就出溢出，内存溢出也就是这个原理
区别：内存溢出，提供的内存不够；内存泄漏，无法再提供内存资源
可能大家会问内存泄露与溢出是考JAVA哪方面？考这个有什么用？
我个人觉的是考大家对JAVA是怎么管理内存这一块的知识?对下是对Java是如何管理内存的解释
Java是如何管理内存
为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。
Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链，当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收。GC为了能够正确释放对象，必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。
在Java中，这些无用的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。虽然，我们有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义，该函数不保证JVM的垃圾收集器一定会执行。因为不同的JVM实现者可能使用不同的算法管理GC。通常GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。

Continue reading 【转】Java内存泄露与溢出的区别

转自http://developer.51cto.com/art/201009/227691.htm

垃圾收集GC（Garbage Collection）是Java语言的核心技术之一，之前我们曾专门探讨过Java 7新增的垃圾回收器G1的新特性，但在JVM的内部运行机制上看，Java的垃圾回收原理与机制并未改变。垃圾收集的目的在于清除不再使用的对象。GC通过确定对象是否被活动对象引用来确定是否收集该对象。GC首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。

引用计数收集器

引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象（不是引用）都有一个引用计数。当一个对象被创建时，且将该对象分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象+1），但当一个对象的某个引用超过了生命周期或者被设置为一个新值时，对象的引用计数减1。任何引用计数为0的对象可以被当作垃圾收集。当一个对象被垃圾收集时，它引用的任何对象计数减1。

优点：引用计数收集器可以很快的执行，交织在程序运行中。对程序不被长时间打断的实时环境比较有利。

缺点： 无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0.

跟踪收集器

早期的JVM使用引用计数，现在大多数JVM采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，GC必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。

下一步，GC要删除不可到达的对象。删除时，有些GC只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多GC可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。

为此，GC需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有GC运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 GC不断增加或同时运行以减少或者清除应用程序的中断。有的GC使用单线程完成这项工作，有的则采用多线程以增加效率。

一些常用的垃圾收集器

◆标记－清除收集器
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。并且，由于它只是清除了那些未标记的对象，而并没有对标记对象进行压缩，导致会产生大量内存碎片，从而浪费内存。
◆标记－压缩收集器
有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。

复制收集器

这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，JVM生成的新对象则放在另一半空间中。GC运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。并且对于指定大小堆来说，需要两倍大小的内存，因为任何时候都只使用其中的一半。

增量收集器

增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾，也可理解为把堆栈分成一小块一小块，每次仅对某一个块进行垃圾收集。这会造成较小的应用程序中断时间，使得用户一般不能觉察到垃圾收集器正在工作。

分代收集器

复制收集器的缺点是：每次收集时，所有的标记对象都要被拷贝，从而导致一些生命周期很长的对象被来回拷贝多次，消耗大量的时间。而分代收集器则可解决这个问题，分代收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。JVM生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象(非短命对象)将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。

并行收集器

并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多CPU机器上使用多线程技术可以显著的提高java应用程序的可扩展性。

最后，贴出一个非常简单的跟踪收集器的例图，以便大家加深对收集器的理解：

跟踪收集器图例

使用垃圾收集器要注意的地方

下面将提出一些有关垃圾收集器要注意的地方，垃圾收集器知识很多，下面只列出一部分必要的知识：
◆每个对象只能调用finalize(   )方法一次。如果在finalize(   )方法执行时产生异常（exception），则该对象仍可以被垃圾收集器收集。
◆垃圾收集器跟踪每一个对象，收集那些不可触及的对象（即该对象不再被程序引用 了），回收其占有的内存空间。但在进行垃圾收集的时候，垃圾收集器会调用该对象的finalize(   )方法（如果有）。如果在finalize()方法中，又使得该对象被程序引用(俗称复活了)，则该对象就变成了可触及的对象，暂时不会被垃圾收集了。但是由于每个对象只能调用一次finalize(   )方法，所以每个对象也只可能 "复活 "一次。
◆Java语言允许程序员为任何方法添加finalize(   )方法，该方法会在垃圾收集器交换回收对象之前被调用。但不要过分依赖该方法对系统资源进行回收和再利用，因为该方法调用后的执行结果是不可预知的。
◆垃圾收集器不可以被强制执行，但程序员可以通过调研System.gc方法来建议执行垃圾收集。记住，只是建议。一般不建议自己写System.gc，因为会加大垃圾收集工作量。

【编辑推荐】

1. 深入Java核心 Java中多态的实现机制
2. 深入Java核心 Java内存分配原理精讲
3. Java程序员必须了解GC的工作原理
4. 简单理解Java GC与幽灵引用

Continue reading 【转】深入Java核心 探秘Java垃圾回收机制