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