Ваши требования не очень понятны. Мой лучший ответ - пройтись по вашему вопросу и постараться указать вам правильное направление по точкам.
- «Записи не нуждаются ни в каких проверках» и «Моему приложению не нужен ответ, но оно должно быть на 100% безопасным, чтобы оно поступало на сервер правильно».
Как именно вы планируете, чтобы клиент знал, что данные были получены без отправки ответа? Вы всегда должны планировать записывать обработку исключений в свое приложение и иметь дело с ситуацией, когда соединение клиента или данные, которые он отправляет, по какой-то причине прерывается. Эти два заявления, которые вы сделали, похоже, противоречат друг другу; вам не нужен ответ, но вы должны знать, что данные поступают? Будет ли ваше приложение использовать хрустальный шар для подтверждения получения данных (если это так, пожалуйста, пришлите мне такой хрустальный шар - я бы хотел использовать его для короткого замыкания на фондовом рынке).
- «Выполнить код отправки данных в отдельном потоке», «сохранить данные в памяти и отправить позже», «сохранить данные локально и получить их на сервере», и «отправка данных не может быть выполнена» мое приложение ждет ".
Хорошо, похоже, вы хотите неблокирующий ввод / вывод. Но реальность такова, что даже при неблокирующем вводе / выводе все еще требуется некоторое количество времени для фактической отправки данных. Мой вопрос: почему вы запрашиваете неблокирующие и / или быстрые операции ввода-вывода? Если бы передача данных была просто чрезвычайно быстрой, имело бы значение, если бы она не была неблокируемой? Это дизайнерское решение с вашей стороны, но из вашего вопроса не понятно зачем вам это нужно, так что я просто выкидываю его туда.
Если поместить данные в память и отправить их позже, это не является неблокируемой или многозадачной; это просто откладывает работу до некоторого будущего времени. Я считаю, что программное обеспечение проволочек. Этот метод не уменьшает количество времени или работы, которые ваше приложение должно выполнить для обработки этих данных, он просто переносит их на какую-то будущую дату. Это ничего не даст вам, если не будет никакой пользы для «пакетной» отправки данных большими кусками.
Идея в памяти также звучит как временный буфер. Во многих реализациях потока ввода / вывода будет встроен буфер, а также буфер на вашей сетевой карте, а также буфер на вашем маршрутизаторе и т. Д., И т. Д. Добавление другого буфера в ваш код не кажется, имеет какой-то смысл на поверхности, если вы не можете объяснить, почему вы думаете, что это поможет. То есть какую актуальную, опытную проблему вы пытаетесь решить, вводя буфер? Кроме того, в зависимости от того, как вы отправляете эти данные (т. Е. Какие классы сетевого ввода-вывода вы выбираете), вы можете получить неблокирующий ввод-вывод как часть реализации класса.
Далее, что касается отправки данных в отдельном потоке, это хорошо, если вам нужен неблокирующий ввод / вывод, но (1) вам необходимо обосновать, почему это хорошая идея с точки зрения дизайна вашего программного обеспечения, прежде чем вы идти по этому пути, потому что это добавляет усложнение вашему приложению, поэтому, если оно не решит конкретную, реальную проблему (т.е. в вашем приложении есть пользовательский интерфейс, который не должен зависать / не отвечать из-за ожидающих операций ввода-вывода), то это только добавили усложнение, и вы не получите от этого никакой дополнительной производительности. (2) Существует распространенное искушение использовать потоки, чтобы, опять же, в основном откладывать работу. Перенос работы на другой поток не уменьшает общий объем работы, которую необходимо выполнить, или общий объем операций ввода-вывода, которые ваше приложение будет использовать для выполнения своей функции - он просто откладывает его на другой поток. Бывают случаи, когда это очень полезно, и, возможно, это правильное решение для вашего приложения, но из вашего описания я вижу много запрошенных функций, но не обоснование (или объяснение проблемы, которую вы пытаетесь решить), это резервное копирование это выбор функций / дизайна, который в конечном итоге должен определять направление, в котором вы идете.
Наконец, если сервер «вытягивает» его, а не отправляет на сервер, то все, что вы здесь делаете, это переключение ролей и заставление сервера действовать как клиент, а клиент - как клиент. сервер. Поймите, что «клиент» и «сервер» являются относительными терминами, а сервер - это то, что предоставляет услугу. Простое переключение ролей на самом деле ничего не меняет - просто переключает роли клиент / сервер с одной части программного обеспечения на другую. Сами метки - это просто метки - удобный способ узнать, какая часть предоставляет услугу, а какая часть потребляет услугу (клиент).
- "У меня есть приложение, которое будет генерировать 5-10 новых записей базы данных на одном хосте каждую секунду."
Это не должно быть проблемой. Любой приличный сервер БД будет воспринимать такую работу как крайне низкую нагрузку. С точки зрения скорости и скорости отклика от сервера больше будут зависеть такие вещи, как задержка в сети (если вы передаете эти данные по сети) и другие факторы, связанные с выбором ввода / вывода, которые будут влиять на то, можете ли вы писать 5- 10 записей в секунду, то есть ваша общая пропускная способность.