IdGenerator
1.0.0
เพื่อตอบคำถามด้านประสิทธิภาพที่มักเกิดขึ้นระหว่างการใช้งาน ฉันจึงให้แนวทางปฏิบัติที่ดีที่สุดสามชุดต่อไปนี้:
❄ หากข้อกำหนดการสร้าง ID ไม่เกิน 5W/s ก็ไม่จำเป็นต้องแก้ไขพารามิเตอร์การกำหนดค่าใดๆ
❄ หากเกิน 5W ชิ้น/วินาที และน้อยกว่า 50W ชิ้น/วินาที แนะนำให้แก้ไข: SeqBitLength=10
❄ หากเกิน 50W บิต/วินาที และใกล้ถึง 500W บิต/วินาที ขอแนะนำให้แก้ไข: SeqBitLength=12
โดยสรุป การเพิ่ม SeqBitLength จะส่งผลให้ประสิทธิภาพดีขึ้น แต่ ID ที่สร้างขึ้นจะยาวขึ้น
❄ นี่คืออัลกอริธึมเกล็ดหิมะที่ได้รับการปรับให้เหมาะสม (การดริฟท์ของเกล็ดหิมะ) ซึ่งสร้าง ID ที่สั้นและเร็วขึ้น
❄ รองรับการขยายสภาพแวดล้อมคอนเทนเนอร์โดยอัตโนมัติ เช่น k8s (การลงทะเบียน WorkerId อัตโนมัติ) และสามารถสร้าง ID ที่ไม่ซ้ำกันดิจิทัลในสภาพแวดล้อมแบบสแตนด์อโลนหรือแบบกระจาย
❄ รองรับ C#/Java/Go/C/Rust/Python/Node.js/PHP (ส่วนขยาย C)/SQL/ และภาษาอื่นๆ โดยธรรมชาติ และให้บริการการเรียกใช้ไลบรารี่แบบไดนามิกที่ปลอดภัยแบบมัลติเธรด (FFI)
❄ เข้ากันได้กับอัลกอริธึมเกล็ดหิมะทั้งหมด (โหมดการแบ่งส่วนตัวเลขหรือโหมดคลาสสิก ผู้ผลิตรายใหญ่หรือรายเล็ก) คุณสามารถอัปเกรดหรือเปลี่ยนได้ในอนาคต
❄ นี่คือเครื่องมือสร้าง Snowflake ID ที่ครอบคลุมมากที่สุดในประวัติศาสตร์คอมพิวเตอร์ 【ณ เดือนสิงหาคม 2022】
ในฐานะสถาปนิก คุณต้องการแก้ปัญหาคีย์หลักที่ไม่ซ้ำกันในฐานข้อมูล โดยเฉพาะอย่างยิ่งในระบบแบบกระจายที่มีหลายฐานข้อมูล
คุณต้องการให้คีย์หลักของตารางข้อมูลใช้พื้นที่เก็บข้อมูลน้อยที่สุด สร้างดัชนีเร็วขึ้น และเลือก แทรก และอัปเดตเร็วขึ้น
คุณควรพิจารณาว่าเมื่อแบ่งฐานข้อมูลและตาราง (การรวมฐานข้อมูลและตาราง) ค่าคีย์หลักสามารถใช้ได้โดยตรงและสามารถสะท้อนถึงจังหวะทางธุรกิจได้
หากค่าคีย์หลักยาวเกินไปและเกินค่าสูงสุดของประเภท front-end js Number ประเภท Long จะต้องถูกแปลงเป็นประเภท String และคุณจะรู้สึกหงุดหงิดเล็กน้อย
แม้ว่า Guid จะสามารถเพิ่มค่าอัตโนมัติได้ แต่ก็ใช้พื้นที่มากและความเร็วในการจัดทำดัชนีก็ช้า
อาจมีอินสแตนซ์ของแอปพลิเคชันมากกว่า 50 รายการ และแต่ละคำขอพร้อมกันสามารถเข้าถึง 10W/s
? หากต้องการปรับใช้แอปพลิเคชันในสภาพแวดล้อมคอนเทนเนอร์ ให้รองรับการจำลองแบบแนวนอนและการขยายอัตโนมัติ
คุณไม่ต้องการพึ่งพาการดำเนินการเพิ่มอัตโนมัติของ Redis เพื่อรับ ID คีย์หลักอย่างต่อเนื่อง เนื่องจาก ID ต่อเนื่องก่อให้เกิดความเสี่ยงด้านความปลอดภัยของข้อมูลธุรกิจ
คุณต้องการให้ระบบใช้งานได้นานกว่า 100 ปี
รหัสที่สร้างขึ้นยาวเกินไป
จำนวนการเกิดพร้อมกันในทันทีนั้นไม่เพียงพอ
ปัญหาการโทรกลับเวลาไม่สามารถแก้ไขได้
ไม่รองรับการสร้างรหัสการสั่งซื้อล่วงหน้าหลังการเสริม
อาจอาศัยระบบจัดเก็บข้อมูลภายนอก
✔ จำนวนเต็ม เพิ่มขึ้นอย่างซ้ำซากเมื่อเวลาผ่านไป (ไม่จำเป็นต้องต่อเนื่องกัน) มีความยาวสั้นลง และจะไม่เกินค่าสูงสุดของประเภท js Number ใน 50 ปี (การกำหนดค่าเริ่มต้น)
✔ เร็วกว่า เร็วกว่าอัลกอริธึมเกล็ดหิมะแบบเดิม 2-5 เท่า สามารถสร้าง 500,000 รายการได้ภายใน 0.1 วินาที (อิงตาม i7 แรงดันต่ำรุ่นที่ 8)
✔รองรับการประมวลผลการโทรกลับตามเวลา ตัวอย่างเช่น หากเวลาเซิร์ฟเวอร์ถูกตั้งเวลากลับ 1 วินาที อัลกอริธึมนี้สามารถปรับเปลี่ยนโดยอัตโนมัติเพื่อสร้าง ID เฉพาะสำหรับเวลาวิกฤติ
✔รองรับการแทรก ID ใหม่ด้วยตนเอง เมื่อธุรกิจจำเป็นต้องสร้าง ID ใหม่ในช่วงเวลาที่ผ่านมา บิตที่สงวนไว้ของอัลกอริทึมนี้สามารถสร้าง 5,000 ID ต่อวินาที
✔ ไม่ต้องพึ่งพาแคชหรือฐานข้อมูลภายนอกใดๆ (ไลบรารีแบบไดนามิกที่ลงทะเบียน WorkerId โดยอัตโนมัติในสภาพแวดล้อม k8s อาศัย Redis)
✔ฟังก์ชั่นพื้นฐาน พร้อมใช้งานทันที ไม่ต้องใช้ไฟล์กำหนดค่า การเชื่อมต่อฐานข้อมูล ฯลฯ
(พารามิเตอร์: ลำดับการเพิ่มอัตโนมัติ 10 บิต, ค่าสูงสุดดริฟท์ 1,000 ค่า)
| คำขออย่างต่อเนื่อง | 5ก | 5W | 50W |
|---|---|---|---|
| อัลกอริธึมเกล็ดหิมะแบบดั้งเดิม | 0.0045 วินาที | 0.053 วินาที | 0.556 วินาที |
| อัลกอริธึมการดริฟท์หิมะ | 0.0015 วินาที | 0.012 วินาที | 0.113 วินาที |
?ประสิทธิภาพสูงสุด: 500W/s~3000W/s (ข้อมูลการทดสอบทั้งหมดคำนวณจากแรงดันไฟฟ้าต่ำ i7 รุ่นที่ 8)
? เมื่อหมุนเวลาของระบบกลับ อัลกอริธึมจะใช้หมายเลขลำดับที่สงวนไว้ของอนุกรมเวลาที่ผ่านมาเพื่อสร้าง ID ใหม่
? หมายเลข ID ที่สร้างโดยการโทรกลับจะถูกวางไว้ก่อนตามค่าเริ่มต้น และยังสามารถปรับเปลี่ยนในภายหลังได้
? อนุญาตให้ตั้งเวลากลับไปที่ฐานที่ตั้งไว้ล่วงหน้าของอัลกอริธึมนี้ (พารามิเตอร์สามารถปรับได้)
? ID ที่สร้างโดยอัลกอริทึมนี้เป็นจำนวนเต็ม (ใช้พื้นที่สูงสุด 8 ไบต์) ต่อไปนี้คือ ID ที่สร้างขึ้นตามการกำหนดค่าเริ่มต้น:
129053495681099 (运行1年，长度：15)
387750301904971 (运行3年，长度：15)
646093214093387 (运行5年，长度：15)
1292658282840139 (运行10年，长度：16)
9007199254740992 (运行70年，达到 js Number 最大值，长度：16)
165399880288699493 (运行1000年，等同普通雪花算法运行1年，长度：18)
? ค่า ID ที่สร้างโดยอัลกอริธึมนี้คือ 1% -10% ของค่าสูงสุดของหมายเลข js ซึ่งเป็นหนึ่งในพันของค่าของอัลกอริธึมเกล็ดหิมะธรรมดา แต่ความเร็วในการสร้างจะเร็วกว่าอัลกอริธึมเกล็ดหิมะทั่วไป
ค่าสูงสุดของประเภท js Number: 9007199254740992 อัลกอริธึมนี้อาจใช้เวลา 70 ปีในการเข้าถึงค่าสูงสุดของ js Number ขณะที่ยังคงรักษาประสิทธิภาพการทำงานพร้อมกัน (5W+/0.01s) และสูงสุด 64 WorkerIds (6 บิต)
? 每增加 1位 WorkerIdBitLength 或 SeqBitLength，生成的ID数字值将会乘以2（基础长度可参考前一节“ID示例”），反之则除以2。
คำอธิบายระยะเวลาที่สามารถใช้งานได้หมายถึงเมื่อหมายเลข ID ที่สร้างขึ้นสามารถขยายจนเกินค่าสูงสุดของ long (ลงนาม 64 บิต, 8 ไบต์)
• ในการกำหนดค่าเริ่มต้น จะมี ID ที่ไม่ซ้ำกัน 71000 รายการ
? เมื่อรองรับโหนดผู้ปฏิบัติงาน 1,024 โหนด ID จะสามารถใช้งานได้เป็นเวลา 4480 ปีโดยไม่มีการทำซ้ำ
? เมื่อรองรับโหนดผู้ปฏิบัติงาน 4096 ID จะสามารถใช้งานได้เป็นเวลา 1120 ปีโดยไม่มีการทำซ้ำ
❄ WorkerIdBitLength ความยาวบิตของรหัสเครื่อง กำหนดค่าสูงสุดของ WorkerId ค่าเริ่มต้นคือ 6 และช่วงค่าคือ [1, 19] จริงๆ แล้ว บางภาษาใช้ประเภท ushort (uint16) ที่ไม่ได้ลงชื่อในการรับ พารามิเตอร์นี้ ดังนั้นค่าสูงสุดคือ 16 หากใช้ signed short (int16) ค่าสูงสุดคือ 15
❄ WorkerId รหัสเครื่อง พารามิเตอร์ที่สำคัญที่สุด ไม่มีค่าเริ่มต้น จะต้อง ไม่ซ้ำกันทั่วโลก (หรือไม่ซ้ำกันภายใน DataCenterId เดียวกัน) ต้อง ตั้งค่าโดยทางโปรแกรม เงื่อนไขเริ่มต้น (WorkerIdBitLength ใช้ค่าเริ่มต้น) ค่าสูงสุดคือ 63 ค่าสูงสุดตามทฤษฎีคือ 2^WorkerIdBitLength -1 (ภาษาการใช้งานที่แตกต่างกันอาจถูกจำกัดไว้ที่ 65535 หรือ 32767 หลักการจะเหมือนกับกฎ WorkerIdBitLength) ไม่สามารถเหมือนกัน บนเครื่องอื่นหรืออินสแตนซ์ของแอปพลิเคชันที่แตกต่างกัน คุณสามารถกำหนดค่านี้ผ่านแอปพลิเคชันหรือรับค่าโดยการเรียกใช้บริการภายนอก เพื่อตอบสนองต่อความจำเป็นในการลงทะเบียน WorkerId โดยอัตโนมัติ อัลกอริทึมนี้จัดให้มีการใช้งานเริ่มต้น: การลงทะเบียนไลบรารีแบบไดนามิกของ WorkerId ผ่าน Redis โดยอัตโนมัติ โปรดดูรายละเอียดที่ "ToolsAutoRegisterWorkerId"
หมายเหตุพิเศษ : หากเซิร์ฟเวอร์ใช้บริการอิสระหลายบริการ คุณต้องระบุ WorkerId ที่แตกต่างกันสำหรับแต่ละบริการ
❄ SeqBitLength ความยาวบิตของลำดับ ค่าเริ่มต้น 6 ช่วงค่า [3, 21] (แนะนำไม่น้อยกว่า 4) กำหนดจำนวน ID ที่สร้างขึ้นต่อมิลลิวินาที หากจำนวนคำขอต่อวินาทีไม่เกิน 5W เพียงคงค่าเริ่มต้นไว้ที่ 6 หากเกิน 5W และไม่เกิน 50W ขอแนะนำให้กำหนดค่าเป็น 10 หรือมากกว่า เป็นต้น ข้อกำหนดกฎ: WorkerIdBitLength + SeqBitLength ไม่เกิน 22
❄ MinSeqNumber หมายเลขลำดับขั้นต่ำ ค่าเริ่มต้น 5 ช่วงค่า [5, MaxSeqNumber] หมายเลขลำดับ 5 ตัวแรกต่อมิลลิวินาทีสอดคล้องกับตัวเลข 0-4 เป็นบิตที่สงวนไว้ ซึ่ง 1-4 เป็นบิตที่สงวนไว้ที่สอดคล้องกันสำหรับการโทรกลับเวลา , 0 เป็นบิตที่สงวนไว้สำหรับค่าใหม่ด้วยตนเอง
❄ MaxSeqNumber หมายเลขลำดับสูงสุด ช่วงการตั้งค่าคือ [MinSeqNumber, 2^SeqBitLength-1] ค่าเริ่มต้นคือ 0 หมายเลขลำดับสูงสุดที่แท้จริงคือค่าสูงสุด (2^SeqBitLength-1) หากไม่ใช่ 0 ซึ่งเป็นหมายเลขลำดับสูงสุดที่แท้จริง โดยทั่วไปไม่จำเป็นต้องตั้งค่า เว้นแต่ว่าเครื่องหลายเครื่องจะแชร์ WorkerId เพื่อสร้าง ID ในส่วนต่างๆ (ในกรณีนี้ ต้องตั้งค่าหมายเลขลำดับขั้นต่ำอย่างถูกต้อง)
❄ BaseTime เวลาฐาน (หรือที่เรียกว่า: เวลาจุดฐาน, เวลาเริ่มต้น, เวลายุค) มีค่าเริ่มต้น (2020) คือการประทับเวลามิลลิวินาที (จำนวนเต็ม .NET เป็นประเภท DatetTime) ฟังก์ชันของมันคือ: use เมื่อสร้าง ID ความแตกต่าง (เป็นมิลลิวินาที) ระหว่างเวลาของระบบและเวลาพื้นฐานจะใช้เป็นการประทับเวลาสำหรับการสร้าง ID โดยทั่วไปไม่จำเป็นต้องตั้งเวลาพื้นฐาน หากคุณรู้สึกว่าค่าเริ่มต้นเก่าเกินไป คุณสามารถรีเซ็ตได้ อย่างไรก็ตาม โปรดทราบว่าทางที่ดีที่สุดคืออย่าเปลี่ยนค่านี้ในอนาคต
เวอร์ชันที่สองวางแผนที่จะเพิ่มพารามิเตอร์:
❄ DataCenterId , รหัสศูนย์ข้อมูล (รหัสห้องคอมพิวเตอร์ ค่าเริ่มต้น 0) โปรดตรวจสอบให้แน่ใจว่าไม่ซ้ำกันทั่วโลก
❄ DataCenterIdBitLength ความยาวรหัสศูนย์ข้อมูล (ค่าเริ่มต้น 0)
❄ TimestampType ประเภทการประทับเวลา (0 มิลลิวินาที 1 วินาที) ค่าเริ่มต้น 0
1️⃣ โทรในโหมดซิงเกิลตัน อัลกอริทึมนี้ใช้เธรดเดียวเพื่อสร้าง ID และการโทรจากหลายฝ่ายจะไม่เกิดขึ้นพร้อมกัน ภายในอินสแตนซ์แอปพลิเคชันเดียวกัน ผู้เรียกใช้มัลติเธรด (หรือขนาน) เพื่อเรียกอัลกอริทึมนี้ ซึ่งจะไม่เพิ่มความเร็วเอาต์พุต ID
2️⃣ระบุ WorkerId ที่ไม่ซ้ำใคร ความเป็นเอกลักษณ์ระดับโลกของ WorkerId จะต้องได้รับการรับรองโดยระบบภายนอก และกำหนดให้กับพารามิเตอร์รายการของอัลกอริทึมนี้
3️⃣ ใช้ WorkerIds ที่แตกต่างกันเมื่อปรับใช้หลายอินสแตนซ์บนเครื่องเดียว การใช้งานบางประเภทไม่รองรับความเป็นเอกลักษณ์ที่เกิดขึ้นพร้อมกันข้ามกระบวนการ เพื่อความปลอดภัย เมื่อปรับใช้อินสแตนซ์แอปพลิเคชันหลายรายการบนโฮสต์เดียวกัน โปรดตรวจสอบให้แน่ใจว่า WorkerId แต่ละรายการไม่ซ้ำกัน
4️⃣ การจัดการข้อยกเว้น อัลกอริธึมจะส่งข้อยกเว้นทั้งหมด และระบบภายนอกควรตรวจจับข้อยกเว้นและจัดการอย่างดีเพื่อหลีกเลี่ยงไม่ให้ระบบเสียหายมากขึ้น
5️⃣ ทำความเข้าใจคำจำกัดความของ IdGeneratorOptions อย่างรอบคอบ ซึ่งจะเป็นประโยชน์ในการบูรณาการและใช้อัลกอริทึมนี้
6️⃣ใช้อัลกอริธึมการดริฟท์หิมะ แม้ว่าโค้ดจะมีคำจำกัดความของอัลกอริทึมเกล็ดหิมะแบบดั้งเดิม และคุณสามารถระบุ (วิธีการ=2) ที่จุดเริ่มต้นเพื่อเปิดใช้งานอัลกอริทึมแบบดั้งเดิม ยังคงแนะนำให้คุณใช้อัลกอริทึมการเลื่อนเกล็ดหิมะ (วิธีการ=1 ซึ่งเป็นค่าเริ่มต้น) ท้ายที่สุดแล้ว มันมีความสามารถในการยืดตัวได้ดีกว่าและประสิทธิภาพที่สูงกว่า
7️⃣อย่าแก้ไขอัลกอริธึมหลัก อัลกอริธึมนี้มีพารามิเตอร์ภายในจำนวนมากและตรรกะที่ซับซ้อน เมื่อคุณยังไม่เชี่ยวชาญตรรกะหลัก โปรดอย่าแก้ไขโค้ดหลักและใช้ในสภาพแวดล้อมการใช้งานจริง เว้นแต่จะได้รับการตรวจสอบผ่านการทดสอบที่พิถีพิถันและทางวิทยาศาสตร์จำนวนมาก
8️⃣นโยบายการกำหนดค่าภายในโดเมนแอปพลิเคชันเหมือนกัน เมื่อระบบทำงานมาระยะหนึ่งแล้วและโปรเจ็กต์จำเป็นต้องเปลี่ยนจากการระบุ WorkerId ทางโปรแกรมเป็นการลงทะเบียน WorkerId โดยอัตโนมัติ โปรดตรวจสอบให้แน่ใจว่าอินสแตนซ์ทั้งหมดที่ใช้ในโดเมนแอปพลิเคชันเดียวกันใช้กลยุทธ์การกำหนดค่าที่สอดคล้องกัน ซึ่งไม่ใช่เฉพาะสำหรับ WorkerId เท่านั้น แต่ยังรวมถึงพารามิเตอร์การกำหนดค่าอื่นๆ ด้วย
9️⃣จัดการเวลาเซิร์ฟเวอร์ให้ดี อัลกอริธึม Snowflake ขึ้นอยู่กับเวลาของระบบ อย่าปรับเวลาระบบปฏิบัติการด้วยตนเองเป็นจำนวนมาก หากคุณต้องปรับเปลี่ยน อย่าลืมตรวจสอบให้แน่ใจว่าเวลาของระบบเมื่อเริ่มบริการอีกครั้งนั้นมากกว่าเวลาที่ปิดระบบครั้งล่าสุด (หมายเหตุ: การเปลี่ยนแปลงเล็กน้อยในเวลาของระบบที่เกิดจากการซิงโครไนซ์เวลาระดับโลกหรือระดับเครือข่ายหรือการโทรกลับไม่มีผลกระทบต่ออัลกอริทึมนี้)
การเปลี่ยนแปลงการกำหนดค่าหมายถึงการปรับพารามิเตอร์การทำงาน (คุณสมบัติของออบเจ็กต์ IdGeneratorOptions) หลังจากที่ระบบทำงานมาระยะหนึ่งแล้ว โปรดทราบ:
? 1. หลักการแรกคือ: BaseTime สามารถเก่ากว่าได้เท่านั้น (เพิ่มเติมจากปัจจุบัน) เพื่อให้ค่า ID ที่สร้างขึ้นมีขนาดใหญ่กว่าค่าสูงสุดในอดีต เพื่อให้แน่ใจว่าไม่มีเวลาทับซ้อนกันและไม่มีการสร้าง ID ที่ซ้ำกัน [ ไม่แนะนำ ให้ปรับ BaseTime หลังจากที่ระบบกำลังทำงาน]
? 2. อนุญาตให้เพิ่ม WorkerIdBitLength หรือ SeqBitLength ได้ตลอดเวลา แต่ควรใช้การดำเนินการ "ลดลง" ด้วยความระมัดระวัง เนื่องจากอาจทำให้ ID ที่สร้างขึ้นในอนาคตเหมือนกับการกำหนดค่าเก่า [อนุญาตให้ เพิ่ม ค่า xxxBitLength หลังจากที่ระบบกำลังทำงาน]
3. หาก WorkerIdBitLength หรือ SeqBitLength อันใดอันหนึ่งต้องลดลง จะต้องตรงตามเงื่อนไข: ผลรวมของ xxxBitLength ใหม่ทั้งสองจะต้องมากกว่าผลรวมของค่าเก่า [ ไม่แนะนำให้ จำกัดค่า BitLength ให้แคบลงหลังจากใช้งาน]
4. กฎสามข้อข้างต้นไม่ได้รับการควบคุมเชิงตรรกะในอัลกอริทึมนี้ ผู้ใช้ควรทำการเปลี่ยนแปลงการกำหนดค่าหลังจากยืนยันว่าการกำหนดค่าใหม่ตรงตามข้อกำหนด
? ตัวสร้าง ID ที่ไม่ซ้ำใครอาศัย WorkerId เมื่อบริการทางธุรกิจต้องการการจำลองแบบแนวนอนและไม่เลือกปฏิบัติ (การขยายอัตโนมัติ) สิ่งนี้ต้องการความสามารถในการลงทะเบียน WorkerId ที่ไม่ซ้ำทั่วโลกโดยอัตโนมัติก่อนที่จะสร้าง ID ที่ไม่ซ้ำใคร
? อัลกอริธึมนี้มีไลบรารีไดนามิกแบบโอเพ่นซอร์ส (ใช้งานในภาษา Go) ซึ่งสามารถลงทะเบียน WorkerId โดยอัตโนมัติผ่าน Redis ในสภาพแวดล้อมคอนเทนเนอร์ เช่น k8s
? การลงทะเบียน WorkerId ผ่าน redis ไม่ใช่วิธีเดียว คุณยังสามารถพัฒนาบริการการกำหนดค่าแบบรวมศูนย์ได้ เมื่อบริการปลายทางแต่ละรายการเริ่มต้นขึ้น WorkerId ที่ไม่ซ้ำกันจะได้รับผ่านบริการส่วนกลาง
แน่นอนว่าหากบริการของคุณไม่จำเป็นต้องขยายโดยอัตโนมัติ คุณไม่จำเป็นต้องลงทะเบียน WorkerId โดยอัตโนมัติ แต่ตั้งค่าที่ไม่ซ้ำกันทั่วโลกสำหรับบริการเหล่านั้น
มีหลายวิธี เช่น การพัฒนาบริการสร้าง ID แบบรวมศูนย์ ซึ่งสร้าง ID ที่ใช้งานได้สำหรับบริการปลายทางแต่ละอย่าง (เดี่ยวหรือชุด)
ลิงก์รูปภาพ: https://github.com/yitter/IdGenerator/blob/master/Tools/AutoRegisterWorkerId/regprocess.jpg
เส้นทางซอร์สโค้ด:/Go/source/regworkerid/reghelper.go
ลิงค์ดาวน์โหลด: 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();
| ภาษา | GitHub |
|---|---|
| ?ค# | ดูตัวอย่าง |
| ?ชวา | ดูตัวอย่าง |
| ?ไป | ดูตัวอย่าง |
| ? สนิม | ดูตัวอย่าง |
| ?หลาม | ดูตัวอย่าง |
| ?ค | ดูตัวอย่าง |
| ? C (ส่วนขยาย PHP) | ดูตัวอย่าง |
| ? เดลฟี (ปาสคาล) | ดูตัวอย่าง |
| ? | ดูตัวอย่าง |
| ?พิมพ์สคริปต์ | ดูตัวอย่าง |
| ? | ดูตัวอย่าง |
| ?D | ดูตัวอย่าง |
ที่อยู่โอเพ่นซอร์ส: https://github.com/yitter/IdGenerator
กลุ่ม QQ: 646049993
