边缘计算场景下Java数据同步与计算卸载实战

前阵子去得物面试Java岗位，技术面聊到微服务和中间件的时候，面试官抛了个问题过来："你们做过边缘计算吗？谈谈边缘计算场景下的数据同步和计算卸载。"坦白说，我简历上写的是常规业务开发，边缘计算属于平时看概念但不深究的范畴。好在我之前在一个物联网项目里接触过边缘网关相关的开发，勉强算没被问懵。回来之后我把这个问题彻底梳理了一遍，从基础概念到方案选型再到Java落地实现，整理成这篇文章。不管你是准备面试、还是真的在做边缘计算相关的Java开发，这篇应该能帮你把链路打通。

1. 面试现场复盘：一个问题问出的三层深水区

1.1 面试官到底在考什么

先把话说透：边缘计算并不是Java面试的高频考点，得物这种体量的公司，业务上也不会天天谈边缘节点。那面试官为什么问？我后来复盘，他真正想考的是三件事。

第一，知识广度。候选人有没有接触过云原生和物联网交叉的领域，还是只会在Spring Boot里写CRUD。边缘计算是典型的分布式系统场景，能聊它，说明你对数据链路、网络环境、设备异构这些东西有概念，而这恰恰是业务开发往更高层走必须补的课。

第二，数据一致性基本功。数据同步听上去简单，但在边缘场景里，网络抖动、断网、弱网、设备重启都是常态。你怎么保证数据不丢、不重、不乱序？这背后是幂等设计、增量同步、版本控制、补偿任务这一整套基本功。面试官真正想听的不是你背了多少名词，而是你有没有在真实项目里解决过这类问题。

第三，架构取舍能力。计算卸载这个问题更是直接跳到架构层。哪些计算放本地、哪些卸载到边缘节点、哪些上云？这个决策过程体现的是候选人对延迟、带宽、算力、能耗几个维度的权衡能力，而不是单纯"会写代码"。

所以如果你也被问到类似问题，千万别慌着背概念。面试官要的是你把它当一个工程问题来分析，而不是当名词解释来回答。

1.2 先搞清楚一个最基础的问题：边缘计算节点是一个机房吗

这里必须展开说一个特别容易被误解的点。我在面试时说的第一句话是"边缘计算节点不一定是机房"，面试官点了点头，示意我继续。这个点其实是整道题的入口，很多人恰恰挂在入口上。

从物理形态上看，边缘计算节点可以是机房、一体机、小站、网关、甚至一块嵌入式板卡。在运营商的5G边缘计算方案里，节点通常以"MEC机房"的形式存在，麻雀虽小五脏俱全，里面有服务器、交换机、存储。但在工业物联网场景里，一个边缘节点可能就是部署在产线旁边的一台工控机，或者是一个树莓派大小的物联网网关。到了车联网场景，一个车载计算单元本身就是一个边缘节点。所以"一个节点是不是一个机房"这个问题，答案取决于你在哪个行业语境下聊。

从逻辑形态上看，边缘计算节点的定义只有一句话：靠近数据源或用户的计算单元。它强调的是"位置"和"职责"，而不是"体积"。中心云就像一个大型超市的中央仓库，货品全、规模大，但离用户远；边缘节点就像社区里的便利店，备货有限，但胜在近。用户要买瓶水，去便利店比去中央仓库快得多。数据要处理，边缘节点也比把数据绕一圈送回云端快得多。

理解了这个，你才能理解后面所有的问题。数据同步为什么难？因为边缘节点和中心云之间不是专线，可能是4G/5G、Wi-Fi、甚至窄带物联网。计算卸载为什么需要策略？因为边缘节点的算力和存储是有限的，不是所有任务都能在本地跑完。"一个节点是不是一个机房"背后其实是边缘计算最核心的边界约束：资源有限、网络不稳、环境复杂。所有方案设计都是在这个约束下展开的。

2. 边缘计算的数据同步：从CDC到最终一致性的完整链路

2.1 为什么边缘场景的数据同步这么难

常规的分布式系统数据同步，至少可以假设网络是可靠的、机房专线带宽是稳定的。但在边缘计算场景里，这几个假设全部不成立。

首先是网络不可靠。边缘节点可能部署在工厂地下室、偏远变电站、行驶中的车辆上，网络随时可能断。一断可能就是几分钟甚至几小时，数据在本地积压，链路恢复后需要追赶式同步。

其次是数据量严重不对称。边缘侧在本地采集的数据量往往是海量的，但上行带宽又很小。边缘节点上可能每秒钟产生上千条传感器数据，但上行链路只有几百Kbps，你不可能把所有原始数据都搬到中心云。

再次是时钟漂移。物联网设备大多没有高精度时钟，NTP同步也不一定覆盖所有终端。不同节点产生的时间戳可能本身就不同步，这给数据排序和增量判断带来很大麻烦。

最后是数据格式异构。边缘节点可能对接不同厂商的设备和协议，Modbus、OPC UA、MQTT、CoAP，每种协议的数据字段和语义都不一样，同步之前得先做结构化处理。

正是这些难点决定了：边缘计算的数据同步不能照搬传统的数据库主从复制方案，而要用增量捕获、缓冲队列、幂等消费、对账补偿的链路来设计。

2.2 主流的同步方案盘点：从MongoShake到SQL Server CDC/CT

聊到具体方案，面试官可能会追问一句"你用过哪些同步工具"。这里我不藏私，把边缘场景里常用的几条路都列出来。

MySQL binlog同步是最常见的结构化数据同步方案。基于binlog的增量解析，把主库的增删改操作实时解析出来，投递到消息队列，再由边缘侧消费写入。这套方案在局域网内很成熟，但边缘场景下网络抖动会导致binlog消费滞后或断点续传问题。Java侧可以用Canal模拟从库协议读取binlog，配合ZooKeeper记录位点，实现断点续传。这是我个人用的比较多的一条链路：Canal采集binlog到Kafka，边缘侧写一个Kafka消费者做幂等写入。

MongoShake是MongoDB生态里的数据同步利器，阿里开源的。它基于MongoDB的oplog实现增量同步，支持从副本集同步到另一个副本集或者云上的MongoDB实例。边缘计算场景里，很多时序数据、设备档案都是以文档形式存在MongoDB里的，用MongoShake可以实时把边缘节点的数据汇聚到中心集群。它有完整的断点续传机制，网络中断后会从oplog的某个时间点续传，不用手动处理。

SQL Server CDC和CT的对比是热搜词里单独列出来的，这个知识点在面试里非常容易抛出来。先说结论：CDC监听事务日志，粒度细、开销大；CT基于版本号追踪，实现简单、开销小，但只能回答"变没变"，不能回答"怎么变的"。CDC的核心思想是解析SQL Server的事务日志，把INSERT/UPDATE/DELETE操作记录到专门的变更表里，同步程序只需轮询这些变更表即可。而CT的做法是在表上维护一个版本号字段，每次DML操作后版本号自增，同步端通过比对本地的版本号来发现变化行。如果你的业务只需要知道哪些行的数据变了，用CT就够了；如果还需要拿到变更前后的完整数据，必须上CDC。

我用个生活化的类比：CDC就像地铁站的安检监控，每一笔进出闸机都有完整的录像记录，任何操作都能回放；CT就像刷门禁卡，只记录"你进门了、卡号是多少"，至于进门之后干了什么，它不关心。

2.3 Java侧如何保证数据一致性

同步链路搭好之后，真正的工程难点才刚开始：怎么保证一致性。边缘计算场景的网络条件决定了你几乎不可能做分布式强事务，我面试时直接跟面试官讲"边缘场景下优先保证最终一致性"。说完最后一点，面试官的笔停了。

最终一致性的核心有四板斧。

第一，幂等设计。所有同步任务的目标端都要做幂等，同一个消息重复投递不能产生重复数据。做法有很多：数据库表里加唯一键、用业务订单号做唯一约束、Redis里做去重标记，最通用的还是在业务表上加一个"同步批次ID+记录ID"的唯一索引。重复消费时报主键冲突，捕获异常后直接忽略即可。

第二，版本号控制。给每条数据加一个版本字段，比如last_modified_time或者自增的version。写入时判断：如果本地的版本号比新来的数据版本号老，才允许覆盖，否则丢弃。这个方案能天然避乱序数据带来的覆盖问题。代码层面的写法很直接：

// 版本号控制更新 public boolean updateWithVersion(String id, JsonNode newData, long newVersion) { int updated = jdbcTemplate.update( "UPDATE edge_record SET data = ?, version = ?, update_time = ? " + "WHERE id = ? AND version < ?", newData.toString(), newVersion, LocalDateTime.now(), id, newVersion ); return updated > 0; }

如果更新的影响行数为0，说明数据版本比本地的还旧，直接丢弃。

第三，失败重试和补偿任务。同步过程中消息写到一半挂了怎么办？最稳妥的做法是先把消息内容落地成同步任务表，标记状态为"待同步"，由后台任务去轮询。成功则标记"已完成"，失败则累计重试次数，超过阈值转入"人工处理"队列。这套做法本质上就是把实时同步降级成"半实时任务队列"，牺牲一点点实时性，换来极高的可靠性。

第四，对账机制。靠重试只能解决"丢"的问题，解决不了"错"的问题。所以要在链路空闲期跑对账任务：把边缘节点最近一小时产生的数据量和中心侧同步的量做对比，不一致的按主键重新拉取。对账任务可以做成一个独立的Java定时任务，每天凌晨跑一次，输出差异报告到工单系统。

注意：边缘场景里千万别迷信分布式事务框架如Seata这类方案。边缘节点和中心云之间动辄几百毫秒的延迟，事务锁竞争会让整个系统吞吐量跌到没法看。最终一致性加对账补偿在这个场景下是工程上最务实的选择。

3. 计算卸载：把重活卸到哪、怎么卸得优雅

3.1 计算卸载的本质是什么

数据同步解决的是"数据怎么搬家"的问题，计算卸载解决的是"计算在哪里执行"的问题。面试官问到这里，基本上就是从数据层面聊到了架构层面。

计算卸载的本质，是把原本在终端设备或中心云执行的计算任务，转移到一个更合适的计算节点上去执行。为什么要转移？因为终端设备算力有限、续航有限；中心云又太远、延迟太高。边缘节点夹在中间，既能承载比终端更强的算力，又能比云端提供更低的延迟，所以它成了计算卸载的最佳落点。

我之前在物联网项目里遇到过实际的卸载需求：产线上的工业相机拍摄高清图片，单台相机本地做缺陷识别要跑300毫秒，产线节拍只给200毫秒。本地跑不动，把图片传到云端又太慢。最后方案是把推理模型部署在产线旁边的边缘服务器上，相机通过千兆内网把图片卸载到边缘节点推理，整个链路压到120毫秒，完美卡在节拍内。这就是一个典型的从终端卸载到边缘节点的案例。

卸载方向其实有三个：从终端到边缘节点、从边缘节点到云端、从云端到边缘节点。面试时如果能把这个分类讲出来，会显得思路特别清晰。

3.2 动态计算卸载层是什么，怎么决策

"动态计算卸载层"这个热搜词值得单独拎出来讲。动态两个字是关键——卸载决策不是静态配置的，而是根据实时状态动态调整的。

一个完整的动态卸载决策层，至少要考虑四个输入维度：

• 延迟预算：这个任务能容忍多少延迟？比如工业控制类任务延迟预算是几十毫秒级，离线分析类任务可能是分钟级。
• 能耗约束：终端设备电池还剩多少？如果在低电量状态下，尽可能把计算卸载出去以节省终端能耗。
• 数据体积：待处理的数据有多大？上传图片和上传一个温度数值的开销完全不是一个量级。
• 链路质量：当前上行带宽、RTT延迟是多少？链路差的时候卸载反而更慢，不如本地算。

决策算法可以做得复杂（比如基于强化学习的在线决策），但工程落地时我建议先用线性权重评分模型。给每个候选执行节点（本地/边缘/云端）打一个分，选分最高的执行：

public class OffloadDecision { private final double W1 = 0.4; // 延迟权重 private final double W2 = 0.3; // 带宽权重 private final double W3 = 0.3; // 能耗权重 public NodeType decide(TaskMeta task, LinkQuality link, DeviceStatus device) { double localScore = W1 * estimateLatency(task, NodeType.LOCAL) + W2 * estimateBandwidthCost(task, NodeType.LOCAL) + W3 * estimateEnergyCost(task, NodeType.LOCAL); double edgeScore = W1 * estimateLatency(task, NodeType.EDGE) + W2 * estimateBandwidthCost(task, NodeType.EDGE) + W3 * estimateEnergyCost(task, NodeType.EDGE); double cloudScore = W1 * estimateLatency(task, NodeType.CLOUD) + W2 * estimateBandwidthCost(task, NodeType.CLOUD) + W3 * estimateEnergyCost(task, NodeType.CLOUD); return minScoreNode(localScore, edgeScore, cloudScore); } }

实际工程里，权重系数需要根据业务特性用压测数据来调。不过这个结构也够用了，它至少做到了"卸载决策不是拍脑袋，而是动态计算的"。

3.3 Java实现异步卸载的落地姿势

决策做完之后，真正的执行环节是异步化的。Java生态里做计算卸载任务编排最顺手的方式，我推荐基于CompletableFuture + 消息队列 + 线程池三层组合。

第一层，任务的提交方（比如物联网网关）把卸载请求丢给线程池，异步执行，不阻塞业务主流程。

CompletableFuture<Result> future = CompletableFuture .supplyAsync(() -> offloadService.execute(task, targetNode), edgeExecutor) .orTimeout(5, TimeUnit.SECONDS) .exceptionally(ex -> Result.timeoutOrFailed(ex.getMessage()));

第二层，任务状态写入Redis或者数据库，前端可通过轮询或者WebSocket推送实时查看执行进度。

第三层，执行结果通过消息队列异步回调给发起方，这样发起方不用一直占着一个连接等结果。卸载到云端的任务如果执行时间较长，还可以把任务ID作为关联键，回调时按ID找对应的上下文。

这里有个坑必须提醒：不要把所有任务都用一个全局线程池。计算密集型任务和IO密集型任务的线程池参数应该分开配置。计算密集型的核心线程数设为CPU核数加一，IO密集型的可以设大一些。混用一个池子的后果是：卸载一个耗时长的深度学习任务，把执行短任务的轻量级请求也堵在队列里了。

4. 边缘计算与Java技术栈的融合实战

4.1 Java在边缘侧能干什么

面试聊到这儿，面试官通常会抛一个很实际的问题："你说你熟悉Java，那Java在边缘计算这个场景里到底能干什么？"

这个问题不好答，因为很多人觉得边缘计算是C/C++和Python的天下，Java的启动重、内存占用高，不适合嵌入式环境。这个观点对也不对。

先说对的部分。在内存只有几十MB的嵌入式设备上，跑一个完整的Spring Boot应用确实不现实。JVM热启动慢，占用资源多，这类场景用C或者Rust更合适。但边缘计算的节点形态是分层的，从MCU到边缘网关再到边缘服务器，每一层的算力资源差异巨大。Java的主战场在边缘网关和边缘服务器这一层，而不是最底层的MCU。

在边缘服务器或边缘网关上，Java能做的事情非常多：

• 用Spring Boot开发边缘计算网关，负责设备接入、协议解析、数据转发
• 用Netty开发高性能的网络服务，处理大量设备的长连接
• 用Quarkus或Spring Native做云原生边缘应用，配合GraalVM编译成原生镜像，启动时间从秒级降到毫秒级，内存占用大幅缩小
• 用Java调用TensorFlow Lite或者ONNX Runtime的Java API，在边缘节点上跑AI推理

第二个方向（嵌入式AI）正好对上了"边缘计算与嵌入式AI"这个热搜词。边缘侧跑AI模型的典型栈是：Python训练模型，导出成TensorFlow Lite格式，Java应用加载模型跑推理。Java这边的推理代码其实不复杂：

// 加载TFLite模型并执行推理 Interpreter tflite = new Interpreter(loadModelFile("/model/defect_detect.tflite")); float[][] input = normalizeImage(cameraImage); float[][] output = new float[1][numClasses]; tflite.run(input, output); float maxProb = findMax(output[0]); return maxProb > THRESHOLD ? "NG" : "OK";

Java在这个链路里的定位很清晰：它负责AI模型之外的所有业务逻辑——数据采集、推理调度、结果上报、任务管理。模型本身用C++跑，但把模型调度起来、把推理结果快速分发出去，Java天生擅长。

4.2 一个简单的物联网边缘数据同步Demo

为了不让这套方案显得悬在空中，我写了一个极简可跑的同步Demo。场景是：边缘网关采集温湿度数据，通过增量同步的方式把数据同步到中心云。

整体设计：边缘侧维护一个自增的本地ID，同步时只拉取上次同步ID之后的数据。中心云提供两个HTTP接口，一个处理批量上行，一个处理变更拉取。

关键点：增量游标。边缘节点和中心云各存一个last_sync_id，每次同步后更新。

@RestController public class EdgeSyncController { @Autowired private JdbcTemplate jdbcTemplate; // 边缘节点主动拉取增量变更（中心云侧接口） @GetMapping("/edge/sync/pull") public List<Map<String, Object>> pullIncremental(@RequestParam long lastSyncId, @RequestParam int limit) { return jdbcTemplate.queryForList( "SELECT * FROM device_events WHERE id > ? ORDER BY id ASC LIMIT ?", lastSyncId, limit ); } // 边缘节点批量上报数据 @PostMapping("/edge/sync/push") public SyncResult pushBatch(@RequestBody List<DeviceEvent> events) { for (DeviceEvent event : events) { jdbcTemplate.update( "INSERT IGNORE INTO device_events (id, device_id, temperature, humidity, capture_time) " + "VALUES (?, ?, ?, ?, ?)", event.getId(), event.getDeviceId(), event.getTemperature(), event.getHumidity(), event.getCaptureTime() ); } return SyncResult.success(events.size()); } }

INSERT IGNORE是MySQL的幂等写入手段之一，重复执行不会报错，只会忽略。边缘侧的任务调度配合定时器，每30秒拉一次增量、上报一次本地缓存，断网时数据保留在本地表中，恢复后自动续传。这个Demo虽然没有做消息队列、没有上Kafka，但整个增量同步、幂等写入、断点续传的骨架都有了。面试时聊清楚这个骨架，比背十个组件名有用得多。

4.3 边缘计算场景下的Java性能优化技巧

边缘节点性能要比中心云服务器弱不少。春招面试时如果能把性能优化细节讲出来，会是很强的加分项。

第一个方向是内存优化。边缘服务器经常只有2GB甚至1GB内存，JVM堆设置要精打细算。使用G1垃圾回收器时，-Xmx不要超过物理内存的50%，留出一部分给堆外内存和Metaspace。另外要特别关注堆外内存的释放，尤其是用Netty做网络通信时，DirectBuffer如果分配过多不释放，会直接导致OutOfMemory。

第二个方向是连接复用。边缘节点到中心云的链路本来就金贵，TCP长连接复用比短连接性能高出一个数量级。HttpClient要设置连接池，数据库连接池也不要用默认参数。比如HikariCP的maximumPoolSize在边缘场景下设为5-10就够用了，而不是常规的50。池太大反而浪费资源，因为流量根本到不了那么高。

第三个方向是批量化。边缘侧的每一次网络请求都有成本，把多条记录合并成一个批次提交，效果立竿见影。比如上面的Demo里，pushBatch接口一次接收一个JSON数组，边缘侧的采集线程攒够100条或者每5秒钟批量上报一次。批量化之后，同样的数据量，网络请求次数减少到原来的百分之一。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

这部分是我在实际项目里踩过的坑，整理成速查表，给有需要的人直接对照。

5.2 我踩过的几个典型的坑

第一个坑是时区问题。边缘节点分布在不同的物理位置，设备的时区配置五花八门。我遇到过一次线上事故：华东的节点上报时间都是北京时间，华西的节点上报时间却用了UTC。两边的数据合到一个表里，排序乱了，对账任务也报了一堆差异。排查了半天，最后定位到是边缘网关在初始化时读的是设备的本地时区，而设备出厂默认是UTC。后来统一规定：所有边缘节点一律用UTC时间存储，展示层再转本地时区。这个规范一定要在项目启动时就定好，不然后期改数据的成本极高。

第二个坑是主键冲突导致静默丢数据。我当时用的同步方案是从边缘侧读取自增ID，目标端也插入这个ID。一开始跑得好好的，后来某个边缘节点的ID发生了回退，插入时撞上了目标端已有的主键，报错后默认被捕获并干掉了。问题在于这个"干掉"太安静，没有告警，导致一堆数据无声丢失。后来在同步逻辑里加了一个规则：插入冲突时不能直接丢弃，要放到重试表，让对账任务去核对。这个改动救了很多次场。

第三个坑是Kafka消费组重平衡太频繁。边缘侧同步任务消费者数量多，Kafka broker可用性不稳定时会不断触发rebalance，每次rebalance期间消费停顿，同步延迟飙高。排查后确认是消费者心跳超时阈值设得太小，边缘侧网络抖动一下，broker就以为消费者挂了。把session.timeout.ms和heartbeat.interval.ms调大之后，问题明显缓解。

第四个坑是边缘节点掉电恢复后的补数风暴。断电恢复后，边缘节点本地积压了几万条数据。恢复同步那一刻，所有线程同时去抢带宽，把家里的上行链路打满了，结果连正常的监控探针都发不出去。解决办法是分批限速同步：每次只同步1000条，同步完等1秒再同步下一批，让带宽留出余量。这种做法在恢复初期看似慢，但十几分钟之内就能把积压追平，整体上反而更稳。

5.3 排查链路的基本方法论

碰到数据同步故障，我现在的排查顺序非常固定：先看游标、再看队列、最后看目标端。

游标是增量同步的命根子。last_sync_id停在哪里，数据就推到哪里。第一步先去Redis或数据库里看游标值，如果游标不动了，说明链路源头就堵了，后续排查往下走。

队列看的是消息积压。查看Kafka的消费Lag指标，如果Lag持续增长，说明消费者处理速度跟不上，优先查目标端的写入性能，看看是不是有慢SQL或者锁等待。

目标端看的是幂等结果。检查唯一索引冲突次数、重试表里的积压量。重试表积压变大，一定是同步任务在目标端反复失败，这时候把任务扔到本地模拟运行一遍，看错误日志就清楚了。

这套方法论可能不算高深，但胜在稳定，每条线索都有对应的检查手段，不会像无头苍蝇一样乱撞。

6. 面试回答框架与复盘心得

6.1 如果重新回答这道题，我会怎么说

经过这次复盘，我自己总结了一个回答框架，下次再被问到这种跨领域问题，我会按四层结构来答。

第一层，定义问题。先澄清边缘计算节点的形态（不一定是机房），明确这个场景的网络、算力、数据量约束。这一步让面试官知道你不是在背书，而是在分析问题。

第二层，拆解数据同步。讲清楚数据同步的难点（弱网、断网、时钟漂移、异构数据），再说方案（增量同步工具如Canal/MongoShake/SQL Server CDC，配合幂等写入、版本控制、补偿任务），最后落到Java实现（可参考上面那个增量同步Demo的骨架）。

第三层，拆解计算卸载。先说明卸载本质是算力资源的动态调度，再讲决策维度（延迟预算、带宽、能耗、数据体积），然后讲执行层的异步化（CompletableFuture + MQ），最后抛一个实际案例，比如工业相机缺陷检测从本地上移到边缘节点的性能对比。

第四层，收束到个人经验。举一个自己在真实项目里踩过的坑（比如掉电恢复后的补数风暴），这说明你真的做过，而不是从面经里背来的。

这个框架的好处是：每一层都有明确的细节支撑，面试官想深挖哪一层你都有东西可聊。最怕的是概念讲了一大堆，一追问落地细节就哑火。

6.2 最后分享一点个人的实际体会

面试时聊到"边缘计算的数据同步和计算卸载"，我最大的感悟是：这类问题不是考察你会不会某一个具体技术，而是考察你有没有形成"在约束下做架构决策"的思维方式。边缘节点算力有限、带宽有限、网络质量不稳定，这三个约束一摆出来，所有"标准答案"都失效了，你必须回到问题的本质去设计链路。这和平时写CRUD很不一样，CRUD的约束相对少，方案往往有固定模板；而边缘计算逼着你去做真正的权衡。

另一个体会是：拿到这类问题，千万不要被名词吓住。数据同步的核心就三件事——从哪里拿增量、怎么保证不重不漏、断了怎么恢复；计算卸载的核心也三件事——什么任务需要卸、往哪卸、卸完怎么把结果拿回来。把这三件事答清楚，概念名词只是附加分。

得物那次面试虽然没有走到最后，但这个问题让我把边缘计算这块知识彻底补齐了，也算没白跑一趟。如果你也在准备面试，建议把这个题目当作一个引子，顺着"数据一致性"和"任务调度"两条线继续深挖，收获会比背一百道八股文大得多。