redis:
1、热点数据的缓存
由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合expire，我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见，我们几乎所有的项目都有所运用。
2、限时业务的运用
可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。
3、计数器相关问题
redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
4、排行榜相关问题
关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。
在奶茶活动中，我们需要展示各个部门的点赞排行榜， 所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash,通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。
5、分布式锁
这个主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在俞你奔远方的后台中有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先 通过setnx设置一个lock，如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。 当然结合具体业务，我们可以给这个lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间 就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。
6、延时操作
这个目前我做过相关测试，但是还没有运用到我们的实际项目中，下面我举个该特性的应用场景。 比如在订单生产后我们占用了库存，10分钟后去检验用户是够真正购买，如果没有购买将该单据设置无效，同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notifications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期， 我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。 当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。
7、分页、模糊搜索
redis的set集合中提供了一个zrangebylex方法，语法如下：
ZRANGEBYLEX key min max [LIMIT offset count]
通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询，其中- +表示获取全部数据
zrangebylex key min max 这个就可以返回字典区间的数据，利用这个特性可以进行模糊查询功能，这个也是目前我在redis中发现的唯一一个支持对存储内容进行模糊查询的特性。
前几天我通过这个特性，对学校数据进行了模拟测试，学校数据60万左右，响应时间在700ms左右，比mysql的like查询稍微快一点，但是由于它可以避免大量的数据库io操作，所以总体还是比直接mysql查询更利于系统的性能保障。
8、点赞、好友等相互关系的存储
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。 又或者在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。
这个在奶茶活动中有运用，就是利用set存储用户之间的点赞关联的，另外在点赞前判断是否点赞过就利用了sismember方法，当时这个接口的响应时间控制在10毫秒内，十分高效。
9、队列
由于redis有list push和list pop这样的命令，所以能够很方便的执行队列操作。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
mongodb:
不确定业务模型，快速验证的原型项目。
高写负载的场景，存储评论，日志等大规模的非核心业务数据。
大规模或可能爆发式增长的非结构化数据存储。
大数据量缓存。
基于位置的查询业务。
游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新
物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能
物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析
视频直播，使用 MongoDB 存储用户信息、礼物信息等
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
memcache:
1、缓存一些很小但是会被频繁访问的数据或文件，以及访问量很大的动态网页：一般的大数据的信息网站，比如招标网站、房产网站，这样的网站访问量一般比较大，对于网站文章等，这些基本上是一次成型，基本上不会修改的，并不适用于memcached，可以直接使用文件缓存。但是这样的网站一般首页的访问是较为频繁的，所以可以把网站上的信息分类缓存到memcached中，同样的，首页上的推荐信息也可以缓存到memcached中，这样就大大的减轻了服务器的压力。
2、可以缓存计算好的结果：在举一下上个例子，比如招标网，某一分类下的信息可能达到了几百万，这个时候，每次访问列表都需要获取一下总条数，这个如果数据库引擎是innodb,那么获取总条数的时间可能在2s以上，对于客户来说两秒的等待时间无疑已经比较长了，并且一般招标的网站的信息都是第一天写入，第二天才发布，或者在晚上的时候写入，并没有特别高的实时性要求，或者说最早之前写入的数据存在的意义已经不大了，那这个时候，我们可以把这个总条数缓存到memcached中，每天零点更新一下memcached中的总条数，这样就大大的加快了访问速度。
3、可以缓存session数据（临时数据）：比如社交网站，一般用户的在线时间都比较长，这个时候数据如果存在数据库中的话，每次都从数据中读取，无疑数据库的压力是非常大的，这里可以采用memcached集群，把session数据按照用户id或者其他划分到不同的memcached中，这样就减少了对数据库的读写操作，这里需要注意的一点是：session的缓存必须进行更新，需要考虑session的有效时长，以及用户活动状态，延长session的有效时长。
4、可以缓存最热度的信息：以房产网站为例，比如某小区的房源，搜索查看度特别热，可以把这个搜索的sql语句结果写入到session中，这样也极大的减轻了服务器的压力，还提高了客户的体验度。