【转】Redis计数在新浪微博的应用

微博业务的迅速发展，对基础架构层面的要求也愈来愈高。新浪做为国内最先使用redis，而且是国内最大的redis使用者，在redis的使用上，也在逐步优化和提升。

做为微博中一项重要的数据，计数类业务在微博业务中占的比重和重要性逐步提升。计数结果的准确度直接影响用户体验，而且很容易引发用户的投诉。在计数业务上，在不断的优化和改进中，咱们主要经历了如下三个阶段：

初级阶段

从2010年开始，使用redis-2.0版本。在最初业务数据比较少的时候，表现至关不错。但随着数据量和请求量的不断增长，一些问题逐渐暴露出来。

主从同步问题

• 首先遇到的是主从的同步问题。它的原理是当master接收到slave的同步请求后，把内存的数据fork出一个子进程dump出来，造成rdb文件，而后传到slave，slave再把这个文件加载到内存，以后的增量更新由master在执行完每条修改命令后当即同步给slave。 在网络出现问题时，好比瞬断，会致使slave里的数据所有重传。对单个端口来讲，若是数据量小，那么这个影响不大，而若是数据量比较大的话，就会致使网络流量暴增，同时slave在加载rdb时没法响应任何请求。

• 持久化问题

  计数业务中多数使用redis做为存储，所以都开启了aof，并配置为每秒作一次fsync操做将写操做刷新到磁盘。随着aof的增加，须要按期rewrite。Rewrite的机制和生成rdb的过程相似，都是fork出一个子进程来完成的，子进程对于磁盘的持续写入会致使父进程的 fsync操做阻塞，形成大量请求超时。

• 版本升级问题

  因为redis在使用初期bug较多，版本迭代频繁，而版本升级须要关闭redis进程并从新加载aof。对于大量使用redis的微博业务来说，这样的升级成本也愈来愈难以承受。

• 内存使用问题

  2.0版本的redis，在内存使用上相对比较粗放，对于计数这样一个简单的key-value，占用的内存达到100字节以上，存在比较多的优化空间。

进阶阶段

针对redis使用初期存在的问题，咱们逐个进行了改进。主从复制参考mysql的同步方式，使用rdb+aof结合的方式，解决了网络瞬断引发的重传问题，同时限制子进程作后台dump时对磁盘的写入，期间暂停主进程的fsync操做，解决了慢请求的问题。

针对计数业务，咱们开发了专用的版本redisscounter，单个key-value占用的内存key的长度加4个字节的value，将内存的使用量下降到原来的1/4如下。经过预先分配内存数组和double hash技术，消除了redis中hash表的大量指针开销。

对于版本升级的问题，咱们将redis的核心处理逻辑封装到动态库，内存中的数据保存在全局变量里，经过外部程序来调用动态库里的相应函数来读写数据。版本升级时只须要替换成新的动态库文件便可，无须从新载入数据。经过这样的方式，版本升级只需执行一条指令，便可在毫秒级别完成代码的升级，同时对客户端请求无任何影响。

有了上面的改进后，新版本开始大量应用，多数业务均可以做为完整的存储替代之前的mysql+memcached组合。对于微博的评论数和转发数，因为微博条目不断增长，没法保存全量数据，所以采用mysql+redisscounter组合的方式，mysql保存全量数据，使用两组 redisscounter保存最近几个月的热数据，经过按期滚动两组redisscounter里的数据来清理冷数据。

高级阶段

随着微博的发展，针对单条微博的计数也不断增长，从原来的评论数、转发数，又增长了表态数，2013年还上线了阅读数。Redisscounter 不能很好的解决这类扩展问题，同时上面的mysql+redisscounter的滚动方式也过于复杂，按期的滚动操做很容易出现问题。针对这类问题，咱们再度作出改进，将key由原先的字符串改为微博id，同时对于每条微博的评论转发等计数，咱们统计发现，绝大多数微博的计数均可以用10~15个bit 来保存，所以能够将多个计数保存到一个4字节的value里，过大的计数值在内存中另外开辟一块空间来保存。这样经过一条get命令便可获取该微博的全部计数。同时针对微博业务的特色，越老的微博被访问的次数就会越少，在内存使用多个数组保存不一样范围的微博，内存不足时将最老的一组微博dump到ssd 上，内部自动实现的滚动能够保证热微博所有在内存里。对于落到ssd上的老数据的访问，经过异步的io线程来读写，通过这样的改进后，去掉了原先的 mysql存储，下降了业务开发成本和运维成本。

从redis在计数业务上的发展经历能够看出，技术的进步是由业务的需求推进的。随着业务的发展，还会遇到更多新的挑战。但愿咱们走过的这些改进之路对于读者在使用redis的过程当中能有所帮助。