- 综合排序
- 最热优先
- 最新优先
- 来自专栏坚毅的PHP
mysql 高并发更新计数问题
问题：功能为链接的点击计数，其他两个计数更新 还有两个内容表的插入，只插入链接对应的id，分4个库，共128个表，mysql每天有5000万次插入和5000万次更新操作，压力负载过大，需要想方案，对计数更新做合并处理
2.6K80发布于 2018-03-20 - 来自专栏全栈程序员必看
利用Redis实现高并发计数器
业务需求中经常有需要用到计数器的场景：譬如一个手机号一天限制发送5条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。使用Redis的Incr自增命令可以轻松实现以上需求。 ReqJson.error(CarError.ONLY_5_TIMES_A_DAY_CAN_BE_FOUND)); return; } //没超过限制，业务逻辑…… } 每次调用接口之前，先获得下计数器自增后的值
2.3K20编辑于 2022-09-01 - 来自专栏搜云库技术团队
高并发文章浏览量计数系统设计
但无论如何，后端应该是可以避免这样的BUG，即使某用户短时间内请求两次或者多次，也应该只增加一次浏览量计数。 由于最近在学习高并发方面的知识，所以这里也考虑一下，如果一个高并发的文章浏览量计数系统，应该如何设计？ 先来理一下需求。 9、尽可能优化性能，满足多个用户的高并发需求。 设计思路 如果要满足高并发，那首先考虑用异步和缓存。所以考虑使用多线程加Redis的解决方案。 后记 虽然最后权衡了并发量和复杂性，我的个人网站的文章浏览逻辑并没有完全按照上述设计思路来做，但上述思路是我对一个高并发文章浏览量计数系统设计的思考，以后如果有机会可以写一个开源的版本。 Java并发编程75道面试题及答案 MQ消息队列应用场景比较介绍 动图+源码+总结：数据结构执行过程及原理 我们来谈下高并发和分布式中的幂等处理 大型分布式系统中的缓存架构 美团面试经历，贡献出来一起学习
3.3K22发布于 2019-10-17 - 来自专栏路人甲Java
java高并发系列 - 第32天：高并发中计数器的实现方式有哪些？
本文主要内容 4种方式实现计数器功能，对比其性能 介绍LongAdder 介绍LongAccumulator 需求：一个jvm中实现一个计数器功能，需保证多线程情况下数据正确性。 java高并发系列目录 1.java高并发系列-第1天:必须知道的几个概念 2.java高并发系列-第2天:并发级别 3.java高并发系列-第3天:有关并行的两个重要定律 4.java高并发系列 - 8.java高并发系列 - 第8天:线程组 9.java高并发系列 - 第9天:用户线程和守护线程 10.java高并发系列 - 第10天:线程安全和synchronized关键字 11.java高并发系列 19.java高并发系列 - 第19天：JUC中的Executor框架详解1 20.java高并发系列 - 第20天：JUC中的Executor框架详解2 21.java高并发系列 -第21天：java 27.java高并发系列 -第27天：实战篇，接口性能提升几倍原来这么简单 28.java高并发系列 -第28天：实战篇，微服务日志的伤痛，一并帮你解决掉 29.java高并发系列 -第29天：高并发中常见的限流方式
2K10发布于 2019-12-10 - 来自专栏猫头虎博客专区
高并发幂等计数器的设计与实现
高并发幂等计数器的设计与实现 摘要 本文探讨了如何实现一个高并发、幂等的计数器服务，该服务用于处理外部的 inc 请求以增加特定视频的播放计数。 这样的设计不仅确保了高并发处理能力，还实现了请求的幂等性。 引言 在分布式系统中，高并发和幂等性是两个非常关键的问题。本文将探讨如何实现一个高并发、幂等的计数器服务。 问题描述: 高并发幂等计数器题目 问题描述： 1．实现一个计数器服务 2．服务接收外部的 inc 请求，每个请求具有全局唯一 request id 和视频 id 3．因为网络和重试的原因，请求可能会重复的到达 这样，我们就得到了一个高并发、幂等的计数器服务。 总结 通过使用 Redis 进行幂等性检查，以及使用 MySQL 进行持久化存储，我们成功地实现了一个高并发、幂等的计数器服务。
56410编辑于 2024-04-09 - 来自专栏码农编程进阶笔记
高并发实战：海量数据的计数器要如何实现？
那么，面临着高并发、大数据量、数据强一致要求的挑战，微博的计数系统是如何设计和演进的呢？你又能从中借鉴什么经验呢？ 支撑高并发的计数系统要如何设计 刚开始设计计数系统的时候，微博的流量还没有现在这么夸张，我们本着 KISS（Keep It Simple and Stupid）原则，尽量将系统设计的简单易维护，所以，我们使用 而信息流的访问量巨大，仅仅靠数据库已经完全不能承担如此高的并发量了。 讲到这里，我其实已经告诉你一个支撑高并发查询请求的计数系统是如何实现的了。 在经过了上面这些优化之后，我们的计数服务就可以支撑高并发大数据量的考验，无论是在性能上、成本上和可用性上都能够达到业务的需求了。
35110编辑于 2025-03-17 - 来自专栏nginx
高并发场景下Redis精确计数与时间窗口过期方案实战
高并发场景下Redis精确计数与时间窗口过期方案实战 引言 在实时数据处理系统中，我们经常需要统计某个事件在特定时间窗口内的发生次数，例如： 统计用户每小时访问次数 限制设备每分钟请求频率 广告曝光按小时去重计数 这类需求通常面临两个核心挑战： 高并发计数：多台服务器同时读写同一个计数器 精确时间窗口：数据到点自动过期，避免累积 本文将详细介绍如何基于 Redis 实现高性能、高可用的计数方案，并提供完整的Java 一、Redis计数方案选型 1.1 为什么选择Redis？ 方案 QPS 数据一致性 实现复杂度 数据库+事务 ~1K 强一致 高 本地缓存 ~100K 最终一致 中 Redis原子操作 50K+ 强一致 低 Redis的单线程模型天然适合计数场景，提供INCR 精确到小时的时间窗口控制 分布式环境下的强一致性 最佳实践建议： 生产环境优先选择Lua脚本方案 对于超高并发场景（如双11），可增加本地缓存层 定期检查Redis内存使用情况 完整代码示例已上传GitHub
30110编辑于 2025-11-15 - 来自专栏DevOps
高并发系统架构设计之实战篇34：计数系统设计之计数器设计
引言 在之前的课程中，我分别从数据库、缓存、消息队列和分布式服务化的角度，带你了解了面对高并发的时候要如何保证系统的高性能、高可用和高可扩展。 那么，面临着高并发、大数据量、数据强一致要求的挑战，微博的计数系统是如何设计和演进的呢？你又能从中借鉴什么经验呢？ 而信息流的访问量巨大，仅仅靠数据库已经完全不能承担如此高的并发量了。 讲到这里，我其实已经告诉你一个支撑高并发查询请求的计数系统是如何实现的了。 在经过了上面这些优化之后，我们的计数服务就可以支撑高并发大数据量的考验，无论是在性能上、成本上和可用性上都能够达到业务的需求了。
82211编辑于 2024-03-29 - 来自专栏架构专题
没有预热，不叫高并发，叫并发高
大家都知道，高并发系统有三把斧子：缓存、熔断和限流。但还有一把斧子，经常被遗忘在角落里，郁郁不得志，那就是预热。 ? 现象举例 先说两个现象。这些现象，只能在并发高的系统中出现。 一、DB重启后，瞬间死亡 一个高并发环境下的DB，进程死亡后进行重启。由于业务处在高峰期间，上游的负载均衡策略发生了重分配。刚刚启动的DB瞬间接受了1/3的流量，然后load疯狂飙升，直至再无响应。 当服务重新加入集群时，却发生了大量高耗时的请求，在请求量高的情况下，甚至大批大批的失败。 引起的原因大概可以归结于： 1、服务启动后，jvm并未完全准备完毕，JIT未编译等。 当系统长期处于低水位的情况下，流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。
3.2K21发布于 2019-07-10 - 来自专栏咖啡拿铁
Java并发计数器探秘
前言 一提到线程安全的并发计数器，AtomicLong 必然是第一个被联想到的工具。Atomic* 一系列的原子类以及它们背后的 CAS 无锁算法，常常是高性能，高并发的代名词。 本文将会阐释，在并发场景下，使用 AtomicLong 来充当并发计数器将会是一个糟糕的设计，实际上存在不少 AtomicLong 之外的计数器方案。 无论在 Jdk1.7 还是 Jdk1.8 中，Atomic* 的开销都是很大的，主要体现在： 高并发下，CAS 操作可能会频繁失败，真正更新成功的线程占少数。 底层指令的开销不见得很低，无论是 LOCK XADD 还是 LOCK CMPXCHG，想深究的朋友可以参考 instruction_tables ，（这一点可能有点钻牛角尖，但不失为一个角度去分析高并发下可行的优化 关注整体性能，CounterBenchmark.rw 是对一组场景的整合打分，可以发现，在我们模拟的高并发计数器场景下，1.8 的 LongAdder 获得整体最低的延迟 98 ns，相比性能最差的 Jdk1.7
1.3K20发布于 2019-10-13 - 来自专栏Kirito的技术分享
Java并发计数器探秘
前言 一提到线程安全的并发计数器，AtomicLong 必然是第一个被联想到的工具。Atomic* 一系列的原子类以及它们背后的 CAS 无锁算法，常常是高性能，高并发的代名词。 本文将会阐释，在并发场景下，使用 AtomicLong 来充当并发计数器将会是一个糟糕的设计，实际上存在不少 AtomicLong 之外的计数器方案。 相关面试题： 单机场景下，有比 AtomicLong 更高效的并发计数器方案吗？ 无论在 Jdk1.7 还是 Jdk1.8 中，Atomic* 的开销都是很大的，主要体现在： 高并发下，CAS 操作可能会频繁失败，真正更新成功的线程占少数。 关注整体性能，CounterBenchmark.rw 是对一组场景的整合打分，可以发现，在我们模拟的高并发计数器场景下，1.8 的 LongAdder 获得整体最低的延迟 98 ns，相比性能最差的 Jdk1.7
1.8K11发布于 2018-09-30 - 来自专栏后台技术底层理解
redis高并发高可用
redis 实现高并发主要依靠主从架构，一主多从. 对于性能来说，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒 10w 的 QPS。 如果想要在实现高并发的同时，容纳大量的数据，那么就需要 redis 集群， 使用 redis cluster 模式，可以提供每秒几十万的读写并发。 这样也可以很轻松实现水平扩容，支撑读高并发。 Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况，所以为了缓解读的压力，所以进行读写分类，并对读进行扩展。 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 ==怎么保证redis是高并发以及高可用的==？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
3.2K10发布于 2020-08-04 - 来自专栏后台及大数据开发
【高并发】秒杀系统高并发请求排队处理
今天无意中看见了这位兄弟的文章 通过请求队列的方式来缓解高并发抢购（初探） 但文章最后说并发超过500 就会出现超发，看了下代码，的确有这个问题 抽空简单完善了下，经压力测试后发现暂无超发现象， 下面为我的代码 欢迎指正 由于是在windows下测试，并发高了就报错 java.net.BindException: Address already in use 这个初看上去很像端口被占用，其实是因为已经完成请求的
4K11发布于 2018-08-02 - 来自专栏PHP在线
大话－高并发
简单理解下高并发: 高并发是指在同一个时间点，有很多用户同时的访问URL地址，比如：淘宝的双11，双12，就会产生高并发,如贴吧的爆吧，就是恶意的高并发请求， 也就是DDOS攻击，再屌丝点的说法就像玩撸啊撸被 ， 签到成功后用户获取到一个积分 已知表 用户表，包含积分字段 高并发意淫分析(属于开发前的猜测)： 在高并发的情况下，会导致，一个用户签到记录会有多条，或者用户签到后不止加一积分 0的时候无法进行抽奖 已知表: 用户表，包含积分字段 奖品表，包含奖品剩余数量字段 高并发意淫分析(属于开发前的猜测): 在高并发的情况下，会导致用户参与抽奖的时候积分被扣除，而奖品实际上已经被抽完了 在实际线上环境可能还会超过这个请求量，如果不经过进行高并发设计处理，服务器分分钟给跪了。 解决问题： 我们通过nodejs写了一个数据处理接口，把统计数据先存到redis的list里。 在高并发接口的设计中可以使用具有高并发能力的编程语言去开发，如：nodejs 做web接口 服务器部署，图片服务器分离，静态文件走CDN 并发测试神器推荐 Apache JMeter Microsoft
2.2K40发布于 2018-03-08 - 来自专栏Java探索之路
高并发技术
而大数据也带来的高并发的问题. 解决高并发问题是大数据时代的永恒主题. 我们假设已经解决高并发的问题, 我们可以通过对数以亿计的数据做日志分析 , 从中分析用户行为 ,分析在哪个渠道的用户最具购买力 , 哪个渠道最容易接纳我们的产品. 即: 高并发>日志>分析行为>画像>推荐>服务 这便是大数据时代下企业发展之路 ,因此 ,解决高并发问题便是关键. 通过相应技术, 解决高并发问题 ,为企业节省更多资金 ,有益企业良性发展. 形式的日志以及日志抽样； 支持按指定关键字(域名，url等)收集Tengine运行状态； 组合多个CSS、JavaScript文件的访问请求变成一个请求； 自动去除空白字符和注释从而减小页面的体积 常用高并发模型设计 ，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗 高性能, 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速 apache 相对于nginx 的优点
4.5K50发布于 2020-07-27 - 来自专栏CSDN搜“看，未来”
高并发（一）
---- 文章目录 取经的地方 曾经，我眼中的高并发 如何理解高并发 高并发系统的设计目标是什么？ 宏观目标 微观目标 高并发的实践方案有哪些？ ---- 曾经，我眼中的高并发 真的，我知道我自己写的算不上高并发，很久了。 确实，十万上下的并发量真·算不上高并发。 3、理解片面，把高并发设计等同于性能优化：大谈并发编程、多级缓存、异步化、水平扩容，却忽视高可用设计、服务治理和运维保障。 ---- 如何理解高并发 高并发意味着大流量，需要运用技术手段抵抗流量的冲击。那到底多大并发才算高并发呢？ 1、**不能只看数据，要看具体的场景。 另外，如果业务场景不同，高并发的落地方案也会存在差异，但是总体的设计思路和可借鉴的方案基本类似。 高并发设计同样要秉承架构设计的3个原则：简单、合适和演进。
1.6K40发布于 2021-09-18 - 来自专栏全栈程序员必看
Qt高并发
QtConcurrent是一个命名空间，提供了用于编写并发软件的更高层次的类和算法。该命名空间中有一个重要的类，QThreadPool，这是一个管理线程池的类。
2.3K20编辑于 2022-09-03 - 来自专栏做不甩锅的后端
什么是并发、高并发以及实现高并发需要考虑的因素
2.什么是高并发 高并发（Hight Concurrnet）,从字面上来理解就是让单位时间同时处理任务的能力尽可能的高。 实际上，从另外一个角度考虑，我们所说的高并发，并行已经是其一个子集。 而水平扩展的能力，实际上从另外一个角度来说，并行是提升系统并发能力的重要手段。 那么，既然是高并发，那么多高才算高呢？ 为了更好的对系统的高并发性进行评价，需要对如下指标进行了解： 响应时间：系统对请求做出响应的时间，既然是高并发系统，这个响应时间就不可能太长，需要尽可能的短。 上述指标内容，主要是反映了高并发系统在高性能上的要求。做为高并发系统，需要实现的目标为： 高性能：这体现了系统的并行处理能力，在有限资源的情况下，提升性能能节省成本。
14.6K12发布于 2021-09-06 - 来自专栏用户3288143的专栏
【高并发】高并发后端设计你必须要会！
缓存 缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。 限流的算法 常见的限流算法有：计数器、漏桶和令牌桶算法。 计数器 计数器是最简单粗暴的算法。比如某个服务最多只能每秒钟处理100个请求。 //服务访问次数，可以放在Redis中，实现分布式系统的访问计数Long counter = 0L;//使用LinkedList来记录滑动窗口的10个格子。
1.5K30发布于 2020-07-07 - 来自专栏全栈程序员必看
Jmeter并发测试_高并发测试
进入后语言是英文的可以选择Options—Choose Language—Chinese(Simplified) 选择左侧TestPlan—添加—线程(用户)—线程组 线程组介绍： 线程数，即为并发请求数量 为0表示并发执行 ramp-Up时间，即为几秒内开启全部线程，可修改 循环次数为1表示所有线程只执行一次。
2.7K30编辑于 2022-11-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号