这是一个创建于 197 天前的主题，其中的信息可能已经有所发展或是发生改变。
自己工作的环境中，很少遇到或者基本就没有高并发的场景，但自己对这部分很感兴趣，像深入学习一下。但平时能接触到的都是一些网上的博客或者书上的一些理论知识。根据自己以往的学习经验，没有在实际的场景中遇到或者实际操练一遍，是很难深入学习的，或者吸收的。但这种高并发的环境自己有限的机器根本搭建不出来，不知道大家都是怎么学习这部分知识的。
第 1 条附言 · 196 天前
多谢大家的回复，提供了很多学习的点
17 条回复 • 2024-05-30 20:57:14 +08:00
 |
1
BiChengfei 197 天前
缓存、异步、分区，有没有悟性看个人了
|
 |
2
loveumozart 197 天前
多高算高并发啊，我们这里一个服务几十万 qps 算高吗，最后还不是就是堆机器、多级缓存，没什么新东西啊。。。毕竟机器成本相对人力成本小很多。。。我觉得相对高并发来说，学习复杂业务可能更好一点，比如一个业务场景涉及七八个服务，八九个中间件这种吧，这种感觉难度更大一点
|
 |
3
anubu 197 天前
云服务商，竞价实例，随用随关，弄个学习环境用不了多少钱。再研究一下性能测试，在云上内网跑压测，流量费都省了。
|
 |
4
chutianyao 197 天前
读写分离、异步处理、多级缓存、分库分表/ 分片、一主多从/多级从、限流、降级、熔断
无非就这几板斧 |
 |
5
z1154505909 197 天前
我遇到的是复杂的业务场景,维护的那个垃圾系统没并发,一次只能跑一个任务,那个任务还会阻塞其他任务的执行,他妈的.没源码改不了,只能在外面打补丁,请求拦截,请求转发,等等手段
|
 |
6
FeifeiJin 197 天前 via Android  8
技术概念：《数据密集型应用系统设计》 https://github.com/Vonng/ddia
管理理论：《微服务设计》 https://awesome-programming-books.github.io/microservice/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E8%AE%BE%E8%AE%A1.pdf 以上两本书看就能理解。 但有个前提，在缺乏实际生产经验下，第一本书的些许概念会很抽象，抽象到比大一老师讲 java 一大特性是抽象时还要更加抽象。 |
 |
8
ClericPy 197 天前
有大语言模型的今天，学东西门槛降低很多了，一步步问吧，不是开玩笑
就学习环境来说，现在比 15 年前好太多了 |
 |
9
xueling 197 天前
首先要有一定的项目基础，再看一些多线程方面的书籍，要看书不要看博客，可以加入一两个开源项目提交些 PR 。工作过程中会用到很多数据指标，可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse
|
 |
10
fkdtz 196 天前 8
有两种路线我比较认可：
一种是边学边用，边踩坑边理解。 这种机会一般只存在初创公司不断发展壮大的同时业务系统也在逐渐迭代升级的过程中，而且业务能在几经折腾之后还能存活下来的，只能说可遇不可求。 另一种是抓住几个经典的成熟系统深入研究横向对比反复蹂躏和被蹂躏，从中汲取系统设计的真谛。 我推荐楼主试试第二种方式。 在我看来应对高并发场景的核心要义是「消除单点」+「状态同步」两手抓。消除单点意味着分布式，这样可以提高系统可用性和吞吐量，而一旦引入了分布式就涉及到节点之间的状态同步问题，状态同步意味着系统中数据要保持某种程度上的一致。最理想的系统肯定是任何时刻都可用，且任何地点读取到的内容都一致，但鱼和熊掌不可兼得，如何在这两者之间寻找一个平衡就是不同项目的差异点，由此才引申出不同项目的特点和适用场景。 例如 InnoDB 为了支持读并发采用了 B+树、Buffer Pool 和 MVCC ，为了支持写并发采用了行级锁，而在单机性能达到瓶颈之后自然会演进到集群架构，也就是消除单点；主从架构中必然涉及到主从节点间的数据同步，如果数据同步采用全异步策略那么性能最高但安全性最差，反之如果采用全同步策略那么性能最差但安全性最高，系统设计一直都是在取舍。 再例如 Redis 全内存操作保证了其性能的底线，而为了在性能和内存占用之间作取舍，Redis 针对不同数据量级设计了不同的数据类型。当单机达到瓶颈之后也自然演进到分布式架构，集群架构思路是分片，而每一个分片之内又是一个主从来提高可用性；如果主从复制完全是异步的，那肯定存在数据丢失的问题，所以用 Redis 的 setnx 方式做分布式锁是存在隐患的，基于此 Redis 提出了 Redlock 算法处理分布式锁。另一种实现分布式锁的方式则是使用 zookeeper ，因为 zookeeper 实现的 ZAB 协议要求多数节点提交才确认成功，同时提供 sync 同步读保证顺序一致性，不过这样的话相对 Redis 性能就差一些。 除了架构上的取舍，在业务上也可以做调整，例如是否真的有必要把所有请求都打到同一组集群上吗？是否可以按业务、地区等维度拆分成不同集群，不同集群各自处理各自的流量，并发也就降下来了，也就有了更多调整空间。这符合康威法则的思想，即组织架构能够影响软件架构。 还有比如能否将数据放在离用户更近的地方？这样用户访问的路径就更短体验更好，服务也因为只需要服务一部分用户从而吞吐量更高性能更好。这也是空间换时间在分布式场景下的应用。 另外系统本身也需要保护，谁还不是个宝宝了，不能来多少流量就放多少流量进来，系统挂了谁也别玩了。这就涉及到限流、降级、熔断等保护后端的措施，所以服务状态监控、告警和自动扩缩容的需求也被提了出来，不过这里更偏向于基础设施和运维侧了。 总之面对高并发场景所面对的问题大体上都是相似的：高可用，高吞吐量，事务和一致性；而解决办法也都类似，在实现过程中不断做取舍：分层、缓存、复制和分片、共识算法思想及实现。学习过程中常常问问自己，这个系统是如何保证高可用和高吞吐的？是完整支持事务还是部分支持事务？以及如何实现事务？做出了什么级别的一致性保证并且如何实现的？ 最后也推荐 ddia 《数据密集型应用系统设计》一书，我认为是程序员必读书目之一，值得多读几遍。 附上一个之前写的读书笔记 https://www.lipijin.com/reading-notes-ddia |
 |
11
LDa 196 天前
@loveumozart 确实
|
 |
12
heiya 196 天前
之前从事过短信发送平台的项目，每天的发送量一个亿到两个亿之间，属于数据密集型应用。qps 在某个时间段内也不算低，勉强算高并发了。在这个项目中除了大量使用多线程这点需要格外注意以外，其实感觉写起来和平时项目一样，剩下的就是堆配置。比如，分布式集群部署、分库分表、负载均衡使用硬件级别的、服务器加配置、使用缓存，其中 redis 集群单实例的内存就几百个 g 。 不过代码里还是理解了不少多线程的知识。
|
 |
13
sleepm 196 天前 1
高并发的哲学原理
https://github.com/johnlui/PPHC |
 |
14
Red998 196 天前
公司决定技术的上限
|
Select Language