技术思考框架：抽象-思路-考量-优化-细节

如何思考问题与思考具体问题同等重要。

引子

如何思考一个技术问题？如何高效地理解某个技术 ？如何快速学习一个新的技术点 ？ 这都须要一个好的技术思考框架。缺少思考框架，知识和技术就变成一堆细节的堆砌，缺少关联，难以理解和记忆，也就难以掌握和应用。

本文来探索一种好的技术思考框架。

技术思考框架

在多年的开发生涯及阅读和理解源码的过程当中，我逐渐造成了一种我的以为比较可行的技术思考框架：“抽象-思路-考量-优化-细节” 五步曲。

• 抽象：给用户提供怎样的抽象。
• 思路：如何去实现它，基本的依据、结构、算法与实现；
• 考量：工程应用上须要考虑哪些因素，作到安全可靠高质量；
• 优化：在考量的基础上，从多个层面去优化和完善；
• 细节：在优化的基础上，打磨细节，精益求精。
  
  

抽象

抽象很是重要。一个典型的例子是删除操做。删除操做提供的是“用户不可见”的抽象。能够采用两种思路：

• 物理删除：直接抹掉数据的全部痕迹，再也找不到了。
• 逻辑删除：没有抹掉数据，只是提供了一个标记，在用户查询时根据标记过滤掉这个数据。逻辑删除为数据恢复提供了前提。

能够看到，提供良好的抽象，而不是直觉上按照用户的要求去作，每每会带来更灵活的设计空间。

抽象最好能用一句话归纳。好比，文字编辑器（UI界面）提供的是“所见即所得”的抽象；理财产品提供的是符合利率模型的计算抽象。

思路

思路是如何去基本实现的问题。在问题讨论初期，提出尽量多种思路，应对不一样的场景。好比排序，就有插入排序、冒泡排序、快速排序、合并排序、希尔排序、桶排序、外部排序、多关键字排序等。不一样的排序具备不一样的特性，在不一样的场景下使用。挖掘尽量多的思路，有助于拓展对问题的思考。好的思路是成功的一半。

考量和优化

考量和优化每每须要丰富的开发实践经验。知道往哪一个方向使力，如何使力，须要解决什么技术难点等。

细节

在掌握宏观视角后，细节的打磨尤其重要。细节处理不当，可能会致使总体工做前功尽弃。程序员或工程师的一大特质，便是体如今细节的考虑和思惟的缜密上。

考虑各类错误和异常，考虑依赖服务、服务器、网络等的不可靠，是作好细节工做的必要前提。

Redis 持久化示例

抽象

持久化，便是给用户提供一个“数据保存了、即便掉电或重启也能从某处找回数据”的抽象。

思路

如何实现 Redis 持久化 ？ 持久化就是将 Redis 内存数据库的数据集状态保存在某个磁盘文件里。能够基于两种思路：

• 基于数据。直接将数据存储在（压缩过的）二进制磁盘文件里，恢复的时候读取数据文件便可，好比 RDB 机制。
• 基于命令。将 Redis 命令存储在磁盘文件里，恢复的时候执行文件里的命令便可，好比 AOF 机制。
  
  

考量

实际工程中要考虑什么因素呢 ？

• 避免数据丢失： 持久化过程若被中断，已持久化的数据不丢失；持久化期间，尽力保证不丢数据，或者丢数据在可接受范围内。
• 性能：持久化能更高效地完成。
• 稳定性：持久化的过程当中，不能影响到 Redis 的正常服务。
• 存储空间： 持久化文件占用的空间应当尽量少。
• 同步： 新增的数据及已持久化后的数据更新也要持久化。
• 恢复速度： 服务器启动或紧急状况须要恢复数据状态时，应当尽量高效、便捷、减小没必要要的坑。
• 可读性： 持久化文件可读，可以为人所理解；可解析，可以为机器高效读取。
• 可追溯： 当数据出现不一致时，或者不对劲时，能够经过追溯持久化文件来定位缘由。
  
  

优化

针对上述考量因素，可制定相应优化措施：

• 异步：新起子进程在后台去作持久化的事情，而不占用服务进程，不阻塞服务的正常运行。好比 BGSAVE 命令。
• 缓冲区：在持久化的过程当中，若是新增命令都直接写到持久化文件，势必会影响正常服务的性能。所以经常使用作法是，在持久化开启以后，新增的命令或数据会先写入到缓冲区，而后以某种策略来同步到持久化文件里。能够配置相应的策略，来实现服务性能和避免数据丢失的权衡。
• AOF 重写：将多条命令重写为一条命令，从而减小可执行命令数，减小 AOF 文件体积，提高恢复速度。读取键值的数据库当前数据状态，生成一条新的命令写入 AOF。为何不直接写入键值呢 ？ 由于要知足可追溯的需求。 AOF 重写后的文件用于恢复数据库状态， 而 AOF 的原文件能够考虑归档，便于在急需的时候定位缘由。
• 二进制与文本文件：二进制文件机器解析更高效，兼容性更强，但人类可读性差； 文本文件可读，解析时可能会有坑，须要经过统一协议来避免。
  
  

细节

RDB 机制的细节：

• SAVE 会阻塞主服务进程，通常用于业务量低峰期； BGSAVE 会建立子进程去作持久化工做，不会阻塞。
• BGSAVE 执行期间，新的 SAVE, BGSAVE 会被拒绝；BGREWRITEOF 会在 BGSAVE 完成以后执行。避免并发操做磁盘引发性能波动或下降。
• save 命令能够配置多久执行一次 BGSAVE ； 能够配置多个 save 命令，任一知足都会执行 BGSAVE（或关系）。默认 [900, 1], [300, 10], [60, 10000]。实际配置值须要根据业务状态调优。
• save 的实现：[ dirty & lastsave ] 。dirty 记录了距离最近一次建立 RDB 文件快照以后的数据库状态修改次数； lastsave 记录了最近一次建立 RDB 文件快照的时间戳。 每隔 100ms 都会检测一次，save 条件是否知足。

AOF 机制的细节：

• appendfsync: 同步持久化文件的策略。 always 每次写缓冲区都同步到持久化文件，不会丢数据，但性能会受影响； everysec 每秒同步，可能会丢失最近 1s 内的数据，性能能够； no 性能最优，但会有较大的丢数据风险。 默认策略是 everysec。
• AOF 重写集合： 为了不缓冲区溢出，重写集合时，可根据 REDIS_AOF_REWRITE_ITEMS_PER_CMD 配置，一个数量为 N 的很大的集合，会拆分为 ( N / REDIS_AOF_REWRITE_ITEMS_PER_CMD +1 ) 个重写命令。
• 应用启动时，默认加载 RDB 文件；恢复数据库状态时，优先使用 AOF 机制，若 AOF 关闭，则采用 RDB 机制。
  
  

高并发处理

再来思考一个问题：如何应对高并发流量呢？这是互联网应用必然面对的一个重大挑战。

抽象

高并发流量问题，本质是资源有限的问题。便是用有限的资源去应对不肯定性的巨大流量的矛盾。假设有足够的资源，加以适当的水平扩展，高并发也不算什么事。难在用现有的架构、现有的资源来应对巨大流量，并且不管预留多少资源，老是不必定能承载将来可能降临的超过负载能力的峰值流量。

思路

既然是资源有限的问题，那么思路也就三条：

• 用更少资源作更多的事情，提高服务能力，提高 QPS；
• 加资源；
• 限流。
  
  

考量

• 稳定性：高并发流量下，首先要考虑的是保证应用不会被超出负荷能力的流量压垮；
• 保障正常服务：对于负荷范围内的正常流量，可以正常服务，正常响应，正常的服务体验。不会由于高负荷致使服务处理能力变差，连正常流量的请求都没法有效应对，或者用户体验变差。
  
  

优化

提高服务能力：

• 用好缓存：能够提高 QPS ，但依然没法阻挡高并发流量；

• 熔断降级：高并发状况下，自动熔断次要的链路，提高 QPS；

• 读写分离： 将高并发流量中的读写部分分开，读写分别处理;

• 分库分表： 提高 DB 的并发处理能力；

• 弹性扩容：要求应用可以弹性部署和启动。在大促活动以前，能够提早扩容。目前难以应对瞬时峰值。

加资源（在不一样层面）：

• 加资源的同时作好负载均衡（分流做用）。经过负载均衡进行分流，一部分流量直接进入服务器，一部分流量走消息队列再走服务。负载均衡可采用七层的 ngnix 和 四层的 LVS 或 F5。负载均衡能抗住大流量；

• 多机房 + CDN：多机房 + CDN + 负载均衡，分别抗住来自不一样地区的大流量。

限流： 仍然没法承载的流量，采用限流处理掉。

细节

• 资源消耗：一个请求会消耗多少资源？CPU、内存、磁盘空间、网络链接及带宽、DB 链接等。
• 如何将缓存用到极致？须要对业务数据有敏感度，采起适当的策略，不断调优，密切注意监控；
• 熔断降级的策略？熔断值的设定与调优；
• 如何部署负载均衡和多机房？须要网络运维能力；
• 在哪些层面限流？限流值如何肯定？
• 读库的复制时延如何解决？
• 分库分表的切换过程当中的新数据如何作到不丢失？

高并发其实是一个实操性很强的事情。没有通过高并发流量的洗礼，只谈理论终究仍是隔着点。不过，至少要了解相关理论，才能在实战中积极运用并积累经验。

技术体系结构

从上述示例能够看到：

• 抽象能够提供更灵活的设计空间和思路。
• 考量因素每每会决定优化的大方向。
• 优化每每须要通盘综合考虑，且要有实操经验。
• 细节在优化的过程当中产生和解决。

抽象、考量和优化，须要建基于一个比较丰富的技术体系结构。为何考虑这个问题而不考虑那个问题？为何选择优化这个而不是优化那个？技术知识点是很是繁杂琐碎的，缺少技术体系结构来有效地组织起来，极可能会脑中一团浆糊，分不清东南西北，对着各类新技术望洋兴叹。

所以，打造一个适合本身的技术体系结构很是重要，这也是将来的核心竞争力之一。好比 “互联网应用服务端的经常使用技术思想与机制纲要” 便是围绕“数据处理”这个中心主题，从灵活性、高性能、高可用、高可靠、一致性、海量、安全、自动化、智能化八个方面打造的技术体系结构。这个体系结构几乎能够容纳各类技术流派和技术优化手段。

小结

本文探讨了一种技术思考框架：基于技术体系结构的“抽象-思路-考量-优化-细节”五步曲。

合适的抽象会带来更灵活的设计空间和思路，而考量则会决定优化的大方向，在优化的过程当中解决细节问题。在学习技术的过程当中，要逐步打造适合本身的技术体系结构，不断充实这个体系结构，从而具有更强的系统思考力和技术吸取力。

参考资料

• 《Redis设计与实现》：第 10, 11 章
• “天猫双11为何能抗住90秒100亿？消费狂欢背后隐藏了哪些架构技术？”