Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

Об авторе: Чэнь Дунмин, руководитель архитектурной группы Пекинского технологического центра Ele.me, отвечает за проектирование архитектуры линейки продуктов Ele.me, а также исследования и разработки инфраструктуры Ele.me. Ранее работал архитектором в Baidu и отвечал за архитектурный дизайн продуктов для обмена мгновенными сообщениями Baidu. Он имеет обширный опыт в построении крупномасштабных систем, исследованиях и разработках инфраструктуры, а также хорошо разбирается в большом параллелизме, проектировании распределенных систем и непрерывной оптимизации в соответствии со сложными бизнес-требованиями. Личный публичный аккаунт WeChat dongming_cdm.

Tedis（https://github.com/eleme/tedis）основан на открытом исходном коде TiKV Совместим с Redis Строгая последовательность протокола NoSQL данныеПроект библиотеки с открытым исходным кодом. В этой статье представлены Tedis Архитектурный дизайн и характеристики проектов с открытым исходным кодом, а также некоторые размышления об архитектуре (в том числе, почему стоит выбрать TiKV и Redis протокол).

Давайте сначала обсудим, почему мы создали собственную базу данных NoSQL на основе TiKV.

Сначала давайте кратко опишем TiKV[1]. TiKV — это подпроект TiDB. TiDB — это распределенная реляционная база данных[2]. TiKV — это уровень хранения данных TiDB. Сам TiKV — это отдельный проект, который может быть независимым от TiDB. Это строго согласованная, горизонтально масштабируемая и высокодоступная распределенная система хранения «ключ-значение».

выбирать TiKV Первая причина TiKV Это строго последовательная система. В другой моей статье (опубликованной в InfoQ, Видеть https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv ), я подробно остановился на вопросе: NoSQL База данных должна быть согласованной и обеспечивать фактическую высокую доступность за счет технологии множественного копирования, то есть NoSQL База данных должна быть «де-факто CA” （effectively СА) система. Но в этой статье я прямо не заявил NoSQL должен был иметьизпоследовательностьда Какой видпоследовательность。На самом деле то, что я подразумеваю под последовательностью, на самом деле является своего рода сильной последовательностью. [3],Или точнее, далинейная консистенция [4]。TiKV Это линейная последовательность. ИКБ Все данные будут сохранены 3 реплики, кроме того, когда узел только с одной репликой выходит из строя или происходит раздел сети. 2 Каждая копия по-прежнему может предоставлять услуги внешнему миру. Теоретически говоря, возникающие одновременно 2 Вероятность одновременного повреждения более чем одной копии очень мала, а это означает, что теоретически может быть достигнута очень высокая доступность. проходить TiKV Помощь в эксплуатации и техническом обслуживании, такая как последовательная модернизация, если она используется в реальном производстве и при хорошей эксплуатации и техническом обслуживании, действительно может обеспечить очень высокую доступность. То есть это называется «действительным». CA”（effectively СА) система.

TiKV проходить Raft [5] Протокол обеспечивает линейную согласованность и высокую доступность. 2 характеристики. Плот да Протокол распределенного консенсуса, Raft протокол, данные можно считать атомарно записанными в 3 на копии. Одной из особенностей протокола консенсуса является то, что большинство операций записи должно быть выполнено, прежде чем запись будет считаться успешной 3. Большинство экземпляров 2 То есть, даже если только одна копия не работает или сеть разделена, ее все равно можно успешно записать и предоставить услуги чтения.

выбирать TiKV Вторая причина TiKV Архитектура масштабируема и Экосистема. существовать TiDB середина TiKV да независима от одного уровня, образуя очень масштабируемую архитектуру, которая действительно может существовать TiKV На нем было расширено множество различных баз данных. Ти БД Сам уровень является расширением этой архитектуры. Эта архитектура аналогична Google Первое поколение компании Spanner система [6],Spanner Система сама по себе также является строго согласованной и высокодоступной распределенной системой. Key-Value система。существовать Spanner На базе Google Построен F1 система [7], достигнуто SQL протокол. 2017 год год, Гугл Модернизированный Spanner ко второму поколению [8], пусть Spanner Уже есть SQL способность. Хотя поколение Spanner+F1 Это такая архитектура, но это все равно очень хорошая архитектура. наш Tedis Этот проект также является проектом, построенным на масштабируемой архитектуре существования, опирающейся на TiKV Обеспечивая возможности нижнего уровня, восходящий Построен отличается от SQL согласованный Redis протокол.Я считаю TiKV Эта масштабируемая архитектура в будущем может стать экосистемой, и поверх нее также могут быть «расширены» другие изданные библиотеки, такие как Mango Соглашение, графическое соглашение. Эти базы данных имеют в основе TiKV То же самое из-за линейной согласованности и высокой доступности, единственная разница — протокол внешнего интерфейса. в настоящий Эта экология момента начала обретать форму,Titan（https://github.com/distributedio/titan） Этот проект с открытым исходным кодом вместе с нашим Tedis Проекты очень похожи, их open source темпы опережают наши, в настоящий момент тоже очень хорош. Я Что касается, мы уверены, что нет этого экологического середина из последнего.

Если коротко, на базе TiKV Тедис реализует следующие технические возможности:

1. Большой объем данных, способный хранить не менее десятков терабайт данных.

2. Высокая производительность, существование соответствует высоким QPS В то же время это обеспечивает относительно низкую задержку.

3. Высокая надежность, данные надежно и постоянно хранятся, а повреждение небольшого количества машин не приведет к потере данных.

4. Высокая доступность,Как линейный сервис существует в базовом хранилище зависимостей,Должны иметь очень полные возможности высокой доступности.,Сервисы доставки еды отличаются от электронной коммерции,Очень высокие требования к производительности в реальном времени,Требования к доступности систем выше из-за.

5. Простота эксплуатации и обслуживания: вы можете мигрировать и расширять кластер без остановки службы.

Следующий,Давайте обсудим второй вопрос,Почемувыбирать Redis протокол.

SQL Язык и стоящая за ним модель отношений, начиная с 1970s С момента своего изобретения область разработки приложений всегда занимала это доминирующее положение, хотя и существуют CAP Руководствуясь теоремой [4],существовать NoSQL Движение середина, появляется много NoSQL системы, как я объяснял ранее, последовательность не должна быть NoSQL причина появиться, уходи SQL Реляционная модель NoSQL Мотивация появиться. но я не думаю NoSQL заменит SQL. Хотя NoSQL Когда оно появляется, первоначальное значение таково: “NO SQL（Нет SQL）”,Но я думаю, что больше подходит другое объяснение NoSQL.,То естьда“Not Only SQL（Не только SQL）”。NoSQL нет SQL Замена должна быть SQL из Мощная добавка。существовать NoSQL Движение середина, выйти из очень хорошего состояния NoSQL Большинство систем имеют свои собственные уникальные протоколы интерфейса, такие как Redis, MongoDB, Cassandra, графовые базы данных и многое другое. Все они имеют свои собственные очень применимые сценарии использования, такие как MongoDB Близкая к объектно-ориентированной, графовая база данных подходит для графовых реляционных операций с узлами. и Redis Я придерживаюсь взглядов разработчиков на структуру данных. Я считаю, что каждый разработчик начинает с массива, хэша. Структуры таблиц и очередей растут таким образом.

Кроме того, Редис Это отличный продукт сам по себе, и его популярность очень высока, особенно в интернет-индустрии. существуют Каждая интернет-компания, Redis Они стали одним из важнейших инструментов в арсенале инженера-разработчика. Редис Уже разработчик SQL Кроме того, это второй по популярности продукт.

Да,выбирать Redis Протокол также принес мне некоторые практические проблемы. Некоторые из наших пользователей изначально столкнулись с ним. Tedis Иногда, всегда нас возьми и Redis по сравнению с. Однако, хотя мы используем Redis интерфейс, но Tedis Не сравнивая себя Redis этот продукт. Редис Это очень хороший кэш. Хотя Redis Вы также можете включить функцию персистентности, потому что Redis Собственный архитектурный дизайн обеспечивает постоянство Redis Все еще не могу достичь «действительного CA”（effectively CA）,и 100% Долговечность. Это Redis и Tedis Большая разница, Тедис да библиотека данных, нет кеша.

Обсудив два вышеупомянутых архитектурных соображения, давайте взглянем на архитектурный дизайн Тедиса.

существовать Tedis середина, мы инкапсулировали TiKV из SDK, да Redis из протокола анализируется и Redis Соглашение конвертируется в пару TiKV из вызова.

На данный момент Тедису еще многое предстоит улучшить.,Но мы улучшим следующие вопросы как можно скорее,существует из календаря с открытым исходным кодом середина:

1. Завершение команды Redis

2. Сжатие, ограничение тока и другие расширенные функции.

3. Cassandra согласованный支持

写существоватьнаконец

В качестве системы хранения,Пользователи не должны перегружаться техническими характеристиками, такими как согласованность и удобство использования.,Пользователям следует больше задуматься о том, какой интерфейс больше подходит для сценариев их приложений.,Каким интерфейсом вы более опытны в использовании?,Какой интерфейс можно использовать для более быстрой разработки функций?

Из-за ограниченности места,В этой статье содержится множество технических подробностей о строгой согласованности, линейной согласованности, Redis, Raft и Spanner, которые невозможно подробно описать.,Планируется обсудить это в отдельном документе.

Ссылки:

1. https://github.com/pingcap/tikv
2. https://github.com/pingcap/TiDB
3. Eventually Consistent – Revisited,Werner Vogels, 2008, http://www.allthingsdistributed.com/2008/12/event ually_consistent .html
4. Linearizability: A Correctness Condition for Concurrent Objects,Maurice P. Herlihy and Jeannette M. Wing,1990
5. In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout, 2014
6. Spanner: Google’s Globally-Distributed Database, James C. Corbett, Jeffrey Dean et al., 2012
7. F1: A Distributed SQL Database That Scales, Jeff Shute et al., 2013 8.Spanner: Becoming a SQL System, David F. Bacon et al., 2017

Заявление об авторских правах: Содержание этой статьи добровольно предоставлено пользователями Интернета, а мнения, выраженные в этой статье, представляют собой только точку зрения автора. Этот сайт предоставляет только услуги по хранению информации, не имеет никаких прав собственности и не принимает на себя соответствующие юридические обязательства. Если на этом сайте обнаружено какое-либо предполагаемое нарушение авторских прав/незаконный контент, Пожалуйста, отправьте электронное письмо на Сообщите, после проверки этот сайт будет немедленно удален.

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/192807.html Исходная ссылка: https://javaforall.cn