为什么使用redis

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

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

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更好用，原因是：一是结构简单，二是硬盘与内存合为一体。
由于结构简单，所以方便扩展；又由于硬盘与内存合为一体，所以使数据也能同步扩展，维护更简单。
注：本文源自http://igoder.iteye.com/blog/1969848