高并发场景的几种处理方法

3 篇文章 0 订阅

        作为后端开发,高并发场景是一个绕不过去的坎,今天就来整理下常见的几种思路(暂时不考虑分布式的情况)

一.并发锁

        首先我们要知道高并发下会出现某一个时刻流量猛增,还有就是如果是抢购之类的库存类并发可能会导致超卖库存为负数之类的,对于并发锁来说主要是解决抢购超卖问题的,并不能很好的解决流量猛增给服务器带来的压力,有时候甚至会加重服务器的压力,所以我们并发量小及服务器配置比较高的时候可以用并发锁来处理,下面就介绍几种常用的并发锁

        1.synchronize(同步排它锁)

        这个对于java开发来说肯定不陌生,它可以让各个线程同步执行,缺点是极度的耗费性能,临时处理可以使用,经常使用的情况下不推荐

        2.数据库锁

        mysql数据库也是自带锁的,这种情况一般用行锁,不过这个会产生事务阻塞数据库,极度耗费性能,且容易造成死锁,一般在内部确定的极低的并发(一般就2个并发)的时候使用

        3.redis锁

        这个用的比较多,首先redis单进程且性能比较高,而且可以分布式实现,我们一般用set nx px 来实现

二.队列

        当我们的流量达到一定的程度,服务器无法负载了,则就需要进行流量消峰了,这时候我们队列就可以排上用场了,这时候我们我们可以把请求推到队列中,然后及时响应请求,至于并发结果我们可以在另一个页面接口或者发邮件展示,这个个方法的缺点就是不能直接获取到队列请求的结果,不过也算是比较优秀的一种方式了

三.预存队列

        上面我们提到了无法获取到队列请求的结果,有时候需要立刻展示的时候比较麻烦,这时候我们就可以倒转队列的消费者生产者了,先预先在队列中预存一定量的货物,让客户抢单请求来消费客户端的货物,这样就能通过是否从队列中取到货物来直接返回结果了,当前上面的请求都要注意好重复请求,重复下单的情况

  • 0
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在高并发场景下,分布式事务是必须的。在选择分布式事务时,需要考虑以下几个方面: 1. 数据一致性:分布式事务需要保证不同节点之间的数据一致性,因此需要选择一种能够保证数据一致性的分布式事务方案,如 2PC(两阶段提交协议)或 3PC(三阶段提交协议)、TCC(补偿事务)等。 2. 性能:分布式事务需要涉及到多个节点之间的通信和协调,因此需要选择一种性能较好的分布式事务方案,如基于消息队列的分布式事务、异步事务等。 3. 可扩展性:在分布式系统中,需要考虑系统的可扩展性,因此需要选择一种能够支持水平扩展的分布式事务方案,如基于分库分表的分布式事务。 4. 容错性:在分布式系统中,需要考虑节点故障的情况,因此需要选择一种能够保证容错性的分布式事务方案,如基于 Paxos 或 Raft 算法的分布式事务。 综上所述,分布式事务的选择需要综合考虑以上几个方面,选择一种适合自己业务场景的分布式事务方案,以保证系统的稳定性和可靠性。 ### 回答2: 在高并发场景下,分布式事务的选择是非常重要的。高并发场景通常由大量的用户请求和复杂的业务逻辑组成,需要保证系统的稳定性和数据的一致性。以下是几种常见的分布式事务选择: 1. 两阶段提交(2PC):这是一种经典的分布式事务协议,它通过协调者和参与者之间的消息进行事务的提交,保证分布式系统中所有节点的一致性。然而,2PC存在单点故障和阻塞问题,同时在网络不稳定的情况下可能导致长时间的等待,不适合高并发场景的使用。 2. TCC(Try-Confirm-Cancel):TCC是一种基于补偿的分布式事务解决方案,它将事务拆分为三个阶段(试验、确认、取消)。在高并发场景下,TCC通过使用乐观锁或幂等性操作来解决并发冲突的问题,提供较好的性能和可伸缩性。 3. 本地消息表:在高并发场景下,将分布式事务转变为本地事务,使用本地消息表来实现事务的异步化和解耦。通过将事务操作记录插入本地消息表,并使用消息队列来异步处理事务,可以提高系统的吞吐量和并发处理能力。 4. Saga模式:Saga模式是一种面向分布式事务的异步解决方案,它将复杂的分布式事务拆分为一系列的局部事务。每个局部事务通过记录其提交和补偿操作,以保证系统的一致性。在高并发场景下,Saga模式具有较好的性能和可伸缩性,但需要更多的系统设计和开发工作。 综上所述,在高并发场景下,选择适合的分布式事务解决方案是非常重要的。根据具体的业务需求和系统特点,我们可以选择2PC、TCC、本地消息表或Saga模式等解决方案,来保证系统的稳定性和数据的一致性。最终的选择应该综合考虑系统性能、可伸缩性和开发成本等因素。 ### 回答3: 高并发场景下的分布式事务选择是一个比较复杂的问题,需要综合考虑系统的性能、一致性和可靠性等多个因素。 在高并发场景下,传统的单机事务往往无法满足要求,因此需要采用分布式事务来处理大量并发请求。目前主流的分布式事务解决方案有两种:基于两阶段提交(2PC)协议和基于消息队列的异步处理。 基于2PC协议的分布式事务是传统的解决方案,通过事务协调者协调各个参与者的事务操作,实现分布式事务的一致性。但是2PC存在的问题是性能低下和可靠性不高。2PC协议需要进行同步的预提交、提交和回滚等操作,整个流程需要等待所有参与者的响应,这会导致事务的响应时间长,并发能力受到限制。同时,2PC的串行执行也对系统的可靠性提出了较高要求,一旦协调者宕机,整个事务将无法进行。 基于消息队列的异步处理是一种新的解决方案,它将事务操作封装为消息,通过消息队列来进行异步处理。参与者将事务消息发送至消息队列,由消息队列异步处理消息,保证事务的可靠性和一致性。通过将事务操作异步化,可以大大提高系统的并发能力和性能。而且,基于消息队列的解决方案对系统的可靠性要求较低,即使消息队列宕机,事务消息也可以通过存储进行恢复。 综上所述,在高并发场景下,基于消息队列的异步处理是更好的分布式事务选择。它能够提供较好的性能和可靠性,适应大规模并发的需求。但需要注意的是,选择分布式事务方案时需要根据实际需求综合考量各种因素,目前还有其他的解决方案,如基于补偿事务和Saga模式等,可以根据具体情况进行选择。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值