ವೀಲ್‌ಸೆಟ್‌ಗಳಿಗಾಗಿ ವಿತರಿಸಲಾದ ರಿಜಿಸ್ಟ್ರಿ: ಹೈಪರ್‌ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್‌ನೊಂದಿಗೆ ಅನುಭವ

ಹಲೋ, ನಾನು DRD KP ಯೋಜನೆಯ ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ (ಚಕ್ರ ಸೆಟ್‌ಗಳ ಜೀವನ ಚಕ್ರವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಡೇಟಾ ರಿಜಿಸ್ಟ್ರಿ ವಿತರಿಸಲಾಗಿದೆ). ತಂತ್ರಜ್ಞಾನದ ನಿರ್ಬಂಧಗಳ ಅಡಿಯಲ್ಲಿ ಈ ಯೋಜನೆಗಾಗಿ ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲಾಕ್‌ಚೈನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಲ್ಲಿ ನಮ್ಮ ತಂಡದ ಅನುಭವವನ್ನು ಇಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಬಹುಪಾಲು, ನಾನು ಹೈಪರ್ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ, ಆದರೆ ಇಲ್ಲಿ ವಿವರಿಸಿದ ವಿಧಾನವನ್ನು ಯಾವುದೇ ಅನುಮತಿ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗೆ ಎಕ್ಸ್‌ಟ್ರಾಪೋಲೇಟ್ ಮಾಡಬಹುದು. ನಮ್ಮ ಸಂಶೋಧನೆಯ ಅಂತಿಮ ಗುರಿಯು ಎಂಟರ್‌ಪ್ರೈಸ್ ಬ್ಲಾಕ್‌ಚೈನ್ ಪರಿಹಾರಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು, ಅಂತಿಮ ಉತ್ಪನ್ನವು ಬಳಸಲು ಆಹ್ಲಾದಕರವಾಗಿರುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲು ತುಂಬಾ ಕಷ್ಟವಲ್ಲ.

ಯಾವುದೇ ಆವಿಷ್ಕಾರಗಳು, ಅನಿರೀಕ್ಷಿತ ಪರಿಹಾರಗಳು ಮತ್ತು ಯಾವುದೇ ವಿಶಿಷ್ಟ ಬೆಳವಣಿಗೆಗಳನ್ನು ಇಲ್ಲಿ ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ (ಏಕೆಂದರೆ ನಾನು ಅವುಗಳನ್ನು ಹೊಂದಿಲ್ಲ). ನಾನು ನನ್ನ ವಿನಮ್ರ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇನೆ, "ಇದು ಸಾಧ್ಯವಾಯಿತು" ಎಂದು ತೋರಿಸಲು ಮತ್ತು ಬಹುಶಃ, ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಉತ್ತಮ ಮತ್ತು ಉತ್ತಮವಲ್ಲದ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡುವಲ್ಲಿ ಬೇರೊಬ್ಬರ ಅನುಭವದ ಬಗ್ಗೆ ಓದಲು ಬಯಸುತ್ತೇನೆ.

ಸಮಸ್ಯೆ: ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳು ಇನ್ನೂ ಸ್ಕೇಲೆಬಲ್ ಆಗಿಲ್ಲ

ಇಂದು, ಅನೇಕ ಡೆವಲಪರ್‌ಗಳ ಪ್ರಯತ್ನಗಳು ಬ್ಲಾಕ್‌ಚೈನ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಅನುಕೂಲಕರ ತಂತ್ರಜ್ಞಾನವನ್ನಾಗಿ ಮಾಡುವ ಗುರಿಯನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಸುಂದರವಾದ ಹೊದಿಕೆಯಲ್ಲಿ ಟಿಕ್ ಮಾಡುವ ಟೈಮ್ ಬಾಂಬ್ ಅಲ್ಲ. ರಾಜ್ಯದ ಚಾನಲ್‌ಗಳು, ಆಶಾವಾದಿ ರೋಲ್‌ಅಪ್, ಪ್ಲಾಸ್ಮಾ ಮತ್ತು ಶಾರ್ಡಿಂಗ್ ಸಾಮಾನ್ಯವಾಗಬಹುದು. ಕೆಲವು ದಿನ. ಅಥವಾ TON ಮತ್ತೆ ಆರು ತಿಂಗಳ ಕಾಲ ಉಡಾವಣೆಯನ್ನು ಮುಂದೂಡಬಹುದು ಮತ್ತು ಮುಂದಿನ ಪ್ಲಾಸ್ಮಾ ಗುಂಪು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ನಾವು ಇನ್ನೊಂದು ಮಾರ್ಗಸೂಚಿಯನ್ನು ನಂಬಬಹುದು ಮತ್ತು ರಾತ್ರಿಯಲ್ಲಿ ಅದ್ಭುತವಾದ ಶ್ವೇತಪತ್ರಗಳನ್ನು ಓದಬಹುದು, ಆದರೆ ಇಲ್ಲಿ ಮತ್ತು ಈಗ ನಾವು ಹೊಂದಿರುವುದನ್ನು ನಾವು ಮಾಡಬೇಕಾಗಿದೆ. ಶಿಟ್ ಮಾಡು.

ಪ್ರಸ್ತುತ ಯೋಜನೆಯಲ್ಲಿ ನಮ್ಮ ತಂಡಕ್ಕೆ ನಿಯೋಜಿಸಲಾದ ಕಾರ್ಯವು ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಹಲವಾರು ವಿಷಯಗಳಿವೆ, ಹಲವಾರು ಸಾವಿರಗಳನ್ನು ತಲುಪುತ್ತದೆ, ಅವರು ನಂಬಿಕೆಯ ಮೇಲೆ ಸಂಬಂಧಗಳನ್ನು ನಿರ್ಮಿಸಲು ಬಯಸುವುದಿಲ್ಲ; ವಿಶೇಷ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವಶ್ಯಕತೆಗಳಿಲ್ಲದೆ ಸಾಮಾನ್ಯ PC ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮತ್ತು ಯಾವುದೇ ಕೇಂದ್ರೀಕೃತ ಲೆಕ್ಕಪತ್ರ ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಕೆಟ್ಟದ್ದಲ್ಲದ ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಒದಗಿಸುವ ಪರಿಹಾರವನ್ನು DLT ಯಲ್ಲಿ ನಿರ್ಮಿಸುವುದು ಅವಶ್ಯಕ. ಪರಿಹಾರದ ಹಿಂದಿನ ತಂತ್ರಜ್ಞಾನವು ದುರುದ್ದೇಶಪೂರಿತ ಡೇಟಾ ಕುಶಲತೆಯ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕು - ಅದಕ್ಕಾಗಿಯೇ ಬ್ಲಾಕ್‌ಚೈನ್ ಇಲ್ಲಿದೆ.

ಮುಂದಿನ ಬೆಳವಣಿಗೆಯು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಲಕ್ಷಾಂತರ ವಹಿವಾಟುಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಶ್ವೇತಪತ್ರಗಳು ಮತ್ತು ಮಾಧ್ಯಮಗಳ ಘೋಷಣೆಗಳು ನಮಗೆ ಭರವಸೆ ನೀಡುತ್ತವೆ. ಇದು ನಿಜವಾಗಿಯೂ ಏನು?

Mainnet Ethereum ಪ್ರಸ್ತುತ ~30 tps ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಕಾರ್ಪೊರೇಟ್ ಅಗತ್ಯಗಳಿಗೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸೂಕ್ತವಾದ ಬ್ಲಾಕ್ಚೈನ್ ಎಂದು ಗ್ರಹಿಸುವುದು ಕಷ್ಟ. ಅನುಮತಿಸಲಾದ ಪರಿಹಾರಗಳಲ್ಲಿ, 2000 tps ತೋರಿಸುವ ಮಾನದಂಡಗಳು ತಿಳಿದಿವೆ (ಕೋರಮ್) ಅಥವಾ 3000 ಟಿಪಿಎಸ್ (ಹೈಪರ್ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್, ಪ್ರಕಟಣೆಯಲ್ಲಿ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಇದೆ, ಆದರೆ ಬೆಂಚ್ಮಾರ್ಕ್ ಅನ್ನು ಹಳೆಯ ಒಮ್ಮತದ ಎಂಜಿನ್ನಲ್ಲಿ ನಡೆಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ). ಆಗಿತ್ತು ಫ್ಯಾಬ್ರಿಕ್ ಅನ್ನು ಆಮೂಲಾಗ್ರವಾಗಿ ಪುನರ್ನಿರ್ಮಿಸುವ ಪ್ರಯತ್ನ, ಇದು ಕೆಟ್ಟ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಿಲ್ಲ, 20000 tps, ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ಇವು ಕೇವಲ ಶೈಕ್ಷಣಿಕ ಅಧ್ಯಯನಗಳು ಅವುಗಳ ಸ್ಥಿರ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ಕಾಯುತ್ತಿವೆ. ಬ್ಲಾಕ್‌ಚೈನ್ ಡೆವಲಪರ್‌ಗಳ ವಿಭಾಗವನ್ನು ನಿರ್ವಹಿಸಲು ಶಕ್ತವಾಗಿರುವ ನಿಗಮವು ಅಂತಹ ಸೂಚಕಗಳನ್ನು ಹೊಂದುವುದು ಅಸಂಭವವಾಗಿದೆ. ಆದರೆ ಸಮಸ್ಯೆ ಥ್ರೋಪುಟ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲ, ಸುಪ್ತತೆಯೂ ಇದೆ.

ಸುಪ್ತತೆ

ವ್ಯವಸ್ಥೆಯಿಂದ ಅದರ ಅಂತಿಮ ಅನುಮೋದನೆಗೆ ವಹಿವಾಟು ಪ್ರಾರಂಭವಾದ ಕ್ಷಣದಿಂದ ವಿಳಂಬವು ಮೌಲ್ಯೀಕರಣ ಮತ್ತು ಆದೇಶದ ಎಲ್ಲಾ ಹಂತಗಳ ಮೂಲಕ ಹಾದುಹೋಗುವ ಸಂದೇಶದ ವೇಗವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಬ್ಲಾಕ್ ರಚನೆಯ ನಿಯತಾಂಕಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನಮ್ಮ ಬ್ಲಾಕ್‌ಚೈನ್ ನಮಗೆ 1000000 ಟಿಪಿಎಸ್‌ನಲ್ಲಿ ಬದ್ಧವಾಗಲು ಅನುಮತಿಸಿದರೂ, 10MB ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸಲು 488 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೂ, ಅದು ನಮಗೆ ಏನಾದರೂ ಸುಲಭವಾಗುತ್ತದೆಯೇ?

ಹೈಪರ್‌ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್‌ನಲ್ಲಿನ ವಹಿವಾಟಿನ ಜೀವನ ಚಕ್ರವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ ಮತ್ತು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಇದು ರಚನೆಯ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲು ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ.

ಇಲ್ಲಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) ಕ್ಲೈಂಟ್ ವಹಿವಾಟನ್ನು ರೂಪಿಸುತ್ತದೆ, ಅದನ್ನು ಅನುಮೋದಿಸುವ ಗೆಳೆಯರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಎರಡನೆಯದು ವಹಿವಾಟನ್ನು ಅನುಕರಿಸುತ್ತದೆ (ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಗೆ ಚೈನ್‌ಕೋಡ್ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಿ, ಆದರೆ ಲೆಡ್ಜರ್‌ಗೆ ಬದ್ಧರಾಗಬೇಡಿ) ಮತ್ತು RWSet ಸ್ವೀಕರಿಸಿ - ಪ್ರಮುಖ ಹೆಸರುಗಳು, ಆವೃತ್ತಿಗಳು ಮತ್ತು CouchDB ಯಲ್ಲಿನ ಸಂಗ್ರಹದಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾದ ಮೌಲ್ಯಗಳು, ( 2) ಅನುಮೋದಕರು ಸಹಿ ಮಾಡಿದ RWSet ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ, (3) ಕ್ಲೈಂಟ್ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಗೆಳೆಯರ (ಅನುಮೋದಕರು) ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ವ್ಯವಹಾರವನ್ನು ಆರ್ಡರ್ ಮಾಡುವ ಸೇವೆಗೆ ಕಳುಹಿಸುತ್ತಾರೆ , ಅಥವಾ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಅದನ್ನು ಕಳುಹಿಸುತ್ತದೆ (ಪರಿಶೀಲನೆಯು ಇನ್ನೂ ನಂತರ ನಡೆಯುತ್ತದೆ), ಆರ್ಡರ್ ಮಾಡುವ ಸೇವೆಯು ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸುತ್ತದೆ ಮತ್ತು (4) ಕೇವಲ ಅನುಮೋದಿಸುವವರಿಗೆ ಮಾತ್ರವಲ್ಲದೆ ಎಲ್ಲಾ ಗೆಳೆಯರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ; ರೀಡ್ ಸೆಟ್‌ನಲ್ಲಿರುವ ಕೀಗಳ ಆವೃತ್ತಿಗಳು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಆವೃತ್ತಿಗಳು, ಎಲ್ಲಾ ಅನುಮೋದಕರ ಸಹಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ಗೆಳೆಯರು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ನಿರ್ಬಂಧಿಸುವಿಕೆಯನ್ನು ಮಾಡುತ್ತಾರೆ.

ಆದರೆ ಇಷ್ಟೇ ಅಲ್ಲ. "ಆರ್ಡರ್ ಮಾಡುವವರು ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸುತ್ತಾರೆ" ಎಂಬ ಪದಗಳ ಹಿಂದೆ ವಹಿವಾಟಿನ ಆದೇಶವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ನಾಯಕರಿಂದ ಅನುಯಾಯಿಗಳಿಗೆ ಮತ್ತು ಹಿಂದಕ್ಕೆ 3 ಸತತ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳನ್ನು ಮರೆಮಾಡಲಾಗಿದೆ: ನಾಯಕನು ಲಾಗ್‌ಗೆ ಸಂದೇಶವನ್ನು ಸೇರಿಸುತ್ತಾನೆ, ಅನುಯಾಯಿಗಳಿಗೆ ಕಳುಹಿಸುತ್ತಾನೆ, ಎರಡನೆಯದು ಸೇರಿಸಿ ಅವರ ಲಾಗ್, ಯಶಸ್ವಿ ಪುನರಾವರ್ತನೆಯ ದೃಢೀಕರಣವನ್ನು ನಾಯಕನಿಗೆ ಕಳುಹಿಸಿ, ನಾಯಕನು ಸಂದೇಶವನ್ನು ಒಪ್ಪಿಸುತ್ತಾನೆ, ಅನುಯಾಯಿಗಳಿಗೆ ಬದ್ಧತೆಯ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ, ಅನುಯಾಯಿಗಳು ಬದ್ಧರಾಗುತ್ತಾರೆ. ಬ್ಲಾಕ್ ಗಾತ್ರ ಮತ್ತು ಸಮಯ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಆರ್ಡರ್ ಮಾಡುವ ಸೇವೆಯು ಒಮ್ಮತವನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ. ಹೈಪರ್ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್ ಎರಡು ಬ್ಲಾಕ್ ರಚನೆಯ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿದೆ: ಬ್ಯಾಚ್ಟೈಮ್ಔಟ್ - ಬ್ಲಾಕ್ ರಚನೆಯ ಸಮಯ ಮತ್ತು ಬ್ಯಾಚ್ಸೈಜ್ - ಬ್ಲಾಕ್ ಗಾತ್ರ (ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಬ್ಲಾಕ್ನ ಗಾತ್ರವು ಬೈಟ್ಗಳಲ್ಲಿ). ನಿಯತಾಂಕಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಿತಿಯನ್ನು ತಲುಪಿದ ತಕ್ಷಣ, ಹೊಸ ಬ್ಲಾಕ್ ಅನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ಹೆಚ್ಚು ಆರ್ಡರ್ ನೋಡ್‌ಗಳು, ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ, ನೀವು BatchTimeout ಮತ್ತು BatchSize ಅನ್ನು ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ. ಆದರೆ RWSets ಆವೃತ್ತಿಯಾಗಿರುವುದರಿಂದ, ನಾವು ಬ್ಲಾಕ್ ಅನ್ನು ದೊಡ್ಡದಾಗಿ ಮಾಡುತ್ತೇವೆ, MVCC ಘರ್ಷಣೆಗಳ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬ್ಯಾಚ್‌ಟೈಮ್‌ಔಟ್‌ನ ಹೆಚ್ಚಳದೊಂದಿಗೆ, UX ದುರಂತವಾಗಿ ಕುಸಿಯುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಈ ಕೆಳಗಿನ ಯೋಜನೆಯು ಸಮಂಜಸ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.

ಬ್ಲಾಕ್ ಅಂತಿಮೀಕರಣಕ್ಕಾಗಿ ಕಾಯುವುದನ್ನು ತಪ್ಪಿಸುವುದು ಮತ್ತು ವಹಿವಾಟಿನ ಸ್ಥಿತಿಯ ಟ್ರ್ಯಾಕ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳದಿರುವುದು ಹೇಗೆ

ರಚನೆಯ ಸಮಯ ಮತ್ತು ಬ್ಲಾಕ್ ಗಾತ್ರವು ದೀರ್ಘವಾಗಿರುತ್ತದೆ, ಬ್ಲಾಕ್ಚೈನ್ನ ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್. ಒಬ್ಬರು ನೇರವಾಗಿ ಇನ್ನೊಂದರಿಂದ ಅನುಸರಿಸುವುದಿಲ್ಲ, ಆದರೆ RAFT ನಲ್ಲಿ ಒಮ್ಮತವನ್ನು ಸ್ಥಾಪಿಸಲು ನಾಯಕರಿಂದ ಅನುಯಾಯಿಗಳಿಗೆ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಮೂರು ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳು ಅಗತ್ಯವಿದೆ ಎಂದು ನೆನಪಿನಲ್ಲಿಡಬೇಕು. ಹೆಚ್ಚು ಆರ್ಡರ್ ನೋಡ್‌ಗಳು, ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಬ್ಲಾಕ್ ರಚನೆಯ ಗಾತ್ರ ಮತ್ತು ಸಮಯ ಚಿಕ್ಕದಾಗಿದೆ, ಅಂತಹ ಸಂವಹನಗಳು ಹೆಚ್ಚು. ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಸಿಸ್ಟಮ್ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸದೆ ರಚನೆಯ ಸಮಯವನ್ನು ಮತ್ತು ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಹೇಗೆ ಹೆಚ್ಚಿಸುವುದು?

ಮೊದಲಿಗೆ, ದೊಡ್ಡ ಬ್ಲಾಕ್ ಗಾತ್ರದಿಂದ ಉಂಟಾಗುವ MVCC ಘರ್ಷಣೆಗಳನ್ನು ನೀವು ಹೇಗಾದರೂ ಪರಿಹರಿಸಬೇಕಾಗಿದೆ, ಅದೇ ಆವೃತ್ತಿಯೊಂದಿಗೆ ವಿಭಿನ್ನ RWSets ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ (ಬ್ಲಾಕ್‌ಚೈನ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಬ್ಯಾಕೆಂಡ್ ಆಗಿರಬಹುದು ಮತ್ತು ನನ್ನ ಪ್ರಕಾರ) MVCC ಸಂಘರ್ಷ ನಿರ್ವಾಹಕ, ಇದು ಪ್ರತ್ಯೇಕ ಸೇವೆಯಾಗಿರಬಹುದು ಅಥವಾ ಮರುಪ್ರಯತ್ನ ತರ್ಕದೊಂದಿಗೆ ವಹಿವಾಟು-ಪ್ರಾರಂಭಿಸುವ ಕರೆಯಲ್ಲಿ ನಿಯಮಿತ ಡೆಕೋರೇಟರ್ ಆಗಿರಬಹುದು.

ಮರುಪ್ರಯತ್ನವನ್ನು ಘಾತೀಯ ತಂತ್ರದೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು, ಆದರೆ ನಂತರ ಸುಪ್ತತೆಯು ಘಾತೀಯವಾಗಿ ಕ್ಷೀಣಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ನೀವು ಕೆಲವು ಸಣ್ಣ ಮಿತಿಗಳಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಮರುಪ್ರಯತ್ನವನ್ನು ಅಥವಾ ಸ್ಥಿರವಾದ ಒಂದನ್ನು ಬಳಸಬೇಕು. ಮೊದಲ ರೂಪಾಂತರದಲ್ಲಿ ಸಂಭವನೀಯ ಘರ್ಷಣೆಗಳನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು.

ಮುಂದಿನ ಹಂತವು ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಕ್ಲೈಂಟ್‌ನ ಸಂವಾದವನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿಸುವುದು ಇದರಿಂದ ಅದು 15, 30 ಅಥವಾ 10000000 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಕಾಯುವುದಿಲ್ಲ, ಅದನ್ನು ನಾವು ಬ್ಯಾಚ್‌ಟೈಮ್‌ಔಟ್ ಎಂದು ಹೊಂದಿಸುತ್ತೇವೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ವಹಿವಾಟಿನಿಂದ ಪ್ರಾರಂಭಿಸಿದ ಬದಲಾವಣೆಗಳನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ / ದಾಖಲಿಸಲಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.
ವಹಿವಾಟಿನ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಬಹುದು. ಅದರ ಬಳಕೆಯ ಸುಲಭತೆಯಿಂದಾಗಿ CouchDB ಸುಲಭವಾದ ಆಯ್ಕೆಯಾಗಿದೆ: ಡೇಟಾಬೇಸ್ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ UI ಅನ್ನು ಹೊಂದಿದೆ, REST API, ಮತ್ತು ನೀವು ಅದಕ್ಕೆ ಪ್ರತಿರೂಪ ಮತ್ತು ಹಂಚಿಕೆಯನ್ನು ಸುಲಭವಾಗಿ ಹೊಂದಿಸಬಹುದು. ಫ್ಯಾಬ್ರಿಕ್ ತನ್ನ ವಿಶ್ವ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸುವ ಅದೇ ಕೌಚ್‌ಡಿಬಿ ನಿದರ್ಶನದಲ್ಲಿ ನೀವು ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹವನ್ನು ರಚಿಸಬಹುದು. ನಾವು ಈ ರೀತಿಯ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

ವ್ಯವಹಾರವನ್ನು ಗೆಳೆಯರಿಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಈ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಇದು ರಚನೆಯ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದ್ದರೆ ಅಸ್ತಿತ್ವದ ID ಅನ್ನು ಬಳಕೆದಾರರಿಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ (ಅದೇ ID ಅನ್ನು ಕೀಲಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ), ಮತ್ತು ನಂತರ ಸ್ಥಿತಿ, TxID ಮತ್ತು ದೋಷ ಕ್ಷೇತ್ರಗಳು ಸಂಬಂಧಿತ ಮಾಹಿತಿಯನ್ನು ಗೆಳೆಯರಿಂದ ಸ್ವೀಕರಿಸಿದಂತೆ ನವೀಕರಿಸಲಾಗಿದೆ.

ಈ ಯೋಜನೆಯಲ್ಲಿ, ಬಳಕೆದಾರರು ಬ್ಲಾಕ್ ಅನ್ನು ಅಂತಿಮವಾಗಿ ರೂಪಿಸಲು ಕಾಯುವುದಿಲ್ಲ, 10 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಪರದೆಯ ಮೇಲೆ ತಿರುಗುವ ಚಕ್ರವನ್ನು ವೀಕ್ಷಿಸುತ್ತಾರೆ, ಅವರು ಸಿಸ್ಟಮ್ನಿಂದ ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತಾರೆ.

ವಹಿವಾಟಿನ ಸ್ಥಿತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು BoltDB ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಾವು ಮೆಮೊರಿಯನ್ನು ಉಳಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಸ್ಟ್ಯಾಂಡ್-ಅಲೋನ್ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಸಂವಹನದಲ್ಲಿ ಸಮಯವನ್ನು ಕಳೆಯಲು ಬಯಸುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ಈ ಸಂವಹನವು ಸರಳ ಪಠ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಡೆಯುವಾಗ. ಅಂದಹಾಗೆ, ಮೇಲೆ ವಿವರಿಸಿದ ಸ್ಕೀಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನೀವು CouchDB ಅನ್ನು ಬಳಸುತ್ತೀರಾ ಅಥವಾ ವಿಶ್ವ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸುತ್ತೀರಾ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, CouchDB ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ವಿಧಾನವನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕೌಚ್‌ಡಿಬಿಯಲ್ಲಿ, ಬಿ-ಟ್ರೀ ನೋಡ್‌ಗಳ ಗಾತ್ರವು 1279 ಬೈಟ್‌ಗಳಾಗಿರುತ್ತದೆ, ಇದು ಡಿಸ್ಕ್‌ನಲ್ಲಿನ ಸೆಕ್ಟರ್ ಗಾತ್ರಕ್ಕಿಂತ ಕಡಿಮೆಯಾಗಿದೆ, ಅಂದರೆ ಮರವನ್ನು ಓದುವುದು ಮತ್ತು ಮರುಸಮತೋಲನ ಮಾಡುವುದು ಎರಡಕ್ಕೂ ಹೆಚ್ಚಿನ ಭೌತಿಕ ಡಿಸ್ಕ್ ಪ್ರವೇಶಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಸೂಕ್ತವಾದ ಗಾತ್ರವು ಮಾನದಂಡವನ್ನು ಪೂರೈಸುತ್ತದೆ ಸುಧಾರಿತ ಸ್ವರೂಪ ಮತ್ತು 4 ಕಿಲೋಬೈಟ್‌ಗಳು. ಆಪ್ಟಿಮೈಸೇಶನ್ಗಾಗಿ, ನಾವು ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ btree_chunk_size 4096 ಗೆ ಸಮ CouchDB ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ. BoltDB ಅಂತಹ ಹಸ್ತಚಾಲಿತ ಹಸ್ತಕ್ಷೇಪಕ್ಕಾಗಿ ಅಗತ್ಯವಿಲ್ಲ.

ಬೆನ್ನಿನ ಒತ್ತಡ: ಬಫರ್ ತಂತ್ರ

ಆದರೆ ಬಹಳಷ್ಟು ಸಂದೇಶಗಳು ಇರಬಹುದು. ರೇಖಾಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿರುವ ಸೇವೆಗಳ ಹೊರತಾಗಿ ಒಂದು ಡಜನ್ ಇತರ ಸೇವೆಗಳೊಂದಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸಿಸ್ಟಮ್ ನಿಭಾಯಿಸಬಲ್ಲದು - ಮತ್ತು ಇಂಟೆಲಿಜ್ ಐಡಿಯಾವನ್ನು ಚಾಲನೆ ಮಾಡುವುದು ಅತ್ಯಂತ ಬೇಸರದ ಯಂತ್ರಗಳಲ್ಲಿಯೂ ಸಹ ದೋಷರಹಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಸಂವಹನ ವ್ಯವಸ್ಥೆಗಳು, ನಿರ್ಮಾಪಕ ಮತ್ತು ಗ್ರಾಹಕನ ವಿಭಿನ್ನ ಥ್ರೋಪುಟ್ನ ಸಮಸ್ಯೆಯನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ನಾವು ಏನು ಮಾಡಬಹುದು ಎಂದು ನೋಡೋಣ.

ಬಿಡಲಾಗುತ್ತಿದೆ: ನಾವು T ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ X ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳಬಹುದು. ಈ ಮಿತಿಯನ್ನು ಮೀರಿದ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಕೈಬಿಡಲಾಗಿದೆ. ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಆದರೆ ನಂತರ ನೀವು UX ಬಗ್ಗೆ ಮರೆತುಬಿಡಬಹುದು.

ನಿಯಂತ್ರಿಸುವುದು: ಗ್ರಾಹಕರು ಕೆಲವು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು, ಅದರ ಮೂಲಕ ಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿ, ಅವರು ನಿರ್ಮಾಪಕರ ಟಿಪಿಎಸ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು. ಕೆಟ್ಟದ್ದಲ್ಲ, ಆದರೆ ಈ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಲೋಡ್ ಕ್ಲೈಂಟ್ನ ಡೆವಲಪರ್ಗಳ ಮೇಲೆ ಬಾಧ್ಯತೆಯನ್ನು ವಿಧಿಸುತ್ತದೆ. ನಮಗೆ, ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ, ಏಕೆಂದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ಬ್ಲಾಕ್‌ಚೈನ್ ಅನ್ನು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ದೀರ್ಘಕಾಲೀನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ.

ಬಫರಿಂಗ್: ಇನ್‌ಪುಟ್ ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ವಿರೋಧಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಬದಲು, ನಾವು ಈ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬಫರ್ ಮಾಡಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿರುವ ವೇಗದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ನಿಸ್ಸಂಶಯವಾಗಿ, ನಾವು ಉತ್ತಮ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಒದಗಿಸಲು ಬಯಸಿದರೆ ಇದು ಅತ್ಯುತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ನಾವು RabbitMQ ನಲ್ಲಿ ಕ್ಯೂ ಬಳಸಿ ಬಫರ್ ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ.

ಸ್ಕೀಮ್‌ಗೆ ಎರಡು ಹೊಸ ಕ್ರಿಯೆಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ: (1) API ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ವ್ಯವಹಾರವನ್ನು ಕರೆಯಲು ಅಗತ್ಯವಾದ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಸಂದೇಶವನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕರು ವಹಿವಾಟನ್ನು ಸಿಸ್ಟಮ್ ಸ್ವೀಕರಿಸಿದೆ ಎಂಬ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ( 2) ಬ್ಯಾಕೆಂಡ್ ಸರದಿಯಿಂದ ಸಂರಚನೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ವೇಗದಲ್ಲಿ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ; ವಹಿವಾಟನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಟೇಟಸ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
ಈಗ ನೀವು ನಿರ್ಮಾಣ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದಷ್ಟು ಸಾಮರ್ಥ್ಯವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು, ಬಳಕೆದಾರರಿಂದ ವಿಳಂಬವನ್ನು ಮರೆಮಾಡಬಹುದು.

ಇತರ ಉಪಕರಣಗಳು

ಚೈನ್‌ಕೋಡ್ ಕುರಿತು ಇಲ್ಲಿ ಏನನ್ನೂ ಹೇಳಲಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಅದರಲ್ಲಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಸಾಮಾನ್ಯವಾಗಿ ಏನೂ ಇರುವುದಿಲ್ಲ. ಚೈನ್‌ಕೋಡ್ ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿರಬೇಕು - ಅದಕ್ಕೆ ಬೇಕಾಗಿರುವುದು ಅಷ್ಟೆ. ಚೌಕಟ್ಟು ಸರಳವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಚೈನ್‌ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. CSKit S7 Techlab ಮತ್ತು ಸ್ಥಿರ ವಿಶ್ಲೇಷಕದಿಂದ ಪುನಶ್ಚೇತನ ^CC.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಫ್ಯಾಬ್ರಿಕ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಸರಳ ಮತ್ತು ಆನಂದದಾಯಕವಾಗಿಸಲು ನಮ್ಮ ತಂಡವು ಉಪಯುಕ್ತತೆಗಳ ಗುಂಪನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದೆ: ಬ್ಲಾಕ್‌ಚೈನ್ ಎಕ್ಸ್‌ಪ್ಲೋರರ್, ಗಾಗಿ ಉಪಯುಕ್ತತೆ ಸ್ವಯಂಚಾಲಿತ ನೆಟ್ವರ್ಕ್ ಮರುಸಂರಚನೆ (ಸಂಸ್ಥೆಗಳನ್ನು ಸೇರಿಸಿ/ತೆಗೆದುಹಾಕಿ, RAFT ನೋಡ್‌ಗಳು), ಇದಕ್ಕಾಗಿ ಉಪಯುಕ್ತತೆ ಪ್ರಮಾಣಪತ್ರ ಹಿಂತೆಗೆದುಕೊಳ್ಳುವಿಕೆ ಮತ್ತು ಗುರುತನ್ನು ತೆಗೆದುಹಾಕುವುದು. ನೀವು ಕೊಡುಗೆ ನೀಡಲು ಬಯಸಿದರೆ, ಸ್ವಾಗತ.

ತೀರ್ಮಾನಕ್ಕೆ

ಈ ವಿಧಾನವು ಹೈಪರ್‌ಲೆಡ್ಜರ್ ಫ್ಯಾಬ್ರಿಕ್ ಅನ್ನು ಕೋರಮ್, ಇತರ ಖಾಸಗಿ ಎಥೆರಿಯಮ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು (ಪಿಒಎ ಅಥವಾ ಪಿಒಡಬ್ಲ್ಯೂ) ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ನೈಜ ಥ್ರೋಪುಟ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಸಾಮಾನ್ಯ ಯುಎಕ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ (ಬ್ರೌಸರ್‌ನಲ್ಲಿರುವ ಬಳಕೆದಾರರಿಗೆ ಮತ್ತು ಸಂಯೋಜಿತ ಸಿಸ್ಟಮ್‌ಗಳ ಬದಿಯಿಂದ. ) ಸ್ಕೀಮ್‌ನಲ್ಲಿ ಫ್ಯಾಬ್ರಿಕ್ ಅನ್ನು Ethereum ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವಾಗ, ಮರುಪ್ರಯತ್ನ ಸೇವೆ / ಡೆಕೋರೇಟರ್‌ನ ತರ್ಕವನ್ನು ಮಾತ್ರ MVCC ಘರ್ಷಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ಪರಮಾಣು ನಾನ್ಸ್ ಇನ್ಕ್ರಿಮೆಂಟ್ ಮತ್ತು ಮರು ಕಳುಹಿಸುವಿಕೆಗೆ ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ಬಫರಿಂಗ್ ಮತ್ತು ಸ್ಥಿತಿ ಸಂಗ್ರಹಣೆಯು ಬ್ಲಾಕ್ ರಚನೆಯ ಸಮಯದಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಬೇರ್ಪಡಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಈಗ ನೀವು ಸಾವಿರಾರು ಆರ್ಡರ್ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಬ್ಲಾಕ್‌ಗಳು ಆಗಾಗ್ಗೆ ರಚನೆಯಾಗುತ್ತವೆ ಮತ್ತು ಆರ್ಡರ್ ಮಾಡುವ ಸೇವೆಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತವೆ ಎಂದು ಭಯಪಡಬೇಡಿ.

ಸಾಮಾನ್ಯವಾಗಿ, ನಾನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸಿದ್ದು ಇದನ್ನೇ. ಯಾರಿಗಾದರೂ ಅವರ ಕೆಲಸದಲ್ಲಿ ಸಹಾಯ ಮಾಡಿದರೆ ನನಗೆ ಸಂತೋಷವಾಗುತ್ತದೆ.

ಮೂಲ: www.habr.com