系统优化设计笔记--曹大公众号文章笔记

Posted 学业未成

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了系统优化设计笔记--曹大公众号文章笔记相关的知识,希望对你有一定的参考价值。

PS:以下整理内容发布至本人博客已通过曹大授权。如需转载,请注明出处。

优化查询: 核查语句慢的SQL和数据结构,分析慢的原因 思考重点:
1、数据结构:考虑数据容量与数据分布规律 数据容量:几百万条,几千万条,几亿条,这些不同数据容量的架构设计,肯定是不一样的 分布规律: 好友列表:平均每个人会有多少好友,有超过100个好友的比例是多少,系统上限是多少 订阅列表:双向订阅、单向订阅的关系。主数据的订阅模型怎么设计? 用户黑名单:平均每个人会拉黑多少人,有超过100个拉黑的比例是多少,系统上限是多少 除了上述例子外,还有就是与之相关业务的数据分布规律是什么样的。 比如:订阅列表里,主要内容是哪些人提供的,平均每次订阅所看到的内容来自于多少用户,top内容贡献者用户的分布规律是怎样的。这里就涉及了 内容数据,订阅数据,以及用户数据三部分的彼此关联 2、请求频次和请求峰值频次分布的规律 同样的一些读写请求,同样的一些SQL,同样的数据内容,在不同请求频度上,结构设计可能会有很大的不同。 如果写频率与读频率的比值很高,那么有些对查询优化改进不大的索引可能需要降级处理,比如一些复合索引是可以降级到单键索引的。 不考虑频次,盲目针对单条查询做优化,有可能会牺牲掉其他方面的响应。 请求频次必须考虑峰值 3、异常的考量和降级策略 异常的考量: 什么是异常考量呢,比如你系统有个搜索功能,很耗费资源,正常情况下,搜索频率很低,这个问题不那么严重。 但如果遇到有人搞你,cc攻击,这个短时间大量不同关键词的搜索请求刷过来,一下子可以把数据库刷爆。 比如论坛上的翻页,特别是大翻页(几十页,几百页),数据请求的全量数据查询。 降级策略: 牺牲部分请求,保障系统的最基本可用性 很多特定诉求导致的负载问题,可以通过暂时的功能屏蔽或诉求屏蔽,来保障整体的系统可用(如何应用到主数据设计上?) 实际应用: 微博为例(主数据设计也是如此) 推策略: 就是每个内容制作者,发布内容后,都会把内容同步推送给所有的订阅者(把内容id推过去就行)。 优势是:每个订阅者有个自己的内容列表,订阅者打开系统的速度超快,没有负载问题。 缺点是:很多大V有几万,甚至几十万订阅者,每发一条信息,就要同步发给几万,几十万订阅者,这发布信息的成本就会巨高。 拉策略: 订阅者打开系统的时候,先拉取其订阅列表,然后针对每个订阅者去查询最新信息,汇总过来生成自己的订阅内容。 优势:发布者发布内容只是一条记录,系统负载极低。 缺点:很多订阅者订阅了大量微博主,那么每次拉取的开销就会巨大 解决方式:推拉结合 怎么结合: 对于访问频率较高的订阅者(活跃用户),推送的效率收益比高; 对于访问频率较低的订阅者(僵尸用户,流失用户等),拉取的效率收益比高; 此外,要考虑用户平均订阅的分布;以及平均粉丝的分布。 而系统基于这种分布规律,就需要寻求一个最佳平衡。 4、过度设计 过度担心某方面的问题,隐患和缺陷,大量精力投入到一些不必要的开发和系统保护上。有时候一些简单粗暴的保护策略是必须的,但要考虑你实现成本。 5、主次不分 急于优化每个看到的问题,比如针对每条慢查询寻根究底 其实要快速定位系统当前阶段的最大问题,快速解决当前最受制约的问题,这是最关键的。 很多问题其实没有想象的那么可怕,一些对系统可用性影响不大的问题,可以等当前紧急问题解决后慢慢处理 6、缺乏预警 直到问题爆发,才想起来去分析,去优化,去解决。 缺乏日常必要的数据跟踪和预警机制,在系统负载出现波动,数据连接池增长异常,但系统整体可用性尚未出现问题的时候,能体现发现这样的异常波动,并准确定位,早做计划,是非常重要的 7、完美主义 先使用一些简单粗暴,导致可用性降级但确定有效的过渡策略,保证系统基本可用性,然后逐渐去彻底解决整个问题

PS:以上整理内容发布至本人博客已通过曹大授权。如需转载,请注明出处。

以上是关于系统优化设计笔记--曹大公众号文章笔记的主要内容,如果未能解决你的问题,请参考以下文章

.NET 云原生架构师训练营(权限系统 代码实现 ActionAccess)--学习笔记

.NET 云原生架构师训练营(设计原则&&设计模式)--学习笔记

微信公众号项目笔记 二

Elasticsearch笔记九之优化

.NET 云原生架构师训练营(系统架构)--学习笔记

.NET 云原生架构师训练营(基于 OP Storming 和 Actor 的大型分布式架构三)--学习笔记...