Какая архитектура подходит?

Question

Я протестировал программу соединения сокетов с идеей, что соединение сокетов само по себе будет одним отдельным потоком, а затем оно будет поставлено в очередь, а другой отдельный поток для dbprocessor будет выбирать из очереди и выполнять несколько операторов sql. Так что я замечаю здесь, где горлышко бутылки, которое обрабатывает дБ. Я хотел бы получить некоторое представление о том, что я делаю правильную архитектуру, или я должен изменить или улучшить мой процесс проектирования?

Требуется захватить данные через сокетные соединения и запустить через процесс db, а затем сохранить их соответствующим образом.

public class cServer
{
 private LinkedBlockingQueue<String> databaseQueue = new LinkedBlockingQueue<String>();

   class ConnectionHandler implements Runnable {
        ConnectionHandler(Socket receivedSocketConn1) {
          this.receivedSocketConn1=receivedSocketConn1;
        }


       // gets data from an inbound connection and queues it for databse update

       public void run(){
         databaseQueue.add(message); // put to db queue
       }
    }
    class DatabaseProcessor implements Runnable {
    public void run(){
             // open database connection
             createConnection();
             while (true){
               message = databaseQueue.take(); // keep taking message from the queue add by connectionhandler and here I will have a number of queries to run in terms of select,insert and updates.
             }
    }

    void createConnection(){
        System.out.println("Crerate Connection");
        connCreated = new Date();
        try{
        dbconn = DriverManager.getConnection("jdbc:mysql://localhost:3306/test1?"+"user=user1&password=*******");
        dbconn.setAutoCommit(false);
        }
        catch(Throwable ex){
           ex.printStackTrace(System.out);
        }
     }
    }

    public void main()
    {
    new Thread(new DatabaseProcessor()).start(); //calls the DatabaseProcessor
    try 
    {
      final ServerSocket serverSocketConn = new ServerSocket(8000);             
      while (true){
        try{
            Socket socketConn1 = serverSocketConn.accept();
            new Thread(new ConnectionHandler(socketConn1)).start();                     
       }
       catch(Exception e){
         e.printStackTrace(System.out);
       }
      }
    } 
    catch (Exception e){
      e.printStackTrace(System.out);
    }

    }

}

Answer 1

Трудно (читай «Невозможно») судить об архитектуре без требований.Поэтому я просто сделаю некоторые выводы:

Максимальная пропускная способность: не используйте базу данных, пишите в плоский файл, возможно, хранящийся на чем-то быстром, например, на твердотельном диске.пользователь получает ответ, не состоящий из ошибки, данные должны храниться надежно): сделайте все это однопоточным, сохраните все в базе данных с избыточными дисками.Убедитесь, что у вас есть компетентный администратор базы данных, который знает о резервном копировании и восстановлении.Проверяйте их через регулярные промежутки времени.

Минимальное время для завершения пользовательского запроса: Ваш подход кажется разумным.

Минимальное время для завершения пользовательского запроса + Максимизация пропускной способности + Хорошее постоянство (что бы это ни значило): Ваш подход кажется хорошим.Вы можете планировать несколько потоков, обрабатывающих запросы к БД.Но проверьте, какую (более) пропускную способность вы фактически получаете и где именно находится узкое место (сеть, ЦП БД, ввод-вывод, конфликт блокировок ...).Убедитесь, что вы не вносите ошибки, используя параллельный подход.

Answer 2

Вам не нужны две темы для этой простой задачи. Просто прочитайте сокет и выполните инструкции.

Answer 3

Как правило, ваша архитектура звучит правильно.Вы должны убедиться, что ваши два потока синхронизированы правильно при чтении / записи из / в очередь.

Я не уверен, что вы подразумеваете под "бутылочным горлышком, который обрабатывает БД"?Если обработка БД занимает много времени и вы в конечном итоге получаете длинную очередь, вы мало что можете сделать, кроме нескольких потоков, выполняющих обработку БД (при условии, что обработка может быть распараллелена, конечно) или выполнить некоторую настройку производительностиПоток БД.

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