牛氣的JavaScript，讓雪花算法成為空氣
本文轉(zhuǎn)載自微信公眾號「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。
沒錯。前端，就是用來坑后端的。
我也只能在這里，發(fā)表這樣無恥的言論。因為xjjdog的修為主要體現(xiàn)在后端上，所以愛屋及烏。這體現(xiàn)了斗爭是人類的基本屬性：程序員除了要干產(chǎn)品經(jīng)理、項目經(jīng)理，內(nèi)部也并不是鐵板一塊。
不過這次要聊的問題，確實是很坑。它幾乎斷送了整個系統(tǒng)，讓暴躁的老板臉上爆炸式的長滿了痘痘。
它的影響不限于此。擴大到整個業(yè)界：
原來能發(fā)財?shù)模飘a(chǎn)了。
原來能結(jié)婚的，分手了。
原來能摸魚的，加班了。
原來搞前端的，搞后端了。
原來能退休的，延期了。
原來能活著的，去世了。
原來能雙休的，大小周了。
為什么牛氣的js，會有這么大的威力?請聽我細細道來。
1. 事出有因
就如標題所說，這個會和雪花算法有關(guān)。
我們有個系統(tǒng)，使用的是MySQL數(shù)據(jù)庫，所以在數(shù)據(jù)庫的主鍵選擇上，使用的是自增ID。
- ID INT PRIMARY KEY AUTO_INCREMENT
這樣的ID簡單流暢，但有一系列的弊端，不過用在一般的系統(tǒng)上，夠用了。
在臨上線之前，項目組邀請公司里最牛x的架構(gòu)師，對項目進行了一次集中體檢。其中的一項重要舉措，就是針對于ID生成器的。
“不知道現(xiàn)在的開發(fā)系統(tǒng)，都至少要使用Snowflake作為ID生成器么?” 架構(gòu)師對自增ID的方案非常的不滿意。
它指出，哪怕你使用UUID，在遇到系統(tǒng)擴容、分庫分表、數(shù)據(jù)遷移等場景的時候，也比自增ID強。
大家伙一討論，覺得非常合理。UUID太無序，美團Leaf這種又太復雜，還不如直接使用老掉牙的Snowflake，直接生成最簡單的ID即可。
類似于這種。
- 527574217068392807
- 527574217068392808
為了讓你有個直觀的認識，我們看一下Java中Long的最大值。
- 9223372036854775807
再看一下Int的最大值。
- 2147483647
可以看到生成的Snowflake ID，是比Int大，比Long小的數(shù)值(和最大的比較)，所以在數(shù)據(jù)庫中使用bigint存儲，再好不過了。
說干就干，批量腳本一改，主鍵就變大變長了~~~
2. 問題發(fā)生
別說，這樣子的ID，看起來還比較順眼。ID在URL里傳遞，在formdata里傳遞，一看就比較的專業(yè)！
- /edit.do?id=527574217068392810
系統(tǒng)按照建議改完之后，單元測試很流暢。黑盒測試草草的點了一下，就算通過了。
靈異事件是被客戶發(fā)現(xiàn)的。
客戶說，很多記錄，無法編輯、無法刪除。提示找不到記錄。
很多公司的尿性你也是知道的，和客戶交流的，通常不太懂技術(shù)。對著客戶的屏幕用牛x的手機拍照，原圖發(fā)過來就有十幾MB。但靈異的是圖片大，內(nèi)容卻模模糊糊。
后端程序員，瞇著眼睛打開圖片，把里面顯示的ID給摳出來，放在系統(tǒng)里一查。
沒有此記錄。
肯定是瞇眼的姿勢有問題。后端程序員不得不再錄一遍。可惜的是，依然沒有這條記錄。
沒辦法，只好把客戶的數(shù)據(jù)庫拷貝一份過來。頁面上一點擊，果然有問題!
瀏覽器response里返回的數(shù)據(jù)竟然和preview里的不一樣
3. 問題驗證
也就是說，一個好好的數(shù)字：527183991665594368，經(jīng)過瀏覽器一翻譯，變成了527183991665594400。
我們在瀏覽器的devtools里面調(diào)試一下。
為了進一步驗證，我們從typescript到j(luò)s，都試驗一下。
- # cat test.ts
- let a = 527183991665594368;
- console.log(a);
- # tsc test.ts
- # cat test.js
- var a = 527183991665594368;
- console.log(a);
- # node test.js
- 527183991665594400
可以看到，在整個js的生態(tài)里，都存在這個問題，真是坑壞了后端。
4. Why?
這是因為。在JavaScript中，存在兩種數(shù)字。Number和BigInt。最常用的，就是number。
最大的Number，叫做Number.MAX_SAFE_INTEGER，它的值為：
2^53-1 或者
+/- 9,007,199,254,740,991
眾所周知，Java中的Long，是64位的。Js中的這個安全Integer，完全達不到Java中定義的長度。
這就是萬惡的IEEE_754規(guī)范，它在Long長度大于17位時會出現(xiàn)精度丟失的問題。
在最新的TypeScript3.2中，可是直接使用BigInt這個類型進行編碼，或者使用long.js這種封裝后的苦，但還是太麻煩了，需要編碼太多，而且還可能漏掉。
使用數(shù)字類型，傳輸數(shù)據(jù)，實在是不太靠譜，轉(zhuǎn)來轉(zhuǎn)去，就物是人非了。
最好的方式，就是使用string進行傳遞。哪怕以后后臺ID的長度變成了128位的，也不懼怕這種轉(zhuǎn)換。
在Java中，如果你用的是jackson，直接通過注解，就可以完成字符串更改，不需要再改動數(shù)據(jù)庫。
- @JsonSerialize(using=ToStringSerializer.class)
- private Long id;
這問題，明顯不是后端的鍋。后端傳遞了正確的數(shù)據(jù)到前端，能不能處理、處理的正確不正確，根本和后端一點關(guān)系都沒有。JS的這種按照規(guī)范的不規(guī)范處理，已經(jīng)讓很多人踩坑。不管是萌新，還是老鳥，依然前赴后繼的掉到坑里，不得不說這個特性是非常反人類的。
不過，我們還是在后端解決了。誰讓咱走的是全棧路線呢?必要時，連產(chǎn)品的活兒都能做!
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
