IdGenerator
1.0.0
Menanggapi pertanyaan kinerja yang sering muncul selama penggunaan, saya memberikan tiga rangkaian praktik terbaik berikut:
❄ Jika persyaratan pembuatan ID tidak melebihi 5W/s, tidak perlu mengubah parameter konfigurasi apa pun.
❄ Jika melebihi 5W potongan/dtk dan kurang dari 50W potongan/dtk, disarankan untuk memodifikasi: SeqBitLength=10
❄ Jika melebihi 50W bit/s dan mendekati 500W bit/s, disarankan untuk memodifikasi: SeqBitLength=12
Singkatnya, meningkatkan SeqBitLength akan menghasilkan kinerja yang lebih baik, namun ID yang dihasilkan akan lebih panjang.
❄ Ini adalah algoritme kepingan salju yang dioptimalkan (snowflake drift), yang menghasilkan ID yang lebih pendek dan lebih cepat.
❄ Mendukung perluasan otomatis lingkungan kontainer seperti k8s (pendaftaran otomatis WorkerId), dan dapat menghasilkan ID unik digital dalam lingkungan yang berdiri sendiri atau terdistribusi.
❄ Secara asli mendukung C#/Java/Go/C/Rust/Python/Node.js/PHP (ekstensi C)/SQL/ dan bahasa lainnya, dan menyediakan panggilan perpustakaan dinamis (FFI) yang aman dan multi-thread.
❄ Kompatibel dengan semua algoritme kepingan salju (mode segmen angka atau mode klasik, pabrikan besar atau kecil), Anda dapat melakukan peningkatan atau peralihan apa pun di masa mendatang.
❄ Ini adalah alat pembuatan ID Kepingan Salju terlengkap dalam sejarah komputer. 【Per Agustus 2022】
? Sebagai seorang arsitek, Anda ingin memecahkan masalah kunci primer unik dalam sebuah database, terutama dalam sistem terdistribusi dengan banyak database.
? Anda ingin kunci utama tabel data menggunakan ruang penyimpanan paling sedikit, mengindeks lebih cepat, dan Pilih, Sisipkan, dan Perbarui lebih cepat.
? Anda harus mempertimbangkan bahwa ketika membagi database dan tabel (menggabungkan database dan tabel), nilai kunci utama dapat digunakan secara langsung dan dapat mencerminkan waktu bisnis.
? Jika nilai kunci utama seperti itu terlalu panjang dan melebihi nilai maksimum tipe Nomor js front-end, tipe Panjang harus diubah menjadi tipe String, dan Anda akan merasa sedikit frustrasi.
? Meskipun Panduan dapat bertambah secara otomatis, ini memakan banyak ruang dan kecepatan pengindeksan lambat.
? Mungkin ada lebih dari 50 contoh aplikasi, dan setiap permintaan bersamaan dapat mencapai 10W/s.
? Untuk menyebarkan aplikasi dalam lingkungan kontainer, mendukung replikasi horizontal dan perluasan otomatis.
? Anda tidak ingin bergantung pada operasi redis peningkatan otomatis untuk mendapatkan ID kunci primer berkelanjutan, karena ID berkelanjutan menimbulkan risiko keamanan data bisnis.
? Anda ingin sistem beroperasi lebih dari 100 tahun.
ID yang dihasilkan terlalu panjang.
Jumlah konkurensi sesaat saja tidak cukup.
Masalah panggilan balik waktu tidak dapat diselesaikan.
Pembuatan ID praorder pasca-tambahan tidak didukung.
Mungkin mengandalkan sistem penyimpanan eksternal.
✔ Bilangan bulat, bertambah secara monoton sepanjang waktu (tidak harus terus menerus), panjangnya lebih pendek, dan tidak akan melebihi nilai maksimum jenis Angka js dalam 50 tahun. (konfigurasi bawaan)
✔ Lebih cepat, 2-5 kali lebih cepat daripada algoritma kepingan salju tradisional, 500.000 dapat dihasilkan dalam 0,1 detik (berdasarkan i7 tegangan rendah generasi ke-8).
✔ Mendukung pemrosesan panggilan balik waktu. Misalnya, jika waktu server dimundurkan 1 detik, algoritma ini dapat secara otomatis beradaptasi untuk menghasilkan ID unik untuk waktu kritis.
✔Mendukung penyisipan ID baru secara manual. Ketika bisnis perlu membuat ID baru dalam waktu historis, bit yang dicadangkan dari algoritme ini dapat menghasilkan 5.000 ID per detik.
✔ Tidak bergantung pada cache atau database eksternal apa pun. (Perpustakaan dinamis yang secara otomatis mendaftarkan WorkerId di lingkungan k8s bergantung pada redis)
✔ Fungsi dasar, siap digunakan, tidak memerlukan file konfigurasi, koneksi database, dll.
(Parameter: urutan peningkatan otomatis 10-bit, nilai maksimum penyimpangan 1000)
| Permintaan terus menerus | 5K | 5W | 50W |
|---|---|---|---|
| Algoritma kepingan salju tradisional | 0,0045 detik | 0,053 detik | 0,556 detik |
| Algoritma penyimpangan salju | 0,0015 detik | 0,012 detik | 0,113 detik |
? Performa terbaik: 500W/dtk~3000W/dtk. (Semua data pengujian dihitung berdasarkan i7 tegangan rendah generasi ke-8)
? Ketika dialback waktu sistem terjadi, algoritme menggunakan nomor urut yang dicadangkan dari rangkaian waktu yang lalu untuk menghasilkan ID baru.
? Nomor ID yang dihasilkan oleh panggilan balik ditempatkan terlebih dahulu secara default, dan juga dapat disesuaikan nanti.
? Berikan waktu untuk diatur kembali ke dasar preset algoritma ini (parameter dapat disesuaikan).
? ID yang dihasilkan oleh algoritma ini adalah bilangan bulat (menempati ruang hingga 8 byte). Berikut ini adalah ID yang dihasilkan berdasarkan konfigurasi default:
129053495681099 (运行1年，长度：15)
387750301904971 (运行3年，长度：15)
646093214093387 (运行5年，长度：15)
1292658282840139 (运行10年，长度：16)
9007199254740992 (运行70年，达到 js Number 最大值，长度：16)
165399880288699493 (运行1000年，等同普通雪花算法运行1年，长度：18)
? Nilai ID yang dihasilkan oleh algoritma ini adalah 1%-10% dari nilai maksimum js Number, yang merupakan seperseribu dari nilai algoritma kepingan salju biasa, namun kecepatan pembangkitannya lebih cepat dari algoritma kepingan salju biasa.
? Nilai maksimum jenis Nomor js: 9007199254740992. Algoritme ini memerlukan waktu 70 tahun untuk mencapai nilai js Number Max dengan tetap mempertahankan kinerja konkurensi (5W+/0,01s) dan maksimum 64 WorkerIds (6bit).
? 每增加 1位 WorkerIdBitLength 或 SeqBitLength，生成的ID数字值将会乘以2（基础长度可参考前一节“ID示例”），反之则除以2。
Penjelasan berapa lama dapat digunakan mengacu pada kapan nomor ID yang dihasilkan dapat bertambah melebihi nilai maksimum long (ditandatangani 64 bit, 8 byte).
• Dalam konfigurasi default, tersedia 71000 ID unik.
? Saat mendukung 1024 node pekerja, ID tersedia selama 4480 tahun tanpa duplikasi.
? Saat mendukung 4096 node pekerja, ID tersedia selama 1120 tahun tanpa duplikasi.
❄ WorkerIdBitLength , panjang bit kode mesin, menentukan nilai maksimum WorkerId, nilai defaultnya adalah 6 , dan rentang nilainya adalah [1, 19]. Faktanya, beberapa bahasa menggunakan tipe unsigned ushort (uint16) untuk menerima parameter ini, jadi nilai maksimumnya adalah 16. Jika digunakan If bertanda pendek (int16), nilai maksimumnya adalah 15.
❄ WorkerId , kode mesin, parameter terpenting , tidak ada nilai default, harus unik secara global (atau unik dalam DataCenterId yang sama), harus disetel secara terprogram , kondisi default (WorkerIdBitLength mengambil nilai default), nilai maksimum adalah 63, nilai maksimum teoritis adalah 2^WorkerIdBitLength -1 (bahasa implementasi yang berbeda mungkin dibatasi hingga 65535 atau 32767, prinsipnya sama dengan aturan WorkerIdBitLength). Nilai ini tidak boleh sama pada mesin yang berbeda atau contoh aplikasi yang berbeda. Anda dapat mengonfigurasi nilai ini melalui aplikasi atau memperoleh nilai dengan memanggil layanan eksternal. Menanggapi kebutuhan pendaftaran WorkerId secara otomatis, algoritma ini menyediakan implementasi default: secara otomatis mendaftarkan perpustakaan dinamis WorkerId melalui redis, lihat "ToolsAutoRegisterWorkerId" untuk detailnya.
Catatan khusus : Jika server menyebarkan beberapa layanan independen, Anda perlu menentukan WorkerId yang berbeda untuk setiap layanan.
❄ SeqBitLength , panjang bit urutan, nilai default 6 , rentang nilai [3, 21] (disarankan tidak kurang dari 4), menentukan jumlah ID yang dihasilkan per milidetik. Jika jumlah permintaan per detik tidak melebihi 5W, pertahankan nilai default 6; jika melebihi 5W dan tidak melebihi 50W, disarankan untuk menetapkan nilai 10 atau lebih besar, dan seterusnya. Persyaratan aturan: WorkerIdBitLength + SeqBitLength tidak melebihi 22.
❄ MinSeqNumber , nomor urut minimum, nilai default 5, rentang nilai [5, MaxSeqNumber], 5 nomor urut pertama per milidetik sesuai dengan angka 0-4 adalah bit yang dicadangkan, dimana 1-4 adalah bit yang dicadangkan sesuai dengan panggilan balik waktu, 0 adalah bit yang dicadangkan untuk nilai baru secara manual.
❄ MaxSeqNumber , nomor urut maksimum, rentang pengaturannya adalah [MinSeqNumber, 2^SeqBitLength-1], nilai defaultnya adalah 0, nomor urut maksimum sebenarnya adalah nilai maksimum (2^SeqBitLength-1), jika bukan 0 , ini adalah nomor urut maksimum sebenarnya, umumnya tidak perlu disetel, kecuali beberapa mesin berbagi WorkerId untuk menghasilkan ID dalam segmen (dalam hal ini, nomor urut minimum harus disetel dengan benar).
❄ BaseTime , waktu dasar (juga dikenal sebagai: waktu titik dasar, waktu asal, waktu epoch), memiliki nilai default (2020), adalah stempel waktu milidetik (bilangan bulat, .NET adalah tipe DatetTime), fungsinya adalah: gunakan saat membuat ID Perbedaan (dalam milidetik) antara waktu sistem dan waktu dasar digunakan sebagai stempel waktu untuk membuat ID. Biasanya tidak perlu mengatur waktu dasar. Jika Anda merasa nilai defaultnya terlalu lama, Anda dapat mengatur ulangnya. Namun, perlu diingat bahwa yang terbaik adalah tidak mengubah nilai ini di masa mendatang.
Versi kedua berencana menambahkan parameter:
❄ DataCenterId , ID pusat data (ID ruang komputer, default 0), pastikan unik secara global.
❄ DataCenterIdBitLength , panjang ID pusat data (default 0).
❄ TimestampType , jenis stempel waktu (0-milidetik, 1 detik), default 0.
1️⃣ Panggilan dalam mode tunggal. Algoritme ini menggunakan satu thread untuk menghasilkan ID, dan panggilan dari beberapa pihak akan bersifat eksklusif satu sama lain. Dalam contoh aplikasi yang sama, pemanggil menggunakan multi-threading (atau paralel) untuk memanggil algoritma ini, yang tidak akan meningkatkan kecepatan keluaran ID.
2️⃣ Tentukan WorkerId yang unik. Sistem eksternal harus memastikan keunikan global WorkerId dan menetapkannya ke parameter entri algoritma ini.
3️⃣ Gunakan WorkerId yang berbeda saat menerapkan beberapa instance pada satu mesin. Tidak semua implementasi mendukung keunikan serentak lintas proses. Agar aman, saat menerapkan beberapa instance aplikasi pada host yang sama, harap pastikan bahwa setiap WorkerId unik.
4️⃣ Penanganan pengecualian. Algoritme akan membuang semua Pengecualian, dan sistem eksternal harus menangkap pengecualian tersebut dan menanganinya dengan baik untuk menghindari kerusakan sistem yang lebih besar.
5️⃣ Pahami dengan cermat definisi IdGeneratorOptions, yang akan berguna untuk mengintegrasikan dan menggunakan algoritma ini.
6️⃣ Gunakan algoritma penyimpangan salju. Meskipun kode berisi definisi algoritme kepingan salju tradisional, dan Anda dapat menentukan (Metode=2) pada titik masuk untuk mengaktifkan algoritme tradisional, tetap disarankan agar Anda menggunakan algoritme penyimpangan kepingan salju (Metode=1, default) , lagi pula, ia memiliki daya regangan yang lebih baik dan kinerja yang lebih tinggi.
7️⃣ Jangan mengubah algoritma inti. Algoritme ini memiliki banyak parameter internal dan logika kompleks. Jika Anda belum menguasai logika inti, mohon jangan mengubah kode inti dan menggunakannya dalam lingkungan produksi kecuali telah diverifikasi melalui sejumlah besar pengujian yang cermat dan ilmiah.
8️⃣ Kebijakan konfigurasi dalam domain aplikasi sama. Ketika sistem telah berjalan selama jangka waktu tertentu dan proyek perlu beralih dari WorkerId yang ditentukan secara terprogram ke mendaftarkan WorkerId secara otomatis, harap pastikan bahwa semua instance yang digunakan dalam domain aplikasi yang sama mengadopsi strategi konfigurasi yang konsisten , tetapi juga menyertakan parameter konfigurasi lainnya.
9️⃣ Kelola waktu server dengan baik. Algoritma Snowflake bergantung pada waktu sistem. Jangan menyesuaikan waktu sistem operasi secara manual dalam jumlah besar. Jika Anda harus melakukan penyesuaian, ingatlah untuk memastikan bahwa waktu sistem saat layanan dimulai kembali lebih lama daripada waktu terakhir kali layanan dimatikan. (Catatan: Perubahan kecil dalam waktu sistem yang disebabkan oleh sinkronisasi waktu atau panggilan balik kelas dunia atau tingkat jaringan tidak berdampak pada algoritme ini)
Perubahan konfigurasi mengacu pada penyesuaian parameter operasi (properti objek IdGeneratorOptions) setelah sistem berjalan selama jangka waktu tertentu. Harap diperhatikan:
? 1. Prinsip pertama adalah: BaseTime hanya bisa lebih lama (lebih jauh dari sekarang), sehingga nilai ID yang dihasilkan lebih besar dari nilai maksimum historis, memastikan tidak ada waktu yang tumpang tindih dan tidak ada ID duplikat yang dihasilkan. [ Tidak disarankan untuk menyesuaikan BaseTime setelah sistem berjalan]
? 2. Meningkatkan WorkerIdBitLength atau SeqBitLength kapan saja diperbolehkan, namun operasi "penurunan" harus digunakan dengan hati-hati, karena hal ini dapat menyebabkan ID yang dihasilkan di masa mendatang sama dengan konfigurasi lama. [Izinkan nilai xxxBitLength apa pun ditingkatkan setelah sistem berjalan]
? 3. Jika salah satu WorkerIdBitLength atau SeqBitLength harus dikurangi, syaratnya harus dipenuhi: jumlah dua xxxBitLength baru harus lebih besar dari jumlah nilai lama. [ Tidak disarankan untuk mempersempit nilai BitLength apa pun setelah dijalankan]
? 4. Ketiga aturan di atas tidak dikontrol secara logis dalam algoritma ini. Pengguna harus melakukan perubahan konfigurasi setelah memastikan bahwa konfigurasi baru memenuhi persyaratan.
? Generator ID unik bergantung pada WorkerId. Ketika layanan bisnis memerlukan replikasi horizontal dan tidak pandang bulu (ekspansi otomatis), hal ini memerlukan kemampuan untuk secara otomatis mendaftarkan WorkerId yang unik secara global sebelum menghasilkan ID unik.
? Algoritme ini menyediakan pustaka dinamis sumber terbuka (diimplementasikan dalam bahasa Go), yang dapat secara otomatis mendaftarkan WorkerId melalui redis di lingkungan container seperti k8s.
? Mendaftarkan WorkerId melalui redis bukanlah satu-satunya cara. Anda juga dapat mengembangkan layanan konfigurasi terpusat. Saat setiap layanan titik akhir dimulai, WorkerId unik diperoleh melalui layanan pusat.
? Tentu saja, jika layanan Anda tidak perlu diperluas secara otomatis, Anda tidak perlu mendaftarkan WorkerId secara otomatis, tetapi menetapkan nilai unik global untuk layanan tersebut.
? Ada banyak metode, seperti mengembangkan layanan pembuatan ID terpusat yang menghasilkan ID yang dapat digunakan untuk setiap layanan titik akhir (tunggal atau batch).
Tautan gambar: https://github.com/yitter/IdGenerator/blob/master/Tools/AutoRegisterWorkerId/regprocess.jpg
Jalur kode sumber:/Go/source/regworkerid/reghelper.go
Tautan unduhan: https://github.com/yitter/IdGenerator/releases/download/v1.3.3/workeridgo_lib_v1.3.3.zip
// 注册一个 WorkerId，会先注销所有本机已注册的记录
// address: Redis连接地址，单机模式示例：127.0.0.1:6379，哨兵/集群模式示例：127.0.0.1:26380,127.0.0.1:26381,127.0.0.1:26382
// password: Redis连接密码
// db: Redis指定存储库，示例：1
// sentinelMasterName: Redis 哨兵模式下的服务名称，示例：mymaster，非哨兵模式传入空字符串即可
// minWorkerId: WorkerId 最小值，示例：30
// maxWorkerId: WorkerId 最大值，示例：63
// lifeTimeSeconds: WorkerId缓存时长（秒，3的倍数），推荐值15
extern GoInt32 RegisterOne(char* server, char* password, GoInt32 db, char* sentinelMasterName, GoInt32 minWorkerId, GoInt32 maxWorkerId, GoInt32 lifeTimeSeconds);
// 注销本机已注册的 WorkerId
extern void UnRegister();
| bahasa | github |
|---|---|
| ?C# | Lihat contoh |
| ? Jawa | Lihat contoh |
| ? Pergi | Lihat contoh |
| ? Karat | Lihat contoh |
| ?Piton | Lihat contoh |
| ?C | Lihat contoh |
| ?C (ekstensi PHP) | Lihat contoh |
| ?Delfi (Pascal) | Lihat contoh |
| ? | Lihat contoh |
| ?Skrip Ketik | Lihat contoh |
| ?V | Lihat contoh |
| ?D | Lihat contoh |
Alamat sumber terbuka: https://github.com/yitter/IdGenerator
Grup QQ: 646049993
