到底多大才算高并发?

定义:

    高并发(High Concurrency)是使用技术手段使系统可以并行处理很多请求。

 

关键指标:

-响应时间(Response Time)

-吞吐量(Throughput)

-每秒查询率QPS(Query Per Second)

-每秒事务处理量TPS(Transaction Per Second)

-同时在线用户数量

 

关键指标的维度:

-平均,如:小时平均、日平均、月平均

-Top百分数TP(Top Percentile),如:TP50、TP90、TP99、TP4个9

-最大值

-趋势

 

「并发」由于在互联网架构中,已经从机器维度上升到了系统架构层面,所以和「并行」已经没有清晰的界限。「并」(同时)是其中的关键。由于「同时」会引发多久才叫同时的问题,将时间扩大,又根据不同业务关注点不同,引申出了引申指标。

引申指标:

-活跃用户数,如:日活DAU(Daily Active User)、月活MAU(Monthly Active Users)

-点击量PV(Page View)

-访问某站点的用户数UV(Unique Visitor)

-独立IP数IP(Internet Protocol)

-日单量

 

二、多大算高并发

    这个问题的答案不是一个数字。来看两个场景:

场景1:

    木头同学去一家创业公司面试。这个公司做的产品还没有上线,面试官小熊之前就职过公司的产品都没有什么量。

小熊:“有高并发经验吗?”

木头:“我们服务单机QPS2000+,线上有4台机器负载均衡。”

这时候小熊心里的表情大概是:

 

    但是如果小熊就职的公司是美团之类的。那这这时候小熊心里的表情大概是:

 

场景2:

固态硬盘SSD(Solid State Disk)说:我读取和写入高达 1000MB/秒

mysql说:我单机TPS10000+

nginx说:我单机QPS10W+

静儿说:给我一台56核200G高配物理机,我可以创建一个单机QPS1000W

 

    不在同一维度,没有任何前提,无法比较谁更牛。“我的系统算不算高并发?”这个问题就如同一个女孩子爱问的问题:“我美不美?”

 

三、高并发的本质

    俗话说:「没有对比就没有伤害」。算不算高并发,这个问题的答案需要加对比和前提。

 

对比包括:

-业界:在业界同类产品中并发量处于什么位置。举个栗子?,美团外卖的日单量是千万级别,一个系统日单量在百万,虽然差一个数量级,但是相比大多数公司已经很不错。

-自身:在自身系统中,并发问题是否已经是系统的瓶颈?如果是,这么这个瓶颈怎么打破?如果不是,那当初架构设计的时候是怎么保证并发不是问题的?(别告诉我:是通过系统没有访问量来保证的[擦汗])。

 

前提包括:

-业务复杂度:举个栗子?,访问百度首页的时间基本就是看自己家的网速,通常情况下都是点一下就看到结果了。而扫描二维码支付,通常需要等很久,虽然这可能已经是业界最牛的支付公司出品了。

-配置:用高配物理机得出的数据和最老最低配的虚拟器上的出来的结果是无法比较的。通常的配置有:cpu、内存、磁盘、带宽、网卡

 

    高并发的本质不是「多大算高并发」的一个数字,而是从架构上、设计上、编码上怎么来保证或者解决由并发引起的问题。当别人问你:“做过高并发吗?”回答者完全可以描述自己系统的各项指标,然后开始叙述自己对系统中对预防、解决并发问题作出的思考和行动。

 

四、总结

    过程大于结果,方向大于方法。

 

相关阅读:

程序常用的设计技巧

美团分布式服务通信框架及服务治理系统OCTO

学会用数据说话-分布式锁究竟可以多少并发?

大话高可用

《怎样在工作环境中提高自己的影响力?》

《演讲稿:新人培养之道》

《自动化管理之新人培养》

《代码整洁之道--边界》

《「苦练基本功」超级大佬推荐工程师必看的书感悟》

关于作者

一线开发十二年,有日本东京和美国硅谷研发经验。有百余项技术发明专利,目前任美团点评技术专家。

技术公众号「编程一生」,公众号头像即为作者本人。

<think>嗯,用户问的是在高并发场景中使用分布式锁时,解锁需要注意什么。首先,我需要回忆一下分布式锁的基本概念和常见问题。分布式锁用于协调个进程或服务对共享资源的访问,防止并发问题。解锁环节如果处理不当,可能会导致死锁或者资源竞争,所以确实需要特别注意。 首先,解锁的时候必须确保只有锁的持有者才能释放锁。比如,如果某个客户端A获取了锁,执行完操作后,另一个客户端B误删了A的锁,那就会出问题。这时候,通常需要在锁中保存客户端唯一标识,比如UUID,删除时验证是否匹配。 然后,原子性操作的问题。比如在Redis中,解锁的时候需要判断是否当前客户端持有锁,如果是再删除。这两个操作必须原子化,否则在判断之后,删除之前,锁可能过期被其他客户端获取,导致误删。所以需要用Lua脚本来保证原子性。 接下来是锁的超时时间设置。如果锁没有设置合理的超时时间,客户端崩溃后,锁无法释放,导致死锁。但设置太短的话,可能在任务未完成时锁就自动释放,其他客户端获取锁,导致数据不一致。可能需要引入自动续期机制,比如Redisson的看门狗。 还有,解锁时要注意网络延迟和时钟不同步的问题。比如,客户端A获取锁,执行时间较长,锁过期自动释放,客户端B获取锁,此时A执行完毕去解锁,可能会误删B的锁。这种情况需要客户端在操作完成后检查锁是否仍然属于自己,或者在解锁时使用版本号等机制。 另外,解锁失败后的处理也很重要。比如,如果解锁失败,应该记录日志,触发告警,或者进行重试,但需要注意重试次数和间隔,避免雪崩效应。 还需要考虑分布式锁的实现方式,比如Redis、Zookeeper等,不同的实现可能解锁时的注意事项有所不同。比如Zookeeper使用的是临时节点,客户端断开连接后节点自动删除,但需要处理会话超时的情况;而Redis依赖超时机制,需要处理锁过期和续期的问题。 可能用户在使用分布式锁时,没有正确实现这些细节,导致生产环境中出现偶发的数据不一致或死锁问题。需要强调每个步骤的关键点,并提供具体的解决方案,比如使用Lua脚本、唯一标识、自动续期等。 最后,总结的时候应该分点列出,确保用户能清晰理解每个注意事项,并提供实际例子或最佳实践,帮助用户正确应用。</think>在高并发场景中使用分布式锁时,解锁环节需要特别注意以下几个核心问题(以Redis分布式锁为例): --- ### 一、必须验证锁的持有者身份 **问题场景**: 客户端A获取锁后,若未验证身份直接解锁,可能导致其他客户端误删锁(例如网络延迟导致A的锁已超时释放,但A仍在执行解锁操作)。 **解决方案**: 1. 加锁时写入唯一标识(如UUID+线程ID) ```bash SET lock_key "客户端A:UUID123" EX 30 NX ``` 2. 解锁时通过Lua脚本原子性验证并删除 ```lua if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end ``` --- ### 二、锁超时与业务执行时间的平衡 **问题场景**: 若锁超时时间(TTL)设置过短,业务未执行完锁已自动释放,导致其他客户端获取锁后产生数据竞争。 **解决方案**: 1. 合理评估业务最耗时,设置TTL = 业务预估时间 + 缓冲时间 2. **自动续期机制**(如Redisson的Watch Dog) ```java RedissonClient redisson = Redisson.create(); RLock lock = redisson.getLock("lock_key"); lock.lock(); // 默认启动Watch Dog,每10秒续期一次 ``` --- ### 三、解锁操作的原子性 **问题场景**: 非原子操作可能导致判断锁归属与删除锁之间出现锁状态变化(如GC停顿导致锁过期后被其他客户端获取)。 **解决方案**: 必须通过Lua脚本或Redis事务保证原子性(推荐Lua脚本)。 --- ### 四、锁释放后的通知机制 **问题场景**: 高并发场景下,锁释放后量客户端立即重试抢锁,可能引发“惊群效应”。 **解决方案**: 结合发布订阅机制(如Redis的`PUBLISH/SUBSCRIBE`),锁释放后通知等待客户端有序获取锁。 --- ### 五、异常情况处理 1. **网络分区(脑裂)** 使用RedLock算法(需部署个独立Redis实例),过半节点加锁成功才算有效。 2. **客户端崩溃** 必须设置TTL兜底,防止死锁(即使未正常解锁,锁也会自动过期)。 --- ### 总结最佳实践 | 步骤 | 关键操作 | 风险规避措施 | |------------|------------------------------|----------------------------------| | 加锁 | 写入唯一标识 + 设置TTL | 防止死锁和误删 | | 解锁 | Lua脚本验证身份 + 原子删除 | 避免锁归属权误判 | | 续期 | Watch Dog自动续期 | 防止业务未完成锁超时 | | 容错 | RedLock节点部署 | 降低脑裂风险 | --- **示例错误案例**: 某电商系统在扣减库存时,因未校验锁持有者身份,导致用户A的订单未完成,锁被用户B提前释放,最终引发超卖问题。 **正确实现**应始终遵循:**加锁带身份、解锁需验证、超时要续期、异常有兜底**。
评论 18
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值