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