Продолжайте отвечать на вопросы Planet Water Friends, как спроектировать большой объем данных, высокий уровень параллелизма, цепочку отношений друзей и цепочку отношений фанатов?
Что такое бизнес цепочки взаимоотношений?
Цепочки отношений в основном делятся на две категории: слабые дружеские отношения и крепкие дружеские отношения, обе из которых имеют типичные приложения для интернет-продуктов.
Для установления слабой дружбы не требуется обоюдного согласия обеих сторон:
-
Пользователь A следует за пользователем B, и согласие пользователя B не требуется.В настоящее время пользователь A и пользователь B являются слабыми друзьями.Для A это временно понимается как «подписка»;
-
Пользователь B следует за пользователем A и не нуждается в согласии пользователя A. В настоящее время пользователь A и пользователь B также являются слабыми друзьями. Для A это временно понимается как «фанаты»;
Цепочка фан-отношений Weibo между айдолами и фанатами — это типичное слабое приложение для дружеских отношений.
Для установления прочных дружеских отношений требуется обоюдное согласие обеих сторон дружеских отношений.:
- Пользователь A запрашивает добавление пользователя B в друзья, и пользователь B соглашается. В настоящее время у пользователя A и пользователя B есть крепкие дружеские отношения друг с другом, то есть A является другом B, а B также является другом A;
Цепочка дружбы QQ - это типичная сильная приложение дружбы.
Buddy Center — это типичный бизнес «многие ко многим»:
-
Пользователь может добавить несколько друзей
-
Также могут быть добавлены несколькими друзьями
Его типичная архитектура:
-
служба друзей: служба центра друзей, обеспечивающая дружественный интерфейс RPC для вызывающих абонентов.
-
db: хранить данные о друзьях
Слабые дружеские отношения, как реализовать уровень хранения?
Благодаря бизнес-анализу слабых дружеских отношений легко понять, что его основные метаданные:
-
guanzhu(uid, guanzhu_uid);
-
fensi(uid, fensi_uid);
в:
-
таблица guanzhu, uid записи пользователя Все подписчики guanzhu_uid
-
таблица fensi, используемая для записи всех пользователей фанатов с uid fensi_uid
Следует подчеркнуть, что генерация слабых отношений создаст две записи: запись о подписке и запись о фанате.
Например: пользователь A (uid=1) подписан на пользователя B (uid=2), A подписан еще на одного пользователя, а у B есть еще один поклонник, поэтому:
-
Таблица guanzhu хочет вставить запись {1, 2}, 1 следует за 2
-
Таблица фенси хочет вставить запись {2, 1}, 2 поклонника 1
Как узнать, на кого подписан пользователь?
Ответ: Чтобы построить индекс по uid guanzhu:
select * from guanzhu where uid=1;
Вы можете получить результат, 1 следует за 2.
Как узнать, на кого подписан пользователь?
Ответ: Чтобы проиндексировать uid fensi:
select * from fensi where uid=2;
Вы можете получить результат, 2 порошка 1.
Крепкая дружба, как реализовать уровень хранения?
Вариант первый
Анализируя бизнес крепких дружеских отношений, легко понять, что его основные метаданные:
- friend(uid1, uid2);
в:
-
uid1, uid стороны в крепких дружеских отношениях
-
uid2, uid другой стороны в крепких дружеских отношениях
Пользователь с uid=1 добавляет пользователя с uid=2, и обе стороны соглашаются добавить друг друга в друзья. Для этих прочных дружеских отношений следует вставить запись {1, 2} или запись {2,1} в база данных?
Ответ: Да. Во избежание двусмысленности можно договориться, что значение uid1 должно быть меньше uid2 при вставке записи.
Например: есть три пользователя с uid=1,2,3, они крепко дружат друг с другом, таких записей в базе может быть три
{1, 2}
{2, 3}
{1, 3}
Как запросить друзей пользователя?
Ответ: Предположим, вы хотите запросить всех друзей с uid=2, просто проиндексируйте uid1 и uid2, затем:
select * from friend where uid1=2
union
select * from friend where uid2=2
чтобы получить результат.
Вариант 2
Крепкие дружеские отношения — это частный случай слабых дружеских отношений.A и B должны заботиться друг о друге(Можно также сказать, что они фанаты друг друга одновременно), то есть для достижения также можно использовать следующую таблицу и таблицу вентиляторов:
-
guanzhu(uid, guanzhu_uid);
-
fensi(uid, fensi_uid);
Например: Пользователь А (uid=1) и Пользователь Б (uid=2) являются сильными друзьями, то есть подписаны друг на друга:
Пользователь A (uid=1) подписан на пользователя B (uid=2), A подписан еще на одного пользователя, а у B есть еще один поклонник, поэтому:
-
В таблицу гуанжу нужно вставить запись {1, 2}
-
таблица фенси для вставки {2, 1} этой записи
В то же время пользователь B (uid=2) также подписан на пользователя A (uid=1), B подписан еще на одного пользователя, а у A есть еще один поклонник, поэтому:
-
Таблица Guanzhu для вставки {2, 1} этой записи
-
таблица фенси для вставки {1, 2} этой записи
Каковы преимущества и недостатки двух реализаций?
Существует два типа реализации крепких дружеских отношений:
-
таблица друзей (uid1, uid2)
-
Избыточность данных таблицы guanzhu и таблицы fensi (далее именуемой положительной таблицей T1 и обратной таблицей T2)
Объем данных небольшой, вроде бы разницы нет, но при больших объемах данных проявляется преимущество избыточности данных:
-
таблица друзей, когда объем данных велик, если uid1 используется для разделения базы данных, тогда запрос на uid2 должен проходить через несколько баз данных
-
Положительная таблица T1 и отрицательная таблица T2 реализуют дружеские отношения за счет избыточности данных. {1,2}{2,1} существуют в двух таблицах соответственно, поэтому обе таблицы используют uid для разделения базы данных, и требуется только один запрос. , вы можете найти соответствующих последователей и поклонников без необходимости многократного сканирования библиотеки
Голос за кадром: Если есть 1 миллиард цепочек отношений, они должны быть разделены по горизонтали.
Избыточность данных — это отношение «многие ко многим»..
Как выполнить избыточность данных?
Следующий вопрос заключается в том, как служба центра друзей реализует избыточность данных.Существуют три распространенных метода.
Метод 1: резервирование синхронизации службы
Как следует из названия, избыточные данные синхронно записываются службой центра друзей, как показано на рисунке 1-4 выше:
-
Деловая сторона вызывает службу и добавляет данные
-
Служба сначала вставляет данные T1
-
Сервис повторно вставляет данные T2
-
Служба возвращает бизнес-сторону для успешного добавления данных
преимущество:
-
Ничего сложного, сервисный уровень изменен с одной записи на две записи.
-
Согласованность данных относительно высока (возвращается, потому что двойная запись прошла успешно)
недостаток:
-
Увеличивается время обработки запроса (для вставки раз время удваивается)
-
Данные по-прежнему могут быть несогласованными. Например, если служба перезапускается после завершения второго шага записи в T1, данные не будут записаны в T2.
Если система более чувствительна к времени обработки, обычно используется второе решение.
Метод 2: асинхронная избыточность службы
Двойная запись данных больше не выполняется службой центра друзей.Служебный уровень отправляет сообщение асинхронно и отправляет его специальной службе репликации данных через шину сообщений для записи избыточных данных, как показано на рисунке 1-6 выше:
-
Деловая сторона вызывает службу и добавляет данные
-
Служба сначала вставляет данные T1
-
Служба отправляет асинхронное сообщение в шину сообщений (вы можете отправить его, не ждите, пока оно вернется, обычно оно завершается быстро)
-
Служба возвращает бизнес-сторону для успешного добавления данных
-
Шина сообщений доставляет сообщение в центр синхронизации данных
-
Вставка центра обработки данных для синхронизации данных T2
преимущество:
- Короткое время обработки запроса (всего 1 вставка)
недостаток:
-
Сложность системы увеличивается, вводится еще один компонент (шина сообщений) и еще один сервис (выделенный сервис репликации данных).
-
Поскольку при успешной вставке возвращенной строки бизнес-данных данные не обязательно вставляются в T2, поэтому данные имеют несогласованное временное окно (это окно очень короткое и в конечном итоге непротиворечивое).
-
Избыточные данные таблицы несовместимы, когда сообщения теряются на шине сообщений
Если вы хотите отделить систему от «избыточности данных», вводится третье часто используемое решение.
Метод 3: автономное асинхронное резервирование
Двойная запись данных больше не выполняется службой центра друзей, а выполняется автономной службой или задачей, как показано на рис. 1-6 выше:
-
Деловая сторона вызывает службу и добавляет данные
-
Служба сначала вставляет данные T1
-
Служба возвращает бизнес-сторону для успешного добавления данных
-
Данные будут записаны в журнал базы данных
-
Автономные службы или задачи читают журнал базы данных
-
Вставьте данные T2 в автономные службы или задачи
преимущество:
-
Двойная запись данных полностью отделена от бизнеса
-
Короткое время обработки запроса (всего 1 вставка)
недостаток:
-
Когда строка возврата бизнес-данных успешно вставлена, данные не обязательно вставляются в T2, поэтому данные имеют несогласованное временное окно (это окно очень короткое и в конечном итоге непротиворечивое).
-
Согласованность данных зависит от надежности автономных сервисов или задач.
Вышеуказанные три схемы имеют свои преимущества и недостатки, которые можно выбрать в соответствии с реальной ситуацией.
Хотя избыточность данных может решить проблему горизонтальной сегментации баз данных в отношениях «многие ко многим», она также создает новые проблемы.Как обеспечить согласованность данных между положительной таблицей T1 и отрицательной таблицей T2?
Из приведенного выше обсуждения видно, что независимо от того, какая схема, поскольку атомарность двухэтапной операции не может быть гарантирована, всегда существует возможность несогласованности данных.Распределенные транзакции с высокой пропускной способностью являются нерешенной проблемой в отрасли. направление оптимизации архитектуры на данный момент:возможная согласованность. Цель состоит не в том, чтобы полностью гарантировать согласованность данных в реальном времени, а в том, чтобы обнаруживать несоответствия как можно раньше и исправлять их.
Согласованность в конечном счете является обычной практикой для согласованности бизнеса в Интернете с высокой пропускной способностью. В частности, существуют три общие схемы, обеспечивающие конечную согласованность данных.
Способ 1: сканирование всех данных в передней и задней избыточных таблицах в автономном режиме
Как показано на рисунке выше, автономный инструмент сканирования запускается в автономном режиме, а положительная таблица T1 и отрицательная таблица T2 постоянно сравниваются.Если данные окажутся несогласованными, они будут компенсированы и исправлены.
преимущество:
-
Относительно простая, низкая стоимость разработки
-
Онлайн-сервисы не нужно модифицировать, а инструменты восстановления отделены от онлайн-сервисов.
недостаток:
-
Эффективность сканирования низкая, а большое количество данных уже гарантирует согласованность.
-
Из-за большого объема отсканированных данных время одного раунда сканирования относительно велико, то есть, если данные противоречивы, временное окно для несогласованности относительно велико.
Существует ли оптимизированный способ повышения эффективности путем сканирования только тех данных, которые «могут иметь несогласованность», вместо того, чтобы каждый раз сканировать все данные?
Способ 2: сканирование дополнительных данных в автономном режиме
Сканирование каждый раз только добавочных данных журнала может значительно повысить эффективность и сократить временной интервал для несогласованности данных, как показано в схеме на рис. 1-4 выше:
-
Напишите положительную таблицу T1
-
После успешного выполнения первого шага напишите лог log1
-
Напишите обратную таблицу T2
-
После успешного выполнения второго шага напишите лог log2
Конечно, нам по-прежнему нужен автономный инструмент сканирования, чтобы постоянно сравнивать журнал log 1 и журнал log 2. Если данные будут признаны несогласованными, они будут компенсированы и исправлены.
преимущество:
-
Хотя он сложнее, чем метод 1, он все же относительно прост.
-
Высокая эффективность сканирования данных, сканирование только добавочных данных
недостаток:
-
Онлайн-сервис немного изменен (стоимость не высока, а еще 2 журнала)
-
Хотя он более оперативный, чем метод 1, своевременность все же не высока, а окно несогласованности зависит от периода сканирования
Есть ли способ определить согласованность в режиме реального времени и исправить ее?
Метод 3: обнаружение «пары сообщений» в режиме реального времени
На этот раз вместо записи журналов сообщения отправляются в шину сообщений, как показано на рис. 1-4 выше:
-
Напишите положительную таблицу T1
-
После успешного выполнения первого шага отправьте сообщение msg1
-
Напишите обратную таблицу T2
-
После успешного выполнения второго шага отправьте сообщение msg2
На этот раз это не автономный инструмент, требующий периодического сканирования, а сервис, который подписывается на сообщения в режиме реального времени и продолжает получать сообщения.
Предполагая, что при нормальных обстоятельствах время получения msg1 и msg2 должно быть в пределах 3 с.Если служба обнаружения не получает msg2 после получения msg1, она попытается определить согласованность данных и компенсировать несогласованность.
преимущество:
-
эффективный
-
Высокий режим реального времени
недостаток:
-
Схема усложняется, и компонент шины сообщений вводится онлайн.
-
Есть оффлайн сервис обнаружения подписки на шину
Однако само техническое решение представляет собой компромисс соотношения затрат и результатов, и решение о том, какой метод использовать, может быть принято в зависимости от степени потребности бизнеса в согласованности.
Суммировать
-
Цепной бизнес отношений — это типичные отношения «многие ко многим», которые делятся на сильных друзей и слабых друзей.
-
избыточность данныхЭто обычная практика горизонтальной сегментации бизнес-данных «многие ко многим».
-
избыточные данныеСуществуют три распространенные схемы
(1) Резервирование сервисной синхронизации
(2) Сервисное асинхронное резервирование
(3) Автономное асинхронное резервирование
-
Избыточность данных вызовет проблемы согласованности.Для интернет-сервисов с высокой пропускной способностью трудно полностью обеспечить согласованность транзакций.Общая практика заключается в том,возможная согласованность
-
Общие практики для окончательной согласованностиДа, найти несоответствия как можно скорее и исправить данные Есть три распространенных решения
(1) Автономный метод полного сканирования
(2) Автономный метод инкрементного сканирования
(3) Онлайн-метод обнаружения в реальном времени
Надеюсь, у всех вас есть вдохновение,идеиважнее вывод.
Вы можете продолжать задавать вопросы и отвечать на любые вопросы.