Redis的使用场景

redis和mysql要根据具体业务场景去选型

• mysql：数据放在磁盘
  
• redis：数据放在内存
  

redis适合放一些频繁使用，比较热的数据，因为是放在内存中，读写速度都非常快，一般会应用在下面一些场景

• 排行榜
  
• 计数器
  
• 消息队列推送
  
• 好友关注，粉丝

实现共同关注的功能：本质上是计算连个用户关注的交集，如果使用关系型数据库，它并不支持交集计算工作，要计算两个集合的交集，除了要对两个数据表进行合并(join)操作之外，还需要对合并的结果执行去重复(distinct)操作最终导致交集操作的实现变得异常复杂。而Redis内置了集合(set)类型并支持对集合执行，交集、并集、差集等操作，使用其中的交际功能就可以实现共同关注功能

对于利用redis实现消息队列的具体方式：http://blog.csdn.net/stationxp/article/details/45731497一共有四篇这里选取了一篇

1、为什么需要消息队列？

当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，就需要消息队列，作为抽象层，弥合双方的差异。

举个例子：业务系统触发短信发送申请，但短信发送模块速度跟不上，需要将来不及处理的消息暂存一下，缓冲压力。 
再举个例子：调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。 
再举个栗子，交互模块5：00到24：00和电商系统联通，和内部ERP断开。1：00到4：00和ERP联通，和电商系统断开。 
再举个例子，服务员点菜快，厨师做菜慢。 
再举个例子，到银行办事的人多，提供服务的窗口少。 
乖乖排队吧。

2、使用消息队列有什么好处？

2.1、提高系统响应速度

使用了消息队列，生产者一方，把消息往队列里一扔，就可以立马返回，响应用户了。无需等待处理结果。

处理结果可以让用户稍后自己来取，如医院取化验单。也可以让生产者订阅（如：留下手机号码或让生产者实现listener接口、加入监听队列），有结果了通知。获得约定将结果放在某处，无需通知。

2.2、提高系统稳定性

考虑电商系统下订单，发送数据给生产系统的情况。 
电商系统和生产系统之间的网络有可能掉线，生产系统可能会因维护等原因暂停服务。

如果不使用消息队列，电商系统数据发布出去，顾客无法下单，影响业务开展。 
两个系统间不应该如此紧密耦合。应该通过消息队列解耦。同时让系统更健壮、稳定。

3、为什么需要分布式？

3.1、多系统协作需要分布式

消息队列中的数据需要在多个系统间共享数据才能发挥价值。 
所以必须提供分布式通信机制、协同机制。

3.2、单系统内部署环境需要分布式

单系统内部，为了更好的性能、为了避免单点故障，多为集群环境。 
集群环境中，应用运行在多台服务器的多个JVM中；数据也保存在各种类型的数据库或非数据库的多个节点上。 
为了满足多节点协作需要，需要提供分布式的解决方案。

4、分布式环境下需要解决哪些问题

4.1、并发问题

需进行良好的并发控制。确保“线程安全“。

不要出现一个订单被出货两次。不要出现顾客A下的单，发货发给了顾客B等情况。

4.2、简单的、统一的操作机制

需定义简单的，语义明确的，业务无关的，恰当稳妥的统一的访问方式。

4.3、容错

控制好单点故障，确保数据安全。

4.4、可横向扩展

可便捷扩容。

5、如何实现？

成熟的消息队列中间件产品太多了，族繁不及备载。

成熟产品经过验证，接口规范，可扩展性强。

结合事业环境因素、组织过程遗产、实施运维考虑、技术路线考虑、开发人员情况等原因综合考虑，基于Redis自己做一个是最可行的选择。

如何做呢？ 
请听下回分解。