【Предговор】
Когато данните достигнат определено количество, базата данни се превръща в тесно място на цялата система, а стратегията за оптимизация обикновено се приема като разделяне между четене и запис, а базата данни реализира разделяне между четене и запис чрез разделяне на основната база данни от базата данни (операция за заявка за запис от основната база данни, операция за заявка за четене от базата данни);
【Идеи за решаване на забавяния в данни】
1. Принципът на синхронизацията на майстор-слейв (тук вземем най-популярния MySQL като пример)
Ето схематична диаграма на класическа MySQL мастър-слейв синхронизация на данни чрез binlog:
2. Как възникват проблемите?
1. От горната схема не е трудно да се установи, че синхронизацията между майстор и подчинен има определено забавяне, което влияе на размера на закъснението:
(1) Размерът на забавянето зависи от количеството данни, генерирани от последната синхронизация до настоящето
(2) Текущата мрежова ситуация между сървърите
(3) Натискът от самия master-slave сървър (CPU, памет, вход и др.)
2. Тъй като услугата за база данни обикновено е в интранет, а сървърът ще бъде по-висок в конфигурацията (повече от реалната нужда) при покупка, синхронизацията е по същество много бърза, обикновено в милисекунди;
3. В общи бизнес ситуации милисекундната латентност може да бъде игнорирана;
4. Има общи и специални случаи, а някои специални ситуации изискват реална милисекундна разлика във времето. Ето често срещани решения за тези специални ситуации.
3. Решения за латентност на данните:
1. Схема 1: Запишете програмата двойно (пишете основната база данни и четете базата данни едновременно)
2. Схема 2: Прочетете програмата, за да проверите основната база данни
3. Схема 3: Запишете основната база данни и кеша (задайте определено време за изтичане, обикновено малко по-голямо от максималното забавяне на синхронизацията на базата данни), прочетете програмата, прочетете кеша и четете подчинената база данни
4. Предимства и недостатъци на трите схеми:
1. Схема 1: Двойното писане ще изисква определено количество производителност, което е сравнително лесно за реализиране и не е подходящо за сценарии на писане с висока честота на едновременно писане;
2. Схема 2: Програмата за четене ще повлияе на производителността на основната библиотека, която е сравнително лесна за реализиране и не е подходяща за сценарии с много едновременно четене.
3. Схема 3: В повечето случаи четенето и записването изискват повече производителност при запис, което е по-сложно за реализиране и е подходящо както за често едновременно четене, така и за запис (четенията и записите в кеша са много бързи);
【Резюме】
1. Изпълнението е важно, но по-важна е идеята;
2. Много основни принципи и идеи са универсални
Оригинален:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Публикувано на 2020-4-2 20:41:03
|
|
|
|
