即时通讯mysql压力_Soul即时通讯之数据库优化

背景

在Soul的IM上线后，初始时用户本地消息量不大的情况下，数据库读写良好，不容易发现问题。

但随着产品用的时间越来越近，有些用户本地聊天数据达到500万条以上时，数据库性能瓶颈逐渐体现出来。

1.读写数据较慢。

2.读写在同一线程里，当大量数据写入时，迟迟读不出数据，体验较差

所以数据库这块急需优化

优化之前的方案

之前im用的是著名三方数据库FMDB，它只是简单的对sqlite进行了封装，线程安全方案是把所有的数据库操作放到了一个串行队列里去同步执行。

因为sqlite是不能多个操作同时访问一个连接，不然会crash。

这样做的好处是确保了数据库连接数据读写安全，缺点是无法进行线程并发操作。

对于IM这种对海量数据存储性能要求较高的项目，FMDB不能满足需求。

优化思考

我们所要做的是支持多线程读写的数据库。

这里介绍下WAL模式：SQLite引入了 WAL 模式，即 Write-Ahead Log。在这种模式下，所有的修改会写入一个单独的 WAL 文件内。这种模式下，写操作甚至可以不去操作数据库，这使得所有的读操作可以在 "写的同时" 直接对数据库文件进行操作，得到更好的并发性能。

这样实现了读和写的并发。

同时sqlite支持三种线程模式：

单线程模型 这种模型下，所有互斥锁都被禁用，同一时间只能由一个线程访问。

多线程模型 这种模型下，一个连接在同一时间内只有一个线程使用就是安全的。

串行模型 开启所有锁，可以随意访问。

优化尝试

前提条件：首先串行模式pass掉，只考虑单线程和多线程模式。

1.建表：

create table if not exists ChatModelDB (localId INTEGER primary key AUTOINCREMENT,

CommonId varchar(256),

text1 varchar(256),

text2 varchar(256),

text3 varchar(256),

text4 varchar(256),

text5 Long Long,

text6 INTEGER),

CommonId建立索引

2.已在数据库里插入100万条数据，每一列都是随机字符。

1.单线程模式 +无wal，也是FMDB模式

插入1万条根据CommonId读取20条

- (void)insert {

dispatch_async(queue, ^{

[db beginTransaction];

for (int j = 0;j<10000;j++) {

NString *insertSql = @"insert *****;

BOOL result = [db executeUpdate:insertSql];

}

[db commit];

}];

});

}

- (void)select{

dispatch_async(queue, ^{

NSArray *array = [db getRowsForQuery:selectSql];

});

}

混合读写

for (i = 0;i<100;i++) {

[self insert];

[self select];

}

写消耗：1237ms,

读消耗：10-20ms

混合读写：72185

2.单线程模式+wal

if (sqlite3_exec(_wdb, "PRAGMA journal_mode=WAL;", NULL, NULL, &error) != SQLITE_OK) {

NSLog(@"Failed to set WAL mode: %s", error);

}

写消耗：480ms

读消耗：10-15ms

混合读写：76205ms

会发现，打开wal模式后，写性能近乎提示了3倍，读性能差别不大。

3.多线程模式+多线程连接+wal

dispatch_async(globlequeue, ^{

sqlite3_open(db);

[self insert];

sqlite3_close(db);

});

dispatch_async(globlequeue, ^{

sqlite3_open(db);

[self select];

sqlite3_close(db);

});

混合读写：157301ms

会发现混合性能很差，真正开启所谓的多线程操作时，实际上是每个线程持有一个数据库句柄，每做一个操作前，要重新打开一个db句柄，执行完后再close db句柄，这样频繁的打开数据是很消耗性能的，一味地追求多线程并不会达到很好的性能，并且操作不好还容易crash。

在移动端这种微操作系统对数据库的依赖远没有后端那般沉重，所以接下来考虑用单句柄+队列的方式进行测试。

4.多线程模式+wal+异步单队列

queue = dispatch_queue_create([[self queueName] UTF8String], DISPATCH_QUEUE_SERIAL);

dispatch_async(queue, ^{

[self insert];

});

dispatch_asyncqueue, ^{

[self select];

});

读写性能和2相差不大

混合读写：68300ms

混合读写性能优于2，在大型app场景下性能尤为明显，本次测试是在无其他业务线程影响下，等于测试示例独自cpu资源，和线上场景误差交大。

5.多线程模式+wal+同步单队列

queue = dispatch_queue_create([[selfqueueName] UTF8String], DISPATCH_QUEUE_SERIAL);

dispatch_sync(queue, ^{

[self insert];

});

dispatch_syncqueue, ^{

[self select];

});

混合读写：66454ms

性能略逊于4，相差微乎其微，考虑切线程影响

考虑，多线程模式+wal模式下，读和读并发，读和写并发，写和写不并发，

而读速度远大于写速度，因为经检验，在500万数据量下，读速度在20ms以内速度较快，所以读并发暂不考虑，只给数据库开启两条连接，读连接和写连接， 只做读和写之间的并发，为此，设置两条队列：读队列和写队列，彼此异步执行，测试示例6。

6.多线程模式+wal+读写队列分离

readqueue = dispatch_queue_create([[self queueName] UTF8String], DISPATCH_QUEUE_SERIAL);

writequeue = dispatch_queue_create([[self queueName] UTF8String], DISPATCH_QUEUE_SERIAL);

dispatch_async(writequeue, ^{

[self insert];

});

dispatch_async(readqueue, ^{

[self select];

});

混合读写：73112ms

这里会发现，双队列的读写速度居然略慢于单队列读写。

分析，因为数据是在demo上跑，demo上无其他任务在执行，等于cpu满负荷只为测试调用，而理论上频繁的线程切换也需要资源开销，单队列模式下的线程切换减少，性能略优于双队列。

但在实际的项目中，app场景复杂，cpu无时不在执行做一些复杂的功能，所以在demo上播放一个长视频进行测试，并且同时异步执行一个while循环空转，测试cpu调度频繁被其他业务影响时数据库操作的性能。

经测试混合读写：1.多线程模式+wal+异步单队列 7800ms左右

2.多线程模式+wal+同步单队列 73960ms左右

3. 多线程模式+wal+读写队列分离 60471ms左右

在cpu调度频繁的场景下，多线程的优势体现了出来，在wal模式下，写性能提升几倍，读和写并发，读和读并发，写和写串行，达到效率最大化。

所以决定选用模式多线程模式+wal+读写队列分离模式。