bd7xzz

大促除了紧张忙碌，还有就是快乐，大促1个月内有吃不完的零食，大促当天有领到手软的红包，各种小礼物，10几米长的桌子上摆满了饮料酒水、蛋糕、零食。一个良好的压测系统应具有流量染色的能力，各依赖接口和资源可基于sdk识别染色的压测流量，进行影子分身（如数据库的影子表、缓存的分身key），这样可防止压测流量产生垃圾数据污染正常的业务流转。不要忘记，系统是变化的，需求是不断变更的，变化就会引入新的问题或曾经出现过的问题。通常资源的负责人也会提前与研发进行沟通，哪些资源是重要的，需要在大促期间重点保护的。

若帖子 ID 作为字符串存储（如 18 位数字），SDS 需要 4（len）+ 4（alloc）+ 19（18 位数字 + 终止符 \0）= 27 字节，但受内存分配器 jemalloc 对齐影响，实际分配 32 字节。仔细思考下，我们的id通过雪花本质上是带时间属性的，如果key拆分的位数正好满足一个时间戳的位数，是不是可以按时间段当做key呢？我们将一个long类型的帖子id拆分成高32位和低32位，其中高32位作为redis的key，低32位作为hash的field，value进行计数。

Linux操作系统是一个可观测性做的非常好的系统，比如我们可以读取虚拟文件系统 /proc的运行时刻系统状态，syslog服务能够记录系统关键日志，全访问的监控命令（如top、netstat等），ebpf、systemtap技术实现内核级别的观测。而由于存量的存在，系统展现自身状态会存在延迟，如：热点事件发生，qps突增进行扩容，但系统需要部署，新的机器上缓存从冷到热是需要一个过程的，所以新机器扩容上来并不能立刻分摊突增的qps，在这里缓存的从冷填充满整个缓存空间步入到热的状态，缓存未填充的部分就是存量。

这句经典的理论已不知出自何处，但无数的先例都是基于此，调节CPU和硬盘之间的性能差是通过加了一个内存实现的，调节CPU和内存之间的性能差是通过加了L1 L2 L3缓存实现的，用户到服务器之间可以通过反向代理、cdn做很多事情。虽说并行提高的算力，但在这么高度的并行流程中，就会存在各种各样的问题，主要包括：执行的依赖关系与顺序、共享数据的并行写安全、为解决共享数据并行写安全问题引入的互斥竞争、并行部分成功和部分失败的问题。职责分离：最常见的就是数据库的主从，主复制写入数据，从同步主的数据后提供读的服务。

本文阐述了单测的重要性，给出了错误的单测示范，针对错误反推出正确的姿势。有效的单测要把握3个特性：简洁、稳定、可靠。使用合适的单测工具库有助于写出好的单测代码（如：使用Spock基于TDD准则进行测试）。《代码整洁之道》和《重构》两本书中编写和重构代码的指导方法也同样适用于单测代码。《有效的单元测试》这本书非常推荐阅读。[1]《有效的单元测试》[2]《代码整洁之道》[3]《重构：改善既有代码的设计》[4]

其实写这篇博文的目的有三：我认为一个好的系统架构是面向错误和失败的，一个优秀的架构师除了能够给出解决复杂系统问题的方案，更需要给出异常和故障的解决方案。无论何时，我们应该精心设计，通过有限的资源解决复杂的问题，并最大化的预测故障，降低故障的发生概率。在这里，我希望能够阐述清楚工作中使用的故障分析方法、故障经验总结思路、预案构造过程，以及如何去实施预案。一份合理可实施的预案不是一个人能完全梳理清楚的，也不是一个人能完全实施展开的，这离不开一个团队。如果你的系统并没有什么用户使用，出现故障可以随时下线修复，那这

1. 背景描述项目背景，说清楚整个项目的背景以及业务方向。2. 目标根据背景列出要实现的目标点：xxxxxxxxx…3. 业务分析3.1 支持的能力若项目已上线，本次只是迭代，要写清楚已有业务的能力，以及针对本次迭代目标，要具备什么能力（功能）若是新项目，要写清楚针对本次迭代目标，要具备什么能力（功能）3.2 行业调研除非你创造了一个杀手级应用，否则你的轮子基本都是重复的。这里要写出业务领域内其他公司是如何实现的，若公司内有类似的实现，要写出公司内其他人是怎么实现的。他人的实现

为何要写这篇博文？一个错误的方案设计重点是什么？拿模板说说总结