系统并发指标:
目标用户数,系统用户数,活跃用户数,在线用户数,并发用户数
只有发起请求,在服务器正在处理这个请求的用户才是并发用户。
事实上,高并发架构主要关注的就是用户发起请求,服务器处理请求时需要消耗的计算资源。所以并发用户数是架构设计时主要关注的指标
1. 分布式缓存客户端 SDK 会根据应用程序传入的 key,从分布式缓存集群中选择一台服务器进行访问,那么这个客户端 SDK 如何选择服务器呢?
- hash和分段
hash,根据key的hash值定位目标所在地址。hash值1结尾的key在node1,2结尾的在node2等。
数据分布比较平均,但是不方便扩容。因为扩容的话,就要重新编辑hash到node的映射逻辑。
Redis集群使用一致性哈希算法,将服务器和缓存key全放在一个哈希环上,缓存保存在顺时针找到的最近的服务器上,当扩容时只会损失一台服务器中大约一半的缓存数据,扩展性好很多,哈希不均匀也可以通过虚拟节点的方式得到很大程度的解决
- 分段,每个node值存储一个范围内的数据。id 100万到101万,在node1,101-102万在node2。
方便扩容,但是数据热点分布可能不均匀。比如现在分配到node11了id值是111万,数据增加1万增加一个node就好。不需要重新处理映射逻辑。 但问题是,数据热点可能不均匀。比如101-110万都是老用户,现在已经不活跃了。热点用户都在最新的1万个用户。带来的结果就是,处理前10万个用户的node饿死了,而最新的node11可能都已经撑死了。
supervisor是一个python写的东西 配置一下可以帮你监控你的进程
搞个gateway 封装成模板,然后往里面塞上Mock平台 全链路追踪 日志采样 自动限流 用户鉴权 中间件这些,再扩展成 服务发现 负载均衡 上个k8s 自动缩扩容 ,然后搞个脚手架 自动根据要求生成代码,增删改查一把梭 网关层按需可插拔,平台化 打通链路形成闭环
本文探讨了高并发场景下系统关注的并发用户数指标,并介绍了分布式缓存的两种策略:hash和分段。Hash策略在数据分布均匀时效果良好,但扩容困难;分段策略便于扩容,但可能引发数据热点问题。Redis集群的一致性哈希和虚拟节点解决了部分问题。此外,文章还提及了进程监控工具Supervisor以及服务架构中的各种组件和自动化工具,如服务发现、负载均衡和自动缩扩容。
482

被折叠的 条评论
为什么被折叠?



