【Передмова】
Коли обсяг даних досягає певної кількості, база даних стає вузьким місцем усієї системи, і стратегія оптимізації зазвичай застосовується як розділення читання і запису, а база даних реалізує розділення читання і запису, розділяючи основну базу даних від бази даних (операція запиту на запис з основної бази, операція запиту на читання з бази даних);
【Ідеї для розв'язання затримок даних】
1. Принцип синхронізації майстер-слейв (тут візьмемо найпопулярніший MySQL як приклад)
Ось схематична схема класичної MySQL майстер-слейв синхронізації даних через binlog:
2. Як виникають проблеми?
1. З наведеної вище схеми неважко встановити, що синхронізація майстер-підлеглий має певну затримку, яка впливає на розмір затримки:
(1) Розмір затримки залежить від обсягу даних, отриманих від останньої синхронізації до теперішнього часу
(2) Поточна мережева ситуація між серверами
(3) Тиск на сам сервер майстер-слейв (процесор, пам'ять, вихід тощо)
2. Оскільки сервіс бази даних зазвичай знаходиться в інтранеті, а сервер буде вищим за конфігурацією (більше, ніж фактична потреба) при покупці, синхронізація фактично дуже швидка, зазвичай у мілісекундах;
3. У загальних бізнес-сценаріях мілісекундну затримку можна ігнорувати;
4. Існують загальні та особливі випадки, а деякі особливі ситуації потребують різниці у мілісекундах у реальному часі. Ось поширені рішення для таких особливих ситуацій.
3. Рішення щодо затримки даних:
1. Схема 1: Записувати програму подвійно (одночасно написати основну базу даних і прочитати базу даних)
2. Схема 2: Прочитайте програму, щоб перевірити основну базу даних
3. Схема 3: Записати основну базу даних і записати кеш (встановити певний час закінчення, зазвичай трохи більший за максимальну затримку синхронізації бази даних), прочитати програму, прочитати кеш і прочитати підлеглу базу даних
4. Переваги та недоліки трьох схем:
1. Схема 1: Подвійний запис споживає певний рівень продуктивності, що відносно просто реалізувати і не підходить для сценаріїв з високою кількістю паралельних записів;
2. Схема 2: Програма читання вплине на продуктивність основної бібліотеки, яка відносно проста у реалізації і не підходить для сценаріїв з великим рівнем одночасного читання.
3. Схема 3: У більшості випадків читання та запис потребують більшої продуктивності запису, що складніше реалізувати, і підходить як для високорівних одночасних читань, так і для запису (читання та запис у кеші дуже швидкі);
【Summary】
1. Реалізація важлива, але ще важливіша ідея;
2. Багато основних принципів і ідей є універсальними
Оригінальний:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Опубліковано 2020-4-2 20:41:03
|
|
|
|
