高并发系统实战课
15 年技术老兵的系统改造心法
徐长龙  前微博架构师、极客时间架构师
专栏
已完结·共 30 讲
|
1.2w 人已学
|
收藏
xmr
我是SRE, 平时做一下稳定性工作。看完本专栏收获满满,深深觉得系统的稳定性是设计出来的,不是维护出来的。
作者回复:提前准备的越多,经验积累的越多,碰到问题时会越从容
2023-07-04
txjlrk
厉害,由浅入深,由理论到实践,面面俱到。 分布式事务也分为柔性和刚性两种
作者回复:你好,老铁,我查了下这个归类方式不错,柔性相对的性能更好类似TCC ,刚性类似2pc 与xa
2022-11-11
宁次君
关于动作历史表,‘对于这种基于大量的数据统计后才能得到的结论数据,我不建议对外提供实时统计计算服务’,‘即使使用缓存临时保存统计结果,这也属于临时方案,建议用其他的表去做类似的事情’,但有些业务就是要对历史表做统计的,比如邀请排行榜这种业务,需要统计邀请记录得到邀请人数,这种如何通过其他表实现呢,谢谢🙏
作者回复:你好,这类排行榜可以使用周期的离线计算去计算或者使用redis zset或者队列消息到专用排行服务汇总,或者使用clickhouse类似辅助数据库实时吞吐计算[这个不推荐]
2024-01-10
希波莱
老师如果想做推荐系统和电商,但引入整套llm 的rag工作流,是不是可以淘汰掉传统的mysql,只用elasticsearch + mongdb + redis就足够了
作者回复:你好,LLM的服务QPS目前有些低,如果直接对外服务QPS上万的广告投放有些亏,可以考虑让他生成策略,这样会好一些。最后存储建议redis。微博就是你说的结构,后来全换成了redis。
2024-01-13
PunkHoo
徐老师你好,文中 "如果双活机房有一个出现故障了,其他城市的机房只能用于备份或临时独立运行,不要跨城市做双活,因为同步延迟过高会导致业务数据损坏的后果。" 这里面如果其他城市的机房在切换前没来得及同步"主库"数据,切换后的数据是否如何保证一致性呢?
作者回复:你好,PunkHoo,很高兴收到你的留言,一般来说但凡碰到彻底失联的机房情况的切换都是有损的,对于损失只是大小问题,对于这种单主库情况,最理想情况就是损失几条数据,如果是多主情况下会好一点。我碰到的情况多数是需要人工对比修复一下,不过我们的数据常见都有create_time,update_time相对的修复难度会小很多。 同时,高频率更新的数据是不推荐用这个方式做多机房的。
2022-10-31
Mr.Tree
对于Raft保证数据读取的强一致性,follower的读取都会向leader发送一个版本确认请求,如果是高并发的情况下,leader的压力岂不是会很大,会不会把它打崩,或者客户端出现延迟,对于这种主从结构系统;出现写冲突是如何处理呢?想到一个场景:张三人在国外,银行账户里存有1w,通过手机银行APP转帐给李四8k,于此同时,张三媳妇在国内通过ATM机查询账户1w,想要取5k,这种同时发生,对于这种强一致性要求系统会怎么处理?
作者回复:你好,Mr.Tree,很高兴收到你的疑问,事实上大部分交易系统为了保证数据的强一致都是用本地主库去做的,当进行交易的时候跨区域通讯到核心机房去做交易。你的开户行决定了你的数据在哪里做决策,在下一节课你会看到Raft算法,这里会对这个疑问有很大的帮助。
2022-11-12
林晓威
老师好,请问光使用base64加密是不是不太安全?这样别人不是很容易知道你用什么加密算法了
作者回复:你好,林晓威,很高兴收到你的提问,这个算法重点并不是这个payload区,payload这里只是附带的数据,只是为了方便业务使用,事实上这个核心在于签名和过期时间,由于密钥是只有服务端有,所以签名是不能伪造的,如果到子业务这里验证签名是正确的密钥加密的,那么代表token的payload的内容肯定是服务器发放的,传输的用户无法更改,如果更改了就会和签名核对不上,通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息,如果有不能公开的信息可以再做一层加密后再放入payload
2022-11-07
夏天
老师您好,文中提到的两个问题交流一下 1. 为什么百万并发系统不能直接使用 MySQL 服务? 百万并发不能使用 MySQL 是否过于绝对 如果系统是读多写少,没有宽表和复杂查询。MySQL 读写分离,也不是没有可能达到百万 qps。 单个节点做到 100k 查询也是有可能的。 2. 为什么 Redis 内存相比磁盘,需要用更多的空间? 这个问题感觉有些奇怪。Redis 是内存数据库,和磁盘比较什么? 对于 Redis 来说,磁盘备份 data,也没其它什么功能了。 内存除了 data 还会存储其它数据结构,比如 client。 感谢交流~
作者回复:你好,夏天,很高兴收到你的提问,第一个问题,单个MySQL是能够达到10w QPS的,这个毋庸置疑,我们确实可以通过多个从库实现这样的设计,但是核心要点在于,我们业务不是所有情况都能优化的这么好的,总是有一些业务需要复杂的场景,拖慢整体的性能,所以从某个角度来看,平均性能和木桶中的短板决定了系统的稳定性和性能。第二个问题Redis在内存中占用的空间比磁盘大这里是有系统特性导致的,这里卖个关子,可以看看我们后续的16篇,会得到答案。
2022-11-06
Sky
你好,请教几个问题。 1,除了数据库,其实缓存也有数据同步的问题,而且缓存的访问量会比数据库高很多,双机房对缓存怎么处理? 2,如果一个城市的网络主干断了,同城双机房也不行,这种情况也不是没有出现过,异地双活应该怎么做?
作者回复:你好,老朋友,很高兴再次见到你 第一个问题确实如此,目前是通过保证用户一段时间内只能访问一个机房来减少延迟,并且客户端保存最后更新时间,用这个方式来刺激服务端主动更新过期的缓存 第二个问题,城市主干线断了,可以让其他城市机房接管之前的双活机房工作,但是必须距离很近的两个机房才可以。核心在于同步延迟过大,会出现刚插入的数据查不到的情况,会让业务很难维护。如果有决心做双活,业务层是必须能够有类似raft的支撑才可以
2022-11-01
徐石头
置顶
Q1:在token过期很短的时候,通过refresh_token频繁更新token,怎么实现对用户实时管理?是不是还是跟用户人数相关,一般这种场景是后台系统,删除一个用户后该用户账号立刻不能登录,后台人数比C端人数少很多,所以管理起来代价比较小,更看重权限安全,放在缓存中进行管理。 A: 如果我来做快速更换昵称的功能,两种方式, a.在用户修改昵称后,内存中加入个用户标识,解析token后读取该标识,有则返回特定code,让客户端重新拿token。甚至可以不用客户端参与,返回301重定向到获取新token的路由。 b. token里面不存用户信息,只存用户ID,需要用户信息的时候从缓存读。
作者回复:你好,徐曙辉,很高兴收到你的再次留言 对于session 方式来说,由于用户每次请求都会读取session cache,客户端本地是不会保存token,所以不存在token内用户头像更新不及时问题。可以说后台系统用session管理用户很方便,因为这个可以做到用户实时管理,当我们禁用用户的时候把session的缓存登陆标志删掉即可。不过这个方式适合少量用户,对于QPS超过10w QPS请求的API则不太适合。 所以使用token方式来签名发给客户端,客户端请求其他子系统的时候,会带上它,子系统只要验证这个token的签名就不需要再去用户中心问一句。所以token使用后,用户中心不会被其他子系统频繁请求,但是也导致token发出去没法再次更改,即使我们用户中心给他拉黑了,其他子系统只认印章,不会过来问问。 同时为了方便token内会保存当前用户一些基础信息,减少其他系统过来询问的次数,这导致,用户更新头像,token没更换,是不会同步更新的 第一个很暴力,但是很有趣~ 第二个方式也很有趣,同时补一个技巧我们可以通过 设定 固定网址 user/用户uid/heaer.jpg方式直接获取用户头像,这样也不用考虑更新问题了
2022-10-28
7S
access_token由于安全问题设置过期的时间非常短,但是refresh_token有效时间非常长,如果refresh_token被泄漏掉,是不是能一直刷新access_token呢。。
作者回复:你好,7S,很高兴收到你的思考,关于这里有一些特殊的小技巧,如请求时带上一些客户端特征,如:请求更换access_token时,带上的refresh_token的请求 同时 需要特殊的签名,存储在本地的token不用明文保存,与服务端通讯时用特殊协议加密等~
2022-10-28
贺子
这里有个小技巧,就是 Follower 在收到查询请求时,会顺便问一下 Leader 当前最新 commit 的 log index 是什么。如果这个 log index 大于当前 Follower 同步的进度,就说明 Follower 的本地数据不是最新的,这时候 Follower 就会从 Leader 获取最新的数据返回给客户端。可见,保证数据强一致性的代价很大。这里和后面的感觉矛盾呀!到底raft是什么机制呀,后面说wait index!tidb就是支持indx read,类似
作者回复:你好,贺子,这里面有几点:首先,在 Raft 算法中,为了保证数据的强一致性,Follower 在收到查询请求时会询问 Leader 当前最新的 commit 的 log index。如果这个 log index 大于 Follower 同步的进度,说明 Follower 的本地数据不是最新的。这时候 Follower 会从 Leader 获取最新的数据返回给客户端,以保证数据的一致性,这就是前面提到的如果想要最新的数据。 更进一步提高性能上来讲,Raft 算法也可以采用了等待 Leader commit log index 的机制来保证数据的一致性。Follower 在处理读取请求时,会等待 Leader 提交的日志达到一定的进度后才返回数据。这样可以确保读取的数据是已经提交并被大多数节点接受的数据,从而实现强一致性。 可以说Raft 算法通过两种方式来保证数据的强一致性:Follower 主动向 Leader 查询最新的 commit log index,以及等待 Leader 的 commit log index 达到一定进度后才返回数据。这些机制确保了数据的一致性,但也会带来一定的代价和延迟。 另外关于 TiDB 的支持 index read,这是因为 TiDB 在 Raft 算法的基础上进行了优化和改进,以提高读取性能和并发性。这与 Raft 算法本身保证数据一致性的机制是相辅相成的。
2023-07-31
讲师

徐长龙

前微博架构师、极客时间架构师

徐长龙,网名蓝天,前微博架构师,曾任穷游网首席架构师、好未来高级架构师,现任极客时间架构师。工作十五年来,他专注于指导高并发业务系统升级与改造。同时,对 RPC 建设、服务化、框架、分布式链路跟踪监控以及 Kubernetes 管理平台也拥有丰富经验。 另外,徐老师早年曾...查看更多
编辑推荐
包含这门课的学习路径

架构师

28门课程 151.8w人学习
看过的人还看了
MySQL 实战 45 讲
林晓斌
网名丁奇,前腾讯云数据库负责人

49讲 | 224920 人已学习

¥68¥199
数据结构与算法之美
王争
前 Google 工程师

81讲 | 283784 人已学习

¥68¥199
左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家

119讲 | 180985 人已学习

¥98¥399
Redis 核心技术与实战
蒋德钧
中科院计算所副研究员

53讲 | 81728 人已学习

¥68¥199
设计模式之美
王争
前 Google 工程师,《数据结构与算法之美》专栏作者

113讲 | 123449 人已学习

¥98¥299
从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)

66讲 | 152602 人已学习

¥68¥199