Percona server与腾讯云cdb热点更新性能压测

特别声明

本文针对腾讯云数据库cdb做热点单行更新性能压测，不涉及其他可用性，功能性介绍。本文的压测结果也不作为任何潜在云客户的购买建议(我可木有收广告费)。

本文仅代表个人压测结果，感兴趣的朋友可以自行压测。

一 压测目的

鉴于有赞业务迅速发展，对于秒杀场景有比较强烈的需求,当前我们的自建数据库使用Percona Server 5.7.22 版本，在应对快手直播以及秒杀场景下，单行更新性能有点吃紧。因此我对比有赞自建数据库和腾讯 cdb在热点秒杀单行更新场景下的性能差异。

二 压测实例配置

2.1 cdb的配置

OS CPU 56core 2.50GHz

文件系统 data1 ext4 noatime,acl,user_xattr 1 2

MySQL版本 5.7.18-txsql-log 20190203

参数

binlog_format[ROW] max_binlog_cache_size[17179869184G] max_binlog_size[256M]

open_files_limit[102400] sync_binlog[0] table_definition_cache[768]

table_open_cache[512] thread_cache_size[512] innodb_adaptive_flushing[ON] 

innodb_adaptive_hash_index[ON] innodb_buffer_pool_instances[8]

innodb_buffer_pool_size[22G] innodb_file_per_table[ON] innodb_flush_log_at_trx_commit[2]

innodb_flush_method[O_DIRECT] innodb_io_capacity[20000] innodb_lock_wait_timeout[7200]

innodb_log_buffer_size[64M] innodb_log_file_size[1G] innodb_log_files_in_group[2]

innodb_max_dirty_pages_pct[75.000000] innodb_open_files[1024] innodb_read_io_threads[12]

innodb_stats_on_metadata[OFF] innodb_thread_concurrency[0] innodb_write_io_threads[12]

2.2 youzan 自建数据库

OS CPU 56core 2.40GHz

文件系统 dev/sdb1 srv ext4 defaults,noatime 1 2

MySQL版本 5.7.22

binlog_format[ROW] max_binlog_cache_size[4G] max_binlog_size[1G]

open_files_limit[65535] sync_binlog[0] table_definition_cache[2000]

table_open_cache[4096] thread_cache_size[1024]

innodb_adaptive_flushing[ON] innodb_adaptive_hash_index[ON] innodb_buffer_pool_instances[8]

innodb_buffer_pool_size[10G] innodb_file_per_table[ON] innodb_flush_log_at_trx_commit[2]

innodb_flush_method[O_DIRECT] innodb_io_capacity[20000] innodb_lock_wait_timeout[50]

innodb_log_buffer_size[16M] innodb_log_file_size[2G] innodb_log_files_in_group[2]

innodb_max_dirty_pages_pct[75.000000] innodb_open_files[4096] innodb_read_io_threads[24]

innodb_stats_on_metadata[OFF] innodb_thread_concurrency[0] innodb_write_io_threads[24]

注意

cdb的数据库 table_open_cache
table_definition_cache
给的比较小,如果是真正的业务使用上千个表的话，性能会有损耗。

关于 bps 因为是单行测试，没有和内存大小没有太大关系，而且10g已经足够大。该差异可以忽略。

三 压测案例

热点更新 ,使用 mysqlslap 多并发更新同一行。

CREATE TABLE `seckill` (
  `id` int(11) DEFAULT NULL,
  `num` bigint(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

insert into seckill(id,num) values(1,200000000000000);

mysqlslap  -uroot -hxxxxx -P 3306 --create-schema='test' --query='begin;update seckill set num=num-1 where id =1 and num>1;commit;' --number-of-queries=1000000  --concurrency=xx

主要模拟数据库在并发数分别设置为:36,48,56,64,72,96,144,192,256个活跃会话下的性能表现，总共压测两组，普通模式和优化模式。其中

普通模式 核心参数

innodb_flush_log_at_trx_commit=1
sync_binlog=1
innodb_deadlock_detect=on

优化模式 核心参数

innodb_flush_log_at_trx_commit=2
sync_binlog=0
innodb_deadlock_detect=off

四 压测结果

普通模式 

普通模式下 设置"双1" ，死锁检测开启，cdb性能表现比percona server 高约15%-50%。随着并发数增加，两者差距减少。

优化模式

优化模式下 设置非"双1"，死锁检测关闭，cdb在并发数小于70的时候性能表现比percona server 高约8%。并发数大于70总有，percona server性能比 cdb 高约10%。

和相关人员沟通了解到他们做如下代码级别的性能优化:

并行写 redo , mtr_commit
提交的时候，先计算其所占 log_sys->buf
所在位置，释放 log_sys->mutex
，然后再将内容 Copy 到缓冲区，提升并发量；

异步刷 redo，即用户线程不需要同步等待 redo log 落盘，而是通过系统线程统一刷 redo ，将同步 IO 等待操作转化为异步操作；

Innodb 线程调度优化，实现了基于资源的锁调度系统，而不是传统的 FIFO 锁调度；

五 小结

总体而言 cdb 热点更新的性能表现上还是很有竞争力的。限于时间和精(jin)力(qian)(主要是该实例比较贵 151RMB/每小时) 我没有做sysbench的通用压测。有兴趣的朋友可以自己压测对比一下看看 。

云的数据库有很多优势，备份，ha，监控，升级降级等各种常规运维都自动化，简化DBA很多事情。劣势是习惯自建运维的人而言云数据库也有很多限制比如宿主机黑盒，底层cpu 个数，iops，各种安全规则等等。给实际操作带来很多不便利比如遇到非业务导致的性能问题，大概率只能联系云dba支持排查了，而且他们的响应时间也是个问题。

后续写写 如果从自建数据库迁移到云数据库要做哪些事情。大家也可以聊聊上云之后，作为DBA 你感觉到有什么改变？