उसी प्रक्रिया के अंदर Raft का अंत: ZooKeeper की सहमति से मूल Lux Quasar तक
Hanzo Datastore, ClickHouse Keeper के नीचे बैठे NuRaft इंजन को Lux Quasar से बदलता है। यह उत्तर-क्वांटम और बिना लीडर वाली सहमति सीधे C++ सर्वर से जुड़ती है, और प्रतिकृति जिस ZooKeeper इंटरफ़ेस से बात करती है उसे ज्यों का त्यों रखा जाता है।

इस पृष्ठ पर
Hanzo Datastore आज प्रतिकृत तालिकाओं का समन्वय वैसे ही करता है जैसे ClickHouse करता है: एक अंतर्निहित, ZooKeeper-संगत Keeper, जो सर्वर प्रक्रिया के अंदर Raft चलाता है। यह काम करता है। यह स्टैक का आखिरी शास्त्रीय, लीडर-आधारित, पूर्व-क्वांटम घटक भी है। यह लेख बताता है कि हम इसे कैसे समाप्त करते हैं, और क्यों "ZK को समाप्त करना" प्रतिकृति को दोबारा लिखना नहीं है।
Keeper को अलग करना: इंटरफ़ेस बनाम इंजन
"ZooKeeper बदलो" सुनते ही सहज प्रतिक्रिया हर Replicated*MergeTree को छूने की कल्पना करना है। आप ऐसा नहीं करते, क्योंकि ClickHouse Keeper पहले से ही दो अलग की जा सकने वाली चीज़ें हैं, जो एक डेमन में गूँथ दी गई हैं:
-
ZooKeeper इंटरफ़ेस — अनुक्रमिक नोड, संस्करण और वॉच के साथ एक रैखिक क्रम वाली कुंजी-मान वृक्ष। स्रोत में यह
KeeperStorageहै, जिसेKeeperStateMachineलपेटता है (src/Coordination/KeeperStateMachine.h,class IKeeperStateMachine : public nuraft::state_machine)। यही अनुबंध है। हर प्रतिकृत तालिका, हरsystem.zookeeperक्वेरी, और हर लीडर चुनाव इसी से बात करता है। -
सहमति इंजन — वह जो लेखन अनुरोधों की धारा लेता है, नोडों के कोरम से उनका क्रम मनवाता है, और फिर उसी सहमत क्रम में स्टेट मशीन पर
commit(log_idx, data)बुलाता है। आज वह NuRaft है:KeeperServer::launchRaftServer(src/Coordination/KeeperServer.cpp) एकnuraft::raft_server, एकasio_service, एकKeeperStateManager, और एकKeeperLogStoreबनाता है।
साफ बात, Rich Hickey वाली बात, यह है कि KeeperStateMachine पहले से सामान्य सहमति इंटरफ़ेस के विरुद्ध लिखा गया है (nuraft::state_machine: pre_commit, commit, rollback, स्नैपशॉट)। उसे न पता है और न परवाह कि नीचे Raft है। इंजन एक ऐसा मान है जिसे बदला जा सकता है, इंटरफ़ेस में वेल्ड की हुई जगह नहीं।
इसलिए: स्टेट मशीन रखें, इंजन बदलें। प्रतिकृति जिस ZooKeeper इंटरफ़ेस पर निर्भर है वह अछूता रहता है। NuRaft, लीडर चुनाव, और अलग Raft कोरम चलाने की शर्त ही समाप्त होती है।
जो इसकी जगह लेता है
इंजन Quasar बन जाता है, Lux की बिना लीडर, DAG-आधारित, उत्तर-क्वांटम सहमति। यहाँ Quasar का काम Raft जैसा ही है: लॉग का क्रम तय करना, और बताना कि कोई प्रविष्टि अंतिम है। फर्क इस बात का है कि सहमति कैसे बनती है। फेलओवर के लिए एक लीडर नहीं, शास्त्रीय हस्ताक्षरों की जगह ML-DSA हस्ताक्षर, और एक निश्चित टर्म के बहुमत की जगह विश्वास-सीमा की अंतिमता।
निर्णायक बात यह है कि Quasar कोई Go सेवा नहीं जिसे हम शेल से बुलाते हों। यह C++ के लिए तैयार द्विआधारी इंटरफ़ेस वाला मूल C इंजन देता है (libluxconsensus)। Datastore सर्वर C++ है। इसलिए इंजन उसी प्रक्रिया के अंदर जुड़ता है: न साइडकार, न समन्वयक तक नेटवर्क की छलांग, न रनटाइम पर दूसरी भाषा।
सीवन सिद्ध है, असली स्टेट मशीन पर
यह खाका नहीं है, और अब मॉडल भी नहीं। हमने एक प्रोग्राम बनाया जो ClickHouse सर्वर लाइब्रेरी को वास्तव में जोड़ता है (libdbms.a) और उत्पादन वाला KeeperStateMachine<KeeperMemoryStorage> चलाता है, वही वर्ग जिससे ReplicatedMergeTree समन्वय करता है, पूरी तरह Quasar पर, और क्रम के पथ में NuRaft कहीं नहीं। यह Datastore वृक्ष में src/Coordination/examples/keeper_quasar_poc.cpp पर रहता है, और असली Linux होस्ट पर बनता तथा चलता है (aarch64, clang-21)।
प्रवाह आज के डिस्पैचर द्वारा NuRaft चलाने के तरीके के प्रति निष्ठावान है: दो चरण, अनुरोध जुड़ने पर preprocess, और सहमति के क्रम के अंतिम होने पर commit:
state_machine->preprocess(rfs, /*lock_mutex*/ true); // append-time, pre-consensus (≙ nuraft pre_commit)
auto buf = IKeeperStateMachine::getZooKeeperLogEntry(rfs); // the real ZooKeeper log entry
lux_chain_add_block(chain, &blk); // the entry rides Quasar (the slot raft_server occupies)
lux_consensus_process_vote(...); // validators agree — no leader
lux_consensus_is_accepted(chain, id, &accepted);
state_machine->commit(height, *buf); // finality → the real KeeperStorage mutates, in order
दस अनुरोधों वाले ReplicatedMergeTree समन्वय क्रम पर चलाने से, जिसमें प्रतिकृति पंजीकरण, ब्लॉक संख्या की वृद्धि, और लीडर चुनाव शामिल हैं, यह हर अनुरोध को पहले से संसाधित करता है, उन्हें Quasar से क्रम देता है, अंतिम करता है, असली KeeperStorage में कमिट करता है, और जताता है कि परिणामी वृक्ष बिल्कुल सही है, हर अनुरोध एक बार, सहमति के क्रम में:
== REAL Keeper state machine reached consensus on Quasar — zero Raft, zero ZK ensemble ==
इसके नीचे न्यूनतम C द्विआधारी इंटरफ़ेस का प्रदर्शन है (pkg/c/examples/cpp_consumer.cpp, make test-cpp), जो libluxconsensus जोड़कर एक ब्लॉक को अंतिम करता है: वही इंजन, ClickHouse पर निर्भरता के बिना। दोनों दोहराए जा सकते हैं। Datastore का उदाहरण वैकल्पिक है (-DENABLE_EXAMPLES=1 -DLUXCONSENSUS_DIR=...) और सामान्य निर्माण का हिस्सा कभी नहीं।
इसे Keeper पर एक-से-एक बिठाएँ:
| आज का Keeper / NuRaft | Quasar पर मूल |
|---|---|
nuraft::raft_server लॉग का क्रम तय करता है | lux_chain_t लॉग का क्रम तय करता है |
KeeperLogStore / Changelog | Quasar का DAG लॉग |
| Raft का लीडर चुनाव | बिना लीडर विश्वास मतदान |
state_machine->commit(idx, data) | वही कॉल, is_accepted पर चलती है |
| शास्त्रीय हस्ताक्षर, निश्चित टर्म का लीडर | ML-DSA हस्ताक्षर, कोई लीडर नहीं |
| चलाने के लिए अलग ZK/Keeper कोरम | प्रक्रिया के अंदर, सर्वर में सहमति |
KeeperStateMachine::commit जोड़ का बिंदु है। NuRaft आज इसे बुलाता है, और Quasar ड्राइवर कल वही विधि बुलाएगा। स्टेट मशीन फर्क नहीं बता सकती, और यही गुण इसे अदला-बदली बनाता है, नया लेखन नहीं।
यह "उत्तर-क्वांटम" से आगे क्यों मायने रखता है
- कोई लीडर नहीं। Raft में हर टर्म एक चुना हुआ लीडर होता है, और उसकी विफलता दोबारा चुनाव तक लेखन रोक देती है। Quasar की बिना-लीडर सहमति उस कतार-शीर्ष निर्भरता को हटा देती है।
- चलाने के लिए दूसरा कोरम नहीं। समन्वय अलग सिस्टम नहीं रहता जिसे आप तैनात करें, देखें, और बैकअप लें। वह सर्वर ही है।
- रचना से ही उत्तर-क्वांटम। सहमति की रक्षा करने वाले हस्ताक्षर ML-DSA हैं, शास्त्रीय वक्र नहीं, इसलिए भविष्य का क्वांटम विरोधी सहमति संदेश गढ़ नहीं सकता।
- एक परिवहन कहानी। यह बाकी दिशा के साथ जुड़ती है: अभी मूल TCP/HTTP, आगे ZAP, और वही Lux आदिम जिनका उपयोग शृंखलाएँ करती हैं।
ईमानदार स्थिति
ऊपर की वास्तुकला वास्तविक है, और प्रमाण अब उत्पादन KeeperStateMachine पर चलता है, किसी मॉडल पर नहीं, असली Linux होस्ट पर बना और सफल। शेष काम इंजन के अंदर की अदला-बदली है: NuRaft के साथ KeeperServer के अंदर Quasar सहमति बैकएंड लाना, उसे तयशुदा बनाना, और फिर KeeperServer जो कुछ करता है, स्नैपशॉट, पुनर्प्राप्ति, सत्र की समाप्ति, पुनर्रचना, उसे पूरी Coordination परीक्षा के हरे होने के साथ वहाँ ले जाना। यह असली काम है। जिस दिन हमने कमिट पथ सिद्ध किया, उस दिन हम नहीं कहेंगे कि Raft जा चुका है। हम कह रहे हैं कि सीवन असली प्रकारों पर टिकता है, जोड़ का बिंदु KeeperStateMachine::commit है, और यही पूरा विषय है।
जब यह उतरेगा, contrib/NuRaft/ और Raft इंजन वृक्ष छोड़ देंगे। ZooKeeper इंटरफ़ेस तब तक रहता है जब तक प्रतिकृति उससे बात करती है। अंतिम पूर्व-क्वांटम घटक को एक भी MergeTree छुए बिना यूँ समाप्त किया जाता है।
- Datastore: github.com/hanzoai/datastore
- Lux सहमति: github.com/luxfi/consensus
और पढ़ें

आज पेश है Hanzo Datastore: पोस्ट-क्वांटम युग के लिए तैयार स्तंभीय OLAP विश्लेषण इंजन
ClickHouse से निकला एक स्तंभीय भंडार, जिसे Hanzo S3 पर भंडारण और संगणना के अलगाव के आसपास फिर से बनाया गया है। प्रोफ़ाइल के मार्गदर्शन और लिंक-काल अनुकूलन से स्मृति लगभग आधी हुई है, gRPC हटा दिया गया है, और बिना नेता वाले पोस्ट-क्वांटम समन्वय की राह खुली है।

राउटर ही रजिस्ट्री है
Hanzo Cloud में कोई चेक-इन OpenAPI फ़ाइल नहीं है। जीवित मार्ग तालिका ही स्रोत है, तीन तरह से प्रक्षेपित, और यदि कोई प्रक्षेपण बहक जाए तो एकैकी आच्छादन परीक्षण बिल्ड को गिरा देता है। 963 पथों पर 1,362 संक्रियाएँ, अनुरोध के समय प्रत्येक प्रक्रिया के लिए उत्पन्न।

Jin 2.0: The Next Generation of Multimodal AI
Announcing Jin 2.0, a major upgrade to our unified multimodal AI architecture with expanded capabilities and improved performance.