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