redis 多线程与阉割版

gggggds

　　
　　终于折腾出redis的多线程版，大概实现：
　　1.每个db一个读写锁，dirty操作写锁，否则读锁。
　　2.一个boss线程，n个worker线程，boss线程负责accept连接，rehash，expire。wokrer负责处理客户端请求。client平均分配到各个worker上。一般的client请求都不会与其他client打交道，除了push遇到bpop，pubsub这两个操作。boss与worker的通信通过一对pipe，类似memcahced的处理方法。这个和java的selector的wakeup实现也有点类似，通过read pipe 来退出阻塞的epool。在linux操作pipe，还有个小技巧，可以通过禁止更新访问时间来减少开销，具体可见http://rdc.taobao.com/blog/cs/?p=1295。
　　3.阉割掉vm，pubsub，dbdump，aof，slave等功能。vm的删除令代码简洁不少，官方也是打算删除的。pubsub在多线程下实现有点困难，这个功能就交给更专业的mq去做吧。至于aof和slave其实是有点类似的，都需要记录command log，这个功能和dbdump考虑后继支持。阉割这些功能后，多线程的实现就简单多了。
　　通过测试，多线程支持对效率提高还是蛮大的。测试环境，两台redhat6.0，i72600（3.4G)，中间千兆带宽（交换机有问题，只能压到50m流量，这个在lange测试案例中，是瓶颈）。为了区分改造后的redis，都用sedis来称呼。测试使用产品带的benchmark，除了request数设为100w，其他都使用默认参数，其中client数50。通过运行一个或多个benchmark来进行压测。redis关闭和持久化相关的功能。整个测试中内存最大几百兆，远远没达到物理内存上限。
　　测试结果见附件的excel（实在没有这个毅力在把图表往blog上整理了），sheet1（网络访问）是client和server不同物理机，sheet2（同物理机）是client和server相同物理机。
　　增加相同物理机的案例，目的是最大减少网络的开销影响，看看多线程能提升多少，另外，实在是50m的流量不够用。每个测试项目有两个指标，采集于benchmark的输出，一项是吞吐量，一项是时延。对于时延，如果第一项是49.95% <= 2，就是说49.95%的完成时间是大于1ms，小于2ms。小于1ms的数量小到可以忽略。
　　大概总结一下测试结果：
　　通过网络，sedis使用4个woker：
　　对于redis，1个benchmark和2个benchmark，在吞吐量上没有太大区别，但是对于两个benchmark，时延增大非常明显。LRANGE (first 600 elements)甚至出现时延207ms的情况，在该案例下，单benchmark最大的时延只是19ms。redis的单线程模型在处理多client时有点吃力，特别是LRANGE 这种比较耗时的操作。
　　对于sedis，1个benchmark，与redis相比，在简单的操作下是吃亏的，首先benchmark是串行的，多个worker的用处不大，反而背上锁的开销。所以在单个benchmark上，简单操作的吞吐量比redis要慢10%到20%左右，但是在较耗cpu的操作下，例如mset和lrange能提升50%左右。对于2个benchmark，与单benchmark相比，吞吐量提升的幅度就比较可观了，各个案例k提升接近100%。有一些没有提升的案例，例如mset和lrange，那是逼近50m的限制了。
　　不通过网络，sedis使用2个woker，毕竟只有4核，以免cpu是瓶颈。
　　对于redis，1个benchmark和2个benchmark，在吞吐量上仍然没太大区别，只是时延增大。应该差不多达到单线程的最大处理能力了。
　　对于sedis，1个benchmark在简单操作下，吞吐量仍然是稍小于redis，mset和lrange也是提升50%左右。
　　2个benchmark，吞吐量比1个benchmark也有一定幅度的提升。把sedis的worker数量加到3，吞吐量还有所上升。
　　总体来说，多线程的支持对于性能的提升是有正向作用的。并且这次的测试client的并发度不足，不能充分发挥出多线程的优势。当然，也不排除存在锁冲突引起的线程阻塞唤醒的负面影响。这里是否能换自旋读写锁？
　　从测试结果来看，redis单服务器在多client高负载情况下还是有点不妥，偶尔出现时延较大的情况，可以考虑master-slave做读写分离。
　　改造完毕后，不得不感叹一下，单线程就是爽啊。。。。