3月
29
2013
0

流水线中的大冒险

上一节说到,流水线中的分支预测本身是为了提高整条流水线的并行度,为此,CPU做了很多努力,例如乱序执行,甚至于流水线本身也是为了这个目的而诞生的。

和我们编写一般程序一样,顺序执行总是最简单、最安全的,指令被一条接着一条地顺序执行,没有人会思考任何有关并发的隐患。但是一旦踏入并发编程的范畴,似乎就开始变得一团糟,你需要考虑数据竞争、锁、内存等等一系列问题。和分支预测一样,有时候你会采用一些试探性的方法去处理并发中产生的问题,例如经典的CAS(Compare And Swap)算法,可能成功可能失败,喜忧参半。

在流水线中也存在着类似的大冒险,典型的有三种:

数据冒险

结构冒险

控制冒险

对应的,也有一些方法去辅助CPU在这些冒险的过程中,尽可能地达到我们期望的结果。 (more…)

Written by Hesey Wang in: 并发,技术 |
3月
18
2013
0

流水线中的分支预测

在现代CPU中,为了提高执行的性能,CPU的多个单元会同时执行多条指令。例如当取址单元正在寻找下一条指令前,上一条指令的译码和执行已经在进行中了,这一套机制被称作CPU流水线(pipeline)。

CPU流水线架构把指令的执行分为了多个阶段,每个单元只负责完成指令执行过程中的一个阶段,而中间结果由专门的流水线寄存器暂存。这样理论上,一条指令的执行假设被分为5个阶段,那么当5个单元同时运行一段时间后,理论上相同时间可以同时执行5条指令,当然这只是最简单的情况,实际的情况要复杂得多。

400px-5_Stage_Pipeline.svg

流水线的引入相当于程序中引入了并发,相应的,会带来很多额外的问题。例如为了更好地让指令流水般地执行,不涉及顺序一致性的指令会被重排序。这里不详细讨论太多流水线的技术细节,只要知道指令并不是一条一条顺序执行的,那样会严重阻碍处理器的性能。

CPU流水线引入的目的在于,希望能够在每个CPU的时钟周期都发射一条新的指令,这样理论上可以达到最高效率。但这有一个前提:如果指令的执行是每个时钟周期一条,那么指令的取值也必须达到每个时钟周期一条,如此,当你在取址阶段拿到要执行的指令时,下一条指令的地址必须被确定了,否则下一个时钟周期便无法取出对应的指令。 (more…)

Written by Hesey Wang in: 并发,技术 |
2月
10
2013
8

从一个开发的角度看负载均衡和LVS

在大规模互联网应用中,负载均衡设备是必不可少的一个节点,源于互联网应用的高并发和大流量的冲击压力,我们通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器(数据库、缓存等等)。

一、负载均衡的作用

负载均衡设备的任务就是作为应用服务器流量的入口,挑选最合适的一台服务器,将客户端的请求转发给它处理,实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构,本质上也是将后端服务器作为计算资源、存储资源,由某台管理服务器封装成一个服务对外提供,客户端不需要关心真正提供服务的是哪台机器,在它看来,就好像它面对的是一台拥有近乎无限能力的服务器,而本质上,真正提供服务的,是后端的集群。

一个典型的互联网应用的拓扑结构是这样的:

top (more…)

Written by Hesey Wang in: 分布式,技术,架构 |
10月
19
2012
1

Linux I/O Scheduler

之前写过一个Blog分享Linux下的几种I/O Scheduler,这次分享一个slide,内容更全一点。

你也可以在slideshare查看和下载:http://www.slideshare.net/heseymx/linux-io-scheduler

(more…)

Written by Hesey Wang in: 技术 |
6月
09
2012
5
4月
03
2012
1

Hive Tips

在Hive中,某些小技巧可以让我们的Job执行得更快,有时一点小小的改动就可以让性能得到大幅提升,这一点其实跟SQL差不多。

首先,Hive != SQL,虽然二者的语法很像,但是Hive最终会被转化成MapReduce的代码去执行,所以数据库的优化原则基本上都不适用于 Hive。也正因如此,Hive实际上是用来做计算的,而不像数据库是用作存储的,当然数据库也有很多计算功能,但一般并不建议在SQL中大量使用计算,把数据库只当作存储是一个很重要的原则(more…)

Written by Hesey Wang in: 分布式,技术 |
2月
17
2012
6

Linux IO调度器

在现代计算机体系中,机械硬盘仍然作为大部分情况下的存储设备使用,而机械硬盘的访问相对内存差了多个数量级,主要原因在于机械臂转动的寻道时间太长,机械操作没法跟上电子信号的传递,所以OS不可能对每次I/O请求都直接作寻道处理,而是需要额外的工作。

在Linux中,这部分工作主要由I/O调度器完成。 (more…)

Written by Hesey Wang in: Linux,技术 |
2月
10
2012
2

支持多域名虚拟主机SSL/TLS认证的技术:SNI

早期的SSLv2根据经典的公钥基础设施PKI(Public Key Infrastructure)设计,它默认认为:一台服务器(或者说一个IP)只会提供一个服务,所以在SSL握手时,服务器端可以确信客户端申请的是哪张证书。

但是让人万万没有想到的是,虚拟主机大力发展起来了,这就造成了一个IP会对应多个域名的情况。解决办法有一些,例如申请泛域名证书,对所有*.yourdomain.com的域名都可以认证,但如果你还有一个yourdomain.net的域名,那就不行了。

在HTTP协议中,请求的域名作为主机头(Host)放在HTTP Header中,所以服务器端知道应该把请求引向哪个域名,但是早期的SSL做不到这一点,因为在SSL握手的过程中,根本不会有Host的信息,所以服务器端通常返回的是配置中的第一个可用证书。因而一些较老的环境,可能会产生多域名分别配好了证书,但返回的始终是同一个。

既然问题的原因是在SSL握手时缺少主机头信息,那么补上就是了。

SNI(Server Name Indication)定义在RFC 4366,是一项用于改善SSL/TLS的技术,在SSLv3/TLSv1中被启用。它允许客户端在发起SSL握手请求时(具体说来,是客户端发出SSL请求中的ClientHello阶段),就提交请求的Host信息,使得服务器能够切换到正确的域并返回相应的证书。

要使用SNI,需要客户端和服务器端同时满足条件,幸好对于现代浏览器来说,大部分都支持SSLv3/TLSv1,所以都可以享受SNI带来的便利。 (more…)

Written by Hesey Wang in: 技术 |
2月
10
2012
1

证书链及在nginx下的配置

通常为了保护Web通信传输,我们会使用SSL/TLS协议去同时实现加密传输和身份认证,这里需要在服务器端配置好CA证书。

CA证书分为两类:根证书(Root CA)中间证书(Intermediate CA)。这里的证书我们用OpenSSL就可以生成,但是只有经过认证的CA机构签发的根证书才会被浏览器或其它设备信任,做法就是预先在浏览器或系统里内置可信的根证书。

但是根证书的使用是收到严格限制的,不可能对于每一类用户都使用根证书去签发子数字证书,所以就有了中间证书的概念。中间证书由根证书或上一级中间证书签发,它可以再往下级签发数字证书。例如我们自己为某个域名申请了证书 My CA,那么对于三级证书链,签发过程是这样的:

Root CA 签发 Intermediate CA, Intermediate CA 签发 My CA

这时我们就可以用My CA去给域名作数字认证了,那么验证的过程可想而知,就是签发的逆过程,这是通过证书链来完成的。 (more…)

Written by Hesey Wang in: 技术 |
2月
06
2012
11

生活的可能性

我时常想起这么个问题:如果当初作了另一个选择,那么恐怕不会是现在的生活吧。

想想就觉得很奇妙,不同的选择,就把人引向不同的道路,有时候一不小心,又殊途同归。记得以前有个笔友在信里说,如果没有遇见彼此,也许生活是完全不同的另一番模样。

和大多数人一样,我也是个不喜欢太多变化的人。本质上人都害怕未知,害怕触碰甚至窥视自己不知道的领域。

但自己的内心又分明躁动不安,我经常反复问自己的一个问题是:

我究竟想要什么? (more…)

Written by Hesey Wang in: 思考 |

©2006 - 2016 Hesey (舒)