深入解析MySQL实战.pdf

MySQL电子书深入MySQL实战快速理解MySQL核心技术业内资深大咖联合出品，详细解读AliSQL在双11等高并发场景下的应用与实践1MySQL电子书3123049688291MySQL高可用MGR8.0 最佳实践MySQL高并发场景实战RDS MySQL Java 开发实战MySQL查询优化MySQL 开发规约实战RDS for MySQL 表和索引优化实战从研发角度深入了解RDS AliSQL内核2020新特性深入MySQL实战微信关注公众号：阿里云数据库第一时间，获取更多技术干货阿里云开发者“藏经阁”海量免费电子书下载34MySQL电子书MySQL高可用MGR8.0 最佳实践（一）MGR是什么（一）MGR插件组成（二）单主模式（二）示例1.MGR的定义MGR是具备强大的分布式协调能力，可用于创建弹性、高可用性、高容错的复制拓扑的一个MySQL插件。2.通讯协议基于Paxos算法的GCS原子广播协议，保证了一条事务在集群内要么在全部节点上提交，要么全部回滚。3.组成员资格MGR内部提供一个视图服务，集群节点之间相互交换各自的视图信息，从而且实现集群整体的稳态。4.数据一致性MGR内部实现了一套不同事务之间修改数据的冲突认证检测机制。在集群的所有节点当中进行一个冲突认证检测，反之，通过冲突认证检测的事务即可提交成功。当一个事务发起提交后，它会通过原子广播协议分发到集群其他Secondary节点。集群的Secondary节点通过冲突检测之后，事务提交成功。在大多数的Secondary节点提交成功之后，会在Primary节点进行提交。反之，如果在冲突认证检测失败，Secondary节点会丢弃这段事务对应的Binlog，Primary节点回滚该事务。上图是一个三节点的MGR实例集群，Member1代表Primary节点，Member2、Member3代表Secondary节点。如上图所示，MGR插件使用 MySQL Server 与 API 接口层以及若干组件，最后由GCS（Group Communication System）协议封装而成。MySQL Server调用MGR插件是基于MySQL现有的主从复制，利用Row格式的Binlog和Gtid等功能实现的集群架构。API接口层复制基于MySQL Server交互的接口集，在逻辑上将MySQL内核与MGR插件隔绝开来。其他组件例如Capture组件，它是负责事务状态在集群内提交或是回滚，以及通过Binlog event广播到其他节点上进行的冲突认证检测进行到哪个阶段。Apply组件代表MGR集群Secondary节点Binlog回放，Recovery组件代表进行崩溃恢复或集群扩容时增量数据的应用。ON表示单主模式，也是默认模式，OFF表示多主模式。如下图所示，在单主模式下（group_replication_single_primary_mode=ON）:1该变量在所有组成员中必须设置为相同的值，同一个组中，不能将成员部署在不同模式中。例如，一个成员配置为单主模式，另一个成员配置为多主模式。2该集群具有一个设置为读写模式的主节点，组中的所有其他成员都设置为只读模式（superread-only=ON）；MGR架构分为单主模式和多主模式。MGR特性集群架构作者：张彦东Member 1Member 2Member 3executecertifybinlogbinlogcommitcommitcertifyrelay logapplybinlogcommitcertifyrelay logapplyConsensusMySQL ServerAPIs：Capture/Apply/LifecycleApplierCaptureRecoveryReplication Protocol LogicsGroup Communication System APIMySQL Group Replication PluginGroupGroup Communication Engine(Paxos variant)34MySQL电子书MySQL高可用MGR8.0 最佳实践（一）MGR是什么（一）MGR插件组成（二）单主模式（二）示例1.MGR的定义MGR是具备强大的分布式协调能力，可用于创建弹性、高可用性、高容错的复制拓扑的一个MySQL插件。2.通讯协议基于Paxos算法的GCS原子广播协议，保证了一条事务在集群内要么在全部节点上提交，要么全部回滚。3.组成员资格MGR内部提供一个视图服务，集群节点之间相互交换各自的视图信息，从而且实现集群整体的稳态。4.数据一致性MGR内部实现了一套不同事务之间修改数据的冲突认证检测机制。在集群的所有节点当中进行一个冲突认证检测，反之，通过冲突认证检测的事务即可提交成功。当一个事务发起提交后，它会通过原子广播协议分发到集群其他Secondary节点。集群的Secondary节点通过冲突检测之后，事务提交成功。在大多数的Secondary节点提交成功之后，会在Primary节点进行提交。反之，如果在冲突认证检测失败，Secondary节点会丢弃这段事务对应的Binlog，Primary节点回滚该事务。上图是一个三节点的MGR实例集群，Member1代表Primary节点，Member2、Member3代表Secondary节点。如上图所示，MGR插件使用 MySQL Server 与 API 接口层以及若干组件，最后由GCS（Group Communication System）协议封装而成。MySQL Server调用MGR插件是基于MySQL现有的主从复制，利用Row格式的Binlog和Gtid等功能实现的集群架构。API接口层复制基于MySQL Server交互的接口集，在逻辑上将MySQL内核与MGR插件隔绝开来。其他组件例如Capture组件，它是负责事务状态在集群内提交或是回滚，以及通过Binlog event广播到其他节点上进行的冲突认证检测进行到哪个阶段。Apply组件代表MGR集群Secondary节点Binlog回放，Recovery组件代表进行崩溃恢复或集群扩容时增量数据的应用。ON表示单主模式，也是默认模式，OFF表示多主模式。如下图所示，在单主模式下（group_replication_single_primary_mode=ON）:1该变量在所有组成员中必须设置为相同的值，同一个组中，不能将成员部署在不同模式中。例如，一个成员配置为单主模式，另一个成员配置为多主模式。2该集群具有一个设置为读写模式的主节点，组中的所有其他成员都设置为只读模式（superread-only=ON）；MGR架构分为单主模式和多主模式。MGR特性集群架构作者：张彦东Member 1Member 2Member 3executecertifybinlogbinlogcommitcommitcertifyrelay logapplybinlogcommitcertifyrelay logapplyConsensusMySQL ServerAPIs：Capture/Apply/LifecycleApplierCaptureRecoveryReplication Protocol LogicsGroup Communication System APIMySQL Group Replication PluginGroupGroup Communication Engine(Paxos variant)56MySQL电子书3.读写节点通常是引导该组的第一个节点，加入该集群的所有其他只读节点均需要从读写节点同步数据，并自动设置为只读模式。单主模式集群原理流程图多主模式集群原理流程图同步原理示例冲突检测原理Write ClientsServer S1 is the primary.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsServer S2 is the new primary.Read ClientsS2S3S4S5（三）多主模式在多主模式下（group_replication_single_primary_mode=OFF）:1.所有节点不会区分Primary和Standby角色；2.加入该集群时，与其他组成员兼容的任何节点都被设置为读写模式，并且可以处理写请求，即使它们在集群内是并发执行的；3.如果组复制中的某个节点停止接受写事务，例如，在某个节点意外宕机的情况下，可以将与其连接的客户端重定向或故障转移到处于读写模式的任何其他健康的节点；4.组复制本身不处理客户端故障转移，因此需要使用中间件框架（例如MySQL Router 8.0代理，连接器或应用程序本身）来实现。如上图所示，以一个三节点的MGR集群为例。在单主模式下，当一个事务发起提交，它会通过原子广播协议将事务伴随着Binlog Event广播到其他Secondary节点上。在获得集群大多数节点同意之后，它会进行一个提交。如果通过冲突认证检测，那么该事务最终会在集群当中提交。如果在Secondary节点上面没有通过冲突认证检测，那么Secondary节点丢弃该事务对应的Binlog，Primary节点回滚该事务。如上图所示，在冲突检测时：1.每个事务的Gtid Set和对应的主键Hash值组成事务认证列表，在每个节点的内存当中都维护这样一个冲突检测库。2.Gtid set：标记数据库的快照版本，事务提交前从gtid_execute变量中获取该值；Write ClientsAll server are primaries.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsS1s client connects to S3.Read ClientsS2S3S4S5（一）同步原理示例（二）冲突检测原理数据同步原理PrepareBinlogCommitCOMMITDB1DB3TXTXSucceedsERROROKFallsCertifyRollbackPaxosDB2Relay logApplyTXSucceedsFallsCertifyDropPaxosDB2DB1DB3PK HASHdb1.tb1.pk=1db1.tb1.pk=2GTID SETgroup_name:1-10group_name:1-1556MySQL电子书3.读写节点通常是引导该组的第一个节点，加入该集群的所有其他只读节点均需要从读写节点同步数据，并自动设置为只读模式。单主模式集群原理流程图多主模式集群原理流程图同步原理示例冲突检测原理Write ClientsServer S1 is the primary.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsServer S2 is the new primary.Read ClientsS2S3S4S5（三）多主模式在多主模式下（group_replication_single_primary_mode=OFF）:1.所有节点不会区分Primary和Standby角色；2.加入该集群时，与其他组成员兼容的任何节点都被设置为读写模式，并且可以处理写请求，即使它们在集群内是并发执行的；3.如果组复制中的某个节点停止接受写事务，例如，在某个节点意外宕机的情况下，可以将与其连接的客户端重定向或故障转移到处于读写模式的任何其他健康的节点；4.组复制本身不处理客户端故障转移，因此需要使用中间件框架（例如MySQL Router 8.0代理，连接器或应用程序本身）来实现。如上图所示，以一个三节点的MGR集群为例。在单主模式下，当一个事务发起提交，它会通过原子广播协议将事务伴随着Binlog Event广播到其他Secondary节点上。在获得集群大多数节点同意之后，它会进行一个提交。如果通过冲突认证检测，那么该事务最终会在集群当中提交。如果在Secondary节点上面没有通过冲突认证检测，那么Secondary节点丢弃该事务对应的Binlog，Primary节点回滚该事务。如上图所示，在冲突检测时：1.每个事务的Gtid Set和对应的主键Hash值组成事务认证列表，在每个节点的内存当中都维护这样一个冲突检测库。2.Gtid set：标记数据库的快照版本，事务提交前从gtid_execute变量中获取该值；Write ClientsAll server are primaries.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsS1s client connects to S3.Read ClientsS2S3S4S5（一）同步原理示例（二）冲突检测原理数据同步原理PrepareBinlogCommitCOMMITDB1DB3TXTXSucceedsERROROKFallsCertifyRollbackPaxosDB2Relay logApplyTXSucceedsFallsCertifyDropPaxosDB2DB1DB3PK HASHdb1.tb1.pk=1db1.tb1.pk=2GTID SETgroup_name:1-10group_name:1-1578MySQL电子书3.事务提交前，数据库中执行了的Gtid集合，随着Binlog中的Event通过原子广播的方式分发到集群的所有节点上进行事务冲突检测。如上图所示，以T1与T2这两条Update语句为例。若T2修改的数据在冲突检测数据库中无匹配记录，则判定为通过冲突检测认证；若T2中的GTID SET包含了冲突检测数据库中相同主键值的GTID SET，则冲突认证检测通过；冲突认证检测通过后，每个节点的冲突检测数据库按照如下规则变更：1.若在冲突检测数据库中无匹配记录，则向其中插入一条新的记录。2.如果有记录，则更新冲突检测数据库中的GTID SET值。若T1修改的数据在冲突检测数据库中有匹配到记录，且T1的GTID SET不包括冲突检测数据库中的GTID SET，则判定为冲突检测不通过。注意：冲突检测不通过时，不会更新认证数据库里的GTID SET。目前业内存在以下问题：1.MGR可确保仅在集群中的大多数节点都已收到事务，并就并发发送的所有事务之间的相对顺序达成一致后才提交事务。相对顺序意味着，在分发到Secondary节点之后，可以不按照Primary节点提交的顺序进行提交，只需保证和集群的一致性即可。2.在流量小的时候不存在任何的性能问题。当流量突增时，如果集群中某些节点的写入吞吐量比其他节点少，尤其是小于Primary节点，则这些节点的数据和Primary节点的数据存在偏差。例如说在集群当中，一个3节点的集群，如果节点之间服务性能存在差异的话，则会存在性能问题。3.在单主模式的集群中，如果发生故障转移，在新的Primary节点可以立刻接受写入请求的情况下，则存在集群内事务一致性的问题。举例说明，当集群扩容时，例如由3节点集群扩容到5节点集群：1.无论采用Clone的方式还是用Xtrabackup做全量数据恢复后，都避免不了在集群扩容期间产生的增量数据以二进制日志的方式来追平；2.若新扩容的节点配置较低，写入吞吐差，则新加入的节点很有可能一直处于Recover的状态，该节点很难达到Online的状态。在进行高可用切换之后，存在事务一致性保证，这是由于Secondary节点和Primary节点存在追数据的过程，如果数据没有追平，那么业务数据可能会读到旧的数据，用户可以根据group_replication_consistency参数对应的可选值进行调整，总共有5个值如下：1.EVENTUAL（三）冲突检测示例DB2DB1DB3PK HASHT1update tb1set xid=2where PK=1gtid_executed:group_name:1-100gtid_executed:group_name:1-100T2update tb1set xid=3where PK=1T1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)T2:update tb1 set xid=2 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETupdategroup_name:1-50PK HASHdb1.tb1.pk=1GTID SETgroup_name:1-101PK HASHT1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETNo need to updategroup_name:1-101（一）存在的问题（二）事务一致性保证性能分析78MySQL电子书3.事务提交前，数据库中执行了的Gtid集合，随着Binlog中的Event通过原子广播的方式分发到集群的所有节点上进行事务冲突检测。如上图所示，以T1与T2这两条Update语句为例。若T2修改的数据在冲突检测数据库中无匹配记录，则判定为通过冲突检测认证；若T2中的GTID SET包含了冲突检测数据库中相同主键值的GTID SET，则冲突认证检测通过；冲突认证检测通过后，每个节点的冲突检测数据库按照如下规则变更：1.若在冲突检测数据库中无匹配记录，则向其中插入一条新的记录。2.如果有记录，则更新冲突检测数据库中的GTID SET值。若T1修改的数据在冲突检测数据库中有匹配到记录，且T1的GTID SET不包括冲突检测数据库中的GTID SET，则判定为冲突检测不通过。注意：冲突检测不通过时，不会更新认证数据库里的GTID SET。目前业内存在以下问题：1.MGR可确保仅在集群中的大多数节点都已收到事务，并就并发发送的所有事务之间的相对顺序达成一致后才提交事务。相对顺序意味着，在分发到Secondary节点之后，可以不按照Primary节点提交的顺序进行提交，只需保证和集群的一致性即可。2.在流量小的时候不存在任何的性能问题。当流量突增时，如果集群中某些节点的写入吞吐量比其他节点少，尤其是小于Primary节点，则这些节点的数据和Primary节点的数据存在偏差。例如说在集群当中，一个3节点的集群，如果节点之间服务性能存在差异的话，则会存在性能问题。3.在单主模式的集群中，如果发生故障转移，在新的Primary节点可以立刻接受写入请求的情况下，则存在集群内事务一致性的问题。举例说明，当集群扩容时，例如由3节点集群扩容到5节点集群：1.无论采用Clone的方式还是用Xtrabackup做全量数据恢复后，都避免不了在集群扩容期间产生的增量数据以二进制日志的方式来追平；2.若新扩容的节点配置较低，写入吞吐差，则新加入的节点很有可能一直处于Recover的状态，该节点很难达到Online的状态。在进行高可用切换之后，存在事务一致性保证，这是由于Secondary节点和Primary节点存在追数据的过程，如果数据没有追平，那么业务数据可能会读到旧的数据，用户可以根据group_replication_consistency参数对应的可选值进行调整，总共有5个值如下：1.EVENTUAL（三）冲突检测示例DB2DB1DB3PK HASHT1update tb1set xid=2where PK=1gtid_executed:group_name:1-100gtid_executed:group_name:1-100T2update tb1set xid=3where PK=1T1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)T2:update tb1 set xid=2 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETupdategroup_name:1-50PK HASHdb1.tb1.pk=1GTID SETgroup_name:1-101PK HASHT1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETNo need to updategroup_name:1-101（一）存在的问题（二）事务一致性保证性能分析910MySQL电子书开启该级别的事务（T2），事务执行前不会等待先序事务（T1）的回放完成，也不会影响后序事务等待该事务回放完成。2.BEFORE开启了该级别的事务（T2），在开始前首先要等待先序事务（T1）的回放完成，确保此事务将在最新的数据上执行。3.AFTER开启该级别的事务（T1），只有等该事务回放完成。其他后序事务（T2）才开始执行，这样所有后序事务都会读取包含其更改的数据库状态，而不管它们在哪个节点上执行。4.BEFORE_AND_AFTER开启该级别等事务（T2），需要等待前序事务的回放完成（T1）；同时后序事务（T3）等待该事务的回放完成。5.BEFORE_ON_PRIMARY_FAILOVER在发生切换时，连到新主的事务会被阻塞，等待先序提交的事务回放完成；这样确保在故障切换时客户端都能读取到主服务器上的最新数据，保证了一致性。用户根据不同的级别，根据业务上是读多写少，还是写多读少，或者是读写均衡的请求，不同的场景选择不同的值即可。1.流控机制的功能性能的问题对应着解决方案，MGR的流控机制试图解决以下问题：1）集群内节点之间不会相差太多的事务；2）快速适应集群内不断变化的负载，例如集群内的写压力暴增或集群中增加更多的节点；3）均分可用写容量到集群内的所有节点上；4）避免减少吞吐量而造成资源浪费。2.基本机制流控机制存在两个基本机制：1）监控集群内所有节点以收集有关吞吐量和队列大小的一些统计信息，以便对每个节点能承受的最大写入压力进行有根据的评估；2）对集群中的所有节点的并发写能力时刻保持监控，一旦某节点的并发压力超过了集群中所有节点的平均写能力，就会对其执行流量控制。3.基本队列流控机制存在两个基本队列：认证队列和二进制日志应用队列。当其中一个队列的大小超过用户定义的阈值时，就会触发流量控制机制。对于流量控制配置：首先，需要选择对谁配置流量控制，是对认证队列、还是针对应用队列、还是两者都需要配置流量控制。然后，对需要配置流量控制的对象（认证队列和应用队列）设置流量控制阈值。4.流控过程流控具体过程如下：1）将根据上一阶段延迟的事务数量逐步减少10%，让触发限流机制的队列减小到限流机制被触发的阈值之内，待到恢复后，为避免在队列大小超过阈值时出现吞吐量的陡增，在此之后，每个时间段的吞吐量只允许增长相同的10%；2）当前的限流机制不会影响到触发限流机制阈值内的事务，但是会延迟应用超过阈值的事务，直到本监控周期结束；3）如果触发节流机制的阈值设置的非常小，部分事务的延迟可能会接近一个完整的监控周期。在日常业务中，MGR高可用集群存在如下经典适用场景：1.弹性复制需要非常灵活的复制基础设施的环境，其中MySQL Server的数量必须动态增加或减少，并且在增加或减少Server的过程中，对业务的副作用尽可能少。例如，云数据库服务。2.高可用分片分片是实现写扩展的一种流行方法。基于MGR实现的高可用分片，其中每个分片都会映射到一个复制组上（逻辑上需要一一对应，但在物理上一个复制组可以承载多个分片）。3.替代主从复制在某些情况下，使用一个主库会造成单点争用。在某些情况下，向整个组内的多个成员同时写入数据，多种模式可以避免单点争用，对应用来说可能伸缩性更强。（三）流控机制适用场景910MySQL电子书开启该级别的事务（T2），事务执行前不会等待先序事务（T1）的回放完成，也不会影响后序事务等待该事务回放完成。2.BEFORE开启了该级别的事务（T2），在开始前首先要等待先序事务（T1）的回放完成，确保此事务将在最新的数据上执行。3.AFTER开启该级别的事务（T1），只有等该事务回放完成。其他后序事务（T2）才开始执行，这样所有后序事务都会读取包含其更改的数据库状态，而不管它们在哪个节点上执行。4.BEFORE_AND_AFTER开启该级别等事务（T2），需要等待前序事务的回放完成（T1）；同时后序事务（T3）等待该事务的回放完成。5.BEFORE_ON_PRIMARY_FAILOVER在发生切换时，连到新主的事务会被阻塞，等待先序提交的事务回放完成；这样确保在故障切换时客户端都能读取到主服务器上的最新数据，保证了一致性。用户根据不同的级别，根据业务上是读多写少，还是写多读少，或者是读写均衡的请求，不同的场景选择不同的值即可。1.流控机制的功能性能的问题对应着解决方案，MGR的流控机制试图解决以下问题：1）集群内节点之间不会相差太多的事务；2）快速适应集群内不断变化的负载，例如集群内的写压力暴增或集群中增加更多的节点；3）均分可用写容量到集群内的所有节点上；4）避免减少吞吐量而造成资源浪费。2.基本机制流控机制存在两个基本机制：1）监控集群内所有节点以收集有关吞吐量和队列大小的一些统计信息，以便对每个节点能承受的最大写入压力进行有根据的评估；2）对集群中的所有节点的并发写能力时刻保持监控，一旦某节点的并发压力超过了集群中所有节点的平均写能力，就会对其执行流量控制。3.基本队列流控机制存在两个基本队列：认证队列和二进制日志应用队列。当其中一个队列的大小超过用户定义的阈值时，就会触发流量控制机制。对于流量控制配置：首先，需要选择对谁配置流量控制，是对认证队列、还是针对应用队列、还是两者都需要配置流量控制。然后，对需要配置流量控制的对象（认证队列和应用队列）设置流量控制阈值。4.流控过程流控具体过程如下：1）将根据上一阶段延迟的事务数量逐步减少10%，让触发限流机制的队列减小到限流机制被触发的阈值之内，待到恢复后，为避免在队列大小超过阈值时出现吞吐量的陡增，在此之后，每个时间段的吞吐量只允许增长相同的10%；2）当前的限流机制不会影响到触发限流机制阈值内的事务，但是会延迟应用超过阈值的事务，直到本监控周期结束；3）如果触发节流机制的阈值设置的非常小，部分事务的延迟可能会接近一个完整的监控周期。在日常业务中，MGR高可用集群存在如下经典适用场景：1.弹性复制需要非常灵活的复制基础设施的环境，其中MySQL Server的数量必须动态增加或减少，并且在增加或减少Server的过程中，对业务的副作用尽可能少。例如，云数据库服务。2.高可用分片分片是实现写扩展的一种流行方法。基于MGR实现的高可用分片，其中每个分片都会映射到一个复制组上（逻辑上需要一一对应，但在物理上一个复制组可以承载多个分片）。3.替代主从复制在某些情况下，使用一个主库会造成单点争用。在某些情况下，向整个组内的多个成员同时写入数据，多种模式可以避免单点争用，对应用来说可能伸缩性更强。（三）流控机制适用场景1112MySQL电子书上图为业内的一个常用的高可用方案。通常在云数据库里，一个三节点的MGR集群本身不保证业务的写入重定向，那么在MGR集群上面加一个读写分离的中间件Maxscale。将源代码重新编译之后，会打开一个它自带的保活机制，Maxscale会自动探测MGR集群里Primer节点状态，如果发生高可用切换或者是当前的Primary节点宕机之后，它会重新探测选取出来一个新的Primary节点，然后自动将业务写请求重定向到新的Primary节点上。业务只需要将Client端经过SQL解析连到Maxscale，然后经Maxscale做一个路由转发，即可实现一个灵活的高可用。高可用方案Member 1SQL解析路由转发Member 2Member 3executeclientclientclientcertifybinlogbinlogcommitcommitcertifyrelay logapplybinlogcommitcertifyrelay logapplyConsensusmaxscaleMySQL高并发场景实战阿里巴巴CEO逍遥子曾说过：“双11是商业界的奥林匹克。”如上图所示，双十一购物始于2009年，历年的订单创建、支付笔数与交易总额都是成倍增长，这不仅带来许多商业机遇，也给后端技术、架构等各个模块带来技术沉淀。双11为MySQL带来了高并发场景的问题与挑战，主要表现在：1）洪峰般的并发根据市场部部门的推广和引流、历年双11的经验，大促的起始时刻呈现接近90度上升趋势。在这么大访问流量下，所有的核心链路的增删改查都是在数据库上操作，对数据库有比较大的冲击，在大量线程并发工作时线程调度工作过多、大量缓存失效、资源竞争加剧、锁冲突严重，如果有复杂SQL或大事务的话还可能导致系统资源耗尽，整个数据库服务不可用，进而导致大促收到影响，甚至失败，比如：下单失败、网页无法打开、无法支付等。此外此类场景也会发生在在线教育、直播电商、在线协同办公等。2）热点行更新问题和挑战作者：凌洛1112MySQL电子书上图为业内的一个常用的高可用方案。通常在云数据库里，一个三节点的MGR集群本身不保证业务的写入重定向，那么在MGR集群上面加一个读写分离的中间件Maxscale。将源代码重新编译之后，会打开一个它自带的保活机制，Maxscale会自动探测MGR集群里Primer节点状态，如果发生高可用切换或者是当前的Primary节点宕机之后，它会重新探测选取出来一个新的Primary节点，然后自动将业务写请求重定向到新的Primary节点上。业务只需要将Client端经过SQL解析连到Maxscale，然后经Maxscale做一个路由转发，即可实现一个灵活的高可用。高可用方案Member 1SQL解析路由转发Member 2Member 3executeclientclientclientcertifybinlogbinlogcommitcommitcertifyrelay logapplybinlogcommitcertifyrelay logapplyConsensusmaxscaleMySQL高并发场景实战阿里巴巴CEO逍遥子曾说过：“双11是商业界的奥林匹克。”如上图所示，双十一购物始于2009年，历年的订单创建、支付笔数与交易总额都是成倍增长，这不仅带来许多商业机遇，也给后端技术、架构等各个模块带来技术沉淀。双11为MySQL带来了高并发场景的问题与挑战，主要表现在：1）洪峰般的并发根据市场部部门的推广和引流、历年双11的经验，大促的起始时刻呈现接近90度上升趋势。在这么大访问流量下，所有的核心链路的增删改查都是在数据库上操作，对数据库有比较大的冲击，在大量线程并发工作时线程调度工作过多、大量缓存失效、资源竞争加剧、锁冲突严重，如果有复杂SQL或大事务的话还可能导致系统资源耗尽，整个数据库服务不可用，进而导致大促收到影响，甚至失败，比如：下单失败、网页无法打开、无法支付等。此外此类场景也会发生在在线教育、直播电商、在线协同办公等。2）热点行更新问题和挑战作者：凌洛1314MySQL电子书库存扣减场景是一个典型的热点问题，当多个用户去争抢扣减同一个商品的库存（对数据库来说，一个商品的库存就是数据库内的一行记录），数据库内对同一行的更新由行锁来控制并发。当单线程（排队）去更新一行记录时，性能非常高，但是当非常多的线程去并发更新一行记录时，整个数据库的性能会跌到趋近于零。3）突发SQL访问当缓存穿透或异常调用、有数据倾斜SQL、未创建索引SQL等情况发生时，在高并发场景下很容易导致数据库压力过大，响应过慢，导致应用链接释放慢，导致整个系统不可用。4）智能化运维双十一期间这些实例的水位管控，机器水位管控，高风险实例识别，高风险实例优化，在流量高峰期从收到报警、识别问题、解决问题至少需要十多分钟，如果处理不及时峰值已经过去，导致大促失败。此外，结合业务还有商品超卖、资源的挑战等问题存在。sysbench/usr/share/sysbench/oltp_read_write.lua-mysql-host=host-mysql-port=port-mysql-user=user-mysql-password=passwd-mysql-db=db-db-driver=mysql-tables=count-table-size=size-reportinterval=interval-threads=threads-time=time prepare/run/clean此外还有mysqlslap，ab1.性能评测的意义1）目的 发现基础设施瓶颈、中间件瓶颈、系统容量瓶颈；发现分布式系统短板。2）用途 保障大促容量充足，保障业务正常运转；保障核心功能、保证用户体验；评估大促成本，包含人工成本、机器成本、运维成本等。3）难点 真实业务场景压测；真实SQL模拟。2.基准测试系统调优为解决以上挑战与问题，我们需要做系统调优，主要从六个方面进行：容量评估、性能评测、架构调优、实例调优、内核调优和监控报警。压测可以分为基准测试和仿真测试。对于MySQL而言，基准测试可以用sysbench或mysqlslap等。基于通用场景的测试，每个实例在不同的业务场景下达到的容量也不同，通常情况下，同一个实例的应用真实的业务场景的值不会超过其基准测试的值。3.全链路压测是大促备战核武器真实业务场景的压测往往比基准测试更加复杂，阿里巴巴在双11的场景下整个压测过程大概可以分为4个步骤，如下图所示：容量评估主要分为三个部分：经验评估、单元压测与全链路压测。经验评估容量评估刚开始阶段是经验评估，根据以往经验值给出一个预估的压力，再除以单台机器的性能，大致可得出所需服务器的数量。根据服务器数量、应用机器数量与DB实例数量，可以得出整个数据库（如链接池）的设置，以及要扩充多少实例和应用机器等，判断能否支撑得住双11的峰值。需要针对上述的预估做一个判断验证，通过压测来完成。单元压测经过经验预估后，需要针对上述的预估做判断验证，可以通过单元压测来完成。由于是分布式的系统，需要预先针对单个实例、单个单元以及单个应用模块来进行压测。单元压测的主要功能是完成单元内的验证，系统整个的架构很多是异地多活，因此不但需要验证整个双11的流量，还要验证在单元内的容量是否充足，以及单个系统的容量，例如压测某一个模块、交易模块、优惠模块等容量是否充足。全链路压测等每一个应用模块验证完成之后，需要对整个链路进行压测，也就是全链路压测。全链路压测是基于场景化的仿真测试，其数据最接近业务的系统值，针对全链路压测，可以借助压测来验证整个分布式系统的容量是否充足。（一）容量评估（二）性能评测经验评估预估压力/单机性能=服务器数量应用机器设置、数据库设置等单元压测验证单元内容量验证单个系统容量全链路压测场景化压测解决分布式系统容量评估相关系统梳理涉及业务梳理技术架构梳理容量预估环境准备服务器准备数据构造业务请求准备正式压测短板压测容量验证/优化预案验证优化短板优化架构优化容量优化1314MySQL电子书库存扣减场景是一个典型的热点问题，当多个用户去争抢扣减同一个商品的库存（对数据库来说，一个商品的库存就是数据库内的一行记录），数据库内对同一行的更新由行锁来控制并发。当单线程（排队）去更新一行记录时，性能非常高，但是当非常多的线程去并发更新一行记录时，整个数据库的性能会跌到趋近于零。3）突发SQL访问当缓