簡(jiǎn)介智能電表遠(yuǎn)程抄表繳費(fèi)管理平臺(tái)JAVA源碼是一套基于JAVA技術(shù)構(gòu)建的物聯(lián)網(wǎng)應(yīng)用主要面向物業(yè)管理方、房東及物聯(lián)網(wǎng)開發(fā)工程師。平臺(tái)兼容正泰、人民、天正、許繼等主流品牌電表通過GPRS、LoRa、NB-IoT等通信方式實(shí)時(shí)采集讀數(shù)有效減少人工抄表負(fù)擔(dān)同時(shí)提供線上繳費(fèi)、用戶權(quán)限管理、異常報(bào)警和能耗報(bào)表生成等完整功能適用于寫字樓、園區(qū)等集中用電場(chǎng)景。資源包為rar壓縮格式共86個(gè)文件含77個(gè)java源文件、8個(gè)xml配置文件和1個(gè)iml工程模塊文件整體僅67KB。java文件承載業(yè)務(wù)邏輯與通信解析xml用于配置框架與接口目錄結(jié)構(gòu)簡(jiǎn)潔便于快速定位核心代碼。該源碼的價(jià)值在于完整呈現(xiàn)了從設(shè)備接入、數(shù)據(jù)任務(wù)調(diào)度到支付接口聯(lián)動(dòng)、報(bào)表輸出的物聯(lián)網(wǎng)閉環(huán)。尤其wwby-worker-ammeter模塊清晰展示了定時(shí)采集與任務(wù)處理的實(shí)現(xiàn)思路。已有2181人學(xué)習(xí)下載適合希望掌握遠(yuǎn)程抄表系統(tǒng)設(shè)計(jì)、或需要二次開發(fā)為生產(chǎn)級(jí)能耗管理平臺(tái)的技術(shù)人員。1. 它解決的痛點(diǎn)不止抄表從遠(yuǎn)程抄表到繳費(fèi)對(duì)賬的一站式Java工程最近拆了一套智能電表遠(yuǎn)程抄表繳費(fèi)管理平臺(tái)的Java源碼工程第一感受是它做的不是“遠(yuǎn)程抄表”這一個(gè)動(dòng)作而是把抄表、計(jì)費(fèi)、繳費(fèi)、對(duì)賬、能耗報(bào)表這些原本散落在Excel里的活全部收攏成了代碼閉環(huán)。管理員在后臺(tái)點(diǎn)一下“抄表”系統(tǒng)自動(dòng)向電表下發(fā)指令拿回讀數(shù)生成賬單用戶繳費(fèi)后回調(diào)自動(dòng)核銷整個(gè)過程不需要人碰電表。對(duì)開發(fā)者的意義在于這套源碼把通信協(xié)議、定時(shí)調(diào)度、賬單狀態(tài)機(jī)、支付回調(diào)這些可復(fù)現(xiàn)的技術(shù)點(diǎn)完整地串了起來既適合做能源信息化項(xiàng)目落地也適合拿來當(dāng)練手工程二次改造。下文我按“架構(gòu)怎么拆、代碼怎么讀、本地怎么跑、坑在哪、怎么改”的順序拆開來寫。2. 技術(shù)選型與整體架構(gòu)從Netty通信網(wǎng)關(guān)到MySQL賬單落庫(kù)2.1 三層模塊劃分網(wǎng)關(guān)負(fù)責(zé)通信核心負(fù)責(zé)業(yè)務(wù)任務(wù)負(fù)責(zé)調(diào)度這套工程的Maven結(jié)構(gòu)是典型的多模塊單體我拆包后看到的模塊劃分大致如下meter-platform ├── meter-common // 通用工具、統(tǒng)一返回體、常量、異常 ├── meter-gateway // Netty服務(wù)、DL/T645協(xié)議編解碼、設(shè)備連接管理 ├── meter-core // 設(shè)備檔案、抄表、賬單、繳費(fèi)業(yè)務(wù)邏輯 ├── meter-job // 定時(shí)任務(wù)與分布式鎖 ├── meter-admin // 管理后臺(tái)HTTP接口對(duì)接Vue前端 └── sql // 建表腳本與初始數(shù)據(jù)把網(wǎng)關(guān)層獨(dú)立成模塊是我比較認(rèn)可的設(shè)計(jì)。抄表平臺(tái)最容易變的部分是“設(shè)備怎么連、報(bào)文怎么解析”而賬單和繳費(fèi)相對(duì)穩(wěn)定所以通信協(xié)議的變化被隔離在 meter-gateway 里不影響 meter-core 的業(yè)務(wù)代碼。數(shù)據(jù)流向大致是電表或集中器主動(dòng)連接Netty服務(wù)端口建立TCP長(zhǎng)連接并維持心跳定時(shí)任務(wù)或手動(dòng)指令觸發(fā)抄表動(dòng)作網(wǎng)關(guān)按設(shè)備檔案拼裝協(xié)議報(bào)文解析完的上行數(shù)據(jù)經(jīng)倍率換算后寫入抄表讀數(shù)表業(yè)務(wù)層按賬期聚合用電量套用電價(jià)方案生成賬單用戶繳費(fèi)后支付網(wǎng)關(guān)的回調(diào)通知更新繳費(fèi)流水和賬單狀態(tài)整條鏈路到這一步就形成了閉環(huán)。2.2 技術(shù)棧選型為什么用Netty而不是HTTP輪詢層技術(shù)選型理由后端框架Spring Boot 2.x生態(tài)成熟Java開發(fā)效率高設(shè)備接入Netty 4.x處理電表長(zhǎng)連接和高頻報(bào)文比BIO可靠業(yè)務(wù)數(shù)據(jù)庫(kù)MySQL 8.x存儲(chǔ)設(shè)備檔案、讀數(shù)、賬單、流水緩存Redis分布式鎖防重復(fù)采集緩存設(shè)備地址ORMMyBatis-Plus單表CRUD代碼量小前端Vue Element UI管理后臺(tái)類項(xiàng)目標(biāo)配組件豐富定時(shí)任務(wù)Spring Scheduled 自研Redis鎖輕量不需要額外引入任務(wù)中心有人會(huì)問電表抄表為什么不用后端定時(shí)發(fā)HTTP請(qǐng)求去讀常見做法是智能電表或集中器主動(dòng)連采集主站因?yàn)殡姳泶蠖嗖渴鹪谂潆姺?、表箱這類內(nèi)網(wǎng)環(huán)境主站主動(dòng)訪問會(huì)被網(wǎng)絡(luò)策略擋住設(shè)備主動(dòng)建連反而最簡(jiǎn)單。Netty在這種場(chǎng)景下有天然優(yōu)勢(shì)大量電表長(zhǎng)連接復(fù)用少量線程報(bào)文邊界靠ByteBuf處理協(xié)議解析用Handler鏈實(shí)現(xiàn)后續(xù)要支持新協(xié)議只需要新增一種decoder。2.3 數(shù)據(jù)庫(kù)設(shè)計(jì)五張核心表撐起業(yè)務(wù)閉環(huán)整個(gè)業(yè)務(wù)閉環(huán)依賴的核心表有 meter_info、meter_reading、bill_info、payment_record、read_task。先看設(shè)備檔案表這個(gè)表是網(wǎng)關(guān)層和業(yè)務(wù)層共同的基礎(chǔ)CREATE TABLE meter_info ( id bigint(20) NOT NULL AUTO_INCREMENT, meter_no varchar(12) NOT NULL COMMENT 12位表地址BCD序低位在前, meter_status tinyint(4) NOT NULL DEFAULT 1 COMMENT 1在線 0離線 2故障, location varchar(64) DEFAULT NULL COMMENT 安裝位置, multiplier decimal(10,2) NOT NULL DEFAULT 1.00 COMMENT 互感器倍率, protocol varchar(16) NOT NULL DEFAULT DLT645 COMMENT 通信協(xié)議類型, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_meter_no (meter_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT電表檔案表;表地址字段和倍率字段在抄表、計(jì)費(fèi)兩處都會(huì)用到所以做了唯一索引避免同一塊表重復(fù)建檔。meter_reading 表保存每次采集到的原始讀數(shù)唯一索引建在 (meter_no, data_id, read_time) 上data_id 是數(shù)據(jù)標(biāo)識(shí)用來區(qū)分總電量、峰電量、谷電量等不同數(shù)據(jù)項(xiàng)。bill_info 表里有一個(gè) status 字段標(biāo)識(shí)賬單狀態(tài)0待支付、1已支付、2已沖正這個(gè)狀態(tài)字段是整個(gè)繳費(fèi)流程的流轉(zhuǎn)依據(jù)。明白這些表的關(guān)系之后再去看代碼基本就能在半小時(shí)內(nèi)把項(xiàng)目主路徑摸清定時(shí)任務(wù)驅(qū)動(dòng)網(wǎng)關(guān)讀表讀到的數(shù)據(jù)進(jìn) meter_reading業(yè)務(wù)層按賬期聚合生成 bill_info繳費(fèi)成功后 payment_record 記錄流水并反向更新 bill_info。核心開發(fā)時(shí)只要不打破這條閉環(huán)在這幾章表上做擴(kuò)展都比較安全。3. 核心模塊拆解一次抄表從指令下發(fā)到生成賬單的完整鏈路3.1 網(wǎng)關(guān)層DL/T645報(bào)文構(gòu)建與響應(yīng)解析遠(yuǎn)程抄表的第一道坎是協(xié)議。國(guó)內(nèi)智能電表大部分走DL/T645-2007規(guī)約報(bào)文特征是以多個(gè)FE作為前導(dǎo)符接著68開頭、16結(jié)尾。讀表指令長(zhǎng)這樣FE FE FE FE 68 12字節(jié)表地址 68 控制碼 數(shù)據(jù)域長(zhǎng)度 數(shù)據(jù)域 校驗(yàn)和 16。其中表地址是BCD碼且低位在前控制碼0x01表示讀數(shù)據(jù)數(shù)據(jù)域里放的是數(shù)據(jù)標(biāo)識(shí)。public class Dlt645Codec { private static final byte START 0x68; private static final byte END 0x16; /** 組裝讀表指令dataId 示例00010000 表示讀當(dāng)前組合有功總電能 */ public static byte[] buildReadRequest(String meterNo, String dataId) { byte[] addr reverseBcd(meterNo); byte[] data hexToByte(dataId); // 這里按DL/T645規(guī)則做加擾數(shù)據(jù)標(biāo)識(shí)每個(gè)字節(jié)加0x33 for (int i 0; i data.length; i) { data[i] (byte) ((data[i] 0x33) 0xFF); } ByteBuffer buf ByteBuffer.allocate(1 12 1 1 1 data.length 1 1); buf.put(START); buf.put(addr); // 12字節(jié)地址域 buf.put(START); buf.put((byte) 0x01); // 控制碼讀數(shù)據(jù) buf.put((byte) data.length); buf.put(data); buf.put((byte) 0); // 校驗(yàn)和占位 buf.put(END); byte[] frame buf.array(); frame[frame.length - 2] checksum(frame, 1, frame.length - 3); return frame; } /** 從起始符后一個(gè)字節(jié)開始累加到數(shù)據(jù)域結(jié)束為止 */ private static byte checksum(byte[] data, int from, int to) { int sum 0; for (int i from; i to; i) { sum (sum (data[i] 0xFF)) 0xFF; } return (byte) sum; } }校驗(yàn)和運(yùn)算范圍從第一個(gè)68之后開始更容易因?yàn)檫吔鐔栴}翻車。請(qǐng)求報(bào)文的組裝邏輯里表地址翻轉(zhuǎn)和0x33加擾是新手最容易漏的兩步漏了以后電表要么不響應(yīng)要么一直返回錯(cuò)誤幀。響應(yīng)報(bào)文的解析方向相反Netty的Handler里收到完整幀后先校驗(yàn)起始符、校驗(yàn)和再取數(shù)據(jù)域長(zhǎng)度然后對(duì)數(shù)據(jù)區(qū)做反轉(zhuǎn)加擾還原。DL/T645的數(shù)據(jù)區(qū)第4位是0x33加密后的科學(xué)計(jì)數(shù)因此還原時(shí)每個(gè)字節(jié)加0x33換算成十進(jìn)制后再移小數(shù)點(diǎn)。這個(gè)讀取邏輯可以封裝為public static BigDecimal decodeReadResponse(byte[] frame) { if (frame[0] ! START || frame[frame.length - 1] ! END) { throw new IllegalArgumentException(非法幀); } int len frame[10] 0xFF; // 數(shù)據(jù)域長(zhǎng)度 byte[] data Arrays.copyOfRange(frame, 14, 14 len); // 前4字節(jié)是數(shù)據(jù)標(biāo)識(shí)后面才是電能值 byte[] valueBytes Arrays.copyOfRange(data, 4, data.length); for (int i 0; i valueBytes.length; i) { valueBytes[i] (byte) ((valueBytes[i] 0x33) 0xFF); } long raw bytesToLong(valueBytes); return BigDecimal.valueOf(raw).movePointLeft(4); }這里的 movePointLeft(4) 是因?yàn)镈L/T645電能值最小單位是0.0001kWh讀到的整數(shù)要除以10000。不同廠家的實(shí)時(shí)數(shù)據(jù)、需量數(shù)據(jù)、電壓數(shù)據(jù)在數(shù)據(jù)標(biāo)識(shí)和單位上各有差別所以實(shí)際工程中通常把 data_id 和單位一起配置成字典避免在代碼里做死。3.2 采集調(diào)度定時(shí)任務(wù)配合Redis鎖防止重復(fù)執(zhí)行定時(shí)抄表最簡(jiǎn)單的方式就是Spring的Scheduled但生產(chǎn)環(huán)境部署多個(gè)實(shí)例時(shí)同一個(gè)任務(wù)會(huì)在每臺(tái)機(jī)器上各跑一次導(dǎo)致同一時(shí)段出現(xiàn)多條讀數(shù)。我習(xí)慣用Redis的setIfAbsent做一個(gè)分布式鎖搶到鎖的實(shí)例才執(zhí)行任務(wù)Component Slf4j public class MeterReadScheduler { Resource private StringRedisTemplate redisTemplate; Resource private MeterReadService meterReadService; Scheduled(cron ${meter.gather.cron}) public void autoRead() { String lockKey task:autoRead:2025041502; Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, running, Duration.ofMinutes(30)); if (!Boolean.TRUE.equals(locked)) { log.warn(已有實(shí)例在執(zhí)行抄表任務(wù)本次跳過); return; } try { meterReadService.readAllOnlineMeters(); } finally { redisTemplate.delete(lockKey); } } }lockKey 里帶上任務(wù)批次號(hào)避免兩輪任務(wù)之間因?yàn)閳?zhí)行時(shí)間過長(zhǎng)而互相干擾。鎖的過期時(shí)間按任務(wù)最大耗時(shí)設(shè)置我一般會(huì)留兩倍余量防止斷電或重啟導(dǎo)致鎖永久不釋放。readAllOnlineMeters 內(nèi)部會(huì)分批處理設(shè)備先把在線設(shè)備id列表查出來每100臺(tái)一組分組發(fā)起讀命令避免一次性把幾千臺(tái)設(shè)備全部壓給網(wǎng)關(guān)層。若設(shè)備回包超時(shí)則把該設(shè)備標(biāo)記為離線等待下輪任務(wù)重試。3.3 計(jì)費(fèi)邏輯階梯電價(jià)和倍率換算怎么落進(jìn)代碼抄到原始讀數(shù)之后不能直接把讀數(shù)差值乘以電價(jià)。實(shí)際用電量要先乘上互感器倍率因?yàn)榇蟛糠蛛姳斫?jīng)電流互感器接入表上顯示1度實(shí)際可能是幾十度。其次大多場(chǎng)景采用階梯電價(jià)按總用電量分檔計(jì)價(jià)public BigDecimal calcBillAmount(MeterReading reading, PricePlan plan) { BigDecimal actual reading.getKwh().multiply(reading.getMultiplier()); BigDecimal amount BigDecimal.ZERO; if (actual.compareTo(plan.getFirstStage()) 0) { amount actual.multiply(plan.getPrice1()); } else if (actual.compareTo(plan.getSecondStage()) 0) { amount plan.getFirstStage().multiply(plan.getPrice1()) .add(actual.subtract(plan.getFirstStage()).multiply(plan.getPrice2())); } else { amount plan.getFirstStage().multiply(plan.getPrice1()) .add(plan.getSecondStage().subtract(plan.getFirstStage()).multiply(plan.getPrice2())) .add(actual.subtract(plan.getSecondStage()).multiply(plan.getPrice3())); } return amount.setScale(2, RoundingMode.HALF_UP); }所有金額計(jì)算全部用BigDecimal這一點(diǎn)是踩過坑才有的覺悟。用double計(jì)費(fèi)每筆差幾分錢日積月累到月底對(duì)賬就是一筆糊涂賬。階梯判斷的結(jié)構(gòu)化表達(dá)其實(shí)可以用策略模式重構(gòu)但當(dāng)前這種if-else寫法在電價(jià)檔位不超過三檔時(shí)最直觀后續(xù)要支持峰平谷分時(shí)電價(jià)再增加按時(shí)間段拆分用電量的計(jì)算器即可。3.4 繳費(fèi)回調(diào)用冪等鍵擋住重復(fù)請(qǐng)求繳費(fèi)環(huán)節(jié)最容易出問題的不是支付而是回調(diào)。支付渠道為了確保通知送達(dá)往往會(huì)重試多次如果后端不處理重復(fù)請(qǐng)求同一筆繳費(fèi)就會(huì)生成多條流水賬單被更新兩次。處理方式是一條唯一索引外加事務(wù)內(nèi)的先查后寫Transactional(rollbackFor Exception.class) public void handlePaymentNotify(PaymentNotifyDTO dto) { Integer count paymentRecordMapper.countByPaymentNo(dto.getPaymentNo()); if (count 0) { return; // 重復(fù)回調(diào)直接忽略 } PaymentRecord record new PaymentRecord(); record.setPaymentNo(dto.getPaymentNo()); record.setBillId(dto.getBillId()); record.setStatus(1); paymentRecordMapper.insert(record); billInfoMapper.updateStatus(dto.getBillId(), BillStatus.PAID); }代碼層面的count查詢只是第一道防線payment_record 表上的 payment_no 唯一索引才是兜底。萬一兩個(gè)請(qǐng)求同時(shí)進(jìn)來一個(gè)插入成功另一個(gè)會(huì)觸發(fā)唯一鍵沖突由全局異常處理器捕獲后同樣返回成功避免支付渠道誤以為通知失敗繼續(xù)重試。4. 本地跑起來從建庫(kù)建表到模擬電表回包的完整流程4.1 環(huán)境準(zhǔn)備與工程導(dǎo)入需要準(zhǔn)備JDK 8或以上版本、Maven 3.x、MySQL、Redis、IDEA。拿到源碼包后用IDEA以Maven工程方式打開根目錄 pom.xml等待依賴下載完成即可。這份工程沒有依賴外部中間件MySQL和Redis裝好就能跑。我通常先把 sql 目錄下的腳本按順序執(zhí)行命名一般是 schema.sql 建表、data.sql 初始化演示數(shù)據(jù)執(zhí)行完后確認(rèn) meter_info 里有幾條設(shè)備記錄。4.2 修改配置時(shí)區(qū)和端口是命門application.yml 里要改的是數(shù)據(jù)源、Redis和Netty端口三個(gè)地方server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/meter_platform?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8mb4 username: root password: root redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml meter: netty: port: 8304 boss-threads: 1 worker-threads: 4 gather: cron: 0 15 2 * * ?數(shù)據(jù)源連接串里的 serverTimezone 一定要顯式寫 Asia/Shanghai實(shí)踐中有不少項(xiàng)目在本地連庫(kù)沒問題一部署到服務(wù)器上報(bào)表就少一天就是時(shí)區(qū)沒指定。Netty端口記住一個(gè)數(shù)就行后面模擬電表也要用同一個(gè)端口。抄表 cron 我改成每分鐘一次方便本地驗(yàn)證生產(chǎn)環(huán)境再換回凌晨執(zhí)行。提示建議本地驗(yàn)證時(shí)把 cron 調(diào)成0 * * * * ?這樣一分鐘就能看到一次自動(dòng)采集效果不用手動(dòng)點(diǎn)按鈕等半天。4.3 寫一個(gè)模擬電表把回包做實(shí)沒有真實(shí)電表怎么驗(yàn)證鏈路常見做法是本地起一個(gè)TCP服務(wù)模擬電表監(jiān)聽同一端口收到讀表命令就回一幀固定數(shù)據(jù)。這里貼一個(gè)我在本地反復(fù)用過的最小實(shí)現(xiàn)public class SimulatorMeterServer { /** 數(shù)據(jù)區(qū)固定回復(fù)當(dāng)前組合有功總電能 123.45 kWh已按DL/T645規(guī)則做過加擾 */ private static final byte[] RESPONSE hexStringToByteArray( 68 11 11 11 11 11 11 68 81 06 00 01 00 00 45 23 01 00 55 16); public static void main(String[] args) throws Exception { ServerSocket serverSocket new ServerSocket(8304); System.out.println(simulator meter listening on 8304); while (true) { Socket socket serverSocket.accept(); new Thread(() - handle(socket)).start(); } } private static void handle(Socket socket) { try (InputStream in socket.getInputStream(); OutputStream out socket.getOutputStream()) { byte[] buffer new byte[128]; int len in.read(buffer); // 粗略判斷收到以68起始的讀請(qǐng)求幀 if (len 4 buffer[4] (byte) 0x68) { out.write(RESPONSE); out.flush(); } } catch (IOException ignored) { } finally { try { socket.close(); } catch (IOException ignored) { } } } }這段模擬器只做了一件事收到讀請(qǐng)求后返回寫死的電量幀。真實(shí)工程里一個(gè)集中器下帶多塊表模擬器還要根據(jù)報(bào)文中的表地址返回對(duì)應(yīng)讀數(shù)但本地驗(yàn)證核心鏈路用這個(gè)就夠了。運(yùn)行時(shí)先啟動(dòng)模擬器再啟動(dòng)后端日志里能看到Netty服務(wù)啟動(dòng)并且定時(shí)任務(wù)觸發(fā)后會(huì)打印讀到的電量值。如果讀到的數(shù)據(jù)不對(duì)先從模擬器回包檢查起再對(duì)照協(xié)議幀格式排查。4.4 驗(yàn)證一條完整業(yè)務(wù)鏈后端啟動(dòng)完成后通過HTTP接口逐層驗(yàn)證更直觀操作請(qǐng)求路徑預(yù)期結(jié)果查看設(shè)備列表GET /api/meter/list?page1能看到模擬表記錄手動(dòng)抄表POST /api/meter/1/read返回當(dāng)前讀數(shù)生成賬單POST /api/bill/settle?billId1賬單狀態(tài)為待支付繳費(fèi)回調(diào)POST /api/pay/notify賬單狀態(tài)變?yōu)橐阎Ц禼url -X POST http://localhost:8080/api/meter/1/read \ -H Content-Type: application/json -d {}我建議把這條鏈路完整走一遍再去看前端頁面。后端調(diào)通能提前暴露大部分問題比如協(xié)議解析錯(cuò)誤、賬單金額不對(duì)、回調(diào)冪等失效這類問題卡在前端調(diào)試階段反而費(fèi)時(shí)間。走完這四步這個(gè)項(xiàng)目對(duì)你來說就已經(jīng)從“源碼”變成“跑起來的系統(tǒng)”了。5. 避坑與排查這套平臺(tái)最容易翻車的五個(gè)細(xì)節(jié)5.1 現(xiàn)象模擬電表能連接但始終解析不到數(shù)據(jù)日志里出現(xiàn) “invalid frame” 或 “校驗(yàn)和錯(cuò)誤”時(shí)先不要懷疑代碼邏輯大概率問題出在幀邊界處理。原因在于前端發(fā)了4個(gè)FE前導(dǎo)符某些實(shí)現(xiàn)會(huì)在讀取時(shí)把前導(dǎo)符也算進(jìn)幀體導(dǎo)致程序從錯(cuò)誤的位置開始解析。 解決方法是統(tǒng)一約定發(fā)送端補(bǔ)前導(dǎo)符接收端在解碼器里跳過FE字節(jié)只拿FE后面的68 開頭報(bào)文。另外檢查表地址是否做了低位反轉(zhuǎn)DL/T645里地址是按字節(jié)倒序傳輸?shù)牡刂穼懛戳穗姳頃?huì)直接不響應(yīng)。5.2 現(xiàn)象同一塊表在同一抄表周期出現(xiàn)了兩條讀數(shù)這是典型的定時(shí)任務(wù)重復(fù)執(zhí)行。本地單實(shí)例不暴露生產(chǎn)環(huán)境多節(jié)點(diǎn)部署后Scheduled在每個(gè)節(jié)點(diǎn)都會(huì)觸發(fā)一遍。 原因就是缺分布式鎖。 解決方法是給任務(wù)加Redis鎖像前面代碼里那樣用 setIfAbsent 保證同一時(shí)刻只有一個(gè)實(shí)例執(zhí)行。還有一種隱蔽場(chǎng)景任務(wù)A執(zhí)行到一半重啟鎖還沒釋放下個(gè)周期任務(wù)B看到鎖存在就跳過導(dǎo)致這個(gè)周期漏采。所以鎖的過期時(shí)間要按任務(wù)最大耗時(shí)配置而不是默認(rèn)10秒。5.3 現(xiàn)象繳費(fèi)后賬單狀態(tài)一直停留在“待支付”這類問題大多出現(xiàn)在回調(diào)處理上。支付渠道回調(diào)通知后端后端更新數(shù)據(jù)庫(kù)失敗但返回了成功渠道認(rèn)為通知已到達(dá)不再重試賬單就卡住了。 另一類原因是先查后寫沒有做好冪等同一回調(diào)處理兩次導(dǎo)致數(shù)據(jù)錯(cuò)亂。 解決方法是繳費(fèi)流水表加唯一索引事務(wù)內(nèi)先查流水再插流水最后更新賬單任何一步失敗都拋異常讓事務(wù)回滾返回非成功讓渠道繼續(xù)重試。排查時(shí)先查 payment_record 表有沒有對(duì)應(yīng)流水沒有就是回調(diào)壓根沒進(jìn)來有就要看賬單更新語句是否被異常攔截。5.4 現(xiàn)象賬單金額和實(shí)際用電對(duì)不上月底總差幾塊錢金額對(duì)不上基本是精度問題。用double做乘法或者倍率計(jì)算順序錯(cuò)了都會(huì)累積誤差。 我在本地測(cè)試時(shí)試著把電表讀數(shù)直接用kwh乘以單價(jià)結(jié)果10臺(tái)模擬表跑一個(gè)月差異從幾分錢慢慢放大到幾塊錢。 解決方法是結(jié)算金額統(tǒng)一用BigDecimal并且先乘倍率得到實(shí)際電量再按階梯分檔計(jì)算倍率要讀 meter_info 里的 multiplier 字段不能寫死在代碼里。還有一個(gè)注意點(diǎn)抄表讀數(shù)要保留數(shù)據(jù)來源總電量要區(qū)分峰平谷否則做分時(shí)電價(jià)時(shí)還得重新解析歷史報(bào)文。5.5 現(xiàn)象前端頁面一到月底報(bào)表查詢就卡死數(shù)據(jù)量上來之后meter_reading 表會(huì)膨脹得很快一天一抄一年就是365條每表。幾萬塊表跑一年就是上千萬行報(bào)表查詢沒有索引就是全表掃描。 常見誤區(qū)是只給主鍵建索引查詢條件里的 meter_no 和 read_time 完全沒有索引可用。 解決方法是建組合索引 (meter_no, read_time)報(bào)表統(tǒng)計(jì)時(shí)把日期條件作為強(qiáng)制過濾項(xiàng)。更徹底的做法是按月分表或建立日匯總表把明細(xì)數(shù)據(jù)歸檔到歷史庫(kù)日常對(duì)賬只查匯總結(jié)果。這套工程本地跑沒有問題要上生產(chǎn)必須提前考慮這個(gè)增長(zhǎng)模型。6. 二次開發(fā)從抄表平臺(tái)延伸到能耗分析6.1 用策略模式接入新協(xié)議實(shí)際落地時(shí)幾乎一定會(huì)遇到第二種、第三種電表協(xié)議比如Modbus RTU或某個(gè)廠家的私有協(xié)議。網(wǎng)關(guān)層如果繼續(xù)用if-else判斷協(xié)議類型新協(xié)議多了之后代碼會(huì)迅速腐化。更合適的做法是定義協(xié)議處理器接口public interface MeterProtocolHandler { boolean support(String protocol); MeterData read(MeterDevice meter); }網(wǎng)關(guān)收到抄表任務(wù)時(shí)遍歷所有已注冊(cè)的 ProtocolHandler找到 support 返回true的那個(gè)實(shí)例來執(zhí)行讀取。新增一種協(xié)議只需要寫一個(gè)新的實(shí)現(xiàn)類并注冊(cè)到Spring容器不需要改動(dòng)原有的DL/T645邏輯。我第一次給這類平臺(tái)加Modbus協(xié)議時(shí)因?yàn)閰f(xié)議解析耦合在讀表服務(wù)里改一處動(dòng)了全鏈路后來重構(gòu)出這個(gè)接口才好了從那以后我每接觸一套抄表平臺(tái)都會(huì)先看協(xié)議層是否留了擴(kuò)展點(diǎn)。6.2 把固定抄表頻率改成按設(shè)備可配平臺(tái)默認(rèn)全局一個(gè) cron 表達(dá)式所有設(shè)備一個(gè)頻率。但能耗管理場(chǎng)景里要按15分鐘頻率采集園區(qū)重點(diǎn)回路普通住戶表一天一次就夠了。改造思路是給 read_task 表增加 cron 字段配置每類設(shè)備的采集頻率調(diào)度器每分鐘掃一次任務(wù)表命中時(shí)間點(diǎn)的任務(wù)才下發(fā)采集請(qǐng)求。這里要重點(diǎn)處理高頻設(shè)備的并發(fā)問題同一集中器下的設(shè)備讀取要串行化否則集中器處理不過來會(huì)大量丟包。6.3 從賬單延伸到能耗分析抄表數(shù)據(jù)的價(jià)值不止于出賬單。采集頻率提高后可以用小時(shí)、天、月維度做聚合統(tǒng)計(jì)算出環(huán)比同比識(shí)別出異常用電時(shí)段。比如某條回路線路在半夜用電量突增大概率是設(shè)備非正常開啟或線路漏電。DL/T645協(xié)議里電壓、電流、有功功率都有對(duì)應(yīng)的數(shù)據(jù)標(biāo)識(shí)擴(kuò)展采集時(shí)不改協(xié)議層只要在數(shù)據(jù)字典里增加新的 data_id 配置就能把更多電能質(zhì)量數(shù)據(jù)拉回來。順著這個(gè)方向這套平臺(tái)就不再只是“抄表繳費(fèi)”而是慢慢長(zhǎng)成一個(gè)小型的企業(yè)能耗平臺(tái)。我拆完這個(gè)工程最大的習(xí)慣變化是以后再接手這類Java項(xiàng)目第一件事不是讀業(yè)務(wù)代碼而是先把模擬器跑起來把端到端鏈路驗(yàn)證通再?zèng)Q定從哪里動(dòng)手改。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取