September 2014 Archives

在看广点通的页面代码,头部有个<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">

查了一下,发现这个是给IE浏览器用的, IE=Edge是IE请使用最新的渲染引擎, chrome=1是激活ChromeFrame 

不过Google已经停止支持Chrome Frame

所以只要IE=Edge就可以了

另外可以不用改代码

Nginx: (server区间内)

add_header "X-UA-Compatible" "IE=Edge";

参考文章:http://www.cnblogs.com/nidilzhang/archive/2010/01/09/1642887.html

在NoSQL存储系统选型中,有很多的维度可以区分系统给的特定优势所在,这里挑选几种维度介绍,注意不全面,也不是唯一的区分方式。没有哪种方案能够完 美的解决问题,重要的是正确的评估需求,然后做出明智的选择,有需要的话甚至可以采用混合使用的方案。对于一个问题,我们只有知道了有哪些可用的解决方 案,然后才能找到最合适解决该问题的方案。

1、数据模型

数据有多种存储的方式,包括键/值对(类似HashMap),半结构化的列式存储和文档结构存储。用户的应用如何存储数据?同时数据模式是否随着时间而变化?

2、存储模型

内存还是持久化?一旦考虑持久化存储,就需要考虑选择的方案是否会影响到访问模式。

3、一致性模型

严格一致性,还是最终一致性?一致性可能会影响操作延时,即系统响应读写请求的速度。

4、物理模型

分布式模式还是单机模式?系统的扩展性如何?

5、读/写性能

需要考虑自己的应用程序的访问模式,是读多写少,还是读写相当,或者写多读少?是用范围扫描数据好,还是用随机读请求数据更好?有些系统可能仅对这些情况中的一种支持的好。

6、辅助索引

辅助索引支持用户按不同的字段和排序方式来访问表。这个维度覆盖了某些完全没有辅助索引支持且不保证数据排序的系统(类似HashMap,即用户需要知道 数据对应键的值),到某些可能通过外部手段简单支持这些功能的系统。如果存储系统不提供这项功能,用户的应用可以应对或自己模拟辅助索引吗?

7、故障处理

机器会崩溃是一个客观存在的问题,需要有一套数据迁移方案来应对这种情况。每个数据存储如何进行服务故障处理?故障处理完毕之后是否可以正常工作?从一个正在提供服务的集群中卸载一台服务器时,也会遇到类似的问题。

8、压缩

需要存储TB级的数据时,尤其当这些数据差异性很小或由可读性文本组成时,压缩会带来非常好的效果。有些压缩算法可以将此类数据压缩到原始文件大小的十分之一。有可选择的压缩组件吗?又有哪些压缩算法可用?

9、负载均衡

加入用户有高读写吞吐率的需求,就要考虑配置一套能够随着负载变化自动均衡处理能力的系统。虽然这样不能完全解决这个问题,但是也可以帮助用户设计高读写吞吐量的程序。

10、原子操作的读-修改-写

RDBMS提供了很多这类的操作(因为它是一个集中式的面向单服务器的系统),但这些操作在分布式系统中较难实现,这些操作可以帮助用户避免多线程造成的资源竞争,也可以帮助用户完成无共享应用服务器的设计。有了这些比较并交换(compare and swap,CAS)操作,或者说检查并设置(check and set)操作,在设计系统的时候可以有效地降低客户端的复杂度。

11、加锁、等待和死锁

复杂的事务处理,如两阶段提交,会增加多个客户端竞争同一个资源的可能性。最糟糕的情况就是死锁,这种情况也很难解决。用户需要支持的系统采用哪种锁模型?这种锁模型能否避免等待和死锁?

 

参考资料:《HBase:权威指南》

nginx下获取部分主机名

| No Comments | No TrackBacks
server {
      listen          80;
      server_name     ^www.(?<domain>+)$;
      root            /var/www/htdocs/;
    if ($host ~* www\.(.*)) {
      set $host_without_www $1;
      }
      if ( $request ~ '/members' ) {
        rewrite ^(.*)$ http://member.$host_without_www/ permanent;
      }

}

架构师的要求

| No Comments | No TrackBacks

一个好的架构师至少要做到四点:

  1. 识别甚至提前预测到程序不同阶段的性能瓶颈,并以合理的代价消除。
  2. 识别束缚程序员生产力发展的瓶颈,并合理的消除。
  3. 解决组里面的尖端问题。
  4. 成为组员的精神支柱和旗帜。

他不应该:

  1. 总结需求。这是产品经理的事,除非他兼任。
  2. 评估工作时间,并保证工作进度。这是项目经理的事,除非他兼任。
  3. 召集,协调工作细节。这个随企业有不同划分,理论上是行政领导干的。有的企业是技术系的来做行政领导,有的是PM。
  4. 亲自写程序。除了初创,架构师亲自冲上去写大段大段的程序是找死的先兆。
  5. 预测技术的发展方向,并做出技术决策。您让TC干什么去?
  6. 政治斗争。架构师也来搞这个,要么被搞死,要么根本没心思做事。但是应该理解办公室政治,并且能够基本掌握情况。一点办公室政治都不懂的架构师肯定被搞死。

技术面试的四个点

| No Comments | No TrackBacks

1. 工程细节和技术细节

2. 技术原理和经验

3. 职位所需要做到最好的一个方面, 盯着问

4. 技术敏锐度和智商

MailGun电子邮件html范本

| No Comments | No TrackBacks

Mailgun提供了一个可以在任意平台都正常显示的html邮件范本

地址: https://github.com/mailgun/transactional-email-templates

litmus 提供了Email Preview。。。