如何解决分布式id精度损失

Long型数据id传给前端精度丢失问题 今天将文章类的数据传给前端时，发现前端接受的数据id不一样 如前端获得的id=1405916999732707300,数据库的是id=1405916999732707330 @Data public class ArticleVo { 原来是分布式`id `比较长，传到前端解析不完全 会有**精度损失**，必须转为`string`类型 进行传输，就不会有问题。

id传到前端精度丢失 防止前端 精度损失 把id转为string 分布式id 比较长，传到前端 会有精度损失，必须转为string类型 进行传输，就不会有问题了 @JsonSerialize(using = ToStringSerializer.class) private Long id; ...

参考网址： https://blog.csdn.net/myth_g/article/details/85223291

Golang中的精度丢失问题及解决方案

基于深度学习的Reid主要流程为输入图像-->CNN(提取特征)-->Global average pooling-->特征向量，将用这些特征来衡量图像的相似情况。并用这些特征进行检索，返回分类情况。 在训练网络的时候需要涉及损失函数，因此就引出了表征学习和度量学习。这篇文章就是帮助学习理解这两类损失函数的理论。

论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》介绍了谷歌开发的大规模分布式系统跟踪基础设施Dapper。Dapper旨在通过提供跨多个服务和计算机的详细跟踪信息，帮助开发人员理解和调试复杂的分布式系统。论文讨论了Dapper背后的动机、其架构以及在诊断性能问题和优化分布式系统方面所提供的实际好处。本文作为回顾经典，重新学习，翻译的同时加入一些现有的理解。

分布式推理系统面临通信瓶颈、负载不均衡等核心挑战。通信优化需从硬件（NVLink/RDMA网络）、算法（FP8量化、稀疏通信）和架构（拓扑感知拆分）三个维度突破，目标将通信耗时占比降至15%以下。负载不均衡问题可通过非均匀层拆分和动态调度解决，使各设备计算耗时差异控制在10%以内。关键技术包括：异步通信重叠计算、热点数据本地化部署、按耗时比例分配模型层等。实践表明，综合应用这些方案可使64卡集群吞吐量接近线性扩展，RDMA带宽利用率稳定在70%-80%。

*问题描述：**MybatisPlus默认雪花算法生成id策略，生成的id为19位，而前端网页界面js能处理的数值长度最多为16位，从而会造成id从前端返回后端会出现精度丢失，以至于后端根据id修改数据时修改失败。**问题解决方法：**1、提供对象转换器JacksonObjectMapper，基于jackson进行Java对象到json数据的转换。2、在配置类中扩展springmvc的消息转换器，在此消息转换器中使用提供的对象转换器进行Java对象到Jackson数据的转换。

1.后端传递id超18位或者过长会导致id精度丢失，如：id:1798613978827898880,可能会变更为：1798613978827898890或者丢失更多位，那么我们需要通过BigInt来解决，采用BigInt获取到的数据会是这样：1798613978827898880/n那么我们需要将获取到的数据转为字符串在通过replace("n"," ")的形式获取到正确的id，完整代码 BigInt(row.id).toString().replace("n", "")，// // 处理精度丢失id。

深度学习中的损失函数

出现这种问题的原因是，前端JS导致的id精度丢失的问题，前端JSON字符串转js对象，接收Long类型的是Number，Number精度是16位（雪花ID是19位），JS的Number数据类型导致精度丢失。 这个问题是在利用雪花算法生成id后，传给前端，当前端将这个长度超出自己处理范围（自己仅能处理16位的）的19位id向后台传的过程中，发生了精度丢失。 那么看到一位优秀的博主把问题说的很好，我这里就部分借鉴一下，原文链接在这里： 雪花算法⽣成ID传到前端之后精度丢失问题_锦年JNian的博客-.

前端接收数据类型为number类型, 最大为16位, 如果后端 id 大于16位, 则会出现 精度丢失 问题, 如雪花算法 id 为18位, 就会出现 精度丢失，在对长度较长的长整型数据进行处理时会损失精度， 从而导致提交的id和数据库中的id不一致

ID精度损失处理方案：Long类型转换成JSON的String类型

后端返回接受前端Date类型解决 后端返回过长Id导致Js中Number类型接收不住发生精度丢失

1.概要 在项目（vue+antD）开发过程中，遇到获取后端分布式唯一ID精度丢失的问题。 原因： javascript 的 Number 类型最大长度是17位；mysql 使用bigint 类型长度是20位,传递到前端会被浏览器用原始的那个json parse方法转换丢失部分数据，浏览器中的Preview上会看到错误结果数据。 解决方案：1、调用第三方插件加工数据，jsonlint.js（已用于生产环境） 2、前端转换成string类型（最终没采用） 2.代码 第一种： 定义工具方法 jsonlint

1.后台的属性类型是long，前台展示时需要（用?c）进行格式化，否则会显示为：100,000,000这种带逗号分隔的形式 <input type="hidden" id="petdId" name="petdId" value="${((testDomainPO.petdId)?c)!''}"/> 2.后台的属性类型是String ，前台往后台传参数时，需要加引号，否则会丢失...

有时我们使用雪花算法设置ID，会遇到前端页面传送的id与数据不一致的情况。 在分页查询时，服务端会将返回的R对象进行json序列化，转换为json格式的数据，而员工的ID是一个Long类型的数据，而且是一个长度为 19 位的长整型数据， 该数据返回给前端是没有问题的。 那么具体的问题出现在哪儿呢？ 问题实际上， 就出现在前端JS中， js在对长度较长的长整型数据进行处理时，页面js处理long类型只能精确到16位，所以 会损失精度， 从而导致提交的id和数据库中的id不一致。 解决方案： 1、要想