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