大数据架构师避而不谈的3大代码陷阱

文章配图，仅供参考

　　第三个陷阱：所谓“高可用 fallback”的重试机制，根本没 fallback，只重试。比如 HTTP client 里 setRetryPolicy(new CustomRetryPolicy(3, 500))，看着很专业，实际每次重试前 sleep(Math.min(500, base (2 ^ retryCount)))，但 base=0；重试三次，每次都是立刻发起新请求，TCP 层还没 tear down 完，connection reset 就来了十七次。更绝的是，重试成功后，下游服务根本收不到幂等 key，因为幂等 header 是第一次才塞的，后续重试全走默认空串——所以同一笔订单进了六次，财务那边半夜打电话来问“为什么同一个 transaction_id 对应四个不同金额”。这个我能打包票：我们用了三年的 okhttp-wrapper，内部 static class RetryExecutor 的构造函数里漏传了 idempotentHeaderKey，但 everyone just copied it from the old project boilerplate.

　　KPI 今年砍了 12%，人力池缩编两个 HC，剩下那俩还在等 OD 转正流程。我刚查了下邮箱，运维老张上午十点二十三分转发了一封关于 Hadoop 3.3.6 安全补丁的邮件，标题写着“紧急”，正文只有两个字：“已发”。我顺手把刚才写的 fallback 伪代码发给了测试小王，她回了个“？”，后面跟了个猫头鹰表情。我没回。

　　优胜劣汰不是靠文档，是靠谁先踩进坑、谁先被 oncall 喊醒、谁的 job 先在凌晨四点爆内存 OOM。大数据架构师避而不谈这三个陷阱，不是因为不懂，是因为谈了等于承认自己当年 merge 了那行 code；而我们这行最体面的共识就是：不谈 commit hash，不查 author，不翻 release note。我今天说了，下礼拜可能就要去支援数据治理平台了——那个项目组上周刚被裁掉三分之一，现在每天站会第一句是“各位，咱们今天能上线吗？”

　　算了，先不提上线的事。我得去看看 DBA 小李有没有把 Kafka broker 上的 num.io.threads 调回来。他昨天在群里说“调太高会导致 page cache 溢出”，但我看到监控里 IO wait 那条线最近总在 92% 徘徊，像根绷着的琴弦。要不要提？先喝口水吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!