Ich habe hier einen Design-Kopfschmerz, ich benutze PHP und MySQL in Verbindung mit Java (mein Projekt ist eine Android-Anwendung). Ich muss entscheiden, wie man in regelmäßigen Abständen eine Reihe von serverseitigen Berechnungen durchführt. Es gibt eine Fülle von Material hier auf SO, wie Cron-Jobs erstellt werden, und das ist großartig, ich kann sehr gut dort enden, aber ich bin mir nicht sicher, wie ich diesen Teil meines Projekts im weiteren Sinne angehen soll.
Die Anwendung ist vollständig auf die geografischen Standorte der Benutzer ausgerichtet. Sie sind immer in Clustern von 4 bis 40 organisiert, und diese Cluster bilden einen Instanzdatensatz in meiner Datenbank. Diese Instanzen können jederzeit aktiv oder inaktiv werden.
Für jeden Datensatz in meiner Datenbank oder, ich bevorzuge eine Instanz in jeder Epoche, möchte ich den Schwerpunkt der Instanz von ihren Benutzerstandorten aus neu berechnen (das ist einfach genug, insbesondere unter Verwendung eines skalaren Ansatzes aufgrund ihrer Nähe) Verschieben des Standorts der Instanz selbst durch Aktualisieren von Breiten- und Längenwerten in der Datenbank für die Instanz. Die Benutzer erhalten diese neuen Koordinaten des Schwerpunkts in regelmäßigen Abständen, wenn sie zu Hause anrufen.
Dies ist, wo es aufgrund meiner Unerfahrenheit Unordentlichkeit wird. Ich begann mit dem Schreiben einer relativ einfachen Berechnung, die eine SQL-Select-Abfrage und eine nachfolgende SQL-Aktualisierungsoperation für jede Instanz in jeder Epoche enthielt. Wenn wir ein Aktualisierungsintervall von etwa 20-30 Sekunden für jetzt annehmen, das ist weniger als eine Minute, verstößt dies offensichtlich gegen eine Beschränkung von 1 Minute für Cron-Jobs. (Es sollte beachtet werden, dass der Zeitunterschied zwischen Epochen fest codiert sein kann, falls dies absolut notwendig ist).
Kurzfristig wird dieser Prozess möglicherweise nur eine vernachlässigbare Zeit benötigen, da nur sehr wenige Instanzen / Cluster vorhanden sind. Es würde jedoch möglicherweise zu viele SQL-Abfragen und viel Zeit, um alle Berechnungen zu einem späteren Zeitpunkt zu verarbeiten stapeln, wenn die Anzahl der Instanzen in die Tausende lief ... Um unnötige Belastung zu reduzieren, möchte ich natürlich einen Mechanismus zu integrieren, um inaktive Instanzen auszuschließen, obwohl ich denke, dass es immer noch vorstellbar ist, dass die erforderliche Berechnungszeit das Epochenintervall überschreiten könnte. Ich denke, das ist ein Problem für (viel) später.
Wie es jetzt aussieht, ist die Frage zweifach:
Mein aktueller Ansatz ist wie folgt:
Klingt der obige Ansatz? An dieser Stelle habe ich vor, es so zu machen, es sei denn, es gibt einen besseren Vorschlag. Ich habe aber keinen festen Überblick darüber, wie ich die Ausführung der Aufgabe in jeder Epoche planen werde (Punkt 4), aber ich habe überall nachgesehen und kann das selbst nicht lösen ohne irgendeine Anleitung bin ich einfach nicht sehr gut. :) Wie immer würden alle Vorschläge sehr geschätzt werden.
Sie sollten in Erwägung ziehen, von einer geplanten Aufgabe zu einer Aktualisierung nach Bedarf überzugehen. Dies ist ziemlich einfach zu erreichen, aber es gibt Kompromisse.
Fügen Sie ein Datum / Uhrzeit-Feld hinzu, das zuletzt aktualisiert wurde
Überprüfen Sie jedes Mal, wenn Sie das Objekt abfragen, das letzte aktualisierte Feld für
"Frische" (in Ihrem Fall, wenn es vor 30 Sekunden & gt; war)
Wenn es frisch ist, senden Sie die Daten an den Benutzer.
Wenn es nicht neu ist, berechnen Sie die Daten neu und speichern Sie sie in der Datenbank
(Achten Sie darauf, das letzte aktualisierte Feld zu ändern). Dann sende das neue
Daten an den Benutzer.
Dies wird die Notwendigkeit einer geplanten Aufgabe & amp; loswerden der Verschwendung der Aktualisierung jeder Zeile. Es kann jedoch die Reaktionen auf den Benutzer verlangsamen.
Tags und Links php mysql delayed-execution recurring