高并发下如何对数据库进行更新操作

问题:

        在高并发的系统下,对数据库进行更行时,如果没有防重机制做拦截,就会导致数据被更新多次,从而影响更新后程序的后续操作。


解决方案:

方案一:

方案详情:加锁查询拦截,在更新前,加锁(分布式系统用分布式锁、也可用数据库锁等),查询需要更新的数据是否存在且未被                    更新,根据查询结果做更新操作,更新后释放锁;

适用情况:对数据需要进行多次更新,或多个中间状态都可以对数据进行操作;

方案优势:保证数据更新的一致性;

方案缺点:系统性能消耗大,锁机制影响系统的效率;

伪代码示例:

//本示例以分布式系统为例,单系统下直接使用Lock或synchronized锁即可
eg:

    // 用redis加锁
    redis.set(key, value);

    // 查询要更新的数据
    int result = select * from table where 条件;

    // 更新操作
    if(result == 1){
        //判断数据是否已经被更新
        if(未被更行){
            //更新
            update table set XXX=x2 where 条件;
        }
    }

    // 释放锁
    redis.del(key);

方案二(推荐):

方案详情:数据库层面拦截,直接在更新数据时带状态更新数据,根据更新后成功与否做后续操作;

适用情况:明确知道更新数据前或后的状态,且不会在更新时多次发生状态变化,保证前后一致性;

方案优势:简单,保证数据更新的一致性,且对效率影响较小;

方案缺点:系统性能消耗大,锁机制影响系统的效率;

伪代码示例:

// 数据库层的sql语句限制即可
int result = update table set 更新的内容 where 原数据的内容  != 更新的内容;

//  更新成功
if(result == 1){

    // 执行更新成功后的操作
    
}else{

    // 执行更新失败后的操作

}

            
原因:

     高并发的情况下,多个请求对同一条数据进行更新操作,易导致数据被多次更新,影响数据库的正确性;

 

相关知识点:

      1.sql语句;

      2.分布式锁;


代码示例:

     如解决方案中的伪代码示例。

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
⾼并发数据库设计 随着乐视硬件抢购的不断升级,乐视集团⽀付⾯临的请求压⼒百倍乃⾄千倍的暴增。作为商品购买的最后⼀环,保证⽤户快速稳定的完成⽀ 付尤为重要。所以在15年11⽉,我们对整个⽀付系统进⾏了全⾯的升级,使之具备了每秒稳定处理10万订单的能⼒。为乐视⽣态各种形式 的抢购秒杀活动提供了强有⼒的⽀撑。 ⼀、库分表 ⼀、库分表 在,memcached等缓存系统盛⾏的互联⽹时代,构建⼀个⽀撑每秒⼗万只读的系统并不复杂,⽆⾮是通过⼀致性哈希扩展缓存节点,⽔平 扩展web服务器等。⽀付系统要处理每秒⼗万笔订单,需要的是每秒数⼗万的更新操作(insert加update),这在任何⼀个独⽴数据库上都 是不可能完成的任务,所以我们⾸先要做的是对订单表(简称order)进⾏分库与分表。 在进⾏数据库操作时,⼀般都会有⽤户ID(简称uid)字段,所以我们选择以uid进⾏分库分表。 分库策略我们选择了"⼆叉树分库",所谓"⼆叉树分库"指的是:我们在进⾏数据库扩容时,都是以2的倍数进⾏扩容。⽐如:1台扩容 到2台,2台扩容到4台,4台扩容到8台,以此类推。这种分库⽅式的好处是,我们在进⾏扩容时,只需DBA进⾏表级的数据同步,⽽不需 要⾃⼰写脚本进⾏⾏级数据同步。 光是有分库是不够的,经过持续压⼒我们发现,在同⼀数据库中,对多个表进⾏并发更新的效率要远远⼤于对⼀个表进⾏并发更新,所以我 们在每个分库中都将order表拆分成10份:order_0,order_1,….,order_9。 最后我们把order表放在了8个分库中(编号1到8,分别对应DB1到DB8),每个分库中10个分表(编号0到9,分别对应order_0到 order_9),部署结构如下图所⽰: 根据uid计算数据库编号: 数据库编号 = (uid / 10) % 8 + 1 根据uid计算表编号: 表编号 = uid % 10 当uid=9527时,根据上⾯的,其实是把uid分成了两部分952和7,其中952模8加1等于1为数据库编号,⽽7则为表编号。所以 uid=9527的订单信息需要去DB1库中的order_7表查找。具体算法流程也可参见下图: 有了分库分表的结构与算法最后就是寻找分库分表的实现⼯具,⽬前市⾯上约有两种类型的分库分表⼯具: 1. 客户端分库分表,在客户端完成分库分表操作,直连数据库 2. 使⽤分库分表中间件,客户端连分库分表中间件,由中间件完成分库分表操作 这两种类型的⼯具市⾯上都有,这⾥不⼀⼀列举,总的来看这两类⼯具各有利弊。客户端分库分表由于直连数据库,所以性能⽐使⽤分库分 表中间件⾼15%到20%。⽽使⽤分库分表中间件由于进⾏了统⼀的中间件管理,将分库分表操作和客户端隔离,模块划分更加清晰,便于 DBA进⾏统⼀管理。 我们选择的是在客户端分库分表,因为我们⾃⼰开发并开源了⼀套数据层访问框架,它的代号叫"芒果",芒果框架原⽣⽀持分库分表功 能,并且配置起来⾮常简单。 芒果主页:mango.jfaster.org 芒果源码:github.com/jfaster/mango ⼆、订单 ⼆、订单ID( (uid维度) 维度) 订单系统的ID必须具有全局唯⼀的特征,最简单的⽅式是利⽤数据库的序列,每操作⼀次就能获得⼀个全局唯⼀的⾃增ID,如果要⽀持每秒 处理10万订单,那每秒将⾄少需要⽣成10万个订单ID,通过数据库⽣成⾃增ID显然⽆法完成上述要求。所以我们只能通过内存计算获得全 局唯⼀的订单ID。 领域最著名的唯⼀ID应该算是UUID了,不过UUID太长⽽且包含字母,不适合作为订单ID。通过反复⽐较与筛选,我们借鉴了Twitter的 Snowflake算法,实现了全局唯⼀ID。下⾯是订单ID的简化结构图: 上图分为3个部分: 1. 时间戳 这⾥时间戳的粒度是毫秒级,⽣成订单ID时,使⽤System.currentTimeMillis()作为时间戳。 1. 机器号 每个订单服务器都将被分配⼀个唯⼀的编号,⽣成订单ID时,直接使⽤该唯⼀编号作为机器号即可。 1. ⾃增序号 当在同⼀服务器的同⼀毫秒中有多个⽣成订单ID的请求时,会在当前毫秒下⾃增此序号,下⼀个毫秒此序号继续从0开始。⽐如在同⼀服务 器同⼀毫秒有3个⽣成订单ID的请求,这3个订单ID的⾃增序号部分将分别是0,1,2。 上⾯3个部分组合,我们就能快速⽣成全局唯⼀的订单ID。不过光全局唯⼀还不够,很多时候我们会只根据订单ID直接查询订单信息,这时 由于没有uid,我们不知道去哪个分库的分表中查询,遍历所有的库的所有表?这显然不⾏。所以我们需要将分库分表的信息添加到订单ID 上,下⾯是带分库分表信息的订单ID简化结构图: 我们在⽣成的全局订单ID头部添加了分库与分表的信息,这样只根据订单ID,我们也能快速的查询到

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值