強力なJavaScriptによりスノーフレークアルゴリズムが実現

[[353520]]

この記事はWeChat公式アカウント「妹の味」から転載したもので、著者は妹が飼っている犬です。記事を転載する場合は、ミスシスターテイスト公式アカウントまでご連絡ください。

それは正しい。フロントエンドは、バックエンドをピットインするために使用されます。

ここではそのような恥知らずな発言しかできません。 xjjdog のスキルは主にバックエンドに反映されるため、彼は犬も愛しています。これは、苦労が人間の基本的な属性であることを示しています。プログラマーは、製品マネージャーやプロジェクト マネージャーであるだけでなく、内部的に単一のグループではありません。

しかし、今回議論する問題は実は非常に難しいものです。それはシステム全体をほぼ破壊し、不機嫌な上司の顔にニキビが爆発する原因となった。

その影響はこれに限定されません。業界全体への拡大：

かつては大金を稼げた人たちが破産した。

本来なら結婚できた人たちも別れた。

昔はサボることができた人たちが、今では残業している。

かつてフロントエンドで働いていた人たちが、今はバックエンドで働いています。

本来退職できるはずだった人たちも退職を延期している。

もともと生きていた人たちは亡くなってしまいました。

以前は週に2日休みがありましたが、今は長い週と短い週があります。

素晴らしい js がなぜこんなに強力なのか? 詳しく説明するので聞いてください。

1. すべてには理由がある

タイトルにあるように、これはスノーフレーク アルゴリズムに関連します。

当社ではMySQLデータベースを使用するシステムを採用しており、データベースの主キーを選択する際に自動増分IDを使用しています。

 ID INT   主要な キー自動増分

この種の ID はシンプルでスムーズですが、いくつかの欠点があります。ただし、一般的なシステムには十分です。

プロジェクトチームは、オンラインになる前に、社内で最も優秀な建築家を招き、プロジェクトの包括的な物理的検査を実施しました。重要な対策の 1 つは、ID ジェネレーターを対象としています。

「現在の開発システムでは、少なくとも ID ジェネレーターとして Snowflake を使用する必要があるのではないでしょうか?」アーキテクトは、自己増分 ID ソリューションに非常に不満でした。

システムの拡張、データベースとテーブルのシャーディング、データの移行などのシナリオに遭遇した場合、UUID を使用する場合でも、自己増分 ID よりも優れていることを指摘しています。

みんなで話し合った結果、とても合理的だと感じました。 UUID は乱雑すぎるし、Meituan Leaf は複雑すぎる。時代遅れの Snowflake を使用して、最も単純な ID を直接生成する方がよい。

こんな感じです。

 527574217068392807
 527574217068392808

直感的に理解できるように、Java の Long の最大値を見てみましょう。

 9223372036854775807

Intの最大値を見てみましょう。

 2147483647

生成された Snowflake ID は、Int よりも大きいが Long よりも小さい値 (最大のものと比較) であることがわかります。そのため、データベースに保存するには bigint を使用するのが最適です。

とにかくやってみてください。バッチスクリプトを変更すると、主キーはより大きくなり、長くなります~~~

2. 問題が発生する

言うまでもなく、この種の ID は見た目も非常に美しいです。 ID は URL とフォームデータで渡されるため、一見するとよりプロフェッショナルに見えます。

 /edit.do?id=527574217068392810

提案どおりにシステムを変更した後、ユニットテストはスムーズに進みました。ブラック ボックス テストは簡単にクリックしただけで合格とみなされました。

超常現象は依頼人によって発見された。

顧客は、多くのレコードを編集または削除できなかったと述べました。記録が見つからないとのことです。

多くの企業の本質はご存知でしょう。顧客とコミュニケーションをとる人たちは、たいていテクノロジーをあまりよく理解していません。私は素晴らしい携帯電話で顧客の画面の写真を撮りましたが、受け取った元の写真のサイズは 10 MB を超えていました。しかし不思議なのは、写真は大きいのに内容がぼやけているということです。

バックエンドプログラマーは目を細めて画像を開き、そこに表示されているIDを抽出し、システムで確認しました。

そのような記録はありません。

目を細める姿勢に何か問題があるに違いない。バックエンドプログラマーはそれを再度記録する必要がありました。残念ながら、これに関する記録はまだありません。

顧客のデータベースをコピーする以外に選択肢はありませんでした。ページをクリックしてみると、確かに問題があることがわかりました。

ブラウザのレスポンスで返されるデータはプレビューで返されるデータと異なります

3. 問題の検証

つまり、正しい数字 527183991665594368 は、ブラウザによって変換されると 527183991665594400 になります。

ブラウザの開発ツールでデバッグしてみましょう。

さらに検証するために、Typescript から js に試してみます。

 # 猫テスト.ts
 a = 527183991665594368 とします。
コンソールにログ出力します。
 # tsc テスト.ts
 # 猫テスト.js
 var a = 527183991665594368;
コンソールにログ出力します。
 # ノードテスト.js
 527183991665594400

この問題は js エコシステム全体に存在し、バックエンドを台無しにしていることがわかります。

4. なぜですか?

理由はこうです。 JavaScript には 2 種類の数値があります。 Number と BigInt。最もよく使われるのは数字です。

最大の数値は Number.MAX_SAFE_INTEGER と呼ばれ、その値は次のとおりです。

2^53-1または

+/- 9,007,199,254,740,991

ご存知のとおり、Java の Long は 64 ビットです。 Js のこの安全な整数は、Java で定義された長さにまったく達しません。

これは、Long の長さが 17 ビットを超えると精度が低下するという、悪質な IEEE_754 仕様です。

最新の TypeScript 3.2 では、エンコードに BigInt 型を直接使用したり、カプセル化された long.js を使用したりすることもできますが、それでも面倒でコーディングが多すぎるため、見逃してしまう可能性があります。

デジタルタイプを使用してデータを送信することは、実際にはあまり信頼性が高くありません。多くの紆余曲折を経て、状況はまったく異なります。

最善の方法は、文字列を使用して渡すことです。将来的にバックグラウンド ID の長さが 128 ビットになったとしても、この変換を気にする必要はありません。

Java では、Jackson を使用すると、データベースを変更せずに、アノテーションを通じて文字列を直接変更できます。

 @JsonSerialize(ToStringSerializer.class を使用)
プライベートな Long ID;

この問題は明らかにバックエンドのせいではありません。バックエンドは正しいデータをフロントエンドに渡します。処理できるかどうか、正しく処理されるかどうかは、バックエンドとはまったく関係ありません。この仕様に従った JS の非標準的な処理により、多くの人が罠に陥っています。新人であろうとベテランであろうと、次々と罠に落ちていく。この特徴は実に反人間的だと言わざるを得ない。

しかし、バックエンドでは解決できました。フルスタックルートを取るように誰が言ったのでしょうか? 必要であれば、製品作業も行えます!

著者について: Sister Taste (xjjdog)、プログラマーが寄り道をすることを許可しない公開アカウント。インフラストラクチャと Linux に重点を置きます。 10 年間のアーキテクチャと 1 日あたり数千億のトラフィックを基に、私たちはお客様とともに高並行性の世界を探求し、新たな体験をお届けします。私の個人 WeChat は xjjdog0 です。今後のコミュニケーションのために、ぜひ私を友達として追加してください。