为什么使用redis

转自:http://igoder.iteye.com/blog/1969848
先解释一下软件编程中常见的一些概念:
抽象先于具象。这个抽象并非虚无的抽象,而是指事物尚未分化为具象之前的那个前体存在。当那个前体存在分化成具象存在之后,前体存在就退化为背景,成为一种抽象。
结构是关联与互动的复合体。
接口是结构的耦合点。
架构是从无结构到有结构的过程。
重构是从旧结构到新结构的过程。
也就是说,结构是架构的结果,架构是结构化的过程。
常听人说语言是工具,这是错误的。语言不是工具,但它和工具都是大脑的延伸。语言是介于智力与工具之间的衔接物。
就好比,人类语言是人与人之间的沟通媒介,是人与工具之间的衔接物,而编程语言,不过是将人类语言换成了另外一种符号系统,故编程语言可以看成是人脑与电脑的沟通媒介。

世界万物,皆有层次性。
最开始只有程序员。架构师、项目经理、产品经理都是从程序员逐步分化出来的,架构师是项目最顶层的那个人,必须熟悉各个层次的需求,而不再仅仅是程序层面的。而凡高层次存在者,皆以对结构的调控与整合为其核心能力。这里的结构调整,涉及各个层次,比如人员结构,成本结构,技术结构,语言结构等等。即是说,复杂的工程项目架构不仅仅只是程序的架构,还会涉及人员、流程、管理等各层次的架构。

cap理论指的是三个层面事物的性质,三个层面指数据、系统、网络,简述如下:
一致性:指数据的一致性。
可用性:指系统的可用性。
容错性:指网络的容错性。
此三层层层嵌套包含,环环相扣,稳定性依次降低,而灵活性与复杂性依次上扬,因此出错率也依次提升。越底层的越简单,也越重要,越具有决定性。网络和系统错了,还可以修补,而数据要是错了,就没法挽回了。这其实和数据库的发展史也是一致和同步的。所以分布式的系统,允许偶尔存在网络问题,但需要保证可用性。集中式系统,允许偶尔存在可用性问题,但需要保证一致性。

话说天下大势,合久必分分久必合。
而这世间的事物,也是以一种分化与构合的方式逐步交替演化而来。

nosql的出现,源于数据存储空间与数据访问时间的矛盾。
传统数据库的存储与访问是集中在一起的。
即是说,数据存在什么地方,就去什么地方访问。
集中模式的优点是数据稳定,生命周期长,可靠,强关系,缺点是空间扩展性有限。
集中模式的代表是关系数据库。

社会的进一步分化,使得IT系统也开始分化。
数据库也逐渐从关系数据库向不同领域不同层次分化。
网民的行为从最开始的只读模式,逐渐分化为读多写少的模式。
随着访问量提升,出现了IO密集型访问(此时主要是读取密集型),从而导致读取时间变慢。
为提升性能,发展了数据库缓存技术,主要是对数据库的读取操作进行分离。

而随着web2.0的进一步发展,网民的生产力进一步提升,存储总量开始增加。
此时虽然仍然是读多写少的模式,但写入量已经大大提升。
原有的缓存技术不能缓解写入压力,而且原有的空间也受硬盘限制,因此开始出现分库分表,实现读写分离。

集中模式的数据库就这样开始逐渐分化:由一个集中的、稳定的、强关系的结构,朝一个分化的、容错的、弱关系的结构发展。
数据的存储空间与数据访问时间也进一步分离。
即原来是数据存在什么地方,就去什么地方访问。现在是数据还是存在老地方(硬盘),但是访问却在另一个地方(比如内存,或另一个服务器)。其目的,就在于缩短IO路径或分离IO,实现高效访问。

存储空间的分化,导致写入的分化,实现空间换时间的效果。这种扩展分为两种模式:
如果横向分离(同一层次,空间分离),则可实现诸如主从复制、分库分表等效果,使得读写分离,IO提升。
如果纵向分离(不同层次,过程分离),则可实现数据库缓存、分布式缓存等效果,也能读写分离,IO提升。

redis首先是一个整体,其次是纵向分离的产物(由硬盘分离成硬盘+内存),然后才是横向分离(分布式)。
它从内部是一分为二,将存储空间分为两块,将存储过程分为两步。
而memcached+mysql是两个东西,从外部将两者合二为一。因此在契合度上,redis必然更有优势。
由于空间分离,数据也开始分离。冷数据下沉,热数据上浮,而为了保持数据的一致和同步,必须保证在分离的同时,使得两者保持联系,以便于即时更新数据。
从整体上来说,redis是一个整体,其整体效果和连贯性要大于M+M的组合效果。redis的数据同步在内部完成,是直接同步;而M+M必须借助中间件完成,是间接同步。
从结构上来说,redis的磁盘存储数据要比mysql简单,而内存结构却比memcached多样和灵活。
从扩展性来说,由于redis的底盘简单而稳定,使其有着良好的扩展性,而上层的复杂性使redis可以适应于更多复杂的业务场景。

原来业内认为M+M的问题是:
1,扩展时维护麻烦;
2,存在数据不一致现象;
3,大容量数据下命中率下降。

而redis基本没有上述问题,因此,redis有逐渐取代memcached的趋势。

mysql后来推出了一个memcached插件,对外提供与memcached协议兼容的接口,使得两者终于结为一个统一的整体了。
可以把memcached插件看成是mysql的一部分,因此我们从nosql的角度来看,mysql也可以视为是nosql的一种。
由于memcached插件朝mysql靠拢,使得memcached插件同时还得受制于mysql,即:memcached插件和mysql更紧密更统一的同时,其生命周期和生存空间受到mysql的制约,一荣俱荣一损俱损,一旦mysql挂了它也得挂。因此memcached插件的推出,使得memcached呈现一种收缩的态势,扩展性受到mysql的限制。
从整体上来说,memcached插件的整体性和连贯性使得redis的优势已经被削弱。
从结构上来说,memcached插件可以天然的利用mysql自身的存储和复制,因此存储方面要强于redis,而上层的内存结构和操作方式等依然弱于redis。
从扩展性来说,memcached插件和mysql结合紧密,由于底盘mysql本身的厚重性,扩展性受限制,使得memcached插件的分布式能力弱化了一些。

综上:
越集中的系统,架构越保守越封闭,稳定性越高,联系越紧密,伸缩性和扩展性必然受到制约。
越开放的系统,架构越分化越创新,稳定性越低,联系越松散,伸缩性和扩展性必然逐步扩大。
系统在开放和分离的同时,为了保证子系统内部的统一和连贯,必然要求子系统内部之间保持联系。
这使得现代系统和架构朝分布式和网络化的方向发展,以一种整体的多系统的连续的方式朝外扩散,一如宇宙的膨胀一般。
从逻辑结构上(而非诞生先后)来说,这种扩展趋势可以简单示例如下:

mysql --> mysql+handlersocket插件 --> mysql+memcached插件 --> mysql+memcachedb --> mysql+memcached

由上可见,系统存储架构从一个强联系的整体,朝一个弱联系的个体分化开去,内存应用一步一步朝独立的方向发展,逐步摆脱mysql的制约,向往极端的自由和灵活,直到memcached完全和mysql隔离,时间和空间不再受mysql限制,必须靠第三方工具进行间接联系,使得扩展性达到极致。
由于系统分化使系统之间的联系进一步弱化,势必要求系统之间采用更加复杂的联系方式。
分化的越厉害,中间节点越多,联系方式就越加复杂,稳定性越低,故障自然越多,维护成本越大。

而redis则以一种相对简单和分散的方式,使得这一过程得以继续延续下去。
因此为什么redis能比M+M更好用,原因是:一是结构简单,二是硬盘与内存合为一体。
由于结构简单,所以方便扩展;又由于硬盘与内存合为一体,所以使数据也能同步扩展,维护更简单。