Das klingt nach einem massiven Projekt. Die Komplexität wird ziemlich schnell steigen, egal ob du es willst oder nicht.
Als Erstes würde ich mit der Erstellung der Dokumentation für die API beginnen.
Wenn Sie Dokumentation haben, können Sie die Anforderungen für Ihr Projekt grafisch darstellen. Die Dinge, die du in Frage stellst, sind eine Art von Anforderungen, aber zu abstrakt, zu groß wie Bilder.
Wenn Sie Anforderungen haben, denken Sie über Softwareentwicklung und -struktur nach.
In diesem Schritt ist es meiner Meinung nach die Trennung der Dinge der Weg zu gehen. Dies erleichtert die Verwaltung. Engpässe finden und so weiter.
Ich weiß nicht, was der Auslöser in Ihrem System sein wird, wenn der Benutzer ein Abzeichen erhalten soll. Also nehme ich eine viereckige Analogie.
Um fair zu sein, die Jungs machen erstaunliche Arbeit, um all diese Anfragen in Echtzeit zu bearbeiten. Ich meine, es sieht so aus, als würden sie prüfen, ob ich bei jeder Anfrage ein Abzeichen bekommen soll. Also löst mein Check-In einen Algorithmus auf der Serverseite aus, um meine Checkin- und Badges-Geschichte, Badge-Regeln zu überprüfen, sie zusammenzumachen, mein verdientes Badge zu erstellen und mein neues Badge als Antwort zu zeigen. Klingt viel richtig? Nun, ist es!
Ich glaube nicht, dass sie all diese Arbeit parallel machen. Dies wäre zu viel Arbeit für einen Server. Obwohl mein Vier-Quadrate-Abzeichen mit keinem anderen Benutzer interagiert (viel einfacher), ist eine parallele Verarbeitung nicht ausgeschlossen.
Also erste Idee, wie foursquare funktionieren könnte. Load Balancer leitet meine Anfrage an einen nicht schwer beladenen Server weiter. Und dort wird alles parallel erledigt. Je mehr die Last, desto mehr sind die Server in Betrieb. Führen Sie alle Berechnungen für Badges im laufenden Betrieb mit nur der Slave-Datenbank durch. Präsentieren, um sein Badge zu verwenden und diese Daten an Master-DB zu senden. Dies ist möglich, da Badges nicht zwischen verschiedenen Benutzern interagieren. Ein Badge - eine Benutzerhistorie wird benötigt.
Eine andere Lösung wäre die Verwendung von map - reduce. Verwenden Sie Message Broker, um Plakettenrezensionen parallel zu verarbeiten. Sie erhalten eine Anfrage. Nachricht an Nachrichtenbroker senden. Die Nachricht landet auf mehreren Arbeitern , in denen ein Worker nur eine bestimmte Badge-Regeln für den Benutzer überprüft Geschichte. Am Ende wäre die Berechnung viel schneller.
Über db-Struktur. Ich denke, es gibt keinen Weg durch alle db zu gehen, um herauszufinden, ob der Benutzer ein Abzeichen erhalten sollte oder nicht. Ich würde mit einer einfachen, direkten Art und Weise gehen, dies zu handhaben. Erstellen Sie einfach eine gut strukturierte db mit Fremdschlüsseln, richtigen Spaltentypen, Indizes an den richtigen Stellen und Sie werden es schaffen. Baue stabilen Boden und optimiere nur, wenn es benötigt wird.
Wenn Sie wirklich zu Beginn des Projekts Optimierungen vornehmen wollen (was ich für eine schlechte Idee halte), würde ich alle badgebezogenen Daten in getrennten Tabellen aufbewahren. Eine Tabelle für ein Abzeichen mit allen spezifischen Spalten für dieses Abzeichen.
Beispiel wäre: badge_restaurants (user_id, badge_id, current_level, checkin_count). Um ein neues Restaurant-Badge zu erhalten, müssen Sie nur überprüfen, ob der Benutzer checkin_count + 1 & gt; = needly quity hat und Sie können nicht weiter suchen.
Natürlich ist das keine perfekte Lösung. Es kann mehr Abstraktion hinzugefügt werden, um es auf anspruchsvollere Weise zu erledigen (nicht Hunderte von Tabellen erstellen). Noch komplexere Abzeichen werden Sie dazu bringen, komplexere Lösungen zu erstellen.