面试题：MariaDB半同步复制在高并发场景下的优化策略

Question

在高并发场景下，MariaDB半同步复制可能会遇到性能瓶颈。请阐述针对这种情况可以采取哪些优化策略，从网络配置、参数调整、架构设计等多方面进行分析。

Answer 1

网络配置方面

1. 优化网络带宽：
   • 增加服务器之间的网络带宽，使用高速网络设备，如10Gbps甚至更高带宽的网卡和交换机，减少网络传输延迟，加快主从节点之间的数据传输速度，使主库在等待从库确认时能更快得到响应。
2. 降低网络延迟：
   • 选择距离较近的数据中心部署主从节点，减少物理距离带来的网络延迟。
   • 优化网络拓扑结构，减少网络跳数，避免复杂的网络路径导致的延迟增加。
   • 配置合理的网络QoS（Quality of Service）策略，为数据库复制流量设置较高优先级，确保复制数据优先传输。

参数调整方面

1. 调整半同步复制参数：
   • rpl_semi_sync_master_timeout：适当增加此参数值，该参数表示主库等待从库确认的超时时间。在网络状况不太理想但并非异常的情况下，适当延长超时时间可以避免主库因短暂的网络延迟而过早判定从库确认失败，重新切换为异步复制模式。但不宜设置过大，否则可能导致主库等待时间过长影响性能。
   • rpl_semi_sync_master_wait_no_slave：可以根据实际情况设置为ON或OFF。如果设置为ON，当没有从库连接时，主库不会等待从库确认，直接进行事务提交，这样在从库故障或连接异常时能保证主库继续正常工作；若设置为OFF，则主库会等待至少一个从库连接并确认。
   • rpl_semi_sync_master_wait_point：控制主库在事务执行的哪个阶段等待从库确认，默认是AFTER_SYNC，即主库在将二进制日志发送给从库后等待确认。根据业务特点，若事务中一些操作耗时较长且可以在从库确认前执行，可考虑设置为AFTER_COMMIT，但需注意这种设置可能会影响数据一致性，要谨慎评估。
2. 调整其他相关参数：
   • innodb_flush_log_at_trx_commit：该参数控制InnoDB存储引擎将日志缓冲写入日志文件并刷盘的频率。默认值为1，表示每次事务提交时都进行刷盘操作，这在高并发场景下可能会带来性能开销。可根据业务对数据一致性的要求，在允许一定数据丢失风险的情况下，设置为0（每秒刷盘一次）或2（每次事务提交时写入日志文件，但由操作系统决定何时刷盘），减少I/O操作，提升性能，但同时要注意数据一致性的权衡。
   • sync_binlog：控制二进制日志刷盘的频率。默认值为1，表示每次事务提交都刷盘，同样会增加I/O开销。可适当增大该值，如设置为100或1000，即每100次或1000次事务提交刷盘一次，但这也会增加在系统崩溃时二进制日志丢失的风险，需要根据业务需求谨慎调整。

架构设计方面

1. 采用多主多从架构：
   • 部署多个主库，每个主库负责处理一部分业务请求，同时每个主库有自己对应的从库。这样可以分散写操作的压力，避免单个主库在高并发写入时成为性能瓶颈。例如，对于一个电商系统，可以按业务模块划分，商品管理相关的写操作由一个主库处理，订单管理相关的写操作由另一个主库处理。同时，每个主库的从库可以承担读操作负载，提高系统整体的读写性能。
2. 引入中间件：
   • 使用数据库中间件如Mycat、Sharding - Sphere等。这些中间件可以实现数据的分片（Sharding），将数据按一定规则（如按用户ID哈希、按时间范围等）分布到多个数据库节点上，从而分散高并发的读写压力。对于读操作，中间件可以根据负载均衡策略将请求分发到不同的从库上；对于写操作，中间件可以根据分片规则将数据正确写入对应的主库节点，有效缓解单个数据库节点的压力。
3. 读写分离：
   • 进一步优化读写分离策略，除了简单地将读请求导向从库，还可以根据业务场景对读请求进行细分。例如，对于实时性要求不高的查询，如统计报表类查询，可以导向离主库同步延迟较大但配置较低成本的从库；对于实时性要求较高的读请求，如用户登录信息查询，导向同步延迟较小的从库。同时，通过缓存（如Redis）来分担一部分读压力，对于经常查询且不经常变化的数据，先从缓存中读取，减少对数据库的读请求次数。