AliRedis单机180w QPS, 8台服务器构建1000w QPS Cache集群

转自：http://www.open-open.com/lib/view/open1389880948758.html

引言:
        现在redis凭借其高性能的优点, 以及丰富的数据结构做为cache已愈来愈流行, 逐步取代了memcached等cache产品,在Twitter,新浪微博中普遍使用,阿里巴巴一样如此. redis已经占据了其不可动摇的地位, 然而在实际的生产环境中, redis也暴露出一些其余问题.如性能瓶颈, 内存冗余, 运维部署复杂等. 本文目的就是分析redis现有的问题, 以及介绍阿里巴巴技术保障团队对redis的改造工做, 使其在生产环境中发挥更大的价值.
 
原生redis的瓶颈: 
1. 单进程单线程, 没法充分发挥服务器多核cpu的性能.
2. 大流量下形成IO阻塞. 一样是因为单进程单线程, cpu在处理业务逻辑的时候,网络IO被阻塞住, 形成没法处理更多的请求.
3. 维护成本高, 若是想要充分发挥服务器的全部资源包括cpu, 网络io等, 就必须创建多个instance, 但此时不可避免会增长维护成本.  拿24核服务器举例来说, 若是部署24个单机版的instance,理论上能够实现10w*24core= 240wQPS的整体性能.可是每一个 instance 有各自独立的数据,占用资源如内存也会同比上升,反过来制约一台服务器又未必能支持这么多的 instance.  若是部署24个Instance来构成单机集群, 虽然能够共享数据，可是由于节点增长, redis的状态通信更加频繁和费时,性能也下会降不少.  而且两种方式都意味着要维护24个Instance，运维成本都会成倍增长. 

4. 持久化. redis提供了两种save方式 1)save触发. 2)bgsave. 固然也可使用3)aof来实现持久化, 可是这3点都有弊端.
         1)save:  因为是单进程单线程, redis会阻塞住全部请求, 来遍历全部redisDB, 把key-val写入dump.rdb. 若是内存数据量过大, 会形成短期几秒到几十秒甚至更长的时间中止服务, 这种方案对于twitter, taobao等大流量的网站, 显然是不可取的.  
         2)bgsave: 在触发bgsave时, redis会fork自身, child进程会进入1)的处理方式,这意味着服务器内存要有一半的冗余才能够, 现在内存已变得愈来愈廉价, 可是对于存储海量数据的状况,内存以及服务器的成本仍是不容忽视的. 
         3)aof:  说到持久化, redis提供的aof算是最完美的方案了, 可是有得必有失, 严重影响性能! 由于redis每接收到一条请求,就要把命令内容完整的写到磁盘文件, 且不说频繁读写会影响磁盘寿命,写磁盘的时间足以拖垮redis总体性能 . 固然熟悉redis的开发者会想到用appendfsync等参数来调整, 但都不是完美.即便使用 SSD，性能也只是略有提高，而且性价比不高。
 
针对以上几种状况, 阿里技术保障团队作了以下优化手段, 其实这不只仅只是优化, 而更是一种对redis的改造.
1. 多线程master + N*work 工做模式.master线程负责监听网络事件, 在接收到一个新的链接后, master会把新的fd注册到worker的epoll事件中, 交由worker处理这个fd的全部读写事件, 这样master线程就能够彻底被释放出来接收更多的链接, 同时又不妨碍worker处理业务逻辑和IO读写.

采用这种master + N*worker的网络层事件模型,能够实现redis性能的平行扩展. 真正的让redis在面临高并发请求时能够丛容面对.
2. 抛弃save, bgsave, aof等三种模式.采用redisDB lock模式. AliRedis在数据存储层把多DB存储模式转换成HashDb存储,将key hash到全部RedisDB上, 这样作有一个弊端就是抛弃了select命令, 但与此同时会带来一个更大的好处, 能够逐个DB持久化而不会影响整个系统, 在作持久化的时候AliRedis只需lock住1/N个redisDb, 占用1/m个线程. 在不须要内存冗余的状况下进行持久化, 相比以前提到的弊端, 这种方式能够带来更大的收益, 更丰厚的回报.
3. 重构hiredis客户端, 支持redis-cluster工做模式, 目前hiredis并不支持redis-cluster模式, 阿里技术保障团队对hiredis进行重构,使之支持redis-cluster.
4. 优化jemalloc, 采用大内存页.  Redis在使用内存方面可谓苛刻至极, 压缩, string转number等, 能省就省, 可是在实际生产环境中, 为了追求性能, 对于内存的使用能够适度（不至于如bgsave般浪费）通融处理, 所以AliRedis对jemalloc作了微调, 经过调整pagesize来让一次je_malloc分配更多run空间来储备更多的用户态可用内存, 同时能够减轻换页表的负载, 下降user sys的切换频率, 来提升申请内存的性能, 对jemalloc有兴趣的开发者能够参考jemalloc源码中的bin, run, chunk数据结构进行分析.

经过如上改造 , redis 能够充分发挥服务器多核的优点 , 以及网络 IO 复用 , 特别是节省运维成本 , 每台服务器只需维护一个AliRedis 实例 .



测试环境
CPU: Intel Xeon E5-2630 2.3GHz, *2
KERNEL: 3.2.0
GCC: 4.4.6
Jemalloc: 3.2.0
NIC: Intel 82599EB

测试数据
AliRedis单机版性能数据
thread:            1            2              4            8             12          16             20             24
set/get=1:1    83182  162214  301552 605817 876656 1173748 1551113 1800878

AliRedis集群
8个节点, 20台客户端, 配置相同, cpu所有打满.
set/get=1:1   qps: 10,344,877
 
结论
单机版AliRedis能够实现24核跑满180wQPS性能.
集群版能够实现8台服务器支撑1000wQPS的数据请求.
 
阿里巴巴技术保障团队肩负着支撑阿里技术, 保障系统稳定运行的艰巨使命.不论是双11, 仍是双12, 或者其余大促活动, 每一个阿里人都在努力且拼命的工做, 拿本身的劳动来捍卫着阿里集团的荣誉.
 
阿里技术-保障奇迹.
                                                                                    阿里技术保障部-系统运营-网络部-子逍

来自：http://blog.sina.com.cn/s/blog_e59371cc0101br74.html