DTCC2017〡腾讯云CDB的核弹头：TXSQL的研发、实践和未来(2)

　　MySQL redo log是一个顺序写的单缓冲区，log_sys->mutex锁资源竟争激烈，在事务落盘的过程中对LSN相关的读、写都被阻塞，为了解决 log_sys->mutex的锁竟争问题，引入双缓冲区机制&w_mutex锁，在flush redo log 的过程中释放log_sys->mutex，继续持有log_sys->w_mutex，从而阻塞写，不阻塞LSN相关的读操作，flush完成后释放w_mutex;从而提升并发性，提升性能。

　　TXSQL性能数据对比

　　TXSQL功能开发

　　在TXSQL并行复制方面，MySQL并行复制存在的问题：在实际的应用环境中，实例中往往只有一个 Database，导致 relay log 中的事务大部分会分到同一个 worker 线程中，造成备库的性能低下，当主库的性能超过备库的单线程执行的性能时，就会出现延迟，对只读实例产生影响。

　　TXSQL并行复制存在的优化

　　为了解决上述问题，TXSQL 添加了另外一种分发方式，即基于表粒度的分发，为了实现基于表粒度的分发，TXSQL 对于不同的实现，进行了不同的处理:

　　当binlog_row_format= ROW 时, 调用 get_slave_worker 直接进行分发;

　　当 binlog_row_format= statement 时，则需要对语句先进行调用 mysql_parse 对语句进行解析，然后再做分发。

　　TXSQL强同步支持

　　原生 semi-sync 存在着以下问题：

　　semi-sync 在时间超过 rpl_semi_sync_master_timeout 会退化为异步;

　　采用 select 进行监听，当句柄值大于 1024 时则会出现异常，详情可参考 bug#79865;

　　在 after commit 后等待 ACK 容易出现幻读的问题;

　　TXSQL 强同步支持：

　　优化半同步，增加ack线程，收发并行化;

　　修正select时fd超过1024导致异常的bug，改为poll;

　　在半同步基础上实现强同步，一直hold住直到收到ack;

　　修改同步方式时，唤醒正在等待的用户线程，继续等待或者退出;

　　增加一些状态，用于展示当前等待的情况(正在等待的binlog位点，已等待时间);

　　对于主多 binlog 备少 binlog 的情况进行特殊的处理，以保证双写的情况不会发生;

　　TXSQL云上实践

　　XX游戏数据库优化案例

　　问题现象：性能不能满足业务要求，游戏业务逻辑 TPS 不达标;在压力达到一定程度时，CPU 不能充分利用，idle 较高;性能抖动较为明显; thread running 过高，系统负载较高;系统 IO 压力较小，IO 没有问题;

　　问题排查：

　　pt-pmp & pstack & mysql 命令进行问题排查，发现以下问题：