精华内容
下载资源
问答
  • 解决数据库高并发的常见方案

    千次阅读 2018-12-20 09:27:17
    解决数据库高并发的常见方案: 1) 缓存式的 Web 应用程序架构: 在 Web 层和 DB(数据库)层之间加一层 cache 层,主要目的:减少数据库读取负担,提高数 据读取速度。cache 存取的媒介是内存,可以考虑采用分布式的 ...

    解决数据库高并发的常见方案:

    1) 缓存式的 Web 应用程序架构: 在 Web 层和 DB(数据库)层之间加一层 cache 层,主要目的:减少数据库读取负担,提高数 据读取速度。cache 存取的媒介是内存,可以考虑采用分布式的 cache 层,这样更容易破除内存容量 的限制,同时增加了灵活性。

    2) 增加 Redis 缓存数据库:

    3) 增加数据库索引
    索引的设置建议避免踩以下两个坑:

    • 索引越多,查询速度反而会变慢
    • 数据表每写入一次数据,都会让后面的索引编号重新排序,仍然会降低速度(所以建议在经常变动的表里建索引)

    4) 页面静态化:
    嗯,减少用户访问服务器对数据库的读取量

    5) MySQL 主从读写分离:
    当数据库的写压力增加,cache 层(如 Memcached)只能缓解数据库的读取压力。读写集 中在一个数据库上让数据库不堪重负。读写分离就是只在主服务器上写,只在从服务器上读

    6) 分表分库:
    分表【水平拆分】。比如将数据表以业务类别进行拆分,缩短表的长度,可以提高数据库查询的速度(查询时长跟数据的长度成正比),间接提高并发洪峰的处理效率

    8) 负载均衡集群:
    终极解决办法,想要提高性能上的提高,最根本最有效的方法就是提高硬件上的配置,就酱

    展开全文
  • 数据库高并发解决方法总结

    万次阅读 2017-01-23 10:33:23
    数据库高并发解决方法总结

    一个项目刚开始的时候是为了实现基本功能,随着版本和功能的迭代,大数据和高并发成了软件设计必须考虑的问题!

    本质很简单,一个是慢,一个是等。

    两者是相互关联的,因为慢,所以要等,因为等,所以慢,解决了慢,也就解决了等,解决了等,也就解决了慢。

    关键是如何解决慢和等,核心一个是,一个是,一个是分流,最后一个是集群/横向扩张/读写分离/建立主从


    • 是指路径要短:

    典型的mvc结构是请求->controller->model->dao->view,然后把页面返回给用户。要想短的话,

    1,页面静态化- 用户可以直接获取页面,不用走那么多流程,比较适用于页面不频繁更新。

    2,使用缓存- 第一次获取数据从数据库准提取,然后保存在缓存中,以后就可以直接从缓存提取数据。不过需要有机制维持缓存和数据库的一致性。

    3,使用储存过程-那些处理一次请求需要多次访问数据库的操作,可以把操作整合到储存过程,这样只要一次数据库访问就可以了。

    4,批量读取 - 高并发情况下,可以把多个请求的查询合并到一次进行,以减少数据库的访问次数

    5,延迟修改 - 高并发情况下,可以把多次修改请求,先保存在缓存中,然后定时将缓存中的数据保存到数据库中,风险是可能会断电丢失缓存中的数据,

    6,  使用索引 - 索引可以看作是特殊的缓存,尽量使用索引就要求where字句中精确的给出索引列的值。


    • 是指查询的数据要少:

    1,分表 - 把本来同一张表的内容,可以按照地区,类别等分成多张表,很简单的一个思路,但是要尽量避免分出来的多表关联查询。

    2,分离活跃数据 - 例如登录用户业务,注册用户很多,但是活跃的登录用户很少,可以把活跃用户专门保存一张表,查询是先查询活跃表,没有的话再查总表,这也类似与缓存啦。

    3, 分块 - 数据库层面的优化,对程序是透明的,查询大数据只用找到相应块就行。


    • 分流三种:

    1,集群 - 将并发请求分配到不同的服务器上,可以是业务服务器,也可以是数据库服务器。

    2,分布式 - 分布式是把单次请求的多项业务逻辑分配到多个服务器上,这样可以同步处理很多逻辑,一般使用与特别复杂的业务请求。

    3,CDN - 在域名解析层面的分流,例如将华南地区的用户请求分配到华南的服务器,华中地区的用户请求分配到华中的服务器。


    • 横向扩展
    详解我的另一篇文章: mysql横向扩展

    展开全文
  • 数据库高并发高可用架构设计

    千次阅读 2018-11-17 21:26:04
    当总订单量达到300万的时候,我们就开始构思数据库高并发高可用设计了。 1、数据库采用主从部署方式 这是目前最简单的高可用方式。主从部署,主写从读,读写分离。当读操作大于写操作的时候,这种方案带来的性能...

    之前做过一个电商网站,因为前期涉及到的数据量比较小,并发也不是很高,所以只有一个主库。当然所有的小网站都是这么一步步发展过来的。

    当总订单量达到300万的时候,我们就开始构思数据库的高并发高可用设计了。

    1、数据库采用主从部署方式

    这是目前最简单的高可用方式。主从部署,主写从读,读写分离。当读操作大于写操作的时候,这种方案带来的性能提升是很明显的。

    主从复制:

    几乎所有的主流数据库都支持复制,这是进行数据库简单扩展的基本手段。下面以Mysql为例来说明,它支持主从复制,配置也并不复杂,只需要开启主服务器上的二进制日志以及在主服务器和从服务器上分别进行简单的配置和授权。Mysql的主从复制是依据主服务器的二进制日志文件进行的,主服务器日志中记录的操作会在从服务器上重放,从而实现复制,所以主服务器必须开启二进制日志,自动记录所有对于主数据库的更新操作,从服务器再定时到主服务器取得二进制日志文件进行重放则完成了数据的复制。主从复制也用于自动备份。

    读写分离:

    为保证数据库数据的一致性,我们要求所有对于数据库的更新操作都是针对主数据库的,但是读操作是可以针对从数据库来进行。大多数站点的数据库读操作比写操作更加密集,而且查询条件相对复杂,数据库的大部分性能消耗在查询操作上了。 主从复制数据是异步完成的,这就导致主从数据库中的数据有一定的延迟,在读写分离的设计中必须要考虑这一点。以博客为例,用户登录后发表了一篇文章,他需要马上看到自己的文章,但是对于其它用户来讲可以允许延迟一段时间(1分钟/5分钟/30分钟),不会造成什么问题。这时对于当前用户就需要读主数据库,对于其他访问量更大的外部用户就可以读从数据库。  

     

    数据库反向代理:

     

    在读写分离的方式使用主从部署方式的数据库的时候,会遇到一个问题,一个主数据库对应多台从服务器,对于写操作是针对主数据库的,数据库个数是唯一的,但是对于从服务器的读操作就需要使用适当的算法来分配请求啦,尤其对于多个从服务器的配置不一样的时候甚至需要读操作按照权重来分配。  对于上述问题可以使用数据库方向代理来实现。就像WEB反向代理服务器一样,Mysql Proxy同样可以在SQL语句转发到后端的Mysql服务器之前对它进行修改。 

    2、数据库垂直分割 

    上面那种情况是针对读操作远大写,且主库可以支撑写请求。如果单机数据库写请求已经很大,比如超过CPU消耗的50%以上,再去增加从服务器意义不是很大。因为数据在同步的时候,从服务器写请求也将达到50%以上,这时候剩余给查询的资源就会大大降低,整个读写架构的性能也会大幅度下降。

    这时候,就非常有必要对整个数据库架构进行升级,也就是垂直分割,

    最简单的做法就是将业务相对独立的模块进行独立分开部署,这主要是为了避免join无法操作,因为跨库将无法进行join。当根据业务模块对数据进行分库,之后在针对每个库进行主从同步,每个库只需要承担自己业务范围内的查询插入操作,大大提升了性能。 

    3、数据库水平分割

    如果业务分库之后,性能还是有瓶颈,那就对同一个业务库进行多库部署,每个库都存放数据,比如1库中有user表,2库中也有user表,每个库的数据不一样。当要对用户进行增删改查操作时,要先进行路由计算,比如对userId进行路由计算,具体这个用户应该落到那个库中。

    4、数据表的垂直和水平分割

    4.1、对表进行垂直分割,大表变小表,例如一张表的字段达到100多个之后,其中只有部分的字段是经常用到,剩下部分的字段是比较少被查询到的,这时候就可以将一张表拆分成多张表,当然分开的表也要进行数据关联,比如用户表拆分成用户信息表1,信息表2,每张表中都要有userId用来保证相关性。这时候单张表的数据量下降了,单表查询的性能也随之而然上升

    4.2、对表进行水平分割。当一张表的数据量达到1000万,或者几千万的时候,数据的查询写入性能会很差,这时候就需要对表进行水平分割。水平分割比较简单,一般根据一定的路由算法进行定位新的表,常用的就是对id进行取余操作,根据余数来确定数据是哪张表。 

    5、数据库的高可用 

    之前讲到数据库的高可用,就是部署主从服务,

    5.1、当主服务器挂掉之后,手动切换到从服务器。总所周知,手动切换的速度比较慢,要进行配置文件的修改,然后重启web服务器。

    5.2、从库中其中一台挂掉之后,部分读取这台从库的请求将会得不到响应。

    自动化的思路就是从库检测到主库挂掉之后,自动顶替上去。以及从库部分挂掉之后,这些从库将收不到任何请求操作,请求只会去存活的从库上查询。

    先来看从库高可用结构图:

    å¾çæè¿°

    如上图所示,web服务器将不再直接连接从库DB2和DB3,而是连接LVS负载均衡,由LVS连接从库。这样做的好处是LVS能自动感知从库是否可用,从库DB2宕机后,LVS将不会把读数据请求再发向DB2。同时DBA需要增减从库节点时,只需独立操作LVS即可,不再需要项目组更新配置文件,重启服务器来配合。

    再来看主库高可用结构图:

    å¾çæè¿°

    如上图所示,web服务器将不再直接连接主库DB1,而是连接KeepAlive虚拟出的一个虚拟ip,再将此虚拟ip映射到主库DB1上,同时添加DB_bak从库,实时同步DB1中的数据。正常情况下web还是在DB1中读写数据,当DB1宕机后,脚本会自动将DB_bak设置成主库,并将虚拟ip映射到DB_bak上,web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间,就能完成主数据库服务恢复。

    组合上面的结构,得到主从高可用结构图:

    å¾çæè¿°

    数据库高可用还包含数据修补,由于我们在操作核心数据时,都是先记录日志再执行更新,加上实现了近乎实时的快速恢复数据库服务,所以修补的数据量都不大,一个简单的恢复脚本就能快速完成数据修复。

    6、数据分级

    支付系统除了最核心的支付订单表与支付流水表外,还有一些配置信息表和一些用户相关信息表。如果所有的读操作都在数据库上完成,系统性能将大打折扣,所以我们引入了数据分级机制。

    我们简单的将支付系统的数据划分成了3级:

    第1级:订单数据和支付流水数据;这两块数据对实时性和精确性要求很高,所以不添加任何缓存,读写操作将直接操作数据库。

    第2级:用户相关数据;这些数据和用户相关,具有读多写少的特征,所以我们使用redis进行缓存。

    第3级:支付配置信息;这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

    使用本地内存缓存有一个数据同步问题,因为配置信息缓存在内存中,而本地内存无法感知到配置信息在数据库的修改,这样会造成数据库中数据和本地内存中数据不一致的问题。

    为了解决此问题,可以开发了一个高可用的消息推送平台,当配置信息被修改时,我们可以使用推送平台,给支付系统所有的服务器推送配置文件更新消息,服务器收到消息会自动更新配置信息,并给出成功反馈。

    展开全文
  • 数据库并发解决方案

    千次阅读 2012-12-13 20:42:52
    在如今分布式、高并发、各种负载纵横天下的时代,支持高访问量成为检验一个系统合不合格的重要标准,然而我们除了在运算过程中要求系统更加效率外,在最终的数据存储过程中也希望其能够准确。 针对如何解决多...

    在如今分布式、高并发、各种负载纵横天下的时代,支持高访问量成为检验一个系统合不合格的重要标准,然而我们除了在运算过程中要求系统更加效率外,在最终的数据存储过程中也希望其能够准确。


    针对如何解决多线程并发产生的脏数据问题,本文简单列举一些常见案例及应对措施。


    案例一:

    本地起10个线程,分别执行10次,对数据库的一条记录的sum字段(初始值为0)+1操作,中间的业务逻辑我们忽略掉,如何保证执行完毕后sum的值为100?

    表结构:


    字段名 字段类型 可空 字段描述 使用备注
    ID BIGINT(20) N 主键ID 无业务含义
    SUM NUMBER(20) N 金额 初始值为0


    解决措施:乐观锁机制,利用数据库自身的事务来解决问题,update 表 set sum=sum+#increment#   where id=#id#,适用于一些只更新数量、金额的场景。

    尽量不要采用在后台计算一个最终的sum值,然后通过 update 表 set sum=#sum#  where id=#id#,因为此时在读与写的时间间隔里,很有可能其它的线程已经读过或操作过


    案例二:

    买家操作一笔订单,执行确认收货,假如同一笔订单打开了两个窗口,开始时在一个窗口确认成功,后来在另一个窗口又点了一次,此时应如何解决?


    解决措施:在执行“买家确认收货”操作时,我们通常会首先查出这笔订单,判断当前操作用户是否有执行权限,同时判断当前订单的状态是否是“等待买家确认收货”,。。。,如果满足这些前置条件,才允许后面的业务操作,更新数据库。

    当然,存在另一种可能,如果是通过自动化脚本操作呢?两次操作几乎同时执行,也就是说,两次的前置校验都能顺利通过(因此那时,数据库记录还没来的及更新),此时一个好的解决方案,操作时增加前置条件,比如确认收货的前置条件是“等待买家确认收货”,如果此时订单的状态变成了成功就无法操作。

    update 订单表 set  status="交易成功"  where id=#orderId# and status="等待买家确认收货"

    这样,第二次操作sq条件不满足,也就避免执行两次买家确认收货操作。


    案例三:

    增加前置条件是一个不错的解决方案,但是,不是每个业务都会有前置条件,或者说前置条件不明确,无规则,此时就如何解决?


    字段名 字段类型 可空 字段描述 使用备注
    ID BIGINT(20) N 主键ID 无业务含义
    SUM NUMBER(20) N 金额 初始值为0
    attribute_cc INT(11) N 用于为attribute加锁  

    解决措施:可以借助memcache用到的一种同步机制(CAS),比较并交换,在数据库表增加一个冗余字段,每次操作都会自动+1

    执行业务时,首先会从数据库读取该字段信息,更新业务数据时,会自动比较attribute_cc的值是否有变化,如果有变化,表示刚才读的信息已变化过,需要重新操作。

     




    展开全文
  • 现代系统都是数据驱动...都是经过各个应用计算之后的数据,直接操作还不是很方便,所以我们的数据都是通过应用存储到数据库中的,那么问题来了,假如系统高并发运行,同时又两条数据同时执行insert会出现什么,后执...
  • 未来的憧憬 对于高并发高访问的Web应用程序来说,数据库存取瓶颈一直是个令人头疼的问题。大家都知道,当有一个request过来后,web服务器交给app服务器,app处理并从db中存取相关数据,但db存取的花费是相当高昂的...
  • 对于高并发高访问的Web应用程序来说,数据库存取瓶颈一直是个令人头疼的问题。特别当你的程序架构还是建立在单数据库模式,而一个数据池连接数峰值已经达到500的时候,那你的程序运行离崩溃的边缘也不远了。很多小...
  • 数据库学习:高并发数据库设计

    万次阅读 2017-11-13 13:21:19
    数据库学习:高并发数据库设计 随着乐视硬件抢购的不断升级,乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环,保证用户快速稳定的完成支付尤为重要。所以在15年11月,我们对整个支付...
  • 大数据量、高并发数据库的高性能、高可用性解决方案:1.拆表:大表拆小表(垂直拆,水平拆;分表,分区partition,分片sharding),可以在应用层实现,也可以在     大数据量、高并发数据库的高性能、高可用性...
  • 高并发访问数据库问题

    万次阅读 2016-03-23 16:26:38
    在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节: 使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高...
  • 随着系统访问量的增加,QPS越来越数据库磁盘容量不断增加,一般数据库服务器的QPS在800-1200的时候性能最佳,当超过2000的时候sql就会变得很慢并且很容易被请求打死,而单表数据量过大也会导致数据库执行sql很慢...
  • 1、最初级的缓存不一致问题以及解决方案 问题:先修改数据库,再删除缓存,如果删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据出现不一致 解决思路: 先删除缓存,再修改数据库,如果删除缓存...
  • 高并发数据库设计

    千次阅读 2018-09-17 20:12:58
    数据库高可用还包含数据修补,由于我们在操作核心数据时,都是先记录日志再执行更新,加上实现了近乎实时的快速恢复数据库服务,所以修补的数据量都不大,一个简单的恢复脚本就能快速完成数据修复。 五、数据分级...
  • 在数据量很大的情况下,数据层(缓存,数据库)涉及数据的水平扩展,将原本存储在一台服务器上的数据(缓存,数据库)水平拆分到不同服务器上去,以达到扩充系统性能的目的。拆分方式:按照范围水平拆分每一个数据...
  • 高并发解决方案之一 ——负载均衡

    万次阅读 多人点赞 2018-04-15 21:52:15
    由于Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等,在3w以上的高并发环境下,ngnix处理...
  • 数据库并发控制

    千次阅读 2018-06-01 10:56:59
    数据库是一个共享资源,可以供多个用户共享使用. 以事务为单位管理用户程序的并发访问,提高资源共享效率。数据并发性意味着多个用户可以同时访问数据。 并发访问存在冲突吗?如何控制? 事务:用户定义的一个数据库...
  • JavaWeb 并发编程 与 高并发解决方案

    万次阅读 多人点赞 2018-09-12 03:41:00
    在这里写写我学习到和自己所理解的 Java高并发编程和高并发解决方案。现在在各大互联网公司中,随着日益增长的互联网服务需求,高并发处理已经是一个非常常见的问题,在这篇文章里面我们重点讨论两个方面的问题,一...
  • 高并发优化方案

    千次阅读 2018-11-15 21:37:30
    高并发常见优化方案 数据库缓存: 缓存数据是为了让客户端很少甚至不访问数据库,减少磁盘IO,提高并发量,提高应用数据的响应速度。 CDN加速: CDN的全称是Content Delivery Network,CDN系统能够实时地根据...
  • 前两天一个客户找我洽谈建设一个体育活动赛事组织(地级市体育总会)的网站,除展示资讯信息外,网站有一个...我缺少高并发写入数据库的开发经验,对于这种数量级的写入数据库开发方案,请大家给一些指导意见,谢谢!
  • java解决高并发数据库连接池配置

    千次阅读 2019-03-19 02:34:46
    最近一直在处理高并发的问题,大致情况是这样的:大概有五六千人会在中午十二点同时访问网站,操作数据库,导致服务器崩溃。对于频繁修改数据的这种情况,例如:用户要抢商品,且抢完后要刷新看自己抢的商品,这会...
  • 一,用户下单购买商品的情况下,如果有多个人同时下单,减除库存的情况下,如果遇到了减去库存的并发问题,这个时候应该怎么处理呢? 传统的业务流程场景下,处理流程是这样的:1,库存查询,通过dao查询商品库存,...
  • 同时减少数据库的访问次数。 3.使用集群的方式来解决,单台服务器性能的问题 4.使用负载均衡模式,来让每一个服务器资源进行合理的利用 5.资源隔离(springcloud中有两种资源隔离方式--线程池和信号量) 6...
  • 所谓库存超卖是指在并发量大的情况下,卖出去的商品数量比实际库存多,如秒杀系统1、超卖举例:总库存:4个商品 ; 请求人:a、1个商品 b、2个商品 c、3个商品伪代码:select 库存数量 from 库存表 where 商品id=...
  • 互联网的很多业务,特别是在高并发的场景下,基本都是读远远大于写,如果数据库读和写的压力都同在一台主机上,这显然不太合理。 于是,把一台数据库主机分为单独的一台写主库(主要负责写操作),而把读的数据库...
  • 这种方案在不需要考虑高并发得去写缓存,高并发得读写缓存时,是不会有问题,但是如果是在高并发场景下,要保证缓存和数据库的一致性,至少需要解决以下问题: 高并发写时的数据不一致问题 高并发读写时,请求...
  • 高并发处理方案

    千次阅读 2018-02-17 19:07:18
    高并发和大流量:并发:在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行。但是我们所说的并发是:...
  • 高并发的系统下,对数据库进行更行时,如果没有防重机制做拦截,就会导致数据被更新多次,从而影响更新后程序的后续操作。 解决方案方案一: 方案详情:加锁查询拦截,在更新前,加锁(分布式系统用分布式锁...
  • 所谓库存超卖是指在并发量大的情况下,卖出去的商品数量比实际库存多,如秒杀系统。参考文章 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 201,059
精华内容 80,423
关键字:

数据库高并发方案