mysql大数量并发问题

本文采用多线程对MySQL进行并发读取访问，其中以返回用户所需的数据并显示在终端为测试结束节点，即将数据从MySQL集群读取后存储于客户端本地内存中。

测试过程如下：分别针对4种应用场景，从10、20、50、100个线程对MySQL展开测试。测试结果表明：对场景1)一般的并发访问能够满足需求;对于场景2)和3)响应时间在分钟级，分别处于1-3分钟和10分钟左右;对于场景4)则经常会抛出异常，并且以异常点为基准，其响应时间在30 分钟左右。

 

测试环境

 

硬件环境：

Localhost：CPU： Intel Core I5, 主频：3.10G, 内存：4G

MySQL集群：9台服务器

软件环境：

Localhost: Win7，jdk 1.8

MySQL集群： MySQL5.6.25(社区版)

数据规模：

数据条目：一个月的股票数据，2亿4千万余条记录，表结构为50个字段左右，具体内容见下面表结构。

表结构：

 

DROP TABLE IF EXISTS `TAQ_201504`;
CREATE TABLE `TAQ_201504` (
  `SECCODE` varchar(6) NOT NULL,
  `SECNAME` varchar(20) NOT NULL,
  `TDATE` varchar(10) NOT NULL,
  `TTIME` varchar(6) NOT NULL,
  `LASTCLOSE` decimal(19,3) DEFAULT NULL,
  `OP` decimal(19,3) DEFAULT NULL,
  `CP` decimal(19,3) DEFAULT NULL,
  `TQ` decimal(19,3) DEFAULT NULL,
  `TM` decimal(19,3) DEFAULT NULL,
  `TT` decimal(18,0) DEFAULT NULL,
  `CQ` decimal(18,0) DEFAULT NULL,
  `CM` decimal(19,3) DEFAULT NULL,
  `CT` decimal(19,3) DEFAULT NULL,
  `HIP` decimal(19,3) DEFAULT NULL,
  `LOP` decimal(19,3) DEFAULT NULL,
  `SYL1` decimal(19,3) DEFAULT NULL,
  `SYL2` decimal(19,3) DEFAULT NULL,
  `RF1` decimal(19,3) DEFAULT NULL,
  `RF2` decimal(19,3) DEFAULT NULL,
  `BS` varchar(18) DEFAULT NULL,
  `S5` decimal(19,3) DEFAULT NULL,
  `S4` decimal(19,3) DEFAULT NULL,
  `S3` decimal(19,3) DEFAULT NULL,
  `S2` decimal(19,3) DEFAULT NULL,
  `S1` decimal(19,3) DEFAULT NULL,
  `B1` decimal(19,3) DEFAULT NULL,
  `B2` decimal(19,3) DEFAULT NULL,
  `B3` decimal(19,3) DEFAULT NULL,
  `B4` decimal(19,3) DEFAULT NULL,
  `B5` decimal(19,3) DEFAULT NULL,
  `SV5` decimal(20,0) DEFAULT NULL,
  `SV4` decimal(20,0) DEFAULT NULL,
  `SV3` decimal(15,0) DEFAULT NULL,
  `SV2` decimal(15,0) DEFAULT NULL,
  `SV1` decimal(15,0) DEFAULT NULL,
  `BV1` decimal(15,0) DEFAULT NULL,
  `BV2` decimal(15,0) DEFAULT NULL,
  `BV3` decimal(15,0) DEFAULT NULL,
  `BV4` decimal(15,0) DEFAULT NULL,
  `BV5` decimal(15,0) DEFAULT NULL,
  `BSRATIO` decimal(19,3) DEFAULT NULL,
  `SPD` decimal(19,3) DEFAULT NULL,
  `RPD` decimal(19,3) DEFAULT NULL,
  `DEPTH1` decimal(20,3) DEFAULT NULL,
  `DEPTH2` decimal(20,3) DEFAULT NULL,
  `UNIX` bigint(20) DEFAULT NULL,
  `MARKET` varchar(4) DEFAULT NULL,
  KEY `SECCODE` (`SECCODE`,`TDATE`,`TTIME`)
) /*!50100 TABLESPACE ts_cloudstore STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=utf8;

Table TAQ_201504

 

备注：`SECCODE`,`TDATE`,`TTIME`为组合索引，存于内存中。

 

性能测试

 

本文针对4中应用场景展开测试，分别从10、20、50、100个线程对MySQL展开测试。

 

1) 场景1

对某天的业务进行访问查询，即多个线程交互访问如下示例：

select CP from TAQ_201504 where SECCODE='000001' AND TDATE = '20150401';

select CP from TAQ_201504 where SECCODE='000002' AND TDATE = '20150401';

select CP from TAQ_201504 where SECCODE='000003' AND TDATE = '20150401';

select CP from TAQ_201504 where SECCODE='000004' AND TDATE = '20150401';

select CP from TAQ_201504 where SECCODE='000005' AND TDATE = '20150401';

即每5个线程各自执行其中一条查询，以10个线程举例，则各自有2个线程会执行其中1条语句，其它线程与之类同，不再赘述。

表-1结果表明：对于20-50个线程并发的场景下，按天查询1-3个字段，数据响应时间大概在3s 以内。然而，在大量并发(100个线程)的场景下，数据显示所需时间明显增大。需要指出，虽然该测试能够反映一些问题，但是增大多线程间切换所需的时间也是造成该时延增大的原因。

 

2) 场景2

对某个字段所处范围，批量返回查询结果，即多个线程并发访问如下示例：

select CP from TAQ_201504 where SECCODE in ('000005','600010','000001','600100','600180','000002','000007','000008')

表-2结果表明：测试所需时间都已达到分钟级。此外，对于表中异常情形，其症结在于，在单台机器上采用多线程测试，因此受限于本文测试的机器的存储空间。本文作者认为，并非已达到MySQL数据库的极限。

 

3)场景3

指定具体某一个字段，对全表进行查询，即多线程并发访问如下示例：

select cp from TAQ_201504 where ttime='145910'

需要指出，本文未对50、100个线程展开测试，只是因为其耗时过长，故此，并未展开测试。

结果表明：随着字段个数增加，其处理耗时也逐渐增加，而且已达到分钟级，而且基本达到10分钟以上。

 

4)场景4

指定具体某些字段，对全表进行查询，即多线程并发访问如下示例：

select cp from TAQ_201504 where tdate='20150409' and ttime='145910'

 

在查询中指定多个字段会增加查询所需的时间。需要指出，由于上述SQL语句在查询时，扫描数据库花费的时间较多，导致Got error 4008 'Receive from NDB failed' from NDBCLUSTER，因此，表-4红色部分，由于异常过早抛出，因此，在统计时间时存在偏差。本文作者认为，由于每次查询差不多花费半个小时，造成数据访问超时，很大程度上造成上述异常，此外，在单台机器上并发访问该数据库，线程间切换的时间也会对其造成一定的影响。

 

总结

从上述4中场景测试结果来看，对于查询返回数据量相对较少时，多线程访问MySQL是能够满足用户需求的;当访问数据量较大时，多线程访问时能够满足连接需求的，但是具体向用户进行展示时，其处理时间多在分钟级，返回的字段、数据量越多，所耗的时间也逐渐增多。

 

亿级数据的高并发通用搜索引擎架构设计

最近，我设计出了下列这套最新的搜索引擎架构，目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试，在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机，7000万条索引记录的条件下，“搜索查询接口”平均查询速度为0.0XX秒(查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平，详见文章末尾的“附2”)，并且能够支撑高达5000的并发连接;而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程，高达1500 Requests/Sec。

“队列控制器”这一部分是核心，它要控制队列读取，更新MySQL主表与增量表，更新搜索引擎数据存储层Tokyo Tyrant，准实时(1分钟内)完成更新Sphinx增量索引，定期合并Sphinx索引。我预计在这周写出beta版。

图示说明：

1、搜索查询接口：

①、Web应用服务器通过HTTP POST/GET方式，将搜索关键字等条件，传递给搜索引擎服务器的search.php接口;

②③、search.php通过Sphinx的API(我根据最新的Sphinx 0.9.9-rc1 API，改写了一个C语言的PHP扩展sphinx.so)，查询Sphinx索引服务，取得满足查询条件的搜索引擎唯一ID(15位搜索唯一ID：前5 位类别ID 后10位原数据表主键ID)列表;

④⑤、search.php将这些ID号作为key，通过Memcache协议一次性从Tokyo Tyrant中mget取回ID号对应的文本数据。

⑥⑦、search.php将搜索结果集，按查询条件，进行摘要和关键字高亮显示处理，以JSON格式或XML格式返回给Web应用服务器。

2、索引更新接口：

⑴、Web应用服务器通过HTTP POST/GET方式，将要增加、删除、更新的内容告知搜索服务器的update.php接口;

⑵、update.php将接收到的信息处理后，写入TT高速队列(我基于Tokyo Tyrant做的一个队列系统);

注：这两步的速度可达到1500次请求/秒以上，可应对6000万PV的搜索索引更新调用。

3、搜索索引与数据存储控制：

㈠、“队列控制器”守护进程从TT高速队列中循环读取信息(每次50条，直到末尾);

㈡、“队列控制器”将读取出的信息写入搜索引擎数据存储层Tokyo Tyrant;

㈢、“队列控制器”将读取出的信息异步写入MySQL主表(这张主表按500万条记录进行分区，仅作为数据永久性备份用);

㈣、“队列控制器”将读取出的信息写入MySQL增量表;

㈤、“队列控制器”在1分钟内，触发Sphinx更新增量索引，Sphinx的indexer会将MySQL增量表作为数据源，建立增量索引。Sphinx的增量索引和作为数据源的MySQL增量表成对应关系;

㈥、 “队列控制器”每间隔3小时，短暂停止从TT高速队列中读取信息，并触发Sphinx将增量索引合并入主索引(这个过程非常快)，同时清空MySQL增量表(保证了MySQL增量表的记录数始终只有几千条至几十万条，大大加快Sphinx增量索引更新速度)，然后恢复从TT高速队列中取出数据，写入 MySQL增量表。

本架构使用的开源软件：

1、Sphinx 0.9.9-rc1

2、Tokyo Tyrant 1.1.9

3、MySQL 5.1.30

4、Nginx 0.7.22

5、PHP 5.2.6

本架构自主研发的程序：

1、搜索查询接口(search.php)

2、索引更新接口(update.php)

3、队列控制器

4、Sphinx 0.9.9-rc1 API的PHP扩展(sphinx.so)

5、基于Tokyo Tyrant的高速队列系统

附1：MySQL FullText、Lucene搜索、Sphinx搜索的第三方对比结果：

1、查询速度：

MySQL FullText最慢，Lucene、Sphinx查询速度不相上下，Sphinx稍占优势。

2、建索引速度：

Sphinx建索引速度是最快的，比Lucene快9倍以上。因此，Sphinx非常适合做准实时搜索引擎。