双十一高并发场景背后的数据库RDS技术揭秘

【战报】11月11日聚石塔(阿里云数据库RDS产品形态)峰值QPS突破X00w,Proxy 峰值QPS超过X00w。

双十一就要来了,全世界都为其疯狂,但是在双十一抢购中经常会出现几万人抢一个红包或者很多人共同购买一个商品的情况,这就引发了一个数据库比较担心的场景----高并发。作为历届双十一重要保障之一的云数据库RDS部门,从参数优化、链路访问、弹性扩容、架构设计等方面应对高并发场景(如秒杀、百万人抢单等),保障双十一顺利进行。那么背后的技术是如何实现的呢?本文,将带您展开双十一阿里云RDS数据库背后技术的小秘密。

参数优化
在处理“高并发”场景的时候,一些特定的数据库参数就成为能否保障数据快速响应和平顺处理“高并发”问题,就成了关键,如下列出了几个特别重要的参数:
?loose_rds_max_tmp_disk_space:控制MySQL能够使用的临时文件的大小;
?loose_rds_threads_running_high_watermark:控制MySQL并发的查询数目,常用于秒杀
?loose_tokudb_buffer_pool_ratio:控制TokuDB引擎能够使用的buffer内存大小
?loose_max_statement_time:控制查询在MySQL的最长执行时间

举例说明,秒杀场景下的参数设置与影响:
loose_rds_threads_running_high_watermark

是“秒杀”场景开始的时候,可以看到连接数成指数级变化,瞬间增加了10倍

调整参数之前,可以看到RUN数量非常高,会导致数据库报警

调整参数之后,update数值与run数值承更好的方向变化

链路访问
在链路访问方面,我们提供更高安全性的数据库代理访问模式,用户可以根据需要随时开启或关闭。数据库代理的规格大小由RDS系统自动管理,可以在保证租户间资源隔离的前提下,根据负载大小自适应调节。数据库代理对应用透明无感知,也无需人工干预,大大降低了运维成本。
如下图所示

数据库代理位于应用程序(Client)和数据库引擎(Database Engine)中间,由RDS系统自动进行维护,所有的数据库请求(Request)和响应(Response)均从代理层经过和处理。

目前,数据库代理支持如下功能:数据库代理支持以下功能:
? 透明切换:RDS实例在发生故障、规格升级或降级时,数据库代理可以使实例切换更加柔和,降低对应用的影响。
? 读写分离:提供透明的读写分离功能,应用层无需修改代码,查询分发到RDS只读实例,降低主库的负载。

? 短连接优化:突发高并发的短连接(常见于PHP应用)在代理层进行缓冲,减轻对DB层的冲击,降低RDS的CPU负载和CPS(每秒新建连接数),保障数据库运行稳定。
? 防暴力破解:保护RDS实例账号密码,规避账号密码被暴力破解。

弹性扩容
在扩容升级的过程中,主要分为两种情况:本机升级和跨机升级

本机升级

跨机升级,还要做备份数据和日志的迁移工作

扩容升级的常见问题

为什么有时候升级需要很长时间?
可能发生了跨机迁移,迁移时间受限于数据库大小以及系统压力
可用区迁移,数据库版本升级为什么耗时较长?
这两者迁移都会发生跨机迁移
空间升级为什么非常快?
空间升级不用重启迁移数据库
选择弹性扩容的时间
建议在业务低峰期,最近一次备份任务完成后进行升级
架构设计
为了应对日渐增长的双十一购买数据量和仓储数据量,RDS也对各个支持的数据库进行了新的架构设计。
如下表,引擎选择方面:ApsaraDB for RDS,当前支持4款关系型引擎,提供容灾、备份、恢复、监控等方面的全套解决方案


RDS自带的读写分离,让用户使用更方便:

另外,安全问题也一直是商家和用户最关心的问题,在疯狂的‘剁手’中,您一定不想您的商品信息或者购买信息有安全披露,对于这个问题,RDS在安全方面也做了多重保护和设计:

除了以上几点,RDS团队还对数据库的性能等进行了重新的优化,让商家和购买者在抢购中完全不用担心数据库的性能和安全问题,无忧无虑的‘剁手’,尽情享受双十一盛会!

原文地址:http://blog.51cto.com/14031893/2321045

时间: 2024-11-07 04:00:56

双十一高并发场景背后的数据库RDS技术揭秘的相关文章

高并发场景下缓存+数据库双写不一致问题分析与解决方案设计

Redis是企业级系统高并发.高可用架构中非常重要的一个环节.Redis主要解决了关系型数据库并发量低的问题,有助于缓解关系型数据库在高并发场景下的压力,提高系统的吞吐量(具体Redis是如何提高系统的性能.吞吐量,后面会专门讲). 而我们在Redis的实际使用过程中,难免会遇到缓存与数据库双写时数据不一致的问题,这也是我们必须要考虑的问题.如果还有同学不了解这个问题,可以搬小板凳来听听啦. 一.数据库+缓存双写不一致问题引入 要讲数据库+缓存双写不一致的问题,就需要先讲一下这个问题是怎么发生的

【阿里巴巴:高并发的背后】数据库规范

(一) 建表规约 [强制]表达是与否概念的字段,必须使用is_xxx的方式命名,数据类型是unsigned tinyint( 1表示是,0表示否).说明:任何字段如果为非负数,必须是unsigned.正例:表达逻辑删除的字段名is_deleted,1表示删除,0表示未删除. [强制]表名.字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只出现数字.数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑. 说明:MySQL在Windows下不区分大小写,但在Li

扛住阿里双十一高并发流量,Sentinel是怎么做到的?

Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景 本文介绍阿里开源限流熔断方案Sentinel功能.原理.架构.快速入门以及相关框架比较 基本介绍 1 名词解释 服务限流 :当系统资源不够,不足以应对大量请求,对系统按照预设的规则进行流量限制或功能限制 服务熔断:当调用目标服务的请求和调用大量超时或失败,服务调用方为避免造成长时间的阻塞造成影响其他服务,后续对该服务接口的调用不再经过进行请求,直接执行本地的默认方法 服务降级:为了保证核心业务在大量请求下能正常运行,根据实际

SpringBoot实战实现分布式锁一之重现多线程高并发场景

实战前言:上篇博文我总体介绍了我这套视频课程:"SpringBoot实战实现分布式锁" 总体涉及的内容,从本篇文章开始,我将开始介绍其中涉及到的相关知识要点,感兴趣的小伙伴可以关注关注学习学习!!工欲善其事,必先利其器,介绍分布式锁使用的前因后果之前,得先想办法说清楚为啥需要分布式锁以及如何才需要将分布式锁搬上用场!!其中,该课程的学习链接:http://edu.51cto.com/course/15684.html感兴趣的童鞋可以前往观看学习!!! 实战概要:故而此文将介绍一下分布式

云数据库RDS存储能力进化解析!

数据库是企业IT系统的核心,其性能表现会直接影响整体业务系统的性能表现,而影响数据库性能因素包括系统架构设计.应用程序业务SQL语句.数据库参数优化配置.数据库运行的资源能力.系统架构设计和应用程序业务SQL语句都属于数据库外围,需要从整体业务上去设计优化:数据库的参数配置,核心是要根据数据库上的业务和硬件特点细调参数,丰富的DBA经验对此项影响很大,归属于软件配置内容且随时可调整.数据库的硬件资源,在传统企业中属于一项固定资产投资,前期投资成本高,后期更换成本更高,云时代虽然能够随时扩容硬件资

缓存在高并发场景下的常见问题

缓存一致性问题 当数据时效性要求很高时,需要保证缓存中的数据与数据库中的保持一致,而且需要保证缓存节点和副本中的数据也保持一致,不能出现差异现象.这就比较依赖缓存的过期和更新策略.一般会在数据发生更改的时,主动更新缓存中的数据或者移除对应的缓存. 缓存并发问题 缓存过期后将尝试从后端数据库获取数据,这是一个看似合理的流程.但是,在高并发场景下,有可能多个请求并发的去从数据库获取数据,对后端数据库造成极大的冲击,甚至导致 “雪崩”现象.此外,当某个缓存key在被更新时,同时也可能被大量请求在获取,

高并发场景之RabbitMQ

高并发场景之RabbitMQ 上次我们介绍了在单机.集群下高并发场景可以选择的一些方案,传送门:高并发场景之一般解决方案 但是也发现了一些问题,比如集群下使用ConcurrentQueue或加锁都不能解决问题,后来采用Redis队列也不能完全解决问题, 因为使用Redis要自己实现分布式锁 这次我们来了解一下一个专门处理队列的组件:RabbitMQ,这个东西天生支持分布式队列. 下面我们来用RabbitMQ来实现上一篇的场景 一.新建RabbitMQ.Receive private static

高并发场景之RabbitMQ篇

上次我们介绍了在单机.集群下高并发场景可以选择的一些方案,传送门:高并发场景之一般解决方案 但是也发现了一些问题,比如集群下使用ConcurrentQueue或加锁都不能解决问题,后来采用Redis队列也不能完全解决问题, 因为使用Redis要自己实现分布式锁 这次我们来了解一下一个专门处理队列的组件:RabbitMQ,这个东西天生支持分布式队列. 下面我们来用RabbitMQ来实现上一篇的场景 一.新建RabbitMQ.Receive private static ConnectionFact

Java进阶知识点6:并发容器背后的设计理念 - 锁分段、写时复制和弱一致性

一.背景 容器是Java编程中使用频率很高的组件,但Java默认提供的基本容器(ArrayList,HashMap等)均不是线程安全的.当容器和多线程并发编程相遇时,程序员又该何去何从呢? 通常有两种选择: 1.使用synchronized关键字,将对容器的操作有序错开,确保同一时刻对同一个容器只存在一个操作.Vector,HashTable等封装后的容器本质也是这种解决思路,只不过synchronized关键字不需要我们来书写而已. 2.使用java.util.concurrent包下提供的并