ការចាក់សោចែកចាយដោយប្រើ Redis

ហេហេ!

ថ្ងៃនេះយើងនាំមកជូនលោកអ្នកនូវការបកប្រែអត្ថបទដ៏ស្មុគស្មាញមួយអំពីការអនុវត្តការចាក់សោរចែកចាយដោយប្រើប្រាស់ Redis ហើយអញ្ជើញអ្នកឱ្យនិយាយអំពីការរំពឹងទុករបស់ Redis ជាប្រធានបទមួយ។ ការវិភាគនៃក្បួនដោះស្រាយ Redlock នៅក្នុងសំណួរពី Martin Kleppmann អ្នកនិពន្ធសៀវភៅ "កម្មវិធីផ្ទុកខ្ពស់។", ផ្តល់ឱ្យ នៅទីនេះ.

ការចាក់សោរចែកចាយគឺជាបុព្វបទដ៏មានប្រយោជន៍បំផុតដែលប្រើក្នុងបរិស្ថានជាច្រើន ដែលដំណើរការផ្សេងៗគ្នាត្រូវតែដំណើរការលើធនធានរួមក្នុងលក្ខណៈផ្តាច់មុខទៅវិញទៅមក។

មានបណ្ណាល័យ និងប្រកាសមួយចំនួននៅទីនោះដែលពិពណ៌នាអំពីរបៀបអនុវត្ត DLM (Distributed Lock Manager) ដោយប្រើ Redis ប៉ុន្តែបណ្ណាល័យនីមួយៗប្រើវិធីសាស្រ្តផ្សេងគ្នា ហើយការធានាដែលពួកគេផ្តល់គឺខ្សោយណាស់បើប្រៀបធៀបទៅនឹងអ្វីដែលអាចសម្រេចបានជាមួយនឹងការរចនាស្មុគ្រស្មាញជាងបន្តិច។

នៅក្នុងអត្ថបទនេះ យើងនឹងព្យាយាមពណ៌នាអំពីក្បួនដោះស្រាយ Canonical តាមលក្ខខណ្ឌ ដែលបង្ហាញពីរបៀបអនុវត្តការចាក់សោចែកចាយដោយប្រើ Redis ។ យើងនឹងនិយាយអំពី algorithm ដែលហៅថា ចាក់សោរក្រហមវាអនុវត្តកម្មវិធីគ្រប់គ្រងសោរដែលបានចែកចាយ ហើយតាមគំនិតរបស់យើង ក្បួនដោះស្រាយនេះមានសុវត្ថិភាពជាងវិធីសាស្រ្ដតែមួយធម្មតា។ យើងសង្ឃឹមថាសហគមន៍នឹងវិភាគវា ផ្តល់មតិកែលម្អ និងប្រើវាជាចំណុចចាប់ផ្តើមសម្រាប់គម្រោងស្មុគស្មាញ ឬជំនួស។

ការអនុវត្ត

មុននឹងបន្តទៅការពិពណ៌នានៃក្បួនដោះស្រាយ យើងផ្តល់តំណភ្ជាប់ជាច្រើនទៅកាន់ការអនុវត្តដែលត្រៀមរួចជាស្រេច។ ពួកគេអាចត្រូវបានប្រើសម្រាប់ជាឯកសារយោង។

• Redlock-rb (ការអនុវត្តសម្រាប់ Ruby) ។ ក៏មានដែរ។ សម Redlock-rb ដែលបន្ថែមកញ្ចប់ (ត្បូង) សម្រាប់ភាពងាយស្រួលនៃការចែកចាយ ហើយមិនត្រឹមតែសម្រាប់នោះទេ។
• Redlock-py (ការអនុវត្ត Python) ។
• Aioredlock (ការអនុវត្តសម្រាប់ Asyncio Python) ។
• Redlock-php (ការអនុវត្តសម្រាប់ PHP) ។
• PHPRedisMutex (ការអនុវត្តមួយផ្សេងទៀតសម្រាប់ PHP)
• cheprasov/php-redis-lock (បណ្ណាល័យ PHP សម្រាប់ចាក់សោ)
• Redsync (ការអនុវត្តសម្រាប់ Go) ។
• ការកែប្រែឡើងវិញ (ការអនុវត្តសម្រាប់ Java) ។
• Redis::DistLock (ការអនុវត្តសម្រាប់ Perl) ។
• Redlock-cpp (ការអនុវត្តសម្រាប់ C ++) ។
• Redlock-cs (ការអនុវត្តសម្រាប់ C#/.NET) ។
• RedLock.net (ការអនុវត្តសម្រាប់ C#/.NET) ។ ជាមួយនឹងការគាំទ្រសម្រាប់ផ្នែកបន្ថែម async និងចាក់សោ។
• ScarletLock (ការអនុវត្តសម្រាប់ C# .NET ជាមួយនឹងឃ្លាំងទិន្នន័យដែលអាចកំណត់រចនាសម្ព័ន្ធបាន)
• Redlock4Net (ការអនុវត្តសម្រាប់ C# .NET)
• node-redlock (ការអនុវត្តសម្រាប់ NodeJS) ។ រួមបញ្ចូលការគាំទ្រសម្រាប់ការពង្រីកសោ។

ការធានាសុវត្ថិភាពនិងភាពអាចរកបាន

យើងនឹងយកគំរូតាមការរចនារបស់យើងជាមួយនឹងលក្ខណៈសម្បត្តិបីយ៉ាងដែលយើងគិតថាផ្តល់នូវការធានាអប្បបរមាដែលត្រូវការដើម្បីប្រើប្រាស់ការចាក់សោចែកចាយប្រកបដោយប្រសិទ្ធភាព។

1. ទ្រព្យសម្បត្តិសុវត្ថិភាព៖ ការមិនរាប់បញ្ចូលទៅវិញទៅមក។ នៅពេលណាមួយ មានតែអតិថិជនម្នាក់ប៉ុណ្ណោះដែលអាចកាន់សោបាន។
2. ភាពអាចរកបាននៃទ្រព្យសម្បត្តិ A: គ្មានការជាប់គាំងទេ។ វាតែងតែអាចទៅរួចក្នុងការទទួលបានសោ ទោះបីជាម៉ាស៊ីនភ្ញៀវដែលចាក់សោធនធានបរាជ័យ ឬចុះចតលើផ្នែកឌីសផ្សេងក៏ដោយ។
3. ភាពអាចរកបាននៃទ្រព្យសម្បត្តិ B: ការអត់ឱនកំហុស។ ដរាបណាថ្នាំង Redis ភាគច្រើនកំពុងដំណើរការ អតិថិជនអាចទទួលបាន និងបញ្ចេញសោ។

ហេតុអ្វីបានជាការអនុវត្តដោយផ្អែកលើការស្ដារឡើងវិញការបរាជ័យគឺមិនគ្រប់គ្រាន់ក្នុងករណីនេះ
ដើម្បីយល់ពីអ្វីដែលយើងនឹងកែលម្អ សូមវិភាគស្ថានភាពបច្ចុប្បន្នជាមួយបណ្ណាល័យចាក់សោរចែកចាយភាគច្រើនដោយផ្អែកលើ Redis ។

វិធីសាមញ្ញបំផុតដើម្បីចាក់សោធនធានដោយប្រើ Redis គឺដើម្បីបង្កើតកូនសោនៅក្នុងឧទាហរណ៍។ ជាធម្មតា សោត្រូវបានបង្កើតជាមួយនឹងអាយុកាលកំណត់ វាត្រូវបានសម្រេចដោយប្រើមុខងារផុតកំណត់ដែលមាននៅក្នុង Redis ដូច្នេះមិនយូរមិនឆាប់សោនេះត្រូវបានចេញផ្សាយ (ទ្រព្យសម្បត្តិ 2 នៅក្នុងបញ្ជីរបស់យើង)។ នៅពេលដែលអតិថិជនត្រូវការបញ្ចេញធនធាន វាលុបសោ។

នៅ glance ដំបូង, ដំណោះស្រាយនេះដំណើរការល្អ, ប៉ុន្តែមានបញ្ហាមួយ: ស្ថាបត្យកម្មរបស់យើងបង្កើតចំណុចតែមួយនៃការបរាជ័យ។ តើមានអ្វីកើតឡើងប្រសិនបើឧទាហរណ៍ម៉ាស៊ីន Redis បរាជ័យ? តោះបន្ថែមទាសករ! ហើយយើងនឹងប្រើវា ប្រសិនបើអ្នកធ្វើបទបង្ហាញមិនអាចប្រើបាន។ ជាអកុសល ជម្រើសនេះមិនអាចដំណើរការបានទេ។ តាមរយៈការធ្វើដូចនេះ យើងនឹងមិនអាចអនុវត្តបានត្រឹមត្រូវនូវទ្រព្យសម្បត្តិការដកគ្នាទៅវិញទៅមកដែលយើងត្រូវធានាសុវត្ថិភាពនោះទេ ពីព្រោះការចម្លងនៅក្នុង Redis គឺអសមកាល។

ជាក់ស្តែងនៅក្នុងគំរូបែបនេះ លក្ខខណ្ឌនៃការប្រណាំងកើតឡើង៖

1. អតិថិជន A ទទួលបានសោនៅលើមេ។
2. មេបរាជ័យមុនពេលបញ្ចូលគន្លឹះត្រូវបានផ្ទេរទៅទាសករ។
3. អ្នកដើរតាមត្រូវបានតំឡើងឋានៈជាអ្នកដឹកនាំ។
4. អតិថិជន B ទទួលបានសោនៅលើធនធានដូចគ្នាដែល A បានចាក់សោរួចហើយ។ ការរំលោភលើសុវត្ថិភាព!

ជួនកាលវាជារឿងធម្មតាទាំងស្រុងដែលនៅក្នុងកាលៈទេសៈពិសេស ដូចជាការបរាជ័យ អតិថិជនជាច្រើនអាចកាន់សោក្នុងពេលតែមួយ។ ក្នុងករណីបែបនេះ ដំណោះស្រាយផ្អែកលើការចម្លងអាចត្រូវបានអនុវត្ត។ បើមិនដូច្នោះទេយើងណែនាំដំណោះស្រាយដែលបានពិពណ៌នានៅក្នុងអត្ថបទនេះ។

ការអនុវត្តត្រឹមត្រូវជាមួយឧទាហរណ៍តែមួយ

មុននឹងព្យាយាមយកឈ្នះលើចំណុចខ្វះខាតនៃការកំណត់រចនាសម្ព័ន្ធវត្ថុតែមួយដែលបានពិពណ៌នាខាងលើ ចូរយើងយល់ពីរបៀបដោះស្រាយករណីដ៏សាមញ្ញនេះឲ្យបានត្រឹមត្រូវ ព្រោះថាដំណោះស្រាយនេះពិតជាមានសុពលភាពនៅក្នុងកម្មវិធីដែលលក្ខខណ្ឌនៃការប្រណាំងអាចទទួលយកបានពីពេលមួយទៅពេលមួយ ហើយដោយសារតែការទប់ស្កាត់នៅលើ single instance បម្រើជាមូលដ្ឋានដែលត្រូវបានប្រើនៅក្នុងក្បួនដោះស្រាយចែកចាយដែលបានពិពណ៌នានៅទីនេះ។

ដើម្បីទទួលបានសោ សូមធ្វើដូចនេះ៖

SET resource_name my_random_value NX PX 30000

ពាក្យបញ្ជានេះដំឡើងសោលុះត្រាតែវាមិនទាន់មាន (ជម្រើស NX) ដោយមានសុពលភាព 30000 មិល្លីវិនាទី (ជម្រើស PX)។ គន្លឹះត្រូវបានកំណត់ទៅ "myrandomvalue" តម្លៃនេះត្រូវតែមានតែមួយគត់សម្រាប់អតិថិជនទាំងអស់ និងសំណើចាក់សោទាំងអស់។
ជាទូទៅ តម្លៃចៃដន្យត្រូវបានប្រើដើម្បីដោះសោដោយសុវត្ថិភាព ដោយមានស្គ្រីបប្រាប់ Redis៖ គ្រាន់តែដកសោចេញប្រសិនបើវាមាន ហើយតម្លៃដែលរក្សាទុកក្នុងវាគឺពិតជាអ្វីដែលរំពឹងទុក។ នេះត្រូវបានសម្រេចដោយប្រើស្គ្រីប Lua ខាងក្រោម៖

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

វាមានសារៈសំខាន់ណាស់ក្នុងការទប់ស្កាត់សោដែលកាន់ដោយអតិថិជនផ្សេងទៀតពីការដកចេញ។ ឧទាហរណ៍ អតិថិជនអាចទទួលបានសោ បន្ទាប់មកចាក់សោរក្នុងប្រតិបត្តិការមួយចំនួនដែលមានរយៈពេលយូរជាងសោដំបូង (ដើម្បីឱ្យសោមានពេលវេលាផុតកំណត់) ហើយក្រោយមកដកសោដែលអតិថិជនផ្សេងទៀតបានដាក់ចេញ។
ការប្រើ DEL សាមញ្ញគឺមិនមានសុវត្ថិភាពទេ ពីព្រោះអតិថិជនអាចដកសោដែលកាន់ដោយអតិថិជនផ្សេងទៀត។ ផ្ទុយទៅវិញ នៅពេលប្រើស្គ្រីបខាងលើ សោនីមួយៗត្រូវបាន "ចុះហត្ថលេខា" ជាមួយនឹងខ្សែអក្សរចៃដន្យ ដូច្នេះមានតែអតិថិជនដែលបានដាក់វាពីមុនប៉ុណ្ណោះដែលអាចលុបវាចេញបាន។

តើខ្សែចៃដន្យនេះគួរជាអ្វី? ខ្ញុំគិតថាវាគួរតែមាន 20 បៃពី /dev/urandom ប៉ុន្តែអ្នកអាចស្វែងរកវិធីដែលមានតម្លៃថោកដើម្បីធ្វើឱ្យខ្សែអក្សរមានលក្ខណៈប្លែកពីគេសម្រាប់គោលបំណងរបស់អ្នក។ ជាឧទាហរណ៍ វានឹងជាការល្អក្នុងការបណ្តុះ RC4 ជាមួយ /dev/urandom ហើយបន្ទាប់មកបង្កើតស្ទ្រីម pseudo-random ពីវា។ ដំណោះស្រាយសាមញ្ញជាងនេះពាក់ព័ន្ធនឹងការរួមបញ្ចូលគ្នានៃពេលវេលាយូនីកក្នុងគុណភាពបង្ហាញមីក្រូវិនាទី បូកនឹងលេខសម្គាល់អតិថិជន។ វាមិនមានសុវត្ថិភាពទេ ប៉ុន្តែវាប្រហែលជាអាស្រ័យលើកិច្ចការនៅក្នុងបរិបទភាគច្រើន។

ពេលវេលាដែលយើងប្រើជារង្វាស់នៃអាយុកាលរបស់សោត្រូវបានគេហៅថា "អាយុកាលសោរ" ។ តម្លៃនេះគឺទាំងចំនួនពេលវេលាមុនពេលការចាក់សោត្រូវបានចេញផ្សាយដោយស្វ័យប្រវត្តិ និងចំនួនពេលវេលាដែលអតិថិជនត្រូវបញ្ចប់ប្រតិបត្តិការ មុនពេលអតិថិជនផ្សេងទៀតអាចចាក់សោធនធាននោះ ដោយមិនបំពានលើការធានាការបដិសេធទៅវិញទៅមក។ ការធានានេះត្រូវបានកំណត់ត្រឹមតែរយៈពេលជាក់លាក់មួយប៉ុណ្ណោះ ដែលចាប់ផ្តើមពីពេលដែលសោត្រូវបានទិញ។

ដូច្នេះ​យើង​បាន​ពិភាក្សា​អំពី​វិធី​ដ៏​ល្អ​មួយ​ក្នុង​ការ​ទទួល​បាន​និង​ដោះ​លែង​សោរ។ ប្រព័ន្ធ (ប្រសិនបើយើងកំពុងនិយាយអំពីប្រព័ន្ធដែលមិនចែកចាយដែលមានឧទាហរណ៍តែមួយ និងតែងតែមាន) គឺមានសុវត្ថិភាព។ ចូរពង្រីកគំនិតនេះទៅប្រព័ន្ធចែកចាយ ដែលយើងមិនមានការធានាបែបនេះទេ។

ក្បួនដោះស្រាយ Redlock

កំណែដែលបានចែកចាយនៃក្បួនដោះស្រាយសន្មតថាយើងមាន N Redis masters ។ ថ្នាំងទាំងនេះគឺឯករាជ្យទាំងស្រុងពីគ្នាទៅវិញទៅមក ដូច្នេះយើងមិនប្រើការចម្លង ឬប្រព័ន្ធសំរបសំរួលដោយប្រយោលណាមួយផ្សេងទៀតទេ។ យើង​បាន​និយាយ​រួច​ហើយ​អំពី​របៀប​ទទួល​បាន និង​ដោះ​សោរ​ដោយ​សុវត្ថិភាព​លើ​ឧទាហរណ៍​តែមួយ។ យើងយល់ស្របថា algorithm ពេលធ្វើការជាមួយ instance តែមួយ នឹងប្រើវិធីនេះយ៉ាងពិតប្រាកដ។ នៅក្នុងឧទាហរណ៍របស់យើងយើងកំណត់ N ដល់ 5 ដែលជាតម្លៃសមហេតុផល។ ដូច្នេះ យើងនឹងត្រូវការប្រើមេ Redis ចំនួន 5 នៅលើកុំព្យូទ័រផ្សេងគ្នា ឬម៉ាស៊ីននិម្មិត ដើម្បីធានាថាពួកវាធ្វើសកម្មភាពភាគច្រើនដោយឯករាជ្យពីគ្នាទៅវិញទៅមក។

ដើម្បីទទួលបានសោ អតិថិជនអនុវត្តប្រតិបត្តិការដូចខាងក្រោមៈ

1. ទទួលបានពេលវេលាបច្ចុប្បន្នគិតជាមិល្លីវិនាទី។
2. ព្យាយាមជាបន្តបន្ទាប់ដើម្បីទទួលបានការចាក់សោលើករណី N ទាំងអស់ ដោយប្រើឈ្មោះគន្លឹះដូចគ្នា និងតម្លៃចៃដន្យក្នុងគ្រប់ករណីទាំងអស់។ នៅក្នុងដំណាក់កាលទី 2 នៅពេលដែលអតិថិជនកំណត់សោលើមូលដ្ឋាននីមួយៗ អតិថិជនប្រើការពន្យាពេលដើម្បីទទួលបានវាដែលខ្លីគ្រប់គ្រាន់បើប្រៀបធៀបទៅនឹងពេលវេលាបន្ទាប់ពីការចាក់សោរដោយស្វ័យប្រវត្តិ។ ឧទាហរណ៍ ប្រសិនបើរយៈពេលនៃការទប់ស្កាត់គឺ 10 វិនាទី នោះការពន្យារពេលអាចស្ថិតនៅក្នុងចន្លោះ ~ 5-50 មិល្លីវិនាទី។ វាលុបបំបាត់ស្ថានភាពដែលម៉ាស៊ីនភ្ញៀវអាចនៅតែត្រូវបានរារាំងអស់រយៈពេលជាយូរដើម្បីព្យាយាមឈានដល់ថ្នាំង Redis ដែលបរាជ័យ៖ ប្រសិនបើ instance មិនអាចប្រើបាន នោះយើងព្យាយាមភ្ជាប់ទៅ instance ផ្សេងទៀតឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។
3. ដើម្បីយកសោ អតិថិជនគណនាថាតើពេលវេលាបានកន្លងផុតទៅប៉ុន្មាន។ ដើម្បីធ្វើដូច្នេះ វាដកពីតម្លៃពេលវេលាជាក់ស្តែងនៃពេលវេលាដែលបានទទួលក្នុងជំហានទី 1។ ប្រសិនបើ និងលុះត្រាតែអតិថិជនអាចទទួលបានសោរនៅលើករណីភាគច្រើន (យ៉ាងហោចណាស់ 3) និងពេលវេលាសរុបដែលវាបានចំណាយ។ ទទួលបានសោ តិចជាងរយៈពេលចាក់សោ សោត្រូវបានចាត់ទុកថាបានទទួល។
4. ប្រសិនបើសោត្រូវបានទទួល នោះរយៈពេលនៃការចាក់សោត្រូវបានយកជារយៈពេលចាក់សោដើមដកពីពេលវេលាដែលបានកន្លងផុតទៅដែលបានគណនាក្នុងជំហានទី 3។
5. ប្រសិនបើអតិថិជនបរាជ័យក្នុងការទទួលបានសោដោយហេតុផលមួយចំនួន (ទាំងវាមិនអាចចាក់សោវត្ថុ N/2+1 ឬរយៈពេលចាក់សោគឺអវិជ្ជមាន) នោះវានឹងព្យាយាមដោះសោគ្រប់ករណីទាំងអស់ (សូម្បីតែអ្នកដែលគិតថាវាមិនអាចទប់ស្កាត់បានក៏ដោយ។ )

តើ​ក្បួន​ដោះស្រាយ​អសមកាល​ទេ?

ក្បួនដោះស្រាយនេះគឺផ្អែកលើការសន្មត់ថា ទោះបីជាមិនមាននាឡិកាធ្វើសមកាលកម្មដែលដំណើរការទាំងអស់នឹងដំណើរការក៏ដោយ ពេលវេលាក្នុងស្រុកនៅក្នុងដំណើរការនីមួយៗនៅតែដំណើរការក្នុងល្បឿនប្រហាក់ប្រហែលគ្នា ហើយកំហុសគឺតូចបើប្រៀបធៀបទៅនឹងពេលវេលាសរុបបន្ទាប់ពីការចាក់សោ។ ចេញផ្សាយដោយស្វ័យប្រវត្តិ។ ការសន្មត់នេះគឺស្រដៀងគ្នាទៅនឹងស្ថានភាពធម្មតាសម្រាប់កុំព្យូទ័រធម្មតា៖ កុំព្យូទ័រនីមួយៗមាននាឡិកាក្នុងស្រុក ហើយជាធម្មតាយើងអាចពឹងផ្អែកលើការពិតដែលថាភាពខុសគ្នានៃពេលវេលារវាងកុំព្យូទ័រផ្សេងគ្នាគឺតូច។

នៅចំណុចនេះ យើងត្រូវបង្កើតច្បាប់នៃការបដិសេធទៅវិញទៅមករបស់យើងដោយប្រុងប្រយ័ត្នជាងមុន៖ ការដកទៅវិញទៅមកត្រូវបានធានាលុះត្រាតែអតិថិជនកាន់សោរចេញក្នុងអំឡុងពេលដែលសោមានសុពលភាព (តម្លៃនេះទទួលបានក្នុងជំហានទី 3) ដកពេលវេលាខ្លះទៀត (សរុបពីរបី មិល្លីវិនាទីដើម្បីទូទាត់សងសម្រាប់ភាពខុសគ្នានៃពេលវេលារវាងដំណើរការ)។

អត្ថបទគួរឱ្យចាប់អារម្មណ៍ខាងក្រោមប្រាប់បន្ថែមអំពីប្រព័ន្ធបែបនេះដែលទាមទារការសម្របសម្រួលនៃចន្លោះពេល៖ ការជួល៖ យន្តការអត់ធ្មត់ចំពោះកំហុសប្រកបដោយប្រសិទ្ធភាពសម្រាប់ភាពស៊ីសង្វាក់នៃឃ្លាំងសម្ងាត់ឯកសារដែលបានចែកចាយ.

ព្យាយាមម្តងទៀតលើការបរាជ័យ

នៅពេលដែលអតិថិជនបរាជ័យក្នុងការទទួលបានសោ វាត្រូវតែព្យាយាមម្តងទៀតបន្ទាប់ពីការពន្យារពេលចៃដន្យ។ នេះត្រូវបានធ្វើដើម្បី de-synchronize អតិថិជនជាច្រើនដែលព្យាយាមទទួលបានសោនៅលើធនធានដូចគ្នាក្នុងពេលតែមួយ (ដែលអាចនាំឱ្យមានស្ថានភាព "បំបែកខួរក្បាល" ដែលមិនមានអ្នកឈ្នះ)។ លើសពីនេះ កាន់តែលឿនអតិថិជនព្យាយាមដើម្បីទទួលបានការចាក់សោរលើករណី Redis ភាគច្រើន នោះបង្អួចកាន់តែតូចចង្អៀត ដែលស្ថានភាពខួរក្បាលអាចកើតឡើង (និងតិចជាងតម្រូវការសម្រាប់ការព្យាយាមម្តងទៀត) ។ ដូច្នេះតាមឧត្ដមគតិ អតិថិជនគួរតែព្យាយាមផ្ញើពាក្យបញ្ជា SET ទៅ N instances ក្នុងពេលដំណាលគ្នាដោយប្រើ multiplexing ។

វាមានតម្លៃក្នុងការសង្កត់ធ្ងន់នៅទីនេះថាតើវាមានសារៈសំខាន់យ៉ាងណាសម្រាប់អតិថិជនដែលបរាជ័យក្នុងការទទួលបានសោភាគច្រើនដើម្បីបញ្ចេញសោដែលទទួលបាន (ដោយផ្នែក) ដូច្នេះពួកគេមិនចាំបាច់រង់ចាំសោផុតកំណត់មុនពេលសោរធនធានអាចទទួលបានម្តងទៀត។ (ទោះបីជាការបែកខ្ញែកបណ្តាញកើតឡើង ហើយអតិថិជនបាត់បង់ទំនាក់ទំនងជាមួយ Redis ក៏ដោយ អ្នកត្រូវតែបង់ថ្លៃពិន័យដែលអាចរកបាន ខណៈពេលដែលរង់ចាំសោផុតកំណត់)។

ដោះសោ

ការដោះសោគឺជាប្រតិបត្តិការដ៏សាមញ្ញមួយដែលតម្រូវឱ្យដោះសោគ្រប់ករណីទាំងអស់ ដោយមិនគិតពីថាតើម៉ាស៊ីនភ្ញៀវហាក់ដូចជាបានចាក់សោវត្ថុជាក់លាក់ណាមួយដោយជោគជ័យនោះទេ។

ការពិចារណាអំពីសុវត្ថិភាព

តើ​ក្បួន​ដោះស្រាយ​មាន​សុវត្ថិភាព​ទេ? ចូរយើងព្យាយាមស្រមៃមើលថាតើមានអ្វីកើតឡើងនៅក្នុងសេណារីយ៉ូផ្សេងៗ។

ដើម្បីចាប់ផ្តើម ឧបមាថាអតិថិជនអាចទទួលបានសោរលើករណីភាគច្រើន។ ឧទាហរណ៍នីមួយៗនឹងមានសោដែលមានអាយុកាលដូចគ្នាសម្រាប់ទាំងអស់គ្នា។ ទោះជាយ៉ាងណាក៏ដោយ សោទាំងនេះនីមួយៗត្រូវបានដំឡើងនៅពេលផ្សេងគ្នា ដូច្នេះពួកវានឹងផុតកំណត់នៅពេលផ្សេងគ្នា។ ប៉ុន្តែប្រសិនបើសោដំបូងត្រូវបានដំឡើងនៅពេលនោះមិនអាក្រក់ជាង T1 (ពេលវេលាដែលយើងជ្រើសរើសមុនពេលទាក់ទងជាមួយម៉ាស៊ីនមេដំបូង) ហើយសោចុងក្រោយត្រូវបានដំឡើងនៅពេលនោះមិនអាក្រក់ជាង T2 (ពេលវេលាដែលការឆ្លើយតបត្រូវបានទទួល ពីម៉ាស៊ីនមេចុងក្រោយ) បន្ទាប់មកយើងមានទំនុកចិត្តថាសោដំបូងនៅក្នុងសំណុំដែលផុតកំណត់នឹងនៅរស់យ៉ាងហោចណាស់ MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. សោផ្សេងទៀតទាំងអស់នឹងផុតកំណត់នៅពេលក្រោយ ដូច្នេះយើងអាចប្រាកដថាសោទាំងអស់នឹងមានសុពលភាពក្នុងពេលដំណាលគ្នាយ៉ាងហោចណាស់នៅពេលនេះ។

ក្នុងអំឡុងពេលដែលសោភាគច្រើននៅតែមានសុពលភាព អតិថិជនផ្សេងទៀតនឹងមិនអាចទទួលបានសោបានទេ ដោយសារប្រតិបត្តិការ N/2+1 SET NX មិនអាចជោគជ័យបានទេ ប្រសិនបើសោ N/2+1 មានរួចហើយ។ ដូច្នេះនៅពេលដែលសោមួយត្រូវបានទទួល វាមិនអាចទៅរួចទេក្នុងការទទួលបានវាម្តងទៀតនៅពេលតែមួយ (វានឹងបំពានលើទ្រព្យសម្បត្តិនៃការបដិសេធទៅវិញទៅមក)។
ទោះជាយ៉ាងណាក៏ដោយ យើងចង់ធ្វើឱ្យប្រាកដថា អតិថិជនជាច្រើនដែលព្យាយាមទទួលបានសោក្នុងពេលតែមួយ មិនអាចជោគជ័យក្នុងពេលតែមួយបានទេ។

ប្រសិនបើម៉ាស៊ីនភ្ញៀវបានចាក់សោករណីភាគច្រើនក្នុងរយៈពេលប្រហែល ឬច្រើនជាងរយៈពេលចាក់សោអតិបរមា វានឹងចាត់ទុកការចាក់សោនេះមិនត្រឹមត្រូវ ហើយដោះសោករណីទាំងនោះ។ ដូច្នេះ យើងត្រូវតែគិតគូរតែករណីដែលអតិថិជនបានគ្រប់គ្រងដើម្បីទប់ស្កាត់ករណីភាគច្រើនក្នុងរយៈពេលតិចជាងកាលបរិច្ឆេទផុតកំណត់។ ក្នុងករណីនេះទាក់ទងនឹងអំណះអំណាងខាងលើក្នុងអំឡុងពេល MIN_VALIDITY គ្មានអតិថិជនណាម្នាក់អាចទទួលបានសោឡើងវិញទេ។ ដូច្នេះ អតិថិជនជាច្រើននឹងអាចចាក់សោ N/2+1 ក្នុងពេលដំណាលគ្នា (ដែលបញ្ចប់នៅចុងបញ្ចប់នៃដំណាក់កាលទី 2) លុះត្រាតែពេលវេលាដើម្បីចាក់សោភាគច្រើនគឺធំជាងពេលវេលា TTL ដែលបង្ហាញការចាក់សោមិនត្រឹមត្រូវ។

តើ​អ្នក​អាច​ផ្តល់​ភស្តុតាង​ជា​ផ្លូវ​ការ​នៃ​សុវត្ថិភាព បង្ហាញ​ពី​ក្បួន​ដោះស្រាយ​ស្រដៀង​គ្នា​ដែល​មាន​ស្រាប់ ឬ​រក​ឃើញ​កំហុស​នៅ​ក្នុង​ចំណុច​ខាង​លើ​បាន​ទេ?

ការពិចារណាអំពីភាពងាយស្រួល

ភាពអាចរកបាននៃប្រព័ន្ធអាស្រ័យលើលក្ខណៈសំខាន់បី៖

1. ដោះសោដោយស្វ័យប្រវត្តិ (នៅពេលសោផុតកំណត់)៖ គ្រាប់ចុចនឹងអាចប្រើបានម្តងទៀត ដើម្បីប្រើសម្រាប់សោ។
2. ការពិតដែលថាអតិថិជនជាធម្មតាជួយគ្នាទៅវិញទៅមកដោយការដោះសោនៅពេលដែលសោដែលចង់បានមិនត្រូវបានទទួលឬត្រូវបានទទួលហើយការងារបានបញ្ចប់។ ដូច្នេះវាទំនងជាថាយើងនឹងមិនចាំបាច់រង់ចាំសោផុតកំណត់ដើម្បីទទួលបានសោម្តងទៀតនោះទេ។
3. ការពិតដែលថានៅពេលដែលអតិថិជនត្រូវព្យាយាមម្តងទៀតដើម្បីទទួលបានសោ វារង់ចាំរយៈពេលប្រៀបធៀបយូរជាងរយៈពេលដែលត្រូវការដើម្បីទទួលបានសោភាគច្រើន។ នេះកាត់បន្ថយលទ្ធភាពនៃស្ថានភាពខួរក្បាលបំបែកដែលកើតឡើងនៅពេលប្រកួតប្រជែងដើម្បីធនធាន។

ទោះយ៉ាងណាក៏ដោយ មានការពិន័យដែលអាចរកបានស្មើនឹង TTL នៃផ្នែកបណ្តាញ ដូច្នេះប្រសិនបើមានផ្នែកជាប់គ្នា ការពិន័យអាចនឹងគ្មានកំណត់។ វាកើតឡើងនៅពេលណាដែលអតិថិជនទទួលបានសោ ហើយបន្ទាប់មកច្រៀកទៅផ្នែកផ្សេងទៀត មុនពេលដែលវាអាចបញ្ចេញវាបាន។

ជាគោលការណ៍ ដែលបានផ្ដល់ឱ្យផ្នែកបណ្តាញជាប់គ្នាគ្មានកំណត់ ប្រព័ន្ធមួយអាចនៅតែមិនអាចប្រើបានសម្រាប់រយៈពេលគ្មានកំណត់។

ការអនុវត្ត ការបរាជ័យ និង fsync

មនុស្សជាច្រើនប្រើ Redis ពីព្រោះពួកគេត្រូវការដំណើរការម៉ាស៊ីនមេចាក់សោដែលដំណើរការខ្ពស់ទាក់ទងនឹងភាពយឺតយ៉ាវដែលត្រូវការដើម្បីទទួលបាន និងចេញផ្សាយការចាក់សោ និងចំនួនប្រតិបត្តិការទិញ/ចេញផ្សាយដែលអាចបញ្ចប់ក្នុងមួយវិនាទី។ ដើម្បីបំពេញតម្រូវការនេះ មានយុទ្ធសាស្រ្តក្នុងការទំនាក់ទំនងជាមួយម៉ាស៊ីនមេ N Redis ដើម្បីកាត់បន្ថយភាពយឺតយ៉ាវ។ នេះគឺជាយុទ្ធសាស្ត្រពហុគុណ (ឬ "ការគុណបុរសក្រីក្រ" ដែលរន្ធត្រូវបានដាក់ក្នុងរបៀបមិនទប់ស្កាត់ ផ្ញើពាក្យបញ្ជាទាំងអស់ និងអានពាក្យបញ្ជានៅពេលក្រោយ ដោយសន្មតថាពេលវេលាធ្វើដំណើរទៅមករវាងម៉ាស៊ីនភ្ញៀវ និងវត្ថុនីមួយៗគឺស្រដៀងគ្នា) .

ទោះជាយ៉ាងណាក៏ដោយ យើងក៏ត្រូវយកមកពិចារណាផងដែរ ដែលទាក់ទងនឹងការផ្ទុកទិន្នន័យរយៈពេលវែង ប្រសិនបើយើងខិតខំបង្កើតគំរូជាមួយនឹងការស្តារឡើងវិញដែលអាចទុកចិត្តបានពីការបរាជ័យ។

ជាមូលដ្ឋាន ដើម្បីបញ្ជាក់អំពីបញ្ហានេះ ឧបមាថាយើងកំណត់រចនាសម្ព័ន្ធ Redis ដោយមិនមានការផ្ទុកទិន្នន័យរយៈពេលវែងទាល់តែសោះ។ អតិថិជនគ្រប់គ្រងដើម្បីទប់ស្កាត់ 3 ក្នុងចំណោម 5 ករណី។ ករណីមួយក្នុងចំណោមករណីដែលអតិថិជនគ្រប់គ្រងដើម្បីទប់ស្កាត់ត្រូវបានចាប់ផ្តើមឡើងវិញ ហើយនៅពេលនេះមាន 3 ករណីម្តងទៀតសម្រាប់ធនធានដូចគ្នា ដែលយើងអាចទប់ស្កាត់បាន ហើយអតិថិជនផ្សេងទៀតអាចទប់ស្កាត់ឧទាហរណ៍ដែលបានចាប់ផ្តើមឡើងវិញដោយបំពានលើទ្រព្យសម្បត្តិសុវត្ថិភាពដែល សន្មតថាភាពផ្តាច់មុខនៃសោ។

ប្រសិនបើអ្នកបើកទិន្នន័យខាងមុខ (AOF) ស្ថានភាពនឹងប្រសើរឡើងបន្តិច។ ឧទាហរណ៍ អ្នកអាចផ្សព្វផ្សាយម៉ាស៊ីនមេដោយផ្ញើពាក្យបញ្ជា SHUTDOWN ហើយចាប់ផ្តើមវាឡើងវិញ។ ចាប់តាំងពីប្រតិបត្តិការផុតកំណត់នៅក្នុង Redis ត្រូវបានអនុវត្តតាមន័យធៀប តាមរបៀបដែលពេលវេលាបន្តហូរ បើទោះបីជាម៉ាស៊ីនមេត្រូវបានបិទក៏ដោយ តម្រូវការទាំងអស់របស់យើងគឺល្អ។ នេះជារឿងធម្មតាទេ ដរាបណាការបិទជាប្រចាំត្រូវបានធានា។ អ្វីដែលត្រូវធ្វើក្នុងករណីដាច់ភ្លើង? ប្រសិនបើ Redis ត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមលំនាំដើម ជាមួយនឹងការធ្វើសមកាលកម្ម fsync នៅលើថាសរាល់វិនាទី នោះវាអាចទៅរួចដែលថាបន្ទាប់ពីការចាប់ផ្តើមឡើងវិញយើងនឹងមិនមានសោរបស់យើងទេ។ តាមទ្រឹស្តី ប្រសិនបើយើងចង់ធានាសុវត្ថិភាពចាក់សោកំឡុងពេលចាប់ផ្តើមឡើងវិញ នោះយើងគួរតែបើកដំណើរការ fsync=always នៅក្នុងការកំណត់សម្រាប់ការផ្ទុកទិន្នន័យរយៈពេលវែង។ វានឹងសម្លាប់ដំណើរការទាំងស្រុង ដល់កម្រិតនៃប្រព័ន្ធ CP ដែលត្រូវបានប្រើជាប្រពៃណី ដើម្បីអនុវត្តសោរចែកចាយដោយសុវត្ថិភាព។

ប៉ុន្តែស្ថានភាពគឺប្រសើរជាងវាហាក់ដូចជានៅ glance ដំបូង។ ជាគោលការណ៍ សុវត្ថិភាពនៃក្បួនដោះស្រាយត្រូវបានរក្សា ពីព្រោះនៅពេលដែលវត្ថុត្រូវបានចាប់ផ្តើមឡើងវិញបន្ទាប់ពីការបរាជ័យ វាមិនចូលរួមក្នុងការចាក់សោណាមួយដែលបច្ចុប្បន្នសកម្មទៀតទេ។

ដើម្បីធានាបាននូវបញ្ហានេះ យើងគ្រាន់តែត្រូវធានាថាបន្ទាប់ពីការបរាជ័យ វត្ថុនៅតែមិនអាចប្រើបានក្នុងរយៈពេលមួយលើសពី TTL អតិបរមាដែលយើងប្រើបន្តិច។ វិធីនេះយើងនឹងរង់ចាំរហូតដល់កាលបរិច្ឆេទផុតកំណត់ និងការចេញផ្សាយដោយស្វ័យប្រវត្តិនូវសោទាំងអស់ដែលសកម្មនៅពេលបរាជ័យ។

ដោយប្រើការពន្យាពេលចាប់ផ្តើមឡើងវិញ វាជាគោលការណ៍ដែលអាចធ្វើទៅបានដើម្បីសម្រេចបាននូវសុវត្ថិភាព បើទោះបីជាអវត្ដមាននៃការបន្តរយៈពេលវែងណាមួយនៅក្នុង Redis ក៏ដោយ។ ទោះជាយ៉ាងណាក៏ដោយ សូមចំណាំថា នេះអាចបណ្តាលឱ្យមានការផាកពិន័យចំពោះការបំពានលើមធ្យោបាយងាយស្រួល។ ឧទាហរណ៍ ប្រសិនបើករណីភាគច្រើនបរាជ័យ ប្រព័ន្ធនឹងក្លាយទៅជាមិនអាចប្រើបានជាសកលសម្រាប់ TTL (ហើយគ្មានធនធានណាមួយអាចត្រូវបានរារាំងក្នុងអំឡុងពេលនេះ)។

យើងបង្កើនភាពអាចរកបាននៃក្បួនដោះស្រាយ: យើងពង្រីកការទប់ស្កាត់

ប្រសិនបើការងារដែលបានអនុវត្តដោយអតិថិជនមានជំហានតូចៗ វាអាចកាត់បន្ថយរយៈពេលចាក់សោលំនាំដើម និងអនុវត្តយន្តការសម្រាប់ពង្រីកសោ។ ជាគោលការណ៍ ប្រសិនបើម៉ាស៊ីនភ្ញៀវកំពុងរវល់ក្នុងការគណនា ហើយតម្លៃផុតកំណត់នៃការចាក់សោមានកម្រិតទាប នោះអ្នកអាចផ្ញើស្គ្រីប Lua ទៅកាន់គ្រប់ករណីដែលពង្រីក TTL នៃសោ ប្រសិនបើសោនៅតែមាន ហើយតម្លៃរបស់វានៅតែជាតម្លៃចៃដន្យដែលទទួលបាននៅពេល សោត្រូវបានទទួល។

អតិថិជនគួរតែពិចារណាតែសោដែលត្រូវទទួលបានឡើងវិញ ប្រសិនបើវាបានគ្រប់គ្រងដើម្បីចាក់សោករណីភាគច្រើនក្នុងរយៈពេលសុពលភាព។

ពិតមែន ក្បួនដោះស្រាយបច្ចេកទេសមិនផ្លាស់ប្តូរទេ ដូច្នេះចំនួនអតិបរមានៃការព្យាយាមម្តងហើយម្តងទៀតដើម្បីទទួលបានសោត្រូវតែមានកម្រិត បើមិនដូច្នេះទេ លក្ខណៈសម្បត្តិភាពងាយស្រួលនឹងត្រូវបានរំលោភបំពាន។

ប្រភព: www.habr.com