mysql并发写入性能分析

目前，在很多OLTP场景中，MySQL数据库都有着广泛的应用，也有很多不同的使用方式。从数据库的业务需求、架构设计、运营维护、再到扩容迁移，不同的MySQL架构有不同的特点，适应一定的业务场景，或者解决一定的业务问题。

本文从MySQL常见架构、业务环境分类、业务与架构结合使用原则三个方面对MySQL数据库和业务场景进行探讨和说明，让大家先分别对MySQL的架构和业务分类有所了解，然后再将两者贯通起来，使得能够在进行业务与MySQL架构设计时纲举目张，让用户可以用合适的技术解决支撑业务需求。

一、MySQL数据库常见架构

为了对MySQL数据库常见架构，能够有进行比较清晰的认识，下面先从MySQL三种通用基础架构、五种特殊需求架构、架构组合与综合使用三个方面进行说明。

1、MySQL三种常见基础架构
（1）MySQL单实例架构

MySQL单实例，就是在服务器上部署一个MySQL实例来对外提供服务，这是最开始接触MySQL数据库会使用的方式，也是常见学习、研究MySQL数据库的使用方式。

MySQL单实例的使用方式，是MySQL数据库使用的第一阶段，通常这种情况下，MySQL数据库与应用程序会在同一个服务器上。

这种方式主要好处就是部署和使用简单，直接通过编译安装，或者二进制包解压安装，很快就可以有一个可以使用的MySQL数据库环境。同时，这种方式，依赖性少，不需要依赖其他第三方工具或者软件，维护和故障定位也比较容易。

熟悉和掌握好MySQL单实例环境的技能，也是维护其它MySQL架构的基础。

需要注意的是，MySQL单实例在学习和开发环境可以使用一下，但这种方式的可用性和灾备性较弱，如果作为业务系统使用的数据库，尽量不要用这种方式。

（2）MySQL master-slave主从架构
MySQL master-slave主从环境，是在MySQL单实例环境的基础上，将MySQL进行全库备份，再恢复出一个或多个MySQL实例，通过change master命令，指定新恢复出的MySQL实例，从那个MySQL节点上读取变化日志，并在本地应用，使新恢复的实例与原来的MySQL实例数据一致保持一致。

所以，原来的数据一致变化的实例，叫master主节点；从master节点获取日志，并在本地应用，使数据与master阶段保持一致的节点，叫slave从节点；这样的架构环境，就叫 master-slave主从环境。

Master-slave主从环境，是MySQL数据库非常具有特色的功能，也是MySQL数据库应用在生产环境的常见架构。

通过master-slave架构，就可以使线上数据库的数据有了多份，起到了一定的数据备份功能。Slave从库数据变化只通过应用日志实现，一般不会主动产生写数据的情况，但可以提供对外数据读服务，这样通过增加几个slave从库，让只进行数据读取的业务到slave从库上查询，就都可以大大提高业务的读性能和吞吐量。在互联网行业中，非常多的数据读操作远高于数据写操作的业务场景，通过在master主节点写数据，在slave节点上读数据，进行这种读写分离的架构，可以很好地满足业务需求。

当然，MySQL的master-slave主从架构，具体实现也可以非常灵活，1个master主节点，可以有1个或多个slave从节点；而一个slave节点，也可以当做其它节点的slave节点，如果一个slave节点后面再有其它节点当做这个节点的slave从节点，就叫做级联复制。

MySQL的master-save架构，在MySQL单实例架构的基础上，提高了MySQL数据库的性能、可用性和可扩展性，同时也为MySQL数据库追求更高的可用性，提供了基础保障。

（3MySQL MHA高可用架构
虽然MySQL数据库的master-salve主从架构，使数据库有了多份，但这些maste主节点和slave从节点之间，仍然是相对独立的，尤其是master主节点如果出现故障了，仍然是不能对外提供数据库服务的。为了应该各种故障和特殊情况，实现数据库更高的可用性，就需要在master-slave的基础上，通过其它组件来实现更高的可用性。MySQL高可用性的方案比较多，但目前比较主流、比较成熟的方案，还是MySQL + MHA高可用架构。

简单来说，为了实现更高的可用性，就要在master-slave主从环境的基础上，将业务连接master的IP，有master主机的实际IP，变成虚拟的VIP或者域名。应用程序通过VIP访问数据库，进行数据读写，在正常情况下，业务在master上进行读写；如果master节点出现故障，高可用组件会监测到这个故障，并将VIP切换到slave从库上，同时对于slave从库上进行日志的传输和应用，保证slave上的数据，与master节点故障前的数据尽量一致，这样切换后新的slave节点就仍然可以对外提供数据库服务。

当然，对于具体实现来说，在MySQL的master-slave主从结构外，VIP和数据库日志追平的方案也是有多种实现方式，也可进行各种深入定制，甚至一些公司不使用开源软件，直接自己开发来实现高可用组件的各个功能。

目前MySQL + MHA这种高可用实现方式，是比较主流和成熟的实现方式，后面也可能会有一些其它更加完善的高可用实现方式，但都可以归类到实现提高可用性这个范围。

以上内容希望帮助到大家，很多PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家 ，需要请戳这里链接
小结
这里就介绍完了MySQL单实例架构、MySQLmaster-slave主从架构、MySQL+MHA高可用架构，对于MySQL数据库的各种通用性需求，这三种基础架构都可以很好地满足，换句话说，这是MySQL数据库架构中必须要用到和掌握的三种基础架构。

2、五种特殊业务需求架构
通过MySQL中这三种常见基础架构，绝大多数MySQL数据库场景和问题，都可以很好得满足和解决。但一些特殊的场景，或一些特殊的问题，也可以使用除MySQL数据库以外的其它数据库、专门某一类或几类问题的解决方案。针对这些特殊的业务需求，接下来我会先从要解决的问题进行描述和说明，然后再提出对应的解决方案。

（1）MySQL + 分布式Proxy 水平扩展架构
问题：如果业务规模进一步扩大，读写量级尤其是写的量级达到非常大的地步，比如每秒数据写入几十万，甚至几百万，每天的数据量有几亿甚至几十亿的规模，这样的读写就远远不是一个master节点可以支撑的，这时就必须要进行扩展了。

一般来说，MySQL的扩展可分为：按照不同业务进行垂直拆分的垂直扩展，和通过一定的分库分表策略实现的库表水平扩展两种方式。这两种方式可以单独使用，也可以结合使用。但如果是解决大量数据和高并发读写，主要方式还是MySQL水平扩展。

MySQL水平扩展的思路
在一个服务器上的database库和table表，总会受到一台服务器的资源限制，即使服务器的硬件各方面都达到顶配，也还是会有瓶颈。对于业务访问来说，如果有一个Proxy代理层或者中间件层的一个database和一个table，通过代理层按照一定的规则映射和转换，转换成底层多台服务器上的多个database和多个table，这样就相当于多台服务器共同支撑一个业务，可支持的容量就与底层服务器的数量有关。在Proxy代理没有到瓶颈的情况下，底层服务器数量越多，整个水平扩展集群的性能和容量也会越多，几乎可以线性扩展。通过这样的思路，就可以解决大量数据存储和并发的问题。

具体实现来说，水平扩展集群除了MySQL数据库，需要一个分布式Proxy中间件，这种水平扩展中间件种类也比较多，MySQL官方和一些大的的公司都有开发。我们用的比较多的是MyCAT中间件。对于底层的分片，可以有几十个、几百个甚至几千个。

当然，水平扩展可以解决大数据量的问题，需要有分片策略，那相应地，也会有使用这种策略的限制，比如片键选择，跨节点访问，分布式事务等问题，需要与业务进行对应结合和考虑后，才可以很好地使用。

（2）TokuDB/MyRocks/InnoDB 高性能写入架构

问题：MySQL数据库水平拆分，可以对于大数据量的读写进行线性扩展，但相应地底层服务器数量也需要比较多；但对于数据写入量非常大，数据读很少，数据总量大的情况，使用高性能写入架构，会更合适一些。

业务数据写入量非常大，读取量非常高的情况，一般主要对数据insert写入性能，同时对数据压缩效率有特别高的要求。这种特殊的写入要求，需要对数据写入有特殊的优化和设计，并且有比较好的压缩效率和算法，能够将写入的大量数据进行压缩，节省空间。这种写入架构， 通常可以看做是MySQL数据库的一种特殊的存储引擎。

具体到实现而言，MySQL的高性能写入集群，可以使用TokuDB存储引擎。近几年Facebook也开源了其内部实现的MyRocks，可以作为高性能写入的存储引擎。MySQL默认的InnoDB存储引擎，在新的5.7及以后版本优化后，写入性能和压缩性能也有了更高的性能，也可以作为数据写入的一种选择。

（3）MySQL + 缓存（Memcached、Redis等） 高并发读架构

问题：如果业务访问MySQL中的某一些少量热数据，访问的并发量非常高，访问的时效性，数据的一致性要求都非常高，这时候使用MySQL数据库本身支持这些数据读取，可能会在并发性、时效性上出现瓶颈。这时，就可以使用缓存系统结合MySQL来使用。

缓存系统是将MySQL数据库中的少量热数据存放到内存当中，由于内存的IO效率远高于硬盘的IO，相应的CPU消耗也会少很多，这样缓存系统中响应一次业务请求的时间，会远少于直接从MySQL数据库访问需要的时间。于是缓存系统就可以支撑热数据的高并发访问，数据写还是写入MySQL数据库中，数据读操作，优先读取缓存；如果缓存中有，则直接从缓存中返回结果；如果缓存中没有，则从MySQL数据库中读取数据返回应用，并把数据结果再放到缓存的内容中。

具体实现来说，缓存系统常用的技术架构有Memcached 和Redis。Memcached是比较经典的缓存系统，在之前常与LAMP、LNMP流行架构结合使用。Redis是几年新兴的Key-Value键值型NoSQL数据库，除了作为缓存，还可以持久化作为Key-Value数据库使用。

（4）MySQL + 小文件系统（MongoDB、Ceph等） 大字段存取架构

问题：在MySQL数据库中，通常是存储符合关系型数据库原理的小字段，比如数值型、字符型数据；但在实际环境中，除了这些常用字段，还会有一些大字段，比如用户头像这种图片文件、上传的音频、视频文件、帖子内容等大text字段，另外还有一些JSON文件、XML文件等，这些可以以二进制形式存储在MySQL数据库中，但读取和管理都会比较麻烦。这时，就可以使用小文件系统来结合MySQL来使用。

小文件系统，是可以存储并快速访问结构化数据的系统。对于图片、音频、视频、TXT文件、JSON文件、XML文件等大字段，一般就只有简单的读写操作，将这些字段存入到小文件系统中，并将对应的访问链接存入到MySQL数据库的表中。这样通过数据库表，可以快速读写文件位置信息，在小文件系统中，通过文件位置信息，可以实现对大字段的快速读写访问。

具体实现而言，小文件系统也有很多技术软件，比较常见的有MongoDB文档型NoSQL数据库、Ceph分布式小文件系统等。

（5）MySQL + Inforbright/Greenplum 统计分析架构

问题：在MySQL数据库上实时响应业务需要的查询，通常是指OLTP业务，但对于已经产生的数据，通常会在第二天之后，有结果汇总和统计分析需求。这类OLAP需求通常执行频率较低，但每次执行消耗的资源很大，如果与OLTP一样在一个系统上运行，就会造成这两大类业务的相互影响。这时就可以使用MySQL数据库与OLAP统计业务分类结合的架构。

MySQL产生了业务数据后，通常需要在第二天，要对前一天的数据进行各个角度、各个维度的统计、聚合、分析，以体现和反映业务的运营情况。这是让MySQL支持线上OLTP业务，通过数据流转程序，将每天产生的数据流转到离线的数据仓库系统中，在数据仓库系统中，进行各种数据统计分析、结果汇总，并将数据统计结果再流转到结果展示库中。这样就可以很好地实现线上OLTP和线下OLAP的结合使用和执行。

具体实现而言，对于MySQL数据库可以结合的OLAP数据仓库架构，可以选用Inforbright数据仓库，也可以选用 Greenplum分布式MPP数据库仓库。相对而言，Inforbright数据仓库比较轻量级，与MySQL使用类似；Greenplum分布式MPP数据仓库可以支撑海量数据的统计分析，功能、性能、容量等也比Inforbright要更强一下，成本也更大一些。

小结

MySQL五种特殊业务架构，可以说是在MySQL三种常见的、通用的架构基础上，面对特殊的业务场景，遇到特殊的问题，进行针对性解决。

对于大量数据读写，可以采用水平扩展架构；对于有大量数据写入需求，可以采用MySQL高性能写入架构；对于热数据的高并发、快速响应的需求，可以采用MySQL+缓存架构；对于特殊的大字段存取需求，可以采用MySQL+小文件系统架构；对于离线统计分析需求，可以采用MySQL+统计分析架构。

3、架构组合与综合
MySQL三种比较通用的基础架构和五种特殊需求架构，都可以根据场景单独使用，也可以根据特定的场景进行组合几种架构使用，或者综合起来一起使用。

（1）架构组合

对于只有一两种特殊情况的架构，选择基础架构和特殊架构的简单组合就可以了，生产环境中可用到的架构组合类型有：

MySQL+MHA高可用架构 与 MySQL分布式Proxy水平扩展架构 组合
MySQL+MHA高可用架构 与 MySQL小文件系统大字段存取架构 组合
MySQL+MHA高可用架构 与 MySQL缓存高并发读架构 组合
MySQL分布式Proxy水平扩展架构 与 MySQL小文件系统大字段存取架构 组合
MySQL分布式Proxy水平扩展架构 与 MySQL缓存高并发读架构 组合
MySQL高性能写入架构 与 MySQL Inforbright/Greenplum统计分析架构 组合
（2）架构综合

如果是比较复杂的业务场景，几种特殊的数据库架构可以综合起来使用：

MySQL+MHA高可用架构 、MySQL分布式Proxy水平扩展架构、 MySQL缓存高并发读架构、 MySQL小文件系统大字段存取架构、MySQL Inforbright/Greenplum统计分析架构。

二、业务环境分类
第一部分对MySQL的架构进行了说明，这是对MySQL数据库本身的了解，算作“知己”。所有的数据库系统提供服务的对象都是业务系统，所以DBA要对业务系统进行了解，对业务的特点和适合的场景，做到心中有数，可以算作是“知彼”。做到知己知彼，就能更好地贯通两者了。

1、从数据库使用推导数据使用分类
从数据库操作角度看，业务系统对于数据库的操作，大的方面可以分为“读数据”和“写数据”两类。展开来说，写数据有可以具体分为insert插入数据、update修改数据、delete删除数据三种情况。所以，数据库的使用也可以细分为增insert、删delete、改update、查select四种情况。

依据业务系统对数据的操作分类，就可以对业务系统进行归类：

（1）只读业务系统

只读是指只有查询select，没有数据修改的情况。这种情况，是数据库中已经存在一些数据，并且这些数据只作查询或展示用，不会有任何数据变化，比如缓存中的数据、归档后的数据、历史结果数据、统计结果数据等，都是只能进行查询和展示，不会再发生数据变化的。

（2）可读写业务系统

按照写操作的具体情况，可以对可读写业务系统分成三类：

只有插入Insert，没有Update和Delete的可读写业务系统
这种情况是指数据表的数据只会增加，且表中的数据不能再变化，不会再有修改或者删除操作；比如操作记录表、状态变化记录表、留言记录表等。

有Insert和Update，没有Delete的可以读写业务系统
这种情况是指数据表中的数据，可以进行增加和修改，但数据一旦产生，可以变化，但不能修改。这也是一种常见的数据库设计思路，即数据表可以有失效，但生效删除，并不是真正从数据表中删除，而是修改了表中表示状态位的列值，这样就可以保证数据一直具有可回溯性。

Insert、Update、Delete都有的可读写业务系统
这种情况是指数据表中的数据可进行各种操作，可以查询，也可以进行各种变化，添删改除各种操作也都可以进行。

2、常见业务表分类

从业务角度对表进行分类，虽然不同的应用程序对表的使用不同，但还是能够抽象成为几大类表。

（1）配置表

这种表通常存放业务一些基础的配置信息或者字典信息。表的数据量一般都比较小，修改变化的操作不太频繁，通常都是Select查询操作。

（2）状态表

这种表通常存放在业务系统中实体读象的状态信息，常见的有用户信息表，订单信息表等。这种表的数据量与实体读象的规模有直接关系，比如一个APP有多少注册用户，通常这个APP的用户表都会有多少条记录。状态表的变化通常比较频繁，而且Insert、Update、Select操作都会有，Delete操作是否有，通常会根据业务情况的规定决定。

（3）日志表

这种表通常用来记录业务系统中某种实体的状态信息，常见的有用户登录表、充值信息记录表等。这种表的数据规模通常比较大，而且如果业务状态变化频繁，记录的变化信息比较多，这种表的数据量和插入性能都要求比较高。日志表的操作，通常会以Insert操作为主，个别业务会对日志表进行查询。MySQL五种特殊需求架构中的高性能写入架构，主要就是应用这种表的需求。

（4）归档表

这种表，是将上面三种OLTP业务表的数据进行归档或者冷热分离的表。对线上业务三类表进行数据归档、冷热分离，一方面可以控制线上业务表的数据规模，保证业务表性能；另一方面进行归档后，可用于对归档历史数据进行更好的查询反映和支持。归档表的数据量大小与对应的线上表大小、归档周期有关。归档表的操作，除了归档过程的数据加载外，主要就是Select查询操作了，归档后就算是只读表。

（5）统计数据表

统计数据表，是指业务有离线统计分析需求时，需要将各种线上表和归档表的数据，通过ETL过程流转到线上OLAP统计分析系统中的原始数据表。这类表通常数据量会非常大，一个OLAP统计分析平台会汇总多个线上业务系统的数据进行统计分析。统计数据表的操作，除了数据流转动作外，主要就是各种统计分析程序的访问计算。

（6）统计结果表

统计结果表是在业务有离线统计分析需求时，各种统计分析过程访问统计数据表中的数据，按照一定的逻辑进行统计分析后的结果数据。这种统计结果数据，通常数据量会比较小。统计结果表的操作，处理结果流转动作外，主要就是供访问接口进行Select查询。

通过对业务表类型的梳理，可以对所有的业务系统进行一个大体的划分，做到心中有数。

3、DBA对业务的把握
通过数据使用方式对业务系统划分为四类，再通过业务常见表类型划分，就可以对通用的业务使用数据库有一个整体的了解。但对于具体的业务场景，还需要根据每个公司具体的实际情况进行具体确认和考虑。

大多数情况下，某一种具体的业务都可以根据情况归入某一种业务类型中，只是每个业务具体的量级会有不同，大家需要先了解具体业务环境中的量级，再根据业务类型与MySQL架构的使用情况，进行对应就可以了。

如果实际环境中确认有不在现有分类中的情况，则可以通过现有的思路，进行新的类型划分和架构对应。

三、MySQL业务与架构结合使用原则
上面两部分通过对MySQL各种架构进行说明，并通过对业务环境的分类，可以让大家对MySQL架构和业务环境本身有一定的了解。下面我将就我在架构设计和运维当中两者结合的使用原则，对MySQL业务和架构的结合使用进行说明。

1、适用性原则
适用性原则就是在考虑某一个具体业务场景具体使用哪一种或者几种业务场景时，我们要尽量使用合适的技术架构解决合适的问题。

（1）需求与场景

MySQL的三种通用基础架构，适用的场景多一些。但通用业务场景在数据量级、访问规模、读写方式等发生比较大的变化时，就变成了有特殊需求的场景，可以考虑使用某种特定场景对应的MySQL架构技术，尽量保证适用性。

反之，如果实际业务在量级、规模、读写方式还没有达到非常特殊的场景时，尽量使用通用的基础架构就可以满足业务需求，也可以降低系统复杂度和隐患。

（2）整体与部分

不论对于一个业务系统，还是MySQL数据库架构而言，都要从整体和部分两个角度进行看待和考虑。

一个业务系统，首先是一个整体，从整体上看各种业务需求和使用方式，把握好整体，然后再考虑具体的需求；如果没有特殊的需求，则可以按照通用场景来设计和考虑；如果某一部分有特殊的需求，则可以把这部分内容单独划分出来，进行对应的架构设计。

多个通用和特殊的架构，相互组合，完成一个对业务系统支撑的架构总体。

（3）稳定与升级

一般情况下，业务系统都是先用通用架构进行数据支持，在通用架构适用时，业务系统也可以稳定运行。在业务系统不断运行过程中，有新业务场景需求产生时，要综合考虑保证现有业务稳定性、以及升级业务系统到新架构的步骤和阶段。

一般不要一下子全部升级，建议采用先测试、再上线、分批次逐步过渡和升级的方式。

2、阶段性原则
业务系统的发展是有阶段的，MySQL数据库架构的发展也是有阶段的。不同阶段关注的信息和主要处理思路都是不同的，从不同维度考虑阶段性也是使用架构和业务的重要原则。

（1）数量阶段

数量是一个比较明显的阶段判断指标。业务系统通常会有DAU、UV、PV等指标，来帮助判断业务系统的规模。数据库系统、QPS、TPS、一个表的数据量、一个库下的表数量、一个实例下的库数量、总的实例数量、服务器数量，都是与架构结合比较紧密的指标。

以表数据量举例：如果一个表运行一年，数量在10万以下，就可以认为是小表了数据量在10万-1000万以上的，可以认为是中表；数据量在1000万以上，就可以认为是大表，这时就需要考虑归档或水平拆分了；如果数据量在1亿以上，就必须要用特殊架构进行单独处理了。

（2）统一组织

在业务规模和数据规模都比较小的时候，若存在多种不同的架构，还是可以维护的。但如果数据库实例数量和业务模块都大起来之后，统一一种或少数几种数据架构就非常重要了。统一架构组织，可以让业务系统和架构，更加容易控制和维护。

（3）规模控制

业务发展到一定规模，底层架构中的数据库都必须要控制规模，一个实例不能太大，一个表也不能太大，如果超过了约定好的规模，需要进行实力拆分，或者表拆分，以使实例和库表都保持在统一设定的规模当中。

3、扩展性原则
应用业务随着时间会不断变化，底层的MySQL架构也需要随着业务的变化能够具有一定的扩展性，保持变化和扩展的空间，以不断支持业务的发展。

（1）架构之间的打通

从MySQL的三种基础架构就可以看出来，MySQL单实例架构→MySQL master-slave主从架构→MySQL MHA高可用架构，这中间是逐步演进的，有直接的依赖关系。后续Oracle推出的InnoDB Cluster架构，也与这些基础架构有直接演进关系。

其它五种特殊需求的架构，随着业务分类的变化，特殊情况也可能发生变化，可根据这些变化从一种特殊架构调整成为另一种特殊的架构。

（2）OLTP与OLAP

数据库系统一般分为OLTP和OLAP两大类，但实际在目前的业务系统和架构设计中，这两种需求都是需要支持的。只要建立好一个比较稳定、可靠的数据流转体系，将这两者打通，就可以很容易地实现OLTP和OLAP的互通，OLTP的业务数据传送到OLAP中进行统计，OLAP的统计结果，再返回到OLTP中进行展示。

（3）新架构的使用

MySQL架构中除了常见的三种基础架构和五种特殊架构，还有一些新的技术和趋势来尝试完善和解决现有架构的一些问题，比如InnoDB Cluster等技术，对MySQL的扩展和高可用会有更好的解决方式。

虽然目前这些新技术还没有完全稳定和成熟，但在后续新技术架构稳定成熟后，可以很容易地将现有架构扩展成新的技术架构，这样就可以更好地解决业务问题了。
//*****************

        鉴于高频中心库task部分占用机器较多，为节省成本，调研数据库或缓存。在数据库选型之MySQL（二）中，在固态硬盘本地访问MySQL可以满足其10000次/s操作的需求，由于实际环境中存在多个品种（多进程、多线程访问数据库）的业务需求，因此，本文采用多线程在固态硬盘本地访问MySQL展开测试，以期对高频中心库后期架构调整提供实践参考。需要指出，本文作者对该种节省成本的解决方案是不赞成的。

测试环境

        硬件环境

        10.1.120.34：Intel Core I5-4590, 主频：3.30G,  内存：16G， 有固态硬盘

        软件环境：

        10.1.120.34: Cent OS 6.5,  MySQL 5.6.26 (社区版)

性能测试

        针对高频生产的应用需求，本文构造高频中心库系统的数据结构，采用多线程模拟业务需求对本地节点MySQL进行写入操作，分别存储数据总量为60K、100K、600K条数据，对其速率进行测试。需要指出，由于常见I/O访问的瓶颈主要受限于写入测试，本文只针对写入操作进行测试，暂不考虑读取操作或者混合读写方式，若写入操作不满足要求，其它操作无需测试。

        因为10.1.120.34上采用固态硬盘作为存储介质，其安装有MySQL，根据应用场景，分别从10、20、30个线程并发访问MySQL 展开测试。

        测试整个结果见图-1:

图-1 完整测试结果

        10个线程

        从10个线程执行事务处理，需要指出，事务处理数据量固定为1000，以下多线程情况与之类同，不再赘述，10个线程的平均速率见表-1。

表-1  10个线程下每个线程平均访问MySQL测试结果

节点	数据库IP	数据量（K）	平均写入速率（条/s）
本地节点	10.1.120.34	60	4085
本地节点	10.1.120.34	100	4607
本地节点	10.1.120.34	600	3021

         20个线程

         从20个线程执行事务处理，20个线程的平均速率见表-2。

表-2  20个线程下每个线程平均访问MySQL测试结果

节点	数据库IP	数据量（K）	平均写入速率（条/s）
本地节点	10.1.120.34	60	1945
本地节点	10.1.120.34	100	2149
本地节点	10.1.120.34	600	1525

        30个线程

        从30个线程执行事务处理，30个线程的平均速率见表-3。

表-3  30个线程下每个线程平均访问MySQL测试结果

节点	数据库IP	数据量（K）	平均写入速率（条/s）
本地节点	10.1.120.34	60	1266
本地节点	10.1.120.34	100	1461
本地节点	10.1.120.34	600	879

小结

        从表1-3可知：1）随着线程数目增加，线程平均写入速率会减小，而且还很明显；2）随着访问的数据量的增加，以10万条至60万条为例，每个线程平均访问其速率下降也很明显。

        本文测试结果对高频中心库后续架构调整提供有一些实践参考，若以平均速率乘以线程个数来衡量，则该高频生产情形是满足需求的，但是若出现不平衡状况，则为节省成本采用将数据在固态硬盘本地入库落地来生产，然后辅以redis作为缓存来缓解访问系统访问压力的解决方案，本文作者是不赞成这种该方案的，希望对有类似业务需求的朋友有所帮助。