如何实现高稳定性编码？深入探索防御性编码与关键技术策略！

一、防御性编码的意义

类似于“防御性驾驶”对驾驶安全的重要性，防御性编码目的概括起来就一条：将代码质量问题消灭于萌芽。要做到“防御性编码”，就要求我们充分认识到代码质量的严肃性，也就是“一旦你觉得这个地方可能出问题，那基本它就会（在某个时刻）出问题”。当然，实际情况比这个更严峻。由于大家的编码经验和风格差异，导致大家的意识边界是大小不一的，那些潜伏在意识边界之外的“危险”更加隐蔽和不可琢磨。

在意识层面上，我们当然要摒弃“想当然”和“差不多”的思想，严肃评估这些问题发生的可能性，认真对待这些风险。但如若话题止步于此，那其实还是缺乏执行层面的指导意义的，激不起半点“涟漪”的。

二、如何防御性编码？

以下需关注的具体方面更多来自于我的习惯和观察，并且统一用伪代码作问题示例

并发冲突问题 这个问题在实际项目中，被错误地忽视的比例相当高。它的外在表现形式五花八门，但关键点是：“当你的代码被并发调用时，它会怎么表现？” 我们心里要有个运行时的世界观，代码运行的Context是这样的：多线程 -> 多进程 -> 多机器 -> 多集群。我们编码时，要充分考虑代码在上述世界观多点并发的可能性，及相应的潜在后果。

举几个具体的问题例子)：

存在共享变量或者数据。（不限于堆内存，也可能是缓存、DB、文件等）

例子1：

有线程 A 和线程 B 两个线程，需要更新「同一条」数据，会发生这样的场景：

1. 线程 A 更新数据库（X = 1）
2. 线程 B 更新数据库（X = 2）
3. 线程 B 更新缓存（X = 2）
4. 线程 A 更新缓存（X = 1）

最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致。

例子2：

在一个系统中，有两个价格类型 small 和 large，业务逻辑要求 small <= large，
且 small 和 large 有2个入口可以分别修改。

目前方案是：对要改变的small或large，增加上面大小关系校验，不通过则拦截，
例如 改动small的入口上，校验改后的small <= 系统里的large，不通过则不允许修改。

假如，最新需求要求：修改large的入口继续拦截，但修改small的入口不再拦截，
而是发现如果改后small > 系统的large，则将 系统large = 改后的small+0.1
，让约束关系继续成立。 这种改法有问题吗？

答案：这种改法会有问题。即 small这个价格类型存有两个链路同时修改，也是一种并发冲突问题。

举个具体例子：

初始时，系统的small = 2; large = 2;
修改large 链路1：准备将 large 改为 3，检查规则 3(改后large ) >= 2(系统small) 通过。准备写入新的large (3)。
修改small 链路2：准备降 small 改为 4, 发现 4（改后small）> 2(系统large) 不符合规则，则准备自动修改 large = 4（改后small）+ 0.1 = 4.1。准备写入改后small = 4，自动改后 large = 4.1；
如果链路2 最终先完成写入，链路1再完成写入。则链路2写入的 large=4.1 会被链路1 写入的large=3 覆盖。最终系统 large =3，而系统small = 4；破坏了最初的small <= large 的约束。
未考虑集群并发

事务问题

对于先A再B后C的这类组合操作，要仔细考虑保障一致性的必要性，做好是否做事务保障的评估。

事务即要求：对一组的operation combo，要保障好执行顺序，保障好context的一致性，保障好结果的一致性。

数据库事务。发生概率不高，大多会主动预防。

这个问题发生概率倒不高，也比较容易解决。
但要注意，事务执行耗时不要太久，以及避免死锁问题发生

上下文一致性问题。

以上传并处理Excel文件为例，假如实现分为 2 步：

1. 前端调用后端API，上传文件到Server的某个临时目录。
2. 前端 在上传完成时，调用后端另一个API，通知 后端处理此文件。

这个例子在集群环境中就会出现概率性成功或失败的情况，集群节点数量越多，失败概率越高。这是因为前端的前后两次请求调用到了不同节点上，执行上下文出现了不一致。

顺序一致性问题。

常见的，例如对于 ECS运行状态的时序消息，如果下游消费者不是顺序消费，而是并行消费，
就可能导致最终记录的状态 与实际不符。

分布式锁问题 分布式锁日常也经常用到，在使用细节上存在一些容易忽略的盲点。

获取锁

1. 是阻塞式等待锁，还是等不到锁重试，还是等不到锁直接返回。
这个层面主要考量点，这个调用链路对时间和成功率要求是什么。
例如，上游是用户操作，那肯定不能阻塞在等锁那里太久；

2. 锁的key设计很关键。
合理设计lock key，能够降低锁碰撞的概率。
例如，你的lock 是加在一个BU层面上，还是加到某个人身上，那冲突概率显然差别很大。

3. 对于 持久锁，在循环执行业务逻辑时，要做好锁的状态检查。
    RLock lock = redisson.getLock(lock);
    lock.lock(-1L, TimeUnit.MINUTES);
    // 获取到锁就持久占有，避免反复切换
    while( !isStopped ){
         if( lock.isHeldByCurrentThread() ){
              // do some work
         }else{
              // try to acquire lock again. 
         }
         SleepUtil.sleep(loopInterval, TimeUnit.MINUTES);
    }

4. 能用本地锁 不用全局锁。

锁超时

1. 合理设置锁的TTL，结合自己业务场景做取舍
例如，加锁之后执行大量数据的batch计算的场景。
如果锁TTL太长，那计算被异常中断（如机器重启）时，这个长TTL内是无法被其他节点/线程获取到执行权限的；但如果TTL设置太短，那可能还没等执行完成，锁就被意外抢走了。

2. 注意watchDog机制
像Redisson之类的会有锁的watchdog，超过设置或默认的时间，锁就被偷偷释放了。

释放锁

1. 非必要情况下，避免强行释放锁，要检查锁的持有人是否是自己。
2. 对于没有TTL的锁，要考虑极端情况下（进程被强制杀死、机器重启）的锁状态管理。
否则意外一旦出现，锁就永远丢失了。

缓存问题

缓存穿透问题

缓存和数据库都没有的数据，但被大量请求，导致DB压力过大。
常见的解决方式：对空值也进行缓存，但TTL设置相对较短。

缓存击穿问题

一般是缓存的热点key发生过期失效，此时大量请求透过缓存 击中DB，导致DB压力过大。
常见解决方式：缓存查询miss时，设置个互斥锁，只允许一个request真实请求DB和重写缓存，
避免大量请求涌入。

缓存雪崩问题

缓存中的大量数据在较短的时间段内集中过期。一般发生在流量一波波来，缓存创建时间和TTL很接近。

常见解决方案：在TTL设置上不是一刀切，而是在一个合理范围内随机浮动，避免缓存集中失效。

缓存的一致性

一般情况下，一致性要求不会非常严格。但如果需要强一致性保障时，要考虑缓存和DB之间的数据强一致性。
一种可能的方案：只在写DB时才写缓存，读DB操作不写缓存。DB和缓存的写操作要加锁，避免并发问题。
具体流程如下：
当写DB请求发生时：
1. 删除 缓存。此时读操作缓存会miss，读取到DB中的老值。
2. 写入DB。此时读操作缓存会miss，读取到DB中的新值。
3. 写入缓存。此时读操作缓存会 hit，读取到缓存中的新值（与DB新值一致）。
需要注意的是：
1. 缓存针对数据库所有的数据记录，可能导致缓存空间占用高，实际利用率却不高。
2. 如果某个缓存key 是热点，或者流量比较大，尽管缓存“删除-重写入”间隔短，
依然可能会引发缓存击穿问题。

3. 如果缓存写入失败，需要有相应的补偿机制再写入，且需关注 补偿写入与其他正常写入的冲突和时序问题。

缓存命中率

这个本身不是问题，但命中率低说明缓存的设计或使用存在问题，需要重新设计

热点key问题

如果特定缓存节点CPU使用率远高于其他节点，说明可能存在热点key。这个时候需要合理对缓存key做拆分，将流量进一步打散。

失败处理问题 这类问题虽属于低级问题，但往往比较隐蔽。在异常发生时，选择相应处理action时，我们要头脑非常清醒。

失败处理

可能的处理方式：

1. failover。失败立即重试。
2. failback。记录失败，后置处理。
3. failfast。直接失败，返回异常。
4. failsafe。忽略失败，继续流程。

这里不在于选择那种处理方式，而是要“头脑清醒”的结合自己场景需求做出选择。

注意默认值

一些情况下，我们会初始化时设定一些默认值、默认状态等，对于这些情况要充分考虑异常发生时是否存在风险。

例如，在最开始时，代码里配置了当时的开城信息，但这个状态并没有跟业务操作流程打通，也就是没有办法做到及时更新。

那随着时间发展，开发了新的城市，那就可能产生问题。

switch配置问题

分批推送的时间间隔

switch发布时，不同批次会有时间间隔，大部分场景下都可以容忍这个时间间隔。但个别情况下，可能引发诸如数据不一致等问题。

再使用switch时需要对这个问题做提前考虑，若不能容忍这种情况，那需要更换其他方案。

内存值与持久值

switch的逻辑是这样：

1. switch会默认记录代码中的默认值。此时并不是 持久值。

2. 当在代码中修改默认值时，switch平台也会显示代码默认值。此时也并不是 持久值。

3. 只有在switch平台修改值并推送成功，swith平台会保存持久值。

4. switch保存持久值之后，不管代码修改默认值还是去掉 @AppSwitch 配置，持久值都是存在的。

如果你看到switch平台上展示了开关值，以为已经持久化，然后在代码里就把默认值删掉，此时也可能导致故障。

代码重构注意事项

做代码结构重构时，如果没有指定switch的namespace，会导致你推送过的持久化开关失效，进而引发严重的线上故障。

合理使用，避免滥用

switch 提供了简单易用的配置化能力，但不要把应该正常编码要考虑和处理的问题，丢到switch上做开关。否则，最后开关一大堆，维护越发困难，就隐藏了风险。

重大风险评估和处置 针对一个需求开发，我们需要评估风险及我们的承受能力。主要目的是预防重大故障的发生，而不是要预防所有Bug。关于风险处置，也没有一个固定的标准。我建议是结合业务场景，评估风险概率和潜在问题的严重程度，最后来制定相应的解决方案。例如，如果发现有资损风险，那要采取一切手段把漏洞堵上；但如果只是小概率的漏掉钉钉通知，那增加相应的告警即可。我们如何评估重大风险呢？我建议分这么几个环节做评估：

1、梳理 关键的业务流。
2、梳理 每个业务流的关键环节。
3、梳理 每个关键环节的关键逻辑 和 关键上下游。
4、结合自己场景，假定 关键逻辑 和 关键上下游 出现极端问题。例如 网络挂掉、机器重启、高并发来临、缓存挂掉等。

这里需要强调一点，并非所有模块都需要假定非常极端的情况，要结合自己实际业务要求、历史风险等来综合判断。

再举个例子：

假设，有一个用户资金转账系统，用户可以通过App进行跨行转账操作。
那这个系统就要考虑到 转账超时、转账失败等场景。同时还要考虑 转账超时 或 失败时，是fail-fast 好，还是 fail-over好？
此外，还需要考虑到 App端的用户交互设计，假如遭遇网络中断或超时，且用户看不到任何问题提示，那用户很可能再次发起转账尝试，最后转了两笔的钱。

这个评估过程看上去有点冗长，但其实对于了解自己系统和需求细节的人来讲，应该是很容易做到的。如果做不到那就只能加强细节的理解和学习了。