System Design / Architektur bester Ansatz

stimmen
1

Ich habe ein System, das drei allgemeine Teile hat meine Beschreibung zu unterstützen.

1) DATABASE - alle Tabellen zu speichern, diese gleiche Datenbank wird die Daten für andere Dienste speichern , als auch mit einer Web - Anwendung, Silverlight etc ... (muss flexibel sein, wenn auf einem Remote - Server kann über einen Web - Service zur Verfügung gestellt werden, wenn lokal, kann lokal oder über TCP an den Windows - Dienst verbinden)

2) BLACK BOX - Prozess ein Element zu einem Zeitpunkt , indem sie in der Liste der erforderlichen Elemente aus der Datenbank eingespritzt wird , wie ein Rohr, wobei u in einer Reihe von Bedingungen gestellt, die Werte für ein einzelnes Element, und gibt die Ergebnisse für die einzelnen verarbeiteten Artikel.

3) Windows - Dienst - zum Abrufen von Daten aus der Datenbank, spritzt in der Black Box speichert Ergebnisse von Black Box in die Datenbank in vordefinierten Intervallen. Der Dienst kann auf einem anderen Server in die Datenbank sitzen. Werden Fehler protokollieren und ein Fehler auftreten sollte fortgesetzt werden.

Im Durchschnitt hat der Windows-Dienst über 5000 Einzelteile zu verarbeiten, und es wird die Blackbox etwa 1,5 Sekunden dauert 5000 Einzelteile zu verarbeiten.

Meine Fragen sind:

a) Sollte der Windows-Dienst eine Batch-Liste der Elemente erhält aus der Datenbank zu bearbeiten, oder sollte es eine Liste von IDs und in einer Schleife erhält jeweils einzelne Elemente aus der Datenbank, bevor er auf die Blackbox bekommen? Beachten Sie, dass die gleiche Datenbank wie auch von anderen Anwendungen verwendet werden. Zögernd ich die Datenbank bin zu raten, soll ein Web-Service-Aufruf von einer Art sein.

b) Sollte ein einzelnes Element gespeichert werden sofort nach der Verarbeitung? Oder sollte es für die Batch-Verarbeitung warten zu beenden, bevor zu speichern? jedes einzelne Element nach der Verarbeitung als Einsparung ist gut, wenn die Systeme plötzlich in der Mitte des Prozesses ausfällt, zumindest werden die verarbeiteten diejenigen gespeichert, aber auf Kosten der Leistung aufgrund seiner 5000 Anrufe an den Web-Service?

Jede Beratung über eine optimale Lösung?

Prost

Veröffentlicht am 30/12/2009 um 01:02
quelle vom benutzer
In anderen Sprachen...                            


2 antworten

stimmen
1

MSMQ ist Microsofts Queuing Ansatz. Ich bin damit einverstanden eine Warteschlange Ansatz verwendet werden soll - dies in den meisten Systemen erfolgt große Anzahl von Transaktionen Handhabung. Zum Beispiel bei der Bank verwenden ich, dass wir verwenden MQ als unsere Middleware-Lösung workfor.

Der Vorteil ist, dass der nächste Schritt in der Vorarb unmittelbar nach dem ersten Bearbeitung beginnen kann, ohne zu warten, für alle 5000 Einträge verarbeitet werden. Was passiert, wenn die Zahl erhöht sich auf 500 Mio.? Dann wird die Wartezeit für den ersten Punkt zu vervollständigen enorm steigen. Mit Hilfe eine Warteschlange Ansatz wäre es nicht ändern.

Es gibt noch andere Vorteile - Skalierbarkeit, Robustheit, Dinge wie garantierte Lieferung - aber Sie können später über diese Fragen erfahren.

Auch eine gut implementiertes Warteschlange erzeugt sehr wenig warten Overhead in den Prozessen, die es verwenden, da sie fast immer mehr Threads Zugriff auf die Warteschlangen unterstützen. (Es wird Overhead sein, aber es wird nicht eine stark erhöhte Wartezeit).

Beantwortet am 30/12/2009 um 01:27
quelle vom benutzer

stimmen
2

  1. Sie sollten Ihre Artikel in einer Charge ziehen, so dass Sie das Netzwerk mit Anfragen nicht verstopfen. eine Liste von IDs greifen, so dass sie dann Looping und jedes Mal den vollen Punkt ziehen N zusätzliche Datenbankaufrufe.

    • Sie können einen Webservice behandeln verwenden, um die Datenbank aufrufen, wenn Sie denken, Sie von der Abstraktion profitieren. sonst werden Sie nur unnötige Komplexität erstellen.

  2. Aktualisieren Sie die databse wie Sie jedes Element beenden. Die fertigen Produkte können so schnell weiter unten in der Zeile verwendet werden, da sie bereit sind, statt für Chargen von 5000 zu warten, zu beenden.

    • dies setzt voraus, dass Daten für jedes Element wird sparend

    • müssen Sie N-Anrufe (um jedes Element zu speichern), egal was, so dass Sie nicht viel gewinnen, indem Sie warten und dann am Ende jeder Charge machen zu aktualisieren.

    • wenn es abstürzt, werden Sie alle gespeicherten Daten verloren.

    • wenn Sie brauchen, um pro-Element nicht zu speichern Ergebnisse aus der Blackbox dann würden Sie haben einen guten Grund zu betrachten alles als Batch-Aktualisierung.


Ich habe geschrieben eine Reihe von Anwendungen , wie dies für eine Bank. Mein üblicher Ansatz ist als follows-- Es ist ganz einfach, fehlertolerante und effizient. (vorausgesetzt , Sie Mengen von Elementen verarbeiten müssen und Speichern von Daten für jeden)

  1. Die Datenbank hat eine Tabelle, die den Status der Bearbeitung eines Elements, zusätzlich zu dem Artikel Tabelle darstellt. für ein wenig mehr Arbeit im Vorfeld, wird diese Fehlersuche machen und die Prüfung des Prozess zu einem Kinderspiel:

    table ItemsProcessStatus  -- feel free to improve upon the name
    int orderID (auto increment)
    int itemID  (fk to items)
    datetime pulledForProcessing null
    datetime finishedProcessing null
    ..etc
    
  2. Windows - Dienst auf einem Timer läuft, sagen einmal alle X Minuten und zieht limit(Y)Einzelteile zu verarbeiten. Dies markiert die pulledForProcessingFlagge mit einem Zeitstempel in der ItemsProcessStatusTabelle.

    • Sie wollen Elemente ziehen , wo das Datum gezogen null ist [und auch diejenigen , die gezogen wurden, aber noch nicht abgeschlossen, und sind älter als ZMinuten (Ich nehme 15 bis 30 Minuten in der Regel)]

    • Seien Sie vorsichtig mit dem Verfahren, das diese zieht. Sie müssen Schlösser verwenden

    • Sie können dies weiter verfeinern: Auf der ersten Iteration, greifen YElemente, wo Yeine anständige Vermutung ist, wie viel Sie in dieser Zeitspanne verarbeiten können. Die nächste Iteration Sie die Rate berechnen , dass es (als gleitender Mittelwert) wird die Abarbeitung und die die Anzahl der Elemente anpassen zu ziehen. diese Art und Weise sie sich kontinuierlich anpassen mit voller Kapazität zu verarbeiten.

  3. die Windows-Dienst verarbeitet diese eins nach dem anderen (gut, in der Regel ist es multithreaded, so auf einmal viele), indem sie in die Blackbox zu senden.

    • Ich habe sie in einer Thread-Queue <> (nicht mit msmq verwechselt werden). Arbeitsthreads Schleife, aus der Warteschlange zu ziehen, die Verarbeitung des Elements in der Blackbox, und dann die Datenbank zu aktualisieren.

    • Sie können hier eine der typischen Multithreading-Techniken verwenden (warten / Puls, Leser / Schreiber schlank sperren, warten Griffe), oder einfach nur den Worker-Thread Schlaf für ein paar Sekunden, wenn die Warteschlange leer ist

  4. nach jedem Element abgeschlossen ist, rufen Sie die Updates proc für das Element, das auch die ItemsProcessStatus Tabelle aktualisiert (was bedeutet, dass die Bearbeitung abgeschlossen ist)

  5. Wenn Ihr Dienst beendet wird, beenden alle Elemente verarbeitet werden, die verarbeitet werden und sie in der DB aktualisieren.

    • Für alle Elemente , die nicht an die Black Box geschickt haben, deaktivieren Sie diese in der Prozesstabelle , indem Sie pulledForProcessingauf null.

  6. wenn Ihr Dienst stürzt ab, die Sie nicht ‚verlieren‘ eine Menge Daten. Gegenstände, die nicht frei zum Schuss haben wieder gezogen bekommen, wenn sie über eine bestimmtes Alter (Prozesstabelle) sind


Dies funktioniert mit mehreren Instanzen des Windows - Dienstes auf einer Reihe von Servern installiert (obwohl Sie hinzugefügt werden mögen ComputerNameauf die Prozesstabelle jeden Dienst zu identifizieren , welchen Computer ausgeführt wird ). Dies funktioniert , weil jeder Dienst nur den ‚nächsten Satz von Elementen‘ zu Prozess packt - es gibt keine Notwendigkeit für jede Art von Routing oder für die Prozesse miteinander zu kommunizieren.

Beantwortet am 30/12/2009 um 02:19
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more