- 主题:昨天让 AI 给我写了一个算法。
场景：
一台中心服务器，定时发送 keepalive 包给另外几台同类型的 application server 检测和对方的网络链接故障以及对方是否 DOWN 掉。检测不能太灵敏，导致误报，比如网络抖动导致的 keep alive 没有收到回应。也不能太迟钝，导致中心服务器不能及时把 DOWN 掉的app server上的负载移到其他 app server。
首先让 CHATGPT O3 写，要求 N 秒发送一个包，如果 M 秒内没有收到就计算为该包超时。连续 X 个包都没有收到回应就认为 DOWN 了。如果在 X 个包内收到任一回复，认为链接正常。
O3 给出了一个比较简单的基于 RTT, SRTT 的实现，把它的实现丢给 GEMINI 2.5 PRO， 它 REVIEW 之后，增加了 RTTVAR, 以及根据当前状态动态调整 N 的实现。
初步测试效果不错，正在丢给测试部门折腾。
--
FROM 218.76.62.*
我们要轻量级的嵌入到程序内的实现，不然直接丢一个 ETCD 就OK了。
【 在 iwannabe 的大作中提到: 】
: 这玩意儿不是造轮子吗，corosync，zookeeper 之类的实现一大堆
:
--
FROM 218.76.62.*
做 C++ 码农的，逻辑思维都没有问题吧。哈哈。
不过确实，现实中和人交流，发现很多人确实把一个事情前因后果，当前的状态，以及期待达到的目标描述清楚的能力。
【 在 hgoldfish 的大作中提到: 】
: 其实大多数初级程序员缺的是这种描述需求的能力。
:
--
FROM 218.76.62.*
是的，ZK 太重了。
轻量级一点的 ETCD 很好。
【 在 hgoldfish 的大作中提到: 】
: 直接用现成的系统会引入大量组件。
: 比如 websocket 就有个 ping/pong 机制，你不能说引入 zookeeper 来实现 websocket 协议吧。
:
--
FROM 218.76.62.*
你不能完全考虑什么方案都是这种重量级的系统。
我们是卖系统方案的，客户的用户规模从几十个人到几万人，十多万人的都有。
你不能要求别人只是100个用户，也要一大堆机器部署 ZOOKEEPER, SPRIING, elastic search 这些巨无霸吧？
【 在 iwannabe 的大作中提到: 】
: 这玩意儿在开始架构设计的时候就应该考虑高可用实现吧。java spring全家桶天然就带
: 这种failover的实现啊，自己写轮子完全没有必要
:
--
FROM 218.76.62.*
恰好我以前是文学爱好者，曾经加入学校文学社，在一些报刊杂志上发表过散文和诗歌。哈哈。
【 在 hgoldfish 的大作中提到: 】
: 逻辑思维和描述需求是两回事。
: 向 AI 提问，我感觉正是需要语文成绩的时候——我就是这样子跟我家小地青说的，鼓励他学好语文。
:
--
FROM 218.76.62.*