证书链及在nginx下的配置

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

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

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

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

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

生活的可能性

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

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

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

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

我究竟想要什么? 继续阅读

Redis容灾策略

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的性能。

用AtomicStampedReference解决ABA问题

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

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

继续阅读

理解重排序

重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。重排序分为两类:编译期重排序运行期重排序,分别对应编译时和运行时环境。

在并发程序中,程序员会特别关注不同进程或线程之间的数据同步,特别是多个线程同时修改同一变量时,必须采取可靠的同步或其它措施保障数据被正确地修改,这里的一条重要原则是:不要假设指令执行的顺序,你无法预知不同线程之间的指令会以何种顺序执行。

但是在单线程程序中,通常我们容易假设指令是顺序执行的,否则可以想象程序会发生什么可怕的变化。理想的模型是:各种指令执行的顺序是唯一且有序的,这个顺序就是它们被编写在代码中的顺序,与处理器或其它因素无关,这种模型被称作顺序一致性模型,也是基于冯·诺依曼体系的模型。当然,这种假设本身是合理的,在实践中也鲜有异常发生,但事实上,没有哪个现代多处理器架构会采用这种模型,因为它是在是太低效了。而在编译优化和CPU流水线中,几乎都涉及到指令重排序。 继续阅读

Yahoo! S4:分布式流计算平台

一、概述

S4(Simple Scalable Streaming System)最初是Yahoo!为提高搜索广告有效点击率的问题而开发的一个平台,通过统计分析用户对广告的点击率,排除相关度低的广告,提升点击率。目前该项目刚启动不久,所以也可以理解为是他们提出的一个分布式流计算(Distributed Stream Computing)的模型。 继续阅读

QCon2011大会4月8日PPT学习总结

最近正在召开QCon北京2011大会,趁此机会学习了一部分QCon大会的PPT,大会的PPT可以在QCon大会官网下载:http://www.qconbeijing.com/schedule.html

主题:淘宝商品库优化实践

讲师:淘宝核心系统数据库组 余锋(褚霸)

在技术方案的着眼点上,讲师主要强调了:通过高性能硬件支持平台,充分利用Cache(这一点在之后的演讲中多次强调),充分考虑容灾性。同时讲师表示要大胆借助开源产品提高系统性能

在I/O能力的分配上,提高读能力的方式是零散读,提高IOPS,对于提高写能力采用了集中写,提高吞吐量

在Cache分配上,商品库除了采用MySQL的内部存储、虚拟内存以外,还利用了Facebook的Flashcache技术(在文件系统和设备驱动之间新增一次缓存层,实现对热门数据的缓存,一般用SSD作为介质的缓存,通过将传统硬盘上的热门数据缓存到SSD上,然后利用SSD优秀的读性能,来加速系统)。这个方法较之内存缓存,没有内存快,但是可用空间可以比内存大很多。此外还利用了RAID卡内部Cache。

对于系统调优的指导思想,重视理论结合实际,不靠主观猜测而是按实际效果做决定。“内存为王”,用加大内存提升系统性能(其实也是间接加大了缓存)。随机数据和顺序数据分离,随机数据采用Direct IO(优点是CPU占用率小,适用于缓存命中率较低的文件),顺序数据通过缓存读。在保证安全的前提下,一定要充分利用系统各级的Cache

在业务上优化掉复杂查询(类似天涯论坛的做法)。对于InnoDB,分配尽可能大的Buffer Pool,日志数据分开存储,减少锁对多核CPU的影响(减小锁的开销),适时清除InnoDB产生的日志Cache。 继续阅读

NoSQL简介

传统关系型数据库面临很多问题。

1、需要很高的实时插入性能:在高并发读写环境下,每秒上万次读请求勉强可以支撑,但是在每秒上万次写请求之下,硬盘I/O将无法承受。

2、需要海量数据存储能力的同时还需要非常快的查询检索速度:在一个表中存储数以亿计的记录后,使用SQL查询的效率是极为低下的。

3、需要将数据存储无缝扩展到整个集群:数据库的横向扩展比较困难,往往需要停机维护和数据迁移,不能像Web服务器那样简单地通过增加服务器数量来减轻负载。

针对高并发读写海量存储以及可扩展性三个方向,有不同的NoSQL解决方案,这里对每个方向分别简要介绍了Redis、MongoDB、Cassandra三款NoSQL数据库。 继续阅读