Detta är en artikel från Python-världen, men den är fortfarande tillämplig på hela programmeringsfältet, även om multitrådning gör att vi kan behandla förfrågningar snabbare, men det finns också ett tak, gröna (mikrotråds) trådar är lösningen.
Multitrådad mjukvaruutveckling löser ett stort antal problem, särskilt för nätverkscentrerade applikationer som kräver krävande prestanda för att snabbt kunna svara användarna. Tyvärr räcker inte multitrådning för att lösa storskaliga problemSamkörningsexuella problem.
Att hantera dessa problem kräver att programmeringsmodeller ändras, med hjälp av asynkrona händelser och callback-baserade mekanismer. På Druva skapade vi ett python-baserat bibliotek som heter Dhaga för att lösa storskaliga problemSamkörning, medan programmeringsmodellen inte kräver några betydande förändringar.
Mjukvaruutvecklare bor i en sådanSamkörningvärlden. Trådar är förstklassiga medborgare idag, särskilt under utveckling, särskilt när din applikation utför intensiva nätverksoperationer, som inSync-systemet (nätverkssäkerhetssynkroniseringsprodukt) som Druva. Multitrådning hjälper flödet av programmeringskod för nätverksoperationer enkelt och ordnat. När vår applikation behöver prestandaförbättringar eller förbättringar kan den förbättrasElasticitet, vi kan öka antalet trådar.
Men när det gäller tusentals skalorSamkörningFörfrågningar och trådar räcker inte.
Vi fann att multitrådning har följande nackdelar:
1. InSync-systemets klient behöver säkerhetskopiera ett stort antal filer till servern via nätverks-RPC-anrop. Ett typiskt sätt för utvecklare att snabba upp processen är att använda trådar. Dock ökar prestandan som multitrådning ger kostnaden för minne och CPU; Utvecklare måste hålla en balans mellan hastighet och trådtäthet.
2. Våra servrar måste hantera inSync-systemet och tusentals kunderSamkörningAnslutningar och notiser. För att hantera anslutningar effektivt använder vi trådar för att hantera förfrågningar. Men det växande antalet inSync-systemkunder innebär också att vi måste fortsätta öka antalet trådar, vilket förbrukar mycket serverminne och CPU.
3. Vår webbserver måste hantera tusentals parallella HTTP-förfrågningar. Det mesta av arbetet ligger på nätverkssocketarna som tar emot och skickar data och skickar dem till backend på inSync-systemet. Gör att de flesta trådar väntar på nätverksoperationer. Orsaken av C10K-problemet, när det finns tusentals synkrona förfrågningar till webbservern, är det ganska oskalbart att generera en tråd för varje förfrågan (Scale).
Begränsningar hos asynkrona ramverk
Många asynkrona ramverk, inklusive Twisted, Tornado Tornado och asyncore, kan hjälpa utvecklare att gå bort från de populära sätten att använda trådar. Dessa ramverk bygger på icke-blockerande sockets och callback-mekanismer (liknande Node.js). Om vi använder dessa ramverk som de är kommer huvuddelarna av vår Druva-kod att behöva omstruktureras. Det är inte vad vi vill göra. Att refaktorera koden ökar utvecklings- och testcykler, vilket hindrar oss från att uppfylla våra skalningskrav. Eftersom flera delar av produkten måste vara massiva, måste var och en av oss refaktorera dem – därav ansträngningen att fördubbla eller tredubbla.
För att undvika att ändra så mycket kod var vi tvungna att gå ifrån att använda det befintliga ramverket direkt. Som tur var hittade vi några användbara verktyg.
Eftersom vi vill kontrollera exekveringen av kod på nätverks-I/O behöver vi ett sätt att dela upp en tråd i mikrotrådar. Vi finnerGröna ungar。 Den tillhandahåller en icke-implicit mikrotrådsschemaläggning kallad co-rutin coroutine. Med andra ord. Det är användbart när du vill kontrollera att din kod körs. Du kan bygga mikrotrådar för anpassade scheman eftersom du kan kontrollera när greenlets ger pauser. Detta är perfekt för oss eftersom det ger oss full kontroll över schemaläggningen av vår kod.
Tornado är ett enkelt, icke-blockerande webbserverramverk skrivet i Python utformat för att hantera tusentals asynkrona förfrågningar. Vi använder dess kärnkomponent, IOLoop IOStream. IOLoop är en icke-blockerande socket I/O-händelseloop; Den använder epoll (på Linux) eller köer (BSD och Mac OS X), annars väljer (på Windows) om de finns tillgängliga. IOStream tillhandahåller icke-blockerande socklar såsom bekväm förpackning för läsning och skrivning. Vi delegerar alla socket-operationer till Tornado och använder sedan callbacks för att trigga kodoperationer att slutföras (banq-not: mycket likt Node.js mekanism).
Det är en bra början, men vi behöver mer. Om vi använder ovanstående modul direkt i vår kod måste mycket av vår RPC-kod ändras, schemalägga RPC via greenlets, se till att greenlets inte blockeras (om greenlets blir igensatta kommer det att täppa till hela tråden och alla andra), hantera callback-funktioner från tornado.
Vi behöver en abstraktion för att hantera och arrangera greenlets för att undvika att de fylls med externa anrop, och denna abstraktion kan vara enormt skalbar bortom trådar. Denna abstraktion är Dhaga, vilket tillåter applikationskodflödet att programmeras som en traditionell synkron sekvens, men exekveringen är asynkron.
Dhaga (från hindi, vilket betyder tråd) är ett exekveringsramverk för en lättviktig tråd som vi abstraherar. Dhaga-klassen härstammar från greenlets och använder stackväxling för att köra flera kodflöden i en enda operativsystemtråd. Trådar i ett operativsystem kör flera dhagaser med hjälp av samarbetsplanering. När en dhaga väntar (främst väntar på att ett RPC-anrop ska återvända) överlämnar den kontrollen till föräldranivån (dvs. exekveringskontexten för OS-tråden som skapade den). Föräldranivån schemalägger sedan en ny dhaga som är redo att köras. RPC-anropet skickas vidare till tornado-webbservern för att skriva socketen asynkront, och sedan registrera en callback när den återvänder, och när denna RPC återvänder läggs den väntande dhagan till i den exekverbara kön och plockas sedan upp av föräldratråden. (Banq-not: liknande node.js princip)
Vi kan använda Dhaga istället för trådar för höglatensoperationer, och vi använder 512 dhagas i en enda tråd när antalet trådar ökar bortom en rimlig gräns för genomströmning.
|
Publicerad på 2014-12-06 22:21:58
|
|
|
Publicerad på 2014-12-07 17:22:55
