相对于memcache，redis拥有的持久化和多数据类型，非常适合应用于互联网社交、电商等业务较为复杂的系统中。
新浪微博是国内最早（2010年）大规模线上Redis的实践者，到目前已经趋于极致。
看这篇干货，我们能借鉴到如何避免大规模应用redis时，会碰到的问题，如：
1、持久化内存消耗导致服务崩溃。
2、主从同步全量加载问题
3、版本升级的问题
当然，文中还提到了特定业务场景下的定制化应用。
文章摘录：
----------------------------------------------------------------------
微博是从 2010 年开始引入 Redis ，现在 Redis 已经广泛应用于微博的多个业务场景，如关系、计数、通知提醒等，目前 Redis 集群存储超过百亿记录，每天上万亿的读取访问。
持久化问题
在我们大多数业务场景中 Redis 是当做存储来使用，会开启持久化机制。线上采用单机多实例的部署结构，服务器的内存使用率也会比较高。
由于官方版本触发 bgsave 和 bgrewriteaof 操作的时间点是不可控的，依赖于相关的配置项和业务的写入模型，因此可能会出现单机部署的多个 Redis 实例同时触发 bgsave 或 bgrewriteaof 操作，这两个操作都是通过 fork 出一个子进程来完成的，由于 copy-on-write 机制，可能会导致服务器内存很快耗尽， Redis 服务崩溃。
此外在磁盘压力较大时（生成 rdb、aof 重写），对 aof 的写入及 fsync 操作可能会出现阻塞，虽然从 2.4 版本开始 fsync 操作调整到 bio 线程来做，主线程 aof 的写入阻塞仍会导致服务阻塞。
主从同步问题
官方版本的主从同步机制，在网络出现问题时（如瞬断），会导致主从重新进行一次全量复制。
当然官方 2.8 版本支持了 psync 增量复制的机制，一定程度上解决了主从连接断开会引发全量复制的问题
版本升级及管理问题
官方版本在执行升级操作时，需要服务重启，我们大多数线上业务都开启了持久化机制，重启操作耗时较长，加上使用 Redis 业务线比较多，版本升级操作的复杂度很高。
1. 对于持久化机制，采用 rdb + aof 的持久化方式。
aof 文件按固定大小滚动，生成 rdb 文件时记录当前 aof 的 position，全量的数据包含在 rdb 和所记录位置点之后的 aof 文件，废弃 aof 重写机制，生成 rdb 后删除无效的 aof 文件；增加了定时持久化操作的配置项 cronsave，将单机部署的多个 Redis 实例的持久化操作分散在不同的时间点进行，并且错开业务高峰；将对 aof 的写入操作也放到 bio 线程来做，解决磁盘压力较大时 Redis 阻塞的问题。
2. 对于主从同步机制，借鉴 MySQL 的复制机制并做了简化。使用 rdb + aof 的方式，支持基于 aofpositon 的增量复制
----------------------------------------------------------------------
咔咔笔记：
1、真的是业务需求推动技术变革，技术只有持续优化、改进，才能满足业务发展需要，才能体现其价值。
2、即使是再优秀的开源产品，要拿来适配公司业务，还是要深度探究和改进才行。
3、官方提供的redis解决方案，足够满足中小型企业的技术要求，但是如何用到极致，还是需要优秀的人才来打磨。
4、要持久话的数据，能放到mysql就不要扔到redis，当然，除非你对redis的持久化可以像上面他们做的一样靠谱才行。
5、个人还是更倾向于redis的缓存模式和它的实用的数据类型。
来自：http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547263&idx=1&sn=fe484b24660b7e1dc4beabca71fe1cb1&scene=0#rd
