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

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

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

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

早期的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带来的便利。 (更多…)

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

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

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

Root CA 签发 Intermediate CA， Intermediate CA 签发 My CA

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

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

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

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

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

我究竟想要什么？ (更多…)

如果要用一个词来形容2011的话，我想，就用“激动”好了。

这一年我从学校出来，由一个胆胆颤颤的学生，正式转变成一名工作者，经济上的收入虽然不高，但勉强可以做到自收自支，更多的是，开始把自己的能力发挥出来，能够做一些真正产生影响的东西，这是我一直以来都想做的事情。

这一年，很多在书上看到的技术产品，总算可以真的亲手去用，去体验，去借助我的代码直接触摸那些曾经让我觉得无比高耸的高峰。

这一年，我终于成为团队的一员，从小作坊的独立开发，慢慢适应协同开发、合作，不得不说，和一群相投的人一起做事，真的很开心！ (更多…)

Hadoop运行时有三种模式：

单机模式

伪分布式模式

完全分布式模式

前两种可以在单机运行，最后一种用于真实的集群环境，通常用在生产环境上。我们可以搭建本地的伪分布式模式来模拟分布式环境的执行。 (更多…)

Redis利用内存发挥的高性能读写在很多场景下大有所为，但是Redis本身毕竟还是一个单机数据库，如果系统对其属于强依赖，那么还是必须做好必要的容灾，针对这个问题，有以下几种策略：

一、M/S切换

由于Redis是单机数据库，所以针对MySQL的一些容灾方案也能顺利适用，例如当Redis意外宕机，可以将请求马上切到备库，同时快速恢复数据。

二、AOF

Redis有两种持久化的方式，分别是SnapShotting和Append-Only File，其原理和特性可以参考《对redis数据持久化的一些想法》一文，总得来说，快照对性能影响更小，也只会备份需要的数据，但两次快照中间的数据是没法保证一定会持久化的。

相比之下AOF的粒度更细，持久化效果更好，类似于MySQL的BinLog，缺点是会损失一部分性能，而且会记录不必要的日志，这一点当系统运行时间很长时会特别突出，也许恢复所有数据本来只要1个小时，却可能要花100甚至1000小时去搞。

三、读取数据源直接恢复

这个方案是和业务场景相关的，由于之前某个项目中Redis起到了存放索引的作用，所以利用MySQL的数据可以容易地重新建立Redis的所有内容，这里可以临时搞一个Trigger，不断读MySQL写Redis，利用MySQL的顺序读和Redis高TPS的特性，实践中，可以在几分钟内重建上千万的数据量。

目前Redis在功能上通常仍用于Cache，如果需要保证HA的持久化存储，请考虑具体场景，此外也可以考虑是否可以使用原生分布式的memcached或升级硬件（如SSD、Fusion-IO）增强原有DB的性能。

在运用CAS做Lock-Free操作中有一个经典的ABA问题：

线程1准备用CAS将变量的值由A替换为B，在此之前，线程2将变量的值由A替换为C，又由C替换为A，然后线程1执行CAS时发现变量的值仍然为A，所以CAS成功。但实际上这时的现场已经和最初不同了，尽管CAS成功，但可能存在潜藏的问题，例如下面的例子：

(更多…)

学习面向对象的过程中通常的说法是new出来的对象都是分配在堆上的，那么这个结论是不是如此绝对，有没有反例呢？

在Java中，典型的对象不再堆上分配的情况有两种：TLAB和栈上分配。 (更多…)