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