Redis也是一款NoSQL的存储产品，特点是性能，所以牺牲了一致性和分区容错性，以至于该产品更加倾向于做缓存和队列的操作

Redis和Memcached一样，是完全在内存中进行操作，key-value的存储服务

• 它支持更多的数据类型：string（字符串），list（链表），set（集合），zset（有序集合）
• 都支持push/pop、add/remove及取交集并集和差集及更丰富的操作
• 而且这些操作都是原子性的

其中的string也就是和Memcached一样的功能，在性能上完全可以和Memcached比肩甚至超越

因为其实现原理，目前只支持主从的备份环境，如果将其当成如memcached的缓存使用，可以通过一致性hash算法实现如同memcached一样的操作

Redis作为一款存储产品，也用最终一致性为实现目标，部分数据在内存中，如果强制性的设置appendonly，对其的性能有很大的影响（优势！~）

如果需要将数据落地在牺牲一定性能的前提下还是可以通过一定时间同步一次的操纵实现（较为合适）

使用例如：点评的数据统计，排行等

该产品作为队列服务非常适合（很多基本的数据类型完全能满足队列的需求，并且还可以灵活的更换队列流程）

消息队列：

左侧为基本的程序处理流程，传统的调用流程

弊端：

• service如果处理时间较长，那么client需要一直hold，甚至调用超时而失败
• service的些许改动会带来client的代码修改等等

在此基础上，右侧使用消息队列，可以避免该情况的发生

1. 保证消息的传递：如果发送消息时接收者不可用，消息队列会保留消息，直到成功地传递它；
2. 提供异步的通信协议：消息的发送者将消息发送到消息队列后可以立即返回，不用等待接收者的响应，消息会被保存在队列中，直到接收者取出它；
3. 提供路由
4. 解耦，降低两个进程间的耦合度：

• 只要消息格式不变，即使接收者的接口、位置、或者配置改变，也不会给发送者带来任何改变；
• 而且，消息发送者无需知道消息接收者是谁，使得系统设计更清晰；
• 相反的，例如，远程过程调用（RPC）或者服务间通过socket建立连接，如果对方接口改变了或者对方ip、端口改变了，那么另一方需要改写代码或者改写配置；

RabbitMQ是一款现在比较有影响力的消息队列，完整的实现了以上的功能

RabbitMQ 是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成，因此也是继承了这些优点。

AMQP 里主要要说两个组件：Exchange 和 Queue （在 AMQP 1.0 里还会有变动）

如下图所示，绿色的 X 就是 Exchange ，红色的是 Queue ，这两者都在 Server 端，又称作 Broker ，这部分是 RabbitMQ 实现的，而蓝色的则是客户端，通常有 Producer 和 Consumer 两种类型

如果取消路由功能，在系统构架上分离该操作，则Redis完全能应对消息队列的操作，但需要做一定程度的操作封装

如果要实现路由功能，也可以通过第三方代理实现，但良好的设计可以避免该需要，因为路由的作用2点：单点故障及数据过滤分发

• 单点故障目前Redis有明显的限制，需要通过脚本做自我监控以保证主从切换
• 数据过滤分发是程序上可以处理，只需要简化逻辑结构即可

因为Redis提供的是基本的数据结构层面的操作，所以有好的数据结构基础能进行更好的设计，以实现更加灵活的业务需求