MySQL 数据库如何解决高并发问题

前言

我们都知道初创公司一开始都是以单体应用为首要架构，一般都是单体单库的形式。但是版本以及版本的迭代，数据库需要承受更多的高并发已经成了 架构设计 需要考虑的点。

那么解决问题，就得说到方案。但是方案有很多，我们该怎么选择呢？

优化与方案

基本上，我们优化要从几个关键字入手： 短距离 ， 少数据 ， 分散压力 。

短距离

所谓的短距离，指的是从前端到数据库的路径要短。

  1. 页面静态。有些页面的数据是在某些时段是不变的，那么这个页面可以静态化，这样可以提高访问的速度。
  2. 使用缓存。缓存大家都知道，快的原因就是基于内存。所以使用基于内存的缓存的话，可以减少对数据库的访问，同时加速访问速度。
  3. 批量读取。高并发的情况下，可以将多个请求的查询合在一次进行，以减少对数据库的访问速度。
  4. 延迟修改。延迟修改的意思高并发的情况西可能是将多次修改数据放在缓存中，然后定时将缓存中的数据过更新到数据库；也可以是通过缓存的同步策略通过解析异步同步到数据库中。
  5. 使用索引。这个不用说了，索引有着比较多的类型，例如普通索引/主键索引/组合索引/全文索引等。

少数据

所谓的少数据，其实是查询的数据要少。

  1. 分表。所谓的分表，其实有水平切分和垂直拆分。玩过单机的小伙伴都知道，往往一些具有历史性的表单，都会有成百上千万级别的数据。这样子对于 MySQL 来说，即使是加了索引，SQL 方面继续优化，也很难做到更快的查询速度。那么我们可以通过分表的操作来实现。例如说最常见的我们可以根据时间的维度来进行表的水平拆分，今年的数据保持下来，而去年的数据可以存在另外一个表里。
  2. 分离活跃数据。其实这个有点类似缓存，但是不同之处在于数据还是在 MySQL 上面的。例如一个查询商品的业务，有一些火爆/经常被搜索的商品可以存在一张活跃表。查询的时候先查询活跃表，没有的话再查询总商品表。
  3. 分块。这个分块有点类似于算法里面的“索引顺序查找”。通过数据层面的优化，将数据放在不同的块中，而我们只需要计算找到对应的块就行了。

分散压力

所谓的分散压力，其实是分散不同数据库服务器的压力

  1. 集群。集群的概念相信大家都很清楚，对于业务服务器来说其实就是具备相同业务流程的服务器部署多台，通过负载均衡或其他方式来将请求分配到不同服务器。而数据库也一样，通过特定的规则策略将数据导向特定的数据库服务器上。
  2. 分布式。所谓的分布式，其实就是将原本处于同个流程的业务逻辑分配到不同的服务器上面执行，达到了“并发”执行的效果，加快执行速度。
  3. 分库分表。分库分表主要是水平拆分和垂直拆分。对于访问频率高而数据量巨大的单表，可以减少单表的数据，根据特定的维度进行水平拆分，增加数据库的吞吐量，这就是 分表水平拆分 ；而对于业务耦合性低的多表来说，可以将不同的表存储在不同的数据库上，对数据库进行垂直拆分，提高数据库写的能力，即 分库的垂直拆分 。
  4. 建立主从。建立主从的目的其实就是为了读写分离。我们都知道，只要数据库的事务级别够高，那么并发读是不会影响到数据的混乱，而并发写则会。所以建立主从一般来说，写会留在主服务器上写，而会在从服务器上读。 所以基本上让主服务器进行事务性操作，从服务器进行 select 查询。这样子的话，事务性操作（增加/删除/修改）导致的改变更新同步到集群中的从数据库 。

结语

以上就是MySQL 如何处理高并发的详细内容，更多关于MySQL 高并发的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • Tomcat+Mysql高并发配置优化讲解

    Tomcat+Mysql高并发配置优化讲解

    1.Tomcat优化配置 (1)更改Tomcat的catalina.bat 将java变成server模式,增大jvm的内存,在文件开始位置增加 setJAVA_OPTS=-server -Xms1024m -Xmx2048m -Xss512K -XX:PermSize=128m-XX:MaxPermSize=256m setCATALINA_OPTS=-server -Xms512m -Xmx512m 如下图: Xms:初始内存 Xmx:最大内存 (2)更改Tomcat的Server.xml

  • 用于App服务端的MySQL连接池（支持高并发）

    本文向大家介绍了简单的MySQL连接池,用于App服务端比较合适,分享给大家供大家参考,具体内容如下 /** * 连接池类 */ package com.junones.test; import java.sql.Connection; import java.sql.SQLException; import java.util.HashMap; import java.util.Map; import java.util.Map.Entry; import com.mysql.jdbc.jdb

  • MySQL中实现高性能高并发计数器方案（例如文章点击数）

    现在有很多的项目,对计数器的实现甚是随意,比如在实现网站文章点击数的时候,是这么设计数据表的,如:"article_id, article_name, article_content, article_author, article_view--在article_view中记录该文章的浏览量.诈一看似乎没有问题.对于小站,比如本博客,就是这么做的,因为小菜的博客难道会涉及并发问题吗?答案显而易见,一天没多少IP,而且以后不会很大. 言归正传,对文章资讯类为主的项目,在浏览一个页面的时候不但要进行

  • PHP利用Mysql锁解决高并发的方法

    前面写过利用文件锁来处理高并发的问题的,现在我们说另外一个处理方式,利用Mysql的锁来解决高并发的问题 先看没有利用事务的时候并发的后果 创建库存管理表 CREATE TABLE `storage` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `number` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=l

  • PHP+MySQL高并发加锁事务处理问题解决方法

    本文实例讲述了PHP+MySQL高并发加锁事务处理问题解决方法.分享给大家供大家参考,具体如下: 1.背景: 现在有这样的需求,插入数据时,判断test表有无username为'mraz'的数据,无则插入,有则提示"已插入",目的就是想只插入一条username为'mraz'的记录. 2.一般程序逻辑如下: $conn = mysqli_connect('127.0.0.1', 'root', '111111') or die(mysqli_error()); mysqli_selec

  • MySQL 数据库如何解决高并发问题

    前言 我们都知道初创公司一开始都是以单体应用为首要架构,一般都是单体单库的形式.但是版本以及版本的迭代,数据库需要承受更多的高并发已经成了 架构设计 需要考虑的点. 那么解决问题,就得说到方案.但是方案有很多,我们该怎么选择呢? 优化与方案 基本上,我们优化要从几个关键字入手: 短距离 , 少数据 , 分散压力 . 短距离 所谓的短距离,指的是从前端到数据库的路径要短. 页面静态.有些页面的数据是在某些时段是不变的,那么这个页面可以静态化,这样可以提高访问的速度. 使用缓存.缓存大家都知道,快的

  • 详解Mysql数据库平滑扩容解决高并发和大数据量问题

    详解Mysql数据库平滑扩容解决高并发和大数据量问题

    目录 1 停机方案 2 停写方案 3 平滑扩容之双写方案(中小型数据) 4 平滑扩容之2N方案大数据量问题解决 4.1 扩容问题 4.2 解决方案 4.3 双主架构思想 4.4 环境部署 5 数据库秒级平滑2N扩容实践 5.1 新增数据库VIP 5.2 应用服务增加动态数据源 5.3 解除原双主同步 5.4 安装MariaDB扩容服务器 5.5 增加KeepAlived服务实现高可用 5.6 清理数据并验证 1 停机方案 发布公告 停止服务 离线数据迁移(拆分,重新分配数据) 数据校验 更改配置

  • Spring Boot实战解决高并发数据入库之 Redis 缓存+MySQL 批量入库问题

    Spring Boot实战解决高并发数据入库之 Redis 缓存+MySQL 批量入库问题

    目录 前言 架构设计 代码实现 测试 总结 前言 最近在做阅读类的业务,需要记录用户的PV,UV: 项目状况:前期尝试业务阶段: 特点: 快速实现(不需要做太重,满足初期推广运营即可)快速投入市场去运营 收集用户的原始数据,三要素: 谁在什么时间阅读哪篇文章 提到PV,UV脑海中首先浮现特点: 需要考虑性能(每个客户每打开一篇文章进行记录)允许数据有较小误差(少部分数据丢失) 架构设计 架构图: 时序图 记录基础数据MySQL表结构 CREATE TABLE `zh_article_count`

  • 如何利用Redis锁解决高并发问题详解

    redis技术的使用: redis真的是一个很好的技术,它可以很好的在一定程度上解决网站一瞬间的并发量,例如商品抢购秒杀等活动... redis之所以能解决高并发的原因是它可以直接访问内存,而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力. 为什么redis的地位越来越高,我们为何不选择memcache,这是因为memcache只能存储字符串,而redis存储类型很丰富(例如有字符串.LIST.SET等),memcache每个值最大只能存储1M,存储资源非常有限,十分消耗内

  • PHP解决高并发的优化方案实例

    PHP解决高并发的优化方案实例

    我们通常衡量一个Web系统的吞吐率的指标是QPS(Query Per Second,每秒处理请求数),解决每秒数万次的高并发场景,这个指标非常关键.举个例子,我们假设处理一个业务请求平均响应时间为100ms,同时,系统内有20台Apache的Web服务器,配置MaxClients为500个(表示Apache的最大连接数目). 那么,我们的Web系统的理论峰值QPS为(理想化的计算方式): 20*500/0.1 = 100000 (10万QPS) 咦?我们的系统似乎很强大,1秒钟可以处理完10万的

  • Redis锁完美解决高并发秒杀问题

    目录 1 单机环境下的锁 2 分布式情况下使用Redis锁. 3 一台服务宕机,导致无法释放锁 4 给每一把锁加上过期时间 5延长锁的过期时间,解决锁失效 6 使用Redisson简化代码 场景:一家网上商城做商品限量秒杀. 1 单机环境下的锁 将商品的数量存到Redis中.每个用户抢购前都需要到Redis中查询商品数量(代替mysql数据库.不考虑事务),如果商品数量大于0,则证明商品有库存.然后我们在进行库存扣减和接下来的操作.因为多线程并发问题,我们不得不在get()方法内部使用同步代码块

  • PHP使用文件锁解决高并发问题示例

    本文实例讲述了PHP使用文件锁解决高并发问题.分享给大家供大家参考,具体如下: 新建一个.txt文件,文件中什么都不用写. [一].阻塞(等待)模式:(只要有其他进程已经加锁文件,当前进程会一直等其他进程解锁文件) <?php //连接数据库 $con=mysqli_connect("192.168.2.186","root","root","test"); //查询商品数量是否大于0,大于0才能下单,并减少库存 $fp

  • 使用Redis解决高并发方案及思路解读

    目录 NoSQL Redis 痛点 思路 分布式锁 锁续命 扩展 结语 NoSQL Not Only SQL的简称.NoSQL是解决传统的RDBMS在应对某些问题时比较乏力而提出的. 即非关系型数据库,它们不保证关系数据的ACID特性,数据之间一般没有关联,在扩展上就非常容易实现,并且拥有较高的性能. Redis redis是nosql的典型代表,也是目前互联网公司的必用技术. redis是键值(Key-Value)存储数据库,主要会使用到哈希表.大多数时候是直接以缓存的形式被使用,使得请求不直

  • axios解决高并发的方法:axios.all()与axios.spread()的操作

    前言: 很多时候,我们可能需要同时调用多个后台接口,就会高并发的问题,一般解决这个问题方法: axios.all和axios.spread ***注意这里的$get是封装的axios方法 //方法一: searchTopic() { return this.$axios({ url:'地址1', method:'方式',//get/post/patch/put/deleted params:{//参数get所以用params.post.put用data } }) } //方法二: searchs

随机推荐