[原]分享一下我和MongoDB与Redis那些事

缘起:来自于我在近期一个项目上遇到的问题,在Segmentfault上发表了提问

知识背景:

  对不是很熟悉MongoDB和Redis的同学做一下介绍。

            1.MongoDB数组查询:MongoDB自带List,可以存放类似这样的结构 List = [1, 2, 3, 4, 5, 6, 7, 8, 9].

               如果我们有一个 l = [2, 3, 8], 则可以进行这样的查询:spce = { 'List' : { '$in' :  l }, 这里spce就是一个查询条件,代表 l 是 List的一个子集。

            2.Redis队列: Redis提供基本的List(普通链表),set(集合),Zset(有序集合) 类型的结构,将List的 lpush, rpop操作运用起来,可以做一个普通的队列,运用Zset 可以做一个带权值的最小堆排序的队列(可以看做优先级)。

整体架构如下图所示:

生产者产生任务,通过LVS与RPC服务器将任务记录到MongoDB,消费者同样通过RPC服务获取任务,这是个很简单的架构,一般服务可能去掉集群都是这样的。

整个业务架构需要一个前提,任务不能丢失,也就是说任务即使失败也需要重新加入到队列,至少若干次后任然失败也要知道为什么失败(非记录日志形式)。

很多人问为什么不直接用RabbitMQ或者Redis,因为这类消息队列无法做到管理任务超时等情况,因为业务需要,也需要做一些简单的查询,这类队列是不支持某些稍复杂的查询的,而且一开始我们的任务量估计在5KW/Day这样,担心Redis扛不住,后来我发现这是个错误的假设。

问题内容如下:

问题背景: 近期在重构公司内部一个重要的任务系统,由于原来的任务系统使用了MongoDB来保存任务,客户端从MongoDB来取,至于为什么用MongoDB,是一个历史问题,也是因为如果使用到MongoDB的数组查询可以减少任务数量很多次,假设这样的情况,一个md5(看做一条记录的唯一标识)需要针对N种情况做任务处理,如果用到MongoDB的数组,只需要将一个md5作为一条任务,其中包含一个长度为N的待处理任务列表,可以使用到MongoDB的数组(只有N个子任务都处理完后整个任务才算处理完毕),这样整个任务系统的数量级就变为原来的 1/N(如果需要用到普通的关系型数据库,可能需要创建 m*n 个任务,这样算下来我们的任务数量将可能达到一个很大的值,主要是因为处理任务的进程由于某些不确定因素无法控制,所以比较慢)

 

细节描述: 1.当MongoDB的任务数量增多的时候,数组查询相当的慢(已经做索引),任务数达到5K就已经不能容忍了,和我们每天的任务数不在一个数量级。

                2.任务处理每个md5对应的N个子任务必须要全部完成才从MongoDB中删除

                3.任务有相应的优先级(保证高优先级优先处理),任务在超时后可以重置。

 

改进方案如下: 由于原有代码的耦合,不能完全抛弃MongoDB,所以决定加一个Redis缓存。一个md5对应的N个子任务分发到N个Redis队列中(拆分子任务)。一个单独的进程从MongoDB中向Redis中将任务同步,客户端不再从MongoDB取任务。这样做的好处是抛弃了原有的MongoDB的数组查询,同步进程从MongoDB中取任务是按照任务的优先级偏移(已做索引)来取,所以速度比数组查询要快。这样客户端向Redis的N个队列中取子任务,把任务结果返回原来的MongoDB任务记录中(根据md5返回子任务)。

 

改进过程遇到的问题: 由于任务处理端向MongoDB返回时候会有一个update操作,如果N个子任务都完成,就将任务从MongoDB中删除。这样的一个问题就是,经过测试后发现MongoDB在高并发写的情况下性能很低下,整个任务系统任务处理速度最大为200/s(16核, 16G, CentOS, 内核2.6.32-358.6.3.el6.x86_64),原因大致为在频繁写情况下,MongoDB的性能会由于锁表操作急剧下降(锁表时间可以达到60%-70%,熟悉MongoDB的人都知道这是多么恐怖的数字)。

 

具体问题: (Think out of the Box)能否提出一个好的解决方案,能够保存任务状态(子任务状态),速度至少超过MongoDB的?

 

提出这个问题后,很感谢官方将问题发到微博首页,有一个回答我觉得可以采纳:

初步的思考了一下,仅供参考:

首先,提一下索引,相信这个你应该加了索引。
有个问题确认一下,mongodb最新版本中的锁粒度还是Database级别吧,不知道你用的哪个版本,还没到锁表(Collection)这个粒度,所以写并发大的情况下比较糟糕,不过应该性能也不至于糟到像你描述的那样啊?不解,建议考虑任务分库的可能性?
能否考虑把子任务的状态和主任务的状态分开保存。子任务的状态,可以放到redis,主任务只负责自己本身的状态,这样每个主任务更新频率降为1/N,可大大减少mongodb中主任务表的压力。
子任务完成或超时后,可否考虑后台异步单线程顺序同步mongodb的主任务状态?

上面这个Answer可以考虑,但是在做同步过程中发现很多问题。

在开发过程中发现,由单一进程从MongoDB向Redis同步数据,可以采取两种可参考的方案:

            1.模拟MongoDB replication机制,一个进程模拟slave向master请求oplog,然后自己解析数据格式存放到Redis.

            2.一个进程从MongoDB中按照优先级取数据然后同步到Redis.

两种参考方案各有优劣,我最终选择了第二种。

            第一种方案

                  优点:

                      1.主MongoDB查询压力变小

                      2.以后业务扩展很方便(可以运用到查询缓存啊,读写分离什么的)

                  缺点:

                      1.可参考文档较少,需要模拟MongoDB replication的机制较为复杂

                      2.同步实时性无法估计确切时间

            第二种方案:

                  优点:

                      1.编码相对简单,按照优先级做索引后查询不影响原有逻辑

                      2.开发较为灵活(似乎和第一点是一样的)

                  缺点:

                      1.(项目完成后测试不理想,具体原因会做说明)

                      2.同步进程单点,如果进程卡死或者机器崩溃会造成系统卡死

 

方案确定:由单一进程从MongoDB同步任务到Redis.

架构变迁到这样:

 

加上Redis,做到MongoDB的读写分离,单一进程从MongoDB及时把任务同步到Redis中。

看起来很完美,但是上线后出现了各种各样的问题,列举一下:

1.Redis队列长度为多少合适?

2.同步进程根据优先级从MongoDB向Redis同步过程中,一次取多少任务合适?太大导致很多无谓的开销,太小又会频繁操作MongoDB

3.当某一个子任务处理较慢的时候,会导致MongoDB的前面优先级较高的任务没有结束,而优先级较低的确得不到处理,造成消费者空闲

 

最终方案:

在生产者产生一个任务的同时,向Redis同步任务,Redis sort set(有序集合,保证优先级顺序不变),消费者通过RPC调用时候,RPC服务器从Redis中取出任务,然后结束任务后从MongoDB中删除。

测试结果,Redis插入效率。Redis-benchmark 并发150,32byte一个任务,一共100W个,插入效率7.3W(不使用持久化)

在这之前我们的担心都是没必要的,Redis的性能非常的好。

目前此套系统可以胜任每天5KW量的任务,我相信可以更多。后面有文章可能会讲到Redis的事务操作

posted @ 2013-11-05 16:14  _Boz  阅读(10278)  评论(7编辑  收藏  举报
4AI?Z:cp1z?_RJQle1]Gs;P!T)RHroW|