本文目录先出四道题你猜猜掉线这件事其实是四条路掉线了先别打电话五分钟能自己查出来第一块砖别让平台再去“问”桩了心跳不是为了说“我在”是为了能说“它没了”重连别让一万根桩一起冲进来参数到底设多少一张能直接抄的表断网那二十分钟桩得自己会记账最容易翻车的地方一笔订单扣了两次费高峰期让消息先排个队最后一道保险每天凌晨对一遍账还得有一双眼睛几个必须盯的数那买平台的时候该问什么说到底这是一条“把现场变成账”的管道回到那通电话凌晨两点一个场站老板给我打电话。他那个站十二根桩。白天好好的一到晚上十一点以后平台上就只剩五根在线了。我说桩坏了吗他说没坏。人跑过去一看插上枪车能充钱照扣好得很。我说那不就没事吗他一下就急了怎么没事平台上不显示我就不知道谁在充、充了多少、该收多少钱。早上一个车主说充了四十度我这边只有二十七度。这十三度我认还是不认我认了我亏。我不认他投诉。你说这叫什么事。我沉默了。这就是充电桩行业里最不起眼、也最要命的一个问题——桩在。但平台看不见它。说白了你花钱买桩、花钱建站、花钱拉电最后能不能收到钱靠的不是那根桩。靠的是桩和平台之间那条看不见的线。这条线你平时摸不着报表上也不写它。可它一断你那十二根桩当场变成一堆铁。今天这篇我就把这条线从头到尾拆一遍。拆完你会发现大部分“掉线”桩是冤枉的。先出四道题你猜猜我问过不少做场站的老板。下面四个场景哪些是“桩坏了”题一。地下车库桩在线。下午三点突然全掉线五点自己又回来了。A. 桩坏了B. 车库信号的问题C. 平台那边出事了D. 不知道题二。桩一直显示在线。但你在平台上下发“启动充电”桩一点反应都没有。A. 桩坏了B. 平台坏了C. 连接还在但桩里的程序卡死了D. 网络断了题三。车主充了四十二度平台只记了二十七度。桩那边数据好好的。A. 桩少报了B. 平台没存住C. 车主记错了D. 电表不准题四。一笔订单扣了两次费。A. 桩重复上报B. 平台没去重C. 网络重传D. 上面三个一个都不能少答案我放最后你先自己选。我为什么要出题因为**“掉线”这两个字最容易把人带沟里去。**老板觉得是桩的问题打电话找桩厂。桩厂一看桩好着呢回一句你网络的问题。两边都没错。问题就一直搁着。掉线这件事其实是四条路我们把“平台看不见桩”这件事拆开。你会发现能断的地方一共四个。第一条现场的网断了。地下三层车库信号本来就飘。或者场站那个路由器是当年买桩的时候经销商顺手配的四五个设备一上它就开始喘。这种最直观也最好查——桩自己知道它会重连。第二条桩自己卡死了。桩还通着电连接也还在但里面的程序卡住了。它不再回你任何消息。注意这个跟第一条完全不一样。网断了TCP 会告诉你。程序卡死TCP 不会说一个字——它会安安静静地挂着一直“在线”。第三条连接被平台这一边弄丢了。这条最冤也最容易被忽略。桩那边好好的是平台这边出的事重启了一次、内存回收停顿了两秒、或者连接的线程池满了。桩当然会重连。但重连这段时间里账是盲的。第四条消息到了但没落地。桩说“我充完了四十二度”平台收到了处理的时候出错没写进库。桩以为报完了。平台那边什么都没有。四条路修法完全不同。所以“掉线”这事不能笼统地喊得先分清是哪一条。分不清就只剩一个办法重启。而重启解决不了任何问题它只能解决“现在这一下”。掉线了先别打电话五分钟能自己查出来这一段最实用。说句实在话建议你直接抄下来。桩一掉线别急着找桩厂也别急着换路由器。按下面四步走五分钟就能定位。第一步看心跳日志。平台那边翻一根桩最后一次收到消息是什么时候。如果最后一条消息是三分钟前然后戛然而止——那多半是网断了或者桩卡了。第二步看连接数。平台上看两条这根桩的 TCP 连接还在不在整个平台的连接数是不是突然掉了一大块。连接还在、消息不来——那是桩卡死了走第二条路。连接没了、一大片同时没——那要往平台自己身上想走第三条路。第三步看入库日志。连接正常、消息也收到了但数据库里那笔订单没影儿。这就不用查网络了去查处理消息的那段代码。这是第四条路。第四步看队列积压。前面三步都正常就是慢、就是丢——那去看消息队列堆了多少。队列一路往上涨说明后面处理不过来问题在削峰和消费能力上。你看四条路对应四个证据。很多技术团队排查半天没结果是因为一上来就猜。而工程这事靠证据不靠猜。第一块砖别让平台再去“问”桩了最早的做法特别朴素平台每隔三五秒挨个去问一遍——你还在吗这叫轮询。我们算笔账。假设五秒问一次一根桩一天就是 17,280 次。一千根桩呢一天 1,700 万次。一万根呢一天 1.7 亿次。而这 1.7 亿次里绝大部分问出来的答案是“没事”。这就叫花钱买心安。而且买得很贵慢。消息最快也要等一个轮询周期才拿到5 秒就是 5 秒。贵。桩端的流量、平台的计算全花在“问你在不在”上。吵。一万根桩一起问每秒上万次无意义请求数据库都被问烦了。所以正经平台都会换一条路长连接。桩和平台之间拉一条一直不挂断的线。谁有话说直接说。对比项轮询长连接谁主动平台挨个问桩有事就说延迟一个周期秒级基本实时一万根桩的日常开销一天 1.7 亿次基本只有心跳断线感知慢快在 Java 里干这活最顺手的是Netty。一个词概括它省。它用很少的内存就能扛住一条连接一台服务器挂十万、几十万条连接是常事。更值钱的是它把网络里最脏最烦的活全接过去了。拆包、粘包、超时、断连、异常这些脏活累活都不归你管。你只需要写一件事收到消息之后干什么。什么叫粘包拆包说人话就是TCP 是个水管。它不管你往里塞的是整条消息还是消息碎片它就是一股水流。你这边收到的时候可能半条消息也可能三条半粘在一起。不处理这个你的解析程序就会时不时崩一下。而且崩得毫无规律最难查。换成长连接是这条管道的第一块砖。心跳不是为了说“我在”是为了能说“它没了”连上了就完了吗没有。因为 TCP 有个著名的坑它不会告诉你对面已经死了。对面断电、断网TCP 还能察觉。对面程序卡死、连接没关你这边看到的是——连接好好的就是一直不说话。所以必须有心跳。桩每隔一段时间主动发一句“我在”。比如每 30 秒一次。平台这边在 Netty 里挂一个超时检测IdleStateHandler设个读超时比如 90 秒。90 秒内一条消息都没收到平台就不等了——主动把连接断掉把这根桩标成离线。这一步特别关键。它不是等知道桩死了才动手而是先把“多久没消息就算死”这条规矩定死。你别看这条规矩简单。不定它那根卡死的桩能一直“在线”到天亮。第二天你看报表在线率 100%漂亮得很。然后你就被人问既然在线为什么充不了电这里还有个坑顺便说一下心跳别让所有桩同时发。一万根桩都老老实实每 30 秒整发一次。那每 30 秒就有一个瞬间一万条消息一起砸进来。平常没事。忙的时候这就是自己给自己制造洪峰。所以心跳的时间要加一点随机抖动把这一万人打散到 30 秒里的各个时刻。心跳不是为了证明它还活着。是为了让平台能干脆地说出那句它什么时候算死了。重连别让一万根桩一起冲进来连接断了桩会自己重连。这看着简单其实有个特别常见的坑。最朴素的写法是断了就立刻重连一秒一次一直重试。那你想过没有——如果是平台这边重启了呢一万根桩全都在那一秒发现线断了全都在下一秒一起冲回来。平台刚起来什么都还没准备好直接被自己人挤趴下。趴下之后桩又一起重连。这就叫重连风暴。很多“平台重启后起不来”的事故根子在这。正确做法就一句话退避着重连。第一次断了等 1 秒。还不行等 2 秒。再不行4 秒、8 秒、16 秒……最多等到 60 秒。而且每个桩的等待时间再各自加一点随机。这样一万根桩就散开了像排队进场而不是一窝蜂挤门。快不是本事。乱中有序才是。参数到底设多少一张能直接抄的表这一段是我最想给你的东西。上面的道理其实很多人都懂。难的是——具体设多少下面这张表是我们在实际系统里用的常见取值你可以直接拿去参考项目常见取值为什么这么设桩上报心跳间隔30 秒太密费流量太疏反应慢平台判定离线90 秒没消息一般留三个心跳周期的余量重连退避1→2→4→8→16→32→60 秒封顶防止重连风暴退避加随机上下浮动 20%30%把一万根桩打散桩端离线缓存最近 5001000 笔覆盖好几天的断网补传重试一直重试到平台确认为止账不能丢队列积压告警超过平时 3 倍就报提前半天发现事故每日对账凌晨低峰期跑一次出错能自己冒出来这张表不用背。你只要拿它去问你的技术团队一句话“我们这几项现在是多少”答不上来就说明这条线你的平台还没管住。参数不是越漂亮越好。参数是拿来定规矩的。定了规矩系统才知道什么时候该说“我不行了”。断网那二十分钟桩得自己会记账线断了桩会重连。但有个问题躲不过去——断掉的这段时间发生的事怎么办车主在你断线那二十分钟里充了电。钱要收账要记。可平台那会儿是瞎的。所以桩端必须自己有个小账本每一笔交易先在桩自己身上存着等线回来了按顺序补报给平台。这个叫离线补传。设计的时候有三件事得想清楚第一桩上能存多少条。断网断了三天怎么办一般做法是存最近几百到上千条老的就覆盖掉。同时把“我有数据没传完”这个状态一直亮着别让它自己都忘了。第二补传必须带序号。不然平台收到一堆消息不知道谁在前谁在后也不知道中间有没有漏。第三平台得接得住迟到很久的消息。三分钟前的、三小时前的都得能正常入账不能因为“时间不对”就丢了。没有这条通道那二十分钟就是纯亏。而且你连亏了多少都不知道。最容易翻车的地方一笔订单扣了两次费补传这东西一定会带来一个问题——重复。我给你还原一下现场桩把一笔订单报给平台平台收到了也写进库了。就在回“收到”的那一瞬间网断了。桩不知道你到底收没收到。于是它重连之后又报了一遍。结果一笔充电扣了两次费。车主电话就打过来了。客服解释不清。这种投诉处理起来比掉线本身还贵——它伤的是信任。解决办法叫幂等。说白了就一句同一件事做一遍和做十遍结果必须是一个样。落到代码里做法很朴素。每笔订单带一个全局唯一的流水号桩号 枪号 交易号。然后在这个组合上建一个唯一索引ALTERTABLEcharge_orderADDUNIQUEKEYuk_trade(device_no,gun_no,trade_no);第一次来正常入库。第二次来插入的时候直接撞上唯一索引报冲突。平台不去删、不去改直接当它没来过。一笔订单账上永远只有一条。有条件的再在 Redis 上挡一层先把流水号setnx一下重复的连数据库都不用碰。数据库唯一索引是底线缓存是效率。两个一起用才叫稳。用户看不见这一层。但平台稳不稳一大半看这里。高峰期让消息先排个队最后一个点大家最容易忽略——节奏。晚上下班高峰一个城市几百上千个场站同时开充。桩的状态、订单开始、订单结束、电量上报全挤在同一分钟里涌进来。你后端的数据库是撑不住这个瞬间的。这时候就得请出消息队列。桩的消息先进队列不直接怼数据库。后台的消费程序按自己的节奏从队列里取取多快、取多少平台自己说了算。这就是削峰——把一瞬间的洪峰摊平成一整段时间的小水流。但这里有个坑必须提前想好同一根桩的消息不能乱序。如果“充电结束”比“充电开始”先被处理那这笔订单就成了负数。早上做账的时候你就知道了。所以入队的时候要按桩号做路由——同一根桩的消息永远进同一个队列、同一条线上处理。快慢可以让顺序不能让。最后一道保险每天凌晨对一遍账前面全是“防止出错”。但工程上得承认一件事会出错。线会断程序会崩人会写 bug。这不丢人丢人的是错了不知道。所以每个正经平台凌晨都会跑一件事对账。把桩端的交易记录和平台这边的订单按天对上。差集拉出来自动告警人工去看。少一笔补一笔。多一笔查一笔。平时你感觉不到它存在。等真出事那天它就是唯一能告诉你“到底差在哪”的东西。对账不产生利润。但它保护利润。还得有一双眼睛几个必须盯的数上面这些做完还得有地方能看见它们好不好。四个数建议天天看在线率多少桩、多少枪此刻是活的。心跳超时率今天有多少次“90 秒没消息”是不是突然涨了。消息积压队列里堆了多少条有没有越堆越高。补传成功率断过的那些桩数据到底补回来没有。这四个数一起看能提前半天发现事故。只看第一个你永远是在事后救火。那买平台的时候该问什么写到这我知道有老板要问我又不懂技术怎么知道我这个平台行不行不用看代码。就问五个问题答不上来三个的慎重点。第一问一根桩多久没消息你们算它离线答案含糊或者回答“看情况”——这家对掉线的理解就是模糊的。第二问断网的时候桩上的数据存哪能存多少条答不上来的说明没有离线补传。这就是纯亏的那二十分钟。第三问同一笔订单重复报上来两次你们怎么处理好平台会直接说“有唯一约束重复的收下就丢”。说不清的你就等着扣两次费。第四问高峰期数据库扛不住你们怎么办能说出消息队列、能说清“同一根桩排同一条队”的是真遇到过、真解决过。第五问数据丢过一次你们怎么知道的这个问题最狠。答案是“有对账”的才叫专业。你看这五个问题一个技术名词都不用懂。但它们比任何一份产品介绍都更能说明一家平台靠不靠谱。说到底这是一条“把现场变成账”的管道现在我们回头把这几件事串一遍。掉线、心跳、重连、补传、幂等、削峰、对账……听着像七个不相干的技术词。其实它们说的是同一件事——现场是不确定的。信号会断程序会卡消息会迟到、会重复、会丢。但账必须是确定的。这两件事之间隔着一条管道。修这条管道靠的不是什么高深东西。是心跳要设超时、重连要退避、消息要带流水号、同一根桩要排同一条队。都是些听起来不起眼的规矩。可就是这些规矩决定了一笔账到底认不认。别人拼的是自己有多少根桩。你拼的是你的账有多真。回到那通电话我跟那位场站老板说先别急着找桩厂也别急着换路由器。你先问你的平台一句话一根桩超过九十秒没消息它多久能知道自己瞎了他愣了一下说我不知道。我说那你就去问。这一句问下去可能比再买十根桩都值钱。顺便公布答案题一 B、C题二 C题三 B题四 D。题四选 D 的意思是桩重复上报、平台没去重、网络重传这三件事往往一起发生缺一个都出不了这个 bug。本文为技术人员视角的经验分享涉及的心跳、超时、重试参数均为常见工程取值具体以各平台设计为准。 点这里看文档与在线试用 → doc.huizhidata.com慧知开源充电桩平台hcp-cloud可私有化部署、可二次开发的开源充电桩运营平台设备接入用 Spring Cloud Netty支持云快充 1.5/1.6/1.7 与 OCPP 等多协议站点、设备、订单与计费规则统一管理。