前言

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

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

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

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

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

02 問題的根因是什么

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

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

03 類似的問題有哪些

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

千年蟲問題：

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

2038 年問題：

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

04 小結(jié)

對(duì)于發(fā)現(xiàn)的缺陷，不能僅停留在把問題解決了就完事。有時(shí)間和精力，還是需要更深層次的去了解缺陷背后的邏輯和根因是什么，觸類旁通。以避免更多類似的問題發(fā)生。

在寫這篇文章的時(shí)候，又想起了自己以前做報(bào)表相關(guān)的業(yè)務(wù)時(shí)，對(duì)于時(shí)間的精度特別敏感，也會(huì)遇到一些關(guān)于精度上的取舍問題，這需要我們和業(yè)務(wù)方面討論并確認(rèn)清楚，是精確到秒，還是毫秒，以避免出現(xiàn)數(shù)據(jù)邊界的小問題。

以上就是ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問題的詳細(xì)內(nèi)容，更多關(guān)于ES數(shù)據(jù)遷移精度BUG的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！