Привет всем, я брат Лэй.

Чтобы как можно быстрее импортировать 1 миллиард фрагментов данных в базу данных, сначала необходимо уточнить у интервьюера, в каком виде и где находятся 1 миллиард фрагментов данных, насколько велик каждый фрагмент данных, в каком порядке он импортируется образом, и нельзя ли это повторить. Является ли база данных MySQL?

После того, как предположения разъясняются интервьюеру, возникают следующие ограничения:

1、 1 миллиард фрагментов данных, каждый фрагмент данных имеет размер 1 КБ; 2、 Содержимое данных представляет собой неструктурированные журналы доступа пользователей, которые необходимо проанализировать и записать в базу данных; 3、 данныехранится вHdfsилиS3Распределенное хранилище файлов； 4、 Один миллиард фрагментов данных — это не один большой файл, а примерно разделенный на 100 файлов с суффиксом, обозначающим порядок; 5、 Требуется вносить упорядоченно и стараться не повторяться; 6、 база данныхдаMySQL；

Сначала подумайте, возможно ли записать 1 миллиард данных в одну таблицу MySQL?

Может ли одна таблица базы данных поддерживать 1 миллиард?

Ответ — нет. Рекомендуемое значение для одного счетчика составляет менее 2000 Вт. Как рассчитывается это значение?

Структура данных индекса MySQL представляет собой дерево B+, и все данные хранятся в индексе первичного ключа, который является конечным узлом кластеризованного индекса. Производительность вставки и запроса дерева B+ напрямую связана с количеством уровней дерева B+. Ниже 2000W это трехуровневый индекс, а выше 2000w — четырехуровневый индекс.

Mysql b+Размер конечного узла индекса на страницу16K。Каждый текущий элементданные В самый раз1K,Таким образом, просто понятно, что каждый листовой узел хранит 16 данных. Размер каждого нелистового узла в индексе b+ также равен 16 КБ.,Но ему нужно хранить только первичный ключ и указатели на конечные узлы.,我们假设主键изтипда BigInt, длина равна 8 байтах, а размер указателя находится в InnoDB Установить на 6 Байты, поэтому всего 14 байт, чтобы неконечный узел мог хранить 16 * 1024/14=1170。

То есть каждый нелистовой узел может быть связан с 1170 листовыми узлами, и каждый листовой узел хранит 16 фрагментов данных. Отсюда мы можем получить таблицу количества уровней индекса дерева B+ и объема хранилища. При мощности выше 2 к Вт количество индексных слоев равно 4, а производительность еще хуже.

Чтобы облегчить расчет, мы можем спроектировать одну таблицу мощностью 1 к Вт и в общей сложности 100 таблиц с 1 миллиардом фрагментов данных.

Как эффективно писать в базу данных

Производительность записи одной записи в базу данных относительно низкая. Можно рассмотреть возможность записи в базу данных в пакетном режиме. Значение пакета можно регулировать динамически. Размер каждого элемента составляет 1 КБ, и по умолчанию его можно настроить на пакетную запись по 100 элементов.

Как обеспечить одновременную успешную запись пакетных данных? Механизм хранения MySQL Innodb гарантирует, что транзакции пакетной записи будут успешными или неудачными одновременно.

Примечание: если вы готовитесь к собеседованию, чтобы сменить работу в ближайшем будущем, рекомендуется ответить на вопросы онлайн на ddkk.com, охватывающие более 10 000 вопросов собеседования по Java, охватывающие почти все основные вопросы технического собеседования и наиболее полные 500. технические наборы, представленные на рынке. Серия учебных пособий, доступных бесплатно.

При записи в базу данных должна поддерживаться повторная попытка. Если запись в базу данных не удалась, повторите запись. Если после N повторных попыток запись по-прежнему не удалась, рассмотрите возможность записи 100 записей в базу данных, а затем данные, которые не удалось записать, будут распечатаны и записаны. отброшено.

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

Вам нужно одновременно писать в одну и ту же таблицу?

не могу

1、 Одновременная запись в одну и ту же таблицу не может гарантировать, что данные записываются по порядку; 2、 Повышение порога для пакетных вставок в определенной степени увеличивает параллелизм вставок, устраняя необходимость одновременной записи в одну таблицу;

Выбор механизма хранения данных MySQL

MyisamСравниватьinnodbЕсть вкладыши получшепроизводительность,но потерял поддержку транзакций,Нет никакой гарантии успеха или неудачи одновременно при пакетной вставке.,Поэтому, когда время пакетной вставки истекает или происходит сбой,если повторить попытку,Это обязательно приведет к возникновению каких-то повторов. Но чтобы обеспечить более высокую скорость импорта,В качестве одного из планов можно упомянуть механизм хранения данных myisam.

На этом этапе приведу чужие результаты тестов производительности: Сравнительный анализ MyISAM и InnoDB.

картина

Из данных видно, что пакетная запись значительно лучше, чем одиночная. А после того, как innodb отключает политику мгновенного обновления диска, производительность вставки innodb не намного хуже, чем у myisam.

innodb_flush_log_at_trx_commit: Управляет стратегией, используемой MySQL для записи данных на диск.

1、 По умолчанию=1, то есть данные будут обновляться на диске каждый раз при отправке транзакции с максимальной безопасностью и без потери данных; 2、Если настроено как 0、2 будет обновлять данные на диске каждые 1 секунду, и система выйдет из строя.、mysqlcrashможет быть потерян1sизданные；

Учитывая, что Innodb отключает политику мгновенного обновления диска.,партияпроизводительность Неплохо,Поэтому я буду использовать его в первую очередьinnodb（Если компанияMySQLКластер не позволяет изменить это значение политики.,Возможно, вы захотите использовать MyIsam. ). При тестировании онлайн-среды вы можете сосредоточиться на сравнении их вставки.

Вы хотите разветвить базу данных?

Параллельная запись одной базы данных mysql имеет узкое место в производительности. Как правило, запись 5 КБ TPS очень высока.

В настоящее время все данные хранятся на SSD, и производительность должна быть лучше. Но если это HDD, то хотя последовательное чтение и запись будет иметь очень высокую производительность, HDD не справится с одновременной записью. Например, если в каждой библиотеке 10 таблиц, предполагая, что 10 таблиц записываются одновременно, хотя каждая таблица. записывается последовательно, из-за разных мест хранения нескольких таблиц жесткий диск имеет только одну магнитную головку и не поддерживает одновременную запись. Он может выполнять только повторный поиск, что значительно увеличивает затраты времени и теряет высокую производительность последовательного чтения и записи. . Поэтому для жесткого диска одновременная запись нескольких таблиц в одной базе данных не является хорошим решением. Возвращаясь к сценарию SSD, разные производители SSD имеют разные возможности записи и разные возможности одновременной записи. Некоторые поддерживают скорость 500 Мбит/с, некоторые поддерживают чтение и запись со скоростью 1 Гбит/с, некоторые поддерживают 8 одновременных записей, а некоторые поддерживают 4 одновременно. До онлайн-эксперимента мы не знали фактической производительности.

Примечание: если вы готовитесь к собеседованию, чтобы сменить работу в ближайшем будущем, рекомендуется ответить на вопросы онлайн на ddkk.com, охватывающие более 10 000 вопросов собеседования по Java, охватывающие почти все основные вопросы технического собеседования и наиболее полные 500. технические наборы, представленные на рынке. Серия учебных пособий, доступных бесплатно.

Поэтому конструкция должна быть более гибкой и поддерживать следующие возможности:

1、 Поддержка количества баз данных конфигурации; 2、 Поддерживает настройку количества одновременно записываемых таблиц (если MySQL представляет собой HDD-диск, последовательно записывается только одна таблица, а остальные задачи ждут);

Благодаря вышеуказанной конфигурации наша система может гибко настраивать количество онлайн-баз данных и одновременность записи таблиц, будь то HDD или SSD. Независимо от модели производителя твердотельного накопителя или его производительности, конфигурацию можно настроить для постоянного достижения более высокой производительности. Это также идея, лежащая в основе конструкции. Фиксированного порогового значения не существует, но оно должно динамически регулироваться.

Далее поговорим о чтении файлов. Есть 1 миллиард фрагментов данных, каждый фрагмент — 1 КБ, а общий объем — 931 ГБ. Большой файл размером почти 1Т обычно не создается. Итак, наш файл по умолчанию разделен примерно на 100 файлов. Количество каждого файла должно быть примерно одинаковым. Почему его разрезали на 100 частей? Нельзя ли было быстрее импортировать базу данных, разделив ее на 1000 частей и увеличив параллельное чтение? Как уже упоминалось, производительность чтения и записи базы данных ограничена диском, но на любом диске операции чтения выполняются быстрее, чем операции записи. Тем более при чтении вам нужно только читать из файла, а вот при записи MySQL должен выполнять сложные процессы, такие как индексация, парсинг SQL, транзакции и т.д. Следовательно, максимальный параллелизм для записи равен 100, а параллелизм для чтения файлов не должен превышать 100.

Что еще более важно, одновременность чтения файлов равна количеству подтаблиц, что полезно для упрощения разработки модели. То есть 100 задач на чтение и 100 задач на письмо соответствуют 100 таблицам.

Как обеспечить правильность записи в базу данных

Поскольку файл разделен на 100 небольших файлов по 10 ГБ, суффикс файла + номер строки файла можно использовать в качестве уникального ключа записи, гарантируя при этом запись содержимого одного и того же файла в одну и ту же таблицу. Например

1、 index_90.txt записывается в базу данных data_9, table_0,; 2、 index_67.txt записывается в базу данных data_6, table_7;

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

Как читать файлы быстрее

Файл 10G, очевидно, считывается в память за один раз. Чтение файла сцены включает в себя.

1、 Files.readAllBytesОдноразовая загрузка внутренней памяти； 2、 FileReader+BufferedReader читает построчно; 3、 File+BufferedReader； 4、 Сканер читает построчно; 5、 Чтение режима буфера JavaNIOFileChannel;

На MAC сравнение производительности чтения файлов 3.4G этими методами

Память заполнена ООМ

Подробную информацию об оценке можно найти по адресу: Сравнение производительности чтения файлов: https://zhuanlan.zhihu.com/p/142029812.

Видно, что использоватьJavaNIO FileChannnelзначительно лучше,但даFileChannelиз方式да先读取固定大小缓冲区,Построчное чтение не поддерживается. Также нет гарантии, что буфер содержит именно данные целочисленных строк. Если последний байт буфера застрял в середине строки данных,Для чтения следующего пакета данных требуется дополнительное сотрудничество. Как изменить буфер на одну строку данных,Сложнее.

File file = new File("/xxx.zip");
FileInputStream fileInputStream = null;
long now = System.currentTimeMillis();
try {
       fileInputStream = new FileInputStream(file);
       FileChannel fileChannel = fileInputStream.getChannel();

       int capacity = 1 * 1024 * 1024;//1M
       ByteBuffer byteBuffer = ByteBuffer.allocate(capacity);
       StringBuffer buffer = new StringBuffer();
       int size = 0;
       while (fileChannel.read(byteBuffer) != -1) {
          //После чтения устанавливаем позицию на 0 и ограничиваем емкость. Чтобы подготовиться к чтению в байтовый буфер в следующий раз, начните сохранение с 0.
          byteBuffer.clear();
          byte[] bytes = byteBuffer.array();
          size += bytes.length;
       }
       System.out.println("file size:" + size);
} catch (FileNotFoundException e) {
   e.printStackTrace();
} catch (IOException e) {
   e.printStackTrace();
} finally {
   //TODO закрыть ресурс.
}
System.out.println("Time:" + (System.currentTimeMillis() - now));

JavaNIOда基于缓冲区из,ByteBufferМожно преобразовать вbyteмножество,Необходимо преобразовать в строку,И обрабатывать усечение строки.

但даЧтение в режиме JavaIO BufferedReader, естественно, может поддерживать усечение строк, и производительность неплохая.,файл 10G,Чтение займет всего около 30 секунд,Поскольку общее узкое место импорта находится в письменной части,Даже если чтение займет 30 секунд.,На общую производительность это не повлияет. Итак, для чтения файлов используется BufferedReader. Читайте быстрее Это вариант 3.

Если вы координируете задачи чтения файлов и записи задач базы данных

Этот раздел сбивает с толку, поэтому, пожалуйста, прочитайте его терпеливо.

Возможно ли иметь 100 задач чтения, каждая из которых считывает пакет данных и немедленно записывает его в базу данных? Как упоминалось ранее, из-за узкого места одновременной записи в базу данных невозможно для одной базы данных одновременно записывать 10 таблиц большими пакетами. Поэтому одновременная запись 100 задач в базу данных неизбежно приведет к . 10 таблиц в каждой базе данных записываются последовательно одновременно. Это увеличивает нагрузку на одновременную запись на диск. Чтобы максимально увеличить скорость и уменьшить снижение производительности, вызванное одновременной записью на диск, некоторые задачи записи необходимо приостановить. Так нужно ли задачам чтения ограничивать параллелизм? ненужный.

Если предположить, что задачи записи и задачи чтения объединены, это повлияет на параллелизм задач чтения. Первоначальный план состоит в том, чтобы решать задачи чтения и записи отдельно, чтобы никто не задерживал работу другого. Однако во время фактического проектирования это решение оказалось более сложным.

Примечание: если вы готовитесь к собеседованию, чтобы сменить работу в ближайшем будущем, рекомендуется ответить на вопросы онлайн на ddkk.com, охватывающие более 10 000 вопросов собеседования по Java, охватывающие почти все основные вопросы технического собеседования и наиболее полные 500. технические наборы, представленные на рынке. Серия учебных пособий, доступных бесплатно.

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

Сколько осколков нужно подготовить? 100 явно слишком много, если раздел меньше 100, например 10. Тогда должны быть сообщения от нескольких задач, смешанных вместе. Если несколько таблиц одной и той же базы данных находятся в разделе Kafka, и эта база данных поддерживает только пакетную запись одной таблицы, она не поддерживает одновременную запись нескольких таблиц. Сообщения из нескольких таблиц в этой библиотеке смешиваются в одном сегменте. Из-за ограничений параллелизма сообщения, соответствующие таблицам, не поддерживающим запись, могут быть только отброшены. Таким образом, это решение является одновременно сложным и трудным для реализации.

Поэтому от решения Kafka окончательно отказались, а от решения разделения задач чтения и записи временно отказались.

Окончательное решение упрощается до задачи чтения пакета данных и записи пакета. То есть задача отвечает и за чтение файлов, и за вставку в базу данных.

Как обеспечить надежность задачи

Если задача чтения уже выполнена наполовину, как бороться с простоем или выпуском службы? Или, если произошел сбой базы данных, запись по-прежнему не выполняется, и задача временно прекращается. Как гарантировать, что при повторном запуске задачи обработка продолжится в точке останова без повторной записи?

Мы только что упомянули, что можем установить идентификатор первичного ключа для каждой записи, то есть индекс суффикса файла + номер строки файла. Идемпотентность записи может быть гарантирована с помощью идентификатора первичного ключа.

Максимальное значение номера строки, в которой находится файл, составляет примерно 10G/1k = 10M, что равно 10000000. Соедините самый большой суффикс 99. Самый большой идентификатор — 990000000.

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

Если другой задаче также необходимо импортировать базу А как насчет данных? Как реализовать изоляцию идентификатора первичного ключа,Итак, первичный ключID还да需要拼接taskId。Например{taskId}{fileIndex}{fileRowNumber}преобразован вLongтип。еслиtaskIdБольше,Значение после сращивания слишком велико,При преобразовании в тип Long могут возникнуть ошибки.

Самое главное это,Если в некоторых задачах пишет 1к Вт,Некоторые другие задачи пишут 100 Вт.,Невозможно узнать длину каждого заполнителя, используя тип Long.,存在冲突из可能性。而если拼接字符串{taskId}_{fileIndex}_{fileRowNumber} , добавление уникального индекса приведет к ухудшению производительности вставки и не сможет удовлетворить потребность в максимально быстром импорте данных. Поэтому нам нужно подумать о другом плане.

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

INCRBY KEY_NAME INCR_AMOUNT

Укажите, что текущий прогресс увеличен на 100, например incrby task_offset_{taskId} 100. Если пакетная вставка не удалась, повторите попытку. Если произойдет несколько сбоев, будет выполнена одна вставка и одно обновление Redis. Чтобы убедиться, что обновление Redis прошло успешно, вы можете Также добавьте повторы.

Если вы не уверены в согласованности хода выполнения Redis и обновлений базы данных, вы можете рассмотреть возможность использования binlog базы данных и Redis +1 для каждой новой записи.

Если задача прерывается, сначала запрашивается смещение задачи. Затем прочитайте файл с указанным смещением и продолжите обработку.

Как согласовать параллельность задач чтения

Как упоминалось ранее, чтобы избежать чрезмерного параллелизма одной таблицы вставки базы данных, влияющего на производительность базы данных. Рассмотрите возможность ограничения параллелизма. Как это сделать?

Поскольку задачи чтения и задачи письма объединены воедино. Тогда вам нужно одновременно ограничить задачи по чтению. То есть каждый раз для выполнения выбирается только пакет задач чтения и записи.

Прежде чем сделать это, необходимо спроектировать модель хранения таблицы задач.

картина

1、 Для поддержки других линеек продуктов в будущем поле bizId по умолчанию имеет значение 1, которое представляет текущую бизнес-линию; 2、 datbaseIndex представляет назначенный суффикс базы данных; 3、 tableIndex представляет назначенный суффикс имени таблицы; 4、 parentTaskId,即总из任务id； 5、 смещение можно использовать для записи хода выполнения текущей задачи; 6、 1 миллиард фрагментов данных импортируется в базу данных и разделяется на 100 задач. Будет добавлено 100 идентификаторов задач для обработки части данных соответственно, что представляет собой файл 10G; 7、 Статус статуса используется для того, чтобы определить, выполняется ли текущая задача и завершено ли выполнение;

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

Как контролировать параллелизм? Вы можете использовать семафор перераспределения. ключ — идентификатор базы данных,

RedissonClient redissonClient = Redisson.create(config);
  RSemaphore rSemaphore = redissonClient.getSemaphore("semaphore");
    // Установите 1 одновременно градус
  rSemaphore.trySetPermits(1);
  rSemaphore.tryAcquire();//Применить для блокировки, неблокировки.

Миссия отвечает за регулярную ротацию тренировок, и после получения места миссия начинается. Установите статус задачи «Обработка» и отпускайте семафор после завершения или сбоя задачи.

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

Но есть проблема с использованием семафоров для ограничения тока, если задача забывает освободить семафор, или процесс выходит из строя и не может освободить семафор, как с этим бороться? Рассмотрите возможность добавления таймаута к семафору. Итак, если выполнение задачи слишком длительное, что приводит к преждевременному освобождению семафора, а другой клиент конкурирует за семафор, в результате чего два клиента пишут задачу одновременно, как с этим бороться?

Что, очевидно, импорт 1 миллиарда данных в базу данных, как это превратилось в подобную проблему таймаута распределенной блокировки?

на самом делеRedissonиз信号量并没有很好из办法解决信号量超时问题,Нормальное мышление: если выполнение задачи занимает слишком много времени,Вызывает освобождение семафора,Чтобы решить эту проблему, нам нужно всего лишь продлить контракт.,Задача в процессе,Пока не обнаружено, что срок действия экспресс-семафора истек.,Просто продлите контракт на некоторое время.,Всегда следите за тем, чтобы семафор не истекал。但да Redission не дает возможности обновить семафор, что делать?

Примечание: если вы готовитесь к собеседованию, чтобы сменить работу в ближайшем будущем, рекомендуется ответить на вопросы онлайн на ddkk.com, охватывающие более 10 000 вопросов собеседования по Java, охватывающие почти все основные вопросы технического собеседования и наиболее полные 500. технические наборы, представленные на рынке. Серия учебных пособий, доступных бесплатно.

Давайте подумаем об этом по-другому. Мы пытались позволить нескольким узлам конкурировать за семафор, тем самым ограничивая параллелизм. Вы можете попробовать выбрать главный узел и вращать список задач через главный узел. Есть три ситуации:

Случай 1. Число текущих выполнений меньше степени параллелизма.

1、 Затем выберите задачу для выполнения с наименьшим идентификатором, установите статус «в работе» и уведомите сообщение о выпуске; 2、 Процесс, который принимает сообщение, применяет распределенную блокировку, начинает обработку задачи и снимает блокировку после завершения задачи. Он использует обновление распределенной блокировки Redission, чтобы гарантировать, что время блокировки не истечет до завершения задачи.

Случай 2. Число выполняемых в данный момент операций равно степени параллелизма.

1、 Главный узел пытается узнать, заблокирована ли текущая задача; 2、 Если блокировки нет, это означает, что задачу не удалось выполнить, и задачу следует повторно освободить. Если блокировка есть, это означает, что задача выполняется;

Случай 3. Число выполняемых в данный момент операций превышает степень параллелизма.

1、 Сообщайте о нештатных ситуациях, вызывайте полицию и вмешивайтесь вручную;

Использование обучающей задачи ротации главного узла может снизить конкуренцию между задачами, публиковать сообщения через Kafka, а процесс, который получает сообщение, обрабатывает задачу. Чтобы гарантировать, что в потреблении участвует больше узлов, вы можете рассмотреть возможность увеличения количества шардов Kafka. Хотя каждый узел может обрабатывать несколько задач одновременно, это не повлияет на производительность, поскольку узким местом производительности является база данных.

那么主节点应该如何Выбирать Шерстяная ткань？может пройтиZookeeper+curator Выберите основной узел. Надежность относительно высокая.

Существует множество факторов, влияющих на время, необходимое для вставки 1 миллиарда фрагментов данных в базу данных. Включая тип диска базы данных и производительность. Если количество подбаз данных можно разделить на 1000 баз данных, производительность, конечно, будет выше. Количество подбаз данных и подтаблиц должно определяться на основе фактической онлайн-ситуации, которая во многом определяет скорость записи. Наконец, пороговое значение пакетной вставки базы данных не является статичным и требует постоянного тестирования и корректировки для достижения наилучшей производительности. Вы можете постоянно пробовать оптимальный порог для пакетной вставки: 100, 1000, 10000 и т. д.

Наконец, вот несколько важных моментов:

Подвести итог

1、 Вы должны сначала подтвердить ограничения, прежде чем сможете разработать план, чтобы определить основное направление, которое хочет задать интервьюер. Например, как разрезать файл 1T на небольшие файлы, сложно, но это может быть не тот вопрос, который хочет задать интервьюер. расследовать; 2、 С точки зрения масштаба данных необходимо создать подбазу данных и подтаблицу и примерно определить масштаб подтаблицы; 3、 На основе анализа проблем с написанием одной базы данных делается вывод, что необходимы отдельные базы данных; 4、 Учитывая, что диски имеют различную поддержку одновременной записи, параллельную запись в несколько таблиц в одной библиотеке необходимо ограничивать и динамически настраивать, чтобы облегчить отладку в онлайн-среде и найти оптимальное значение; 5、 MySQLinnodb、myisamмеханизм хранения пишетпроизводительность Поддержка различных,也要在线上对Сравнивать验证； 6、 Оптимальный порог для пакетной вставки базы данных необходимо определить путем повторного тестирования; 7、 Из-за ограничений параллелизма сложно разделить задачи чтения и записи на основе Kafka, поэтому задачи чтения и записи объединяются; 8、 После сбоя задачи, требующей от Redis записи хода выполнения, ход выполнения записывается при повторном импорте, чтобы избежать проблем с дублированием данных; 9、 分布式任务из协调工作да难点,использоватьRedissionСемафор не может решить проблему продления тайм-аута, и главный узел может назначать ему задачи.+分布式锁保证任务排他写入主节点использоватьZookeeper+CuratorВыбирать；