Dieser Artikel stammt aus einem persönlichen öffentlichen Konto : TechFlow , Original ist nicht einfach, suchen Sie Aufmerksamkeit
Heute ist der dreizehnte Teil des verteilten Themas . Im heutigen Artikel werden wir nicht über leere Theorie sprechen, sondern über einen praktischen Punkt.
Wie wir alle wissen, arbeiten Weibo-Programmierer häufig von Zeit zu Zeit Überstunden. Im Gegensatz zu anderen Programmierern können Programmierer in anderen Positionen möglicherweise Überstunden steuern, Weibo-Programmierer jedoch nicht. Warum? Da Programmierer nicht vorhersagen können, wann die Sterne neue Big Data haben, ist es für Weibo angemessen, zusammenzubrechen, sobald neues Material vorhanden ist. Viele Fans verwenden Weibo sogar, um die Popularität eines Stars zu messen.
Dies ist natürlich nur ein Absatz, aber für diejenigen von uns, die sich mit Technologie beschäftigen, können wir nicht anders, als eine Frage zu stellen. Weibo ist auch ein ziemlich großes Unternehmen ohne Geld oder Leute. Warum ist das System so instabil?
Natürlich bin ich nicht auf Weibo geblieben. Nehmen wir aus Gründen der Genauigkeit an, dass wir eine ähnliche neue App namens Wei Tehao geöffnet haben. Werfen wir einen Blick darauf, auf welche Probleme wir beim Wachstum der App von 0 stoßen werden. Durch das falsche Projekt von Weite können wir etwas über die Gründe für die Instabilität von Weibo spekulieren.
Die Geburt von Weite
Weite wurde an einem bestimmten Tag in einem bestimmten Jahr geboren. Um das Problem zu vereinfachen, nehmen wir an, dass weite nur zwei Funktionen hat, nämlich weite und seeweite .
Nun, für ein kleines Unternehmen, das gerade geboren wurde, kann man sich keinen bekannten Architekten leisten. Natürlich, wie einfach es ist . Lassen Sie uns die Funktionen aufschlüsseln, und wir werden feststellen, dass es insgesamt nur drei Funktionen gibt. Benutzer senden Mikrofunktionen, folgen anderen Benutzern und zeigen Mikrofunktionen an. Diese drei Funktionen sind sehr einfach, fast nackt.
Schauen wir uns zuerst das Mikroblog des Benutzers an. Wir benötigen nur eine Tabelle, um den Inhalt des Mikroblogs aufzuzeichnen. Diese Tabelle sieht folgendermaßen aus:
Die zweite Funktion besteht darin, Benutzern zu folgen. Wir können eine andere Tabelle verwenden, um die folgende Beziehung zwischen Benutzern aufzuzeichnen, was ebenfalls sehr einfach ist:
Mit diesen beiden Tabellen möchten wir Weite anzeigen. Es ist einfach, die Benutzer-ID zu verwenden, um dem Benutzer in der Tabelle zu folgen, um den betreffenden Benutzer zuzuordnen, und dann die ID des betreffenden Benutzers zu verwenden, um die gesendete Weite zuzuordnen.
Wir verwenden SQL, um diese Abfragebeziehung auszudrücken.
select wetwi.*
from (
select followeeid
from follower
where followerid = curid
)a join wetwi
on a.followeeid = wetwi.userid
Nach einigen Tests ging Weite erfolgreich online, und der Chef probierte es aus und fühlte sich sehr zufrieden. Neue Benutzer sind ebenfalls schnell aufgestiegen, und der verantwortliche Programmierer A wurde vom Chef geschätzt. Er wurde bis zum Management befördert und ist nicht mehr direkt für die technischen Probleme des Projekts verantwortlich.
Einem Mitglied dieser Person, B, wurde eine schwere Verantwortung übertragen und war für das Projekt verantwortlich, aber zu diesem Zeitpunkt trat das Problem auf.
Weite eine Stufe
Mit der Zunahme der Anzahl der Benutzer begann die Aufmerksamkeit der Benutzer schnell zuzunehmen, und bald schenkte ein durchschnittlicher Benutzer Dutzenden anderer Benutzer Aufmerksamkeit. Jedes Mal, wenn der Benutzer aktualisiert wird, werden Mikroinhalte geladen, die von Dutzenden von Personen gleichzeitig veröffentlicht wurden. Darüber hinaus unterstützt Weite Bilder. Es müssen höchstens Dutzende von Bildern und eine große Menge Text gleichzeitig geladen werden. Der Server ist zu spät, um so viele Daten zu übertragen . Häufige Benutzer berichten, dass beim Aktualisieren immer eine Zeitüberschreitung auftritt.
B dachte darüber nach, so einfach, wir können in zwei Schritte unterteilt werden: Open Source und Throttling.
Zunächst müssen wir Open Source verwenden. Zusätzlich zur Erhöhung der Anzahl der Maschinen müssen wir ein CDN mieten und die von Benutzern hochgeladenen Bilder auf das CDN stellen, ohne sie in der Datenbank zu speichern, wodurch die Datenübertragungsgeschwindigkeit beschleunigt wird.
Was ist mit Drosselung? Es ist auch einfach. Wir verwenden eine andere Tabelle, um das letzte Mal zu speichern, wenn der Benutzer aktualisiert wurde . Auf diese Weise müssen wir beim Abfragen die Daten erst nach diesem Zeitpunkt abfragen. Also haben wir eine Tabelle hinzugefügt, um die Zeit aufzuzeichnen.
Auf diese Weise stabilisierte sich das System schließlich und die Anzahl der beschwerdeführenden Benutzer wurde weiter reduziert. Bald gab es einen explosionsartigen Anstieg der Anzahl der Benutzer. Schließlich konnte das System eines Tages nacheinander heiße Ereignisse nicht mehr ertragen und ging nacheinander zurück.
Warum ist es unten?
Da die Datenbankabfrage einige Zeit in Anspruch nimmt , ist sie von Natur aus langsam. Nach dem Hinzufügen des Verknüpfungsvorgangs wird das System langsamer. Da nun die Zeit von Weite beurteilt werden muss, um zum Filtern zu senden, wird eine zusätzliche Abfrage hinzugefügt, die nach Erreichen des Engpasses natürlich nicht mehr zu ertragen ist.
B绞尽脑汁，终于想到了办法，就是缓存。他缓存了用户最后一次刷新的时间，这样就可以减少一次数据库的查询。系统稍微变快了一点，但是并没有坚持多久，终于老板忍无可忍开除了B，花大价钱从大公司挖来了一个架构师C。
与此同时，微特的用户量进一步增长，到了第二个阶段。
微特二阶段
C熟悉了环境之后，气得直骂娘，不从架构考虑问题，只会修修补补要不得啊。怎么可以直接用DB存储数据呢，搞成这样不崩溃才有鬼。
新官上任三把火，搞走了几个混吃等死的老白兔，C又招来当年的几个手下，开始大张旗鼓地重构系统。在分布式系统当中，DB往往都是瓶颈，能不用DB的就不应该用DB。而且微特的模式非常明显，用户发布了新内容之后，最关心的就是他的粉丝，那么我们直接在他更新的时候，就把内容推送到粉丝的缓存里，当用户刷新的时候，直接从缓存拉取数据，这不是要方便得多吗？
C画出了新的架构图（可见C也是灵魂画手）：
微特直接通过kafka等消息系统推送给用户，效率要比DB高多了，C的一帮手下也给力，很快就完成了架构升级。上线之后，果然效果非凡，系统立刻变得稳定了许多，用户抱怨大幅减少。
在这几年里，公司声名鹊起，积累了大量的资源，一举去美国上市了。公司的高管都财富自由了，C来得晚没分到多少，并且看到当年埋了大坑的A混的风生水起，加上长久以来的不和，气不过跑路了。
就在这风生水起的时候，意想不到的事情又发生了。而我们的微特也来到了阶段3。
微特三阶段
C走了之后，系统从此再也没有大的改动，大家都只想把眼前修修补补的工作做好。反正公司也上市了，老板也自由了，底层的员工只想安安稳稳赚点工资。加上系统也稳定得很，没有人觉得有什么改动的必要。
但是由于微特现在太火了，使用的用户越来越多，除了普通用户之外，还把明星艺人吸引来了。这些明星艺人，一个个都有好几千万的粉丝。不是之前升级了架构，改成了通过kafka推送消息而不是去DB查询吗？这下好了，这些明星每次一发微特，都需要发送好几千万次消息。
有几天不知道是过节还是碰巧，这些明星艺人偏偏一起发推，直接就把发送消息的系统挤压挂了。这一挂，虽然微特整个系统没有崩溃，但是吃瓜群众发现再也搜索不到微特了。于是一起在网上骂微特，这一骂，需要发送的消息更多，系统更加扛不住，彻底成了死循环，公司的口碑急转直下。
公司也想解决这个问题，奈何之前做了太多修修补补的工作，整个系统变得非常复杂，很多模块耦合在了一起，加上也没有一个很好的方案，一直也没有一个人下得了决心整个重构，反而往上加了更多补丁。
直到后来，A离职了之后，公司新来的CTO招来了一个业内技术骨干D。D提出了新的想法，将前面两种方案作了折中。大V发送的时候，并不推送到所有粉丝，而是只推送给当前在线的粉丝。离线的粉丝还是通过查询来获取数据。这样一来对流量进行了分流，微特系统变得稳定了许多。
但是这并没有真正彻底解决问题，系统仍然有时候会宕机，但是一时半会也没有什么特别好的办法，系统也变得极为臃肿彻底经不起折腾。于是微特就这样修修补补，变成了程序员加班不规律的公司。
后续
所谓的微特当然是个段子，故事也不是真的，但是技术架构的变迁还是很有参考意义。一个看似简单的问题，真正落地到应用场景当中，往往没有那么简单。系统眼前的稳定也不能代表长远，这也是我们在开始一个项目的时候就需要眼光长远做好规划的原因。更是一个优秀的架构师的价值所在，只不过可惜的是，世上的道理总是这样，知道的人太多，做到的太少。
希望今天这个的这个故事在博君一笑的同时也能给大家一点启发，一个成功的优秀的系统背后，究竟藏着多少思考和心血呢？
今天的文章就是这些，如果觉得有所收获，请顺手点个关注或者转发吧，你们的举手之劳对我来说很重要。