快捷導(dǎo)航

ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問題BUG

更新時間：2022年06月21日 14:05:10 作者：CKL的思考空間

這篇文章主要為大家介紹了ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問題，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

前言

最近在協(xié)助團隊完成 ES 數(shù)據(jù)的切換（業(yè)務(wù)數(shù)據(jù)遷移），過程中遇到一個比較好玩的 BUG ，和大家分享并作為經(jīng)驗記錄。

01 問題發(fā)現(xiàn)過程

通過前期的方案設(shè)計和比較，我們決定通過 elasticdump 工具來做 ES 的數(shù)據(jù)遷移，這個也是比較普遍的遷移方案，于是就動手實施了，過程中也沒遇到什么問題。在最后的數(shù)據(jù)驗證環(huán)節(jié)，發(fā)現(xiàn)有一個 ID 對應(yīng)不上了，如下圖所示，通過對比工具，發(fā)現(xiàn)一個長度較大的 ID 發(fā)生了偏移，其他的數(shù)據(jù)都沒有問題。這是為什么呢？一頭霧水。

根據(jù)二分法的排錯思路，我們需要先確認(rèn)是導(dǎo)出數(shù)據(jù)的問題，還是導(dǎo)入數(shù)據(jù)的問題。查看導(dǎo)出過程的中間文件，發(fā)現(xiàn)在導(dǎo)出的時候就出現(xiàn)了錯誤。于是懷疑是 elasticdump 導(dǎo)出功能的問題。因為這個出錯的字段，主要的特征就是長度比較長（18 位），于是懷疑是精度的問題。就去查了下 elasticdump 的源碼，一番查找后，果然發(fā)現(xiàn)有人遇到過同樣的問題，并已經(jīng)修復(fù)了這個 BUG，并給出了解決方案和一些猜測的原因。于是這個問題就得到了解決。在 elasticdump 的導(dǎo)出命令中，加上－-support-big-int 參數(shù)，就可以了。

好像也很簡單嘛，不是么。其實排錯的過程也走過很多彎路，只是現(xiàn)在回顧起來看著比較輕松而以。

02 問題的根因是什么

只解決問題并不是我的風(fēng)格，總得看看讓我繞這么大圈才解決的問題根因是什么嘛。于是查了相關(guān)資料（結(jié)合上面 GIT 上的對話），可以確認(rèn)，是因為 elasticdump 中有部分功能是用 JS 寫的，而 Js 遵循 IEEE754 規(guī)范，采用雙精度存儲，占用 64 位，從左到右的安排位第一問表示符號位，11 位表示指數(shù)，52 位來表示尾數(shù)，因此 Js 中能精確表示的最大整數(shù)是 253（十進(jìn)制為 9007199254740992），那么大于這個數(shù)（本文中數(shù)值長度 18 位）就可能會丟失精度，因為二進(jìn)制只有 0 和 1，數(shù)值太大，于是就出現(xiàn)了精度丟失的問題?？梢栽?Chrome Console 里面試了一下，果然是這樣，（不是超過了能表示的最大值，而是超過了能精確表示的最大值），和 elasticdump 導(dǎo)出的數(shù)據(jù)變化基本類似。

再往深了想，為什么用 double 類型會出現(xiàn)這個問題，其他的數(shù)據(jù)類型是否會有同樣的問題呢？這就涉及了數(shù)據(jù)精度的問題，在這里篇幅有限，就不再展開，有興趣的同學(xué)可以自己去查看相關(guān)資料，本質(zhì)上還是十進(jìn)制小數(shù)與二進(jìn)制小數(shù)相互轉(zhuǎn)換產(chǎn)生的誤差。

03 類似的問題有哪些

因為這個問題比較好玩，就又找了一些資料看了下，發(fā)現(xiàn)還有兩個精度有關(guān)的 BUG，還蠻好玩的。

千年蟲問題：

這個問題相信很多人 IT 人都聽說過，簡單來說，就是由于前期計算機的存儲資源較為昂，在表達(dá)時間時，為了節(jié)約空間，有位科學(xué)家提出了一個方案，把1960年8月11日，簡寫成 600811。但這樣會有一個問題，就是當(dāng)時被縮寫掉的是 19XX 年中 19，如果時間來到 2000 年，程序就無法準(zhǔn)確表達(dá)時間。比如：2000年1月1日，簡寫成六位數(shù)是 000101。計算機就會懷疑人生，怎么時間倒流了呢？然后就會導(dǎo)致計算機系統(tǒng)發(fā)生紊亂。當(dāng)時大家都覺得自己的程序不會運行到 2000 年，所以就沒太放在心上，而大多數(shù)后來人習(xí)慣了這種記錄方式，就忘記了這回事，結(jié)果引發(fā)了千禧年的大 BUG，造就了多少程序員的不眠之夜。

2038 年問題：

現(xiàn)在很多時候，我們在處理時間問題時，都喜歡用時間戳來記錄，因為簡單方便，不需要考慮時區(qū)問題（時區(qū)問題很讓人頭疼的，一不小出就容易出錯）。但是這里面會有一個小 BUG 喲。什么是時間戳呢？簡單來說就是：以1970年1月1日0 時 0 分 0 秒為起點，然后通過計算秒數(shù)來算出當(dāng)前時間。比如：2021年5月7日15:00:00，換算一下就是 1620370800 秒。但是由于 32 位操作系統(tǒng)所能計算的秒數(shù)有限，到2038年1月19日3:14:07，就會達(dá)到極限。二進(jìn)制：01111111 11111111 11111111 11111111，其后一秒，二進(jìn)制數(shù)字會變?yōu)?10000000 00000000 00000000 00000000，發(fā)生溢出錯誤，造成系統(tǒng)將時間誤解為1901年12月13日20 時 45 分 52 秒，然后系統(tǒng)就會發(fā)生各類錯誤，是不是和上面的千年蟲一樣？理論上到了 2038 年，人們應(yīng)該淘汰掉了 32 位操作系統(tǒng)， 64 位操作系統(tǒng)就不存在這個問題。但是從前面的 “千年蟲” 事件來看，人類從歷史中吸取的唯一教訓(xùn)，就是人類不會吸取任何教訓(xùn)。