PHP löst Probleme mit hoher Parallelität

Der Indikator, den wir normalerweise für die Durchsatzrate eines Websystems messen, ist QPS (Query Per Second, Anzahl der pro Sekunde verarbeiteten Anfragen). Dieser Indikator ist sehr wichtig, um Szenarios mit hoher Parallelität von Zehntausenden Malen pro Sekunde zu lösen. Wir gehen beispielsweise davon aus, dass die durchschnittliche Antwortzeit für die Verarbeitung einer Geschäftsanfrage 100 ms beträgt. Gleichzeitig gibt es 20 Apache-Webserver im System und MaxClients ist auf 500 konfiguriert (was die maximale Anzahl von Apache-Verbindungen angibt).

Dann beträgt der theoretische Spitzen-QPS unseres Websystems (idealisierte Berechnungsmethode):

20*500/0,1 = 100.000 (100.000 QPS)

咦? Unser System scheint sehr leistungsfähig zu sein. Es kann 100.000 Anfragen in einer Sekunde verarbeiten. Der Flash-Sale von 5w/s scheint ein „Papiertiger“ zu sein. Die tatsächliche Situation ist natürlich nicht so ideal. In tatsächlichen Szenarien mit hoher Parallelität sind Maschinen stark ausgelastet und die durchschnittliche Antwortzeit wird zu diesem Zeitpunkt erheblich verlängert.

Ein gewöhnlicher p4-Server kann bis zu 100.000 IPs pro Tag unterstützen. Wenn die Anzahl der Besuche 10 W übersteigt, ist ein dedizierter Server erforderlich, um das Problem zu lösen, egal wie die Software ist optimiert ist, wird es nicht helfen. Die Hauptfaktoren, die die Geschwindigkeit des Servers

beeinflussen, sind: Netzwerk – Lese- und Schreibgeschwindigkeit der Festplatte – Speichergröße – CPU-Verarbeitungsgeschwindigkeit.

Was den Webserver betrifft, gilt: Je mehr Verbindungsprozesse Apache öffnet, desto mehr Kontextwechsel muss die CPU bewältigen, was den CPU-Verbrauch erhöht und direkt zu einer Erhöhung der durchschnittlichen Antwortzeit führt. Daher muss die oben genannte Anzahl an MaxClients anhand von Hardwarefaktoren wie CPU und Speicher berücksichtigt werden. Mehr ist definitiv nicht besser. Sie können es über Apaches eigene Benchmark testen und einen geeigneten Wert erhalten. Dann wählen wir Redis für die Speicherung auf Speicherbetriebsebene. In einem Zustand mit hoher Parallelität ist die Speicherreaktionszeit entscheidend. Obwohl auch die Netzwerkbandbreite ein Faktor ist, sind solche Anforderungspakete im Allgemeinen relativ klein und stellen selten einen Engpass für Anforderungen dar. Es kommt selten vor, dass der Lastausgleich zu einem Systemengpass wird, daher werden wir hier nicht darauf eingehen.

Dann lautet die Frage: Unter der Annahme, dass sich in unserem System in einem Zustand hoher Parallelität von 5 W/s die durchschnittliche Antwortzeit von 100 ms auf 250 ms ändert (in der tatsächlichen Situation sogar noch mehr):

20 *500/0,25 = 40.000 (40.000 QPS)

Unser System bleibt also bei 40.000 QPS. Bei 50.000 Anfragen pro Sekunde ergibt sich ein Unterschied von 10.000.

An einer Autobahnkreuzung kommen beispielsweise 5 Autos pro Sekunde vorbei und überholen 5 Autos, und die Autobahnkreuzung funktioniert normal. Plötzlich können nur noch 4 Autos diese Kreuzung in einer Sekunde passieren, und das Verkehrsaufkommen ist immer noch das gleiche. Daher wird es definitiv einen Stau geben. (Es fühlt sich an, als wären aus 5 Lanes plötzlich 4 Lanes geworden)

In ähnlicher Weise sind in einer bestimmten Sekunde 20*500 verfügbare Verbindungsprozesse voll ausgelastet, aber es gibt immer noch 10.000 neue Anfragen, es gibt keine Verbindung Prozess verfügbar und es wird erwartet, dass das System in einen abnormalen Zustand gerät.

Tatsächlich treten in normalen Geschäftsszenarien ohne hohe Parallelität ähnliche Situationen auf. Es liegt ein Problem mit einer bestimmten Geschäftsanforderungsschnittstelle vor und die Antwortzeit ist extrem langsam Die gesamte Webanfrage hat eine sehr lange Antwortzeit, wodurch die Anzahl der verfügbaren Verbindungen auf dem Webserver allmählich aufgefüllt wird und für andere normale Geschäftsanfragen kein Verbindungsprozess verfügbar ist.

Je erschreckender das Problem ist, desto unzugänglicher ist das System, desto häufiger klicken die Benutzer. Der Teufelskreis führt schließlich zu einer „Lawine“ (einer der Web-Rechner hängt sich auf). Der Datenverkehr soll auf andere Maschinen verteilt werden, die normal funktionieren. Auch die normalen Maschinen bleiben hängen, und dann entsteht ein Teufelskreis, der das gesamte Websystem zum Absturz bringt.

3. Neustart- und Überlastschutz

Wenn im System eine „Lawine“ auftritt, wird ein vorschneller Neustart des Dienstes das Problem nicht lösen. Das häufigste Phänomen ist, dass es nach dem Start sofort aufhängt. Zu diesem Zeitpunkt ist es am besten, den Datenverkehr auf der Eingangsebene zu verweigern und dann neu zu starten. Wenn auch Dienste wie Redis/Memcache ausfallen, müssen Sie beim Neustart auf das „Aufwärmen“ achten, was lange dauern kann.

In Flash-Sale- und Rush-Sale-Szenarien übersteigt der Datenverkehr oft die Vorbereitung und Vorstellungskraft unseres Systems. Zu diesem Zeitpunkt ist ein Überlastschutz erforderlich. Das Ablehnen von Anfragen ist auch eine Schutzmaßnahme, wenn eine vollständige Systemauslastung festgestellt wird. Das Einrichten der Filterung im Frontend ist der einfachste Weg, aber dieser Ansatz wird von Benutzern „kritisiert“. Angemessener ist es, einen Überlastungsschutz auf der CGI-Einstiegsebene festzulegen, um direkte Anfragen von Kunden schnell zurückzugeben.

Datensicherheit bei hoher Parallelität

Wir wissen, dass, wenn mehrere Threads in dieselbe Datei schreiben ( Mehrere Threads führen denselben Code gleichzeitig aus. Wenn das Ergebnis jedes Laufs mit dem eines Einzel-Thread-Laufs übereinstimmt und das Ergebnis das gleiche ist wie erwartet, ist es threadsicher. Wenn es sich um eine MySQL-Datenbank handelt, können Sie das Problem mit einem eigenen Sperrmechanismus lösen. In großen Parallelitätsszenarien wird MySQL jedoch nicht empfohlen. Bei Flash-Sale- und Rush-Sale-Szenarien gibt es ein weiteres Problem, nämlich die „Überlieferung“. Wenn dieser Aspekt nicht sorgfältig kontrolliert wird, kommt es zu einer übermäßigen Lieferung. Wir haben auch gehört, dass einige E-Commerce-Unternehmen Eilkäufe durchführen. Nachdem der Käufer das Produkt erfolgreich gekauft hat, erkennt der Händler die Bestellung nicht als gültig an und weigert sich, die Ware zu liefern. Das Problem liegt hier möglicherweise nicht unbedingt darin, dass der Händler betrügerisch vorgeht, sondern darin, dass die Gefahr einer Überausgabe auf der technischen Ebene des Systems besteht.

1. Gründe für die Überlieferung

Angenommen, wir haben in einem bestimmten Eilverkaufsszenario insgesamt nur 100 Produkte. Im letzten Moment haben wir 99 Produkte verbraucht und nur noch das letzte. Zu diesem Zeitpunkt sendete das System mehrere gleichzeitige Anfragen. Die von diesen Anfragen gelesenen Produktsalden betrugen alle 99, und dann verabschiedeten sie alle diese Saldenbeurteilung, was schließlich zu einer Überausgabe führte. (Dasselbe wie in der zuvor im Artikel erwähnten Szene)

Im Bild oben hat der gleichzeitige Benutzer B ebenfalls „erfolgreich gekauft“, sodass eine weitere Person das Produkt erhalten kann. Dieses Szenario kann in Situationen mit hoher Parallelität sehr leicht auftreten.

Optimierungsplan 1: Setzen Sie das Feld „Inventarnummer“ auf „ohne Vorzeichen“, da das Feld keine negative Zahl sein darf.

<?php
//优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false
include(&#39;./mysql.php&#39;);
$username = &#39;wang&#39;.rand(0,1000);
//生成唯一订单
function build_order_no(){
  return date(&#39;ymd&#39;).substr(implode(NULL, array_map(&#39;ord&#39;, str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0,$username){
    global $conn;
    $sql="insert into ih_log(event,type,usernma)
    values(&#39;$event&#39;,&#39;$type&#39;,&#39;$username&#39;)";
    return mysqli_query($conn,$sql);
}
function insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
{
      global $conn;
      $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price,username,number)
      values(&#39;$order_sn&#39;,&#39;$user_id&#39;,&#39;$goods_id&#39;,&#39;$sku_id&#39;,&#39;$price&#39;,&#39;$username&#39;,&#39;$number&#39;)";
     return  mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
$sql="select number from ih_store where goods_id=&#39;$goods_id&#39; and sku_id=&#39;$sku_id&#39; ";
$rs=mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
  if($row[&#39;number&#39;]>0){//高并发下会导致超卖
      if($row[&#39;number&#39;]<$number){
        return insertLog(&#39;库存不够&#39;,3,$username);
      }
      $order_sn=build_order_no();
      //库存减少
      $sql="update ih_store set number=number-{$number} where sku_id=&#39;$sku_id&#39; and number>0";
      $store_rs=mysqli_query($conn,$sql);
      if($store_rs){
          //生成订单
          insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number);
          insertLog(&#39;库存减少成功&#39;,1,$username);
      }else{
          insertLog(&#39;库存减少失败&#39;,2,$username);
      }
  }else{
      insertLog(&#39;库存不够&#39;,3,$username);
  }
?>

2 Sperridee

Es gibt viele Ideen zur Lösung der Thread-Sicherheit, und wir können die Diskussion aus der Richtung des „pessimistischen Sperrens“ beginnen.

Pessimistisches Sperren, d. h. beim Ändern von Daten wird der gesperrte Zustand übernommen, um Änderungen von externen Anfragen auszuschließen. Wenn Sie auf einen gesperrten Zustand stoßen, müssen Sie warten.

Obwohl die obige Lösung das Problem der Thread-Sicherheit löst, vergessen Sie nicht, dass unser Szenario „hohe Parallelität“ ist. Mit anderen Worten, es wird viele solcher Änderungsanfragen geben, und jede Anfrage muss auf eine „Sperre“ warten. Einige Threads haben möglicherweise nie die Chance, diese „Sperre“ zu ergreifen, und solche Anfragen werden dort sterben. Gleichzeitig wird es viele solcher Anfragen geben, was die durchschnittliche Antwortzeit des Systems sofort erhöht. Dadurch wird die Anzahl der verfügbaren Verbindungen erschöpft und das System fällt in eine Ausnahme.

Optimierungsplan 2: Verwenden Sie MySQL-Transaktionen, um die Operationszeilen zu sperren

<?php
//优化方案2：使用MySQL的事务，锁住操作的行
include(&#39;./mysql.php&#39;);
//生成唯一订单号
function build_order_no(){
  return date(&#39;ymd&#39;).substr(implode(NULL, array_map(&#39;ord&#39;, str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
    global $conn;
    $sql="insert into ih_log(event,type)
    values(&#39;$event&#39;,&#39;$type&#39;)";
    mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
mysqli_query($conn,"BEGIN");  //开始事务
$sql="select number from ih_store where goods_id=&#39;$goods_id&#39; and sku_id=&#39;$sku_id&#39; FOR UPDATE";//此时这条记录被锁住,其它事务必须等待此次事务提交后才能执行
$rs=mysqli_query($conn,$sql);
$row=$rs->fetch_assoc();
if($row[&#39;number&#39;]>0){
    //生成订单
    $order_sn=build_order_no();
    $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
    values(&#39;$order_sn&#39;,&#39;$user_id&#39;,&#39;$goods_id&#39;,&#39;$sku_id&#39;,&#39;$price&#39;)";
    $order_rs=mysqli_query($conn,$sql);
    //库存减少
    $sql="update ih_store set number=number-{$number} where sku_id=&#39;$sku_id&#39;";
    $store_rs=mysqli_query($conn,$sql);
    if($store_rs){
      echo &#39;库存减少成功&#39;;
        insertLog(&#39;库存减少成功&#39;);
        mysqli_query($conn,"COMMIT");//事务提交即解锁
    }else{
      echo &#39;库存减少失败&#39;;
        insertLog(&#39;库存减少失败&#39;);
    }
}else{
  echo &#39;库存不够&#39;;
    insertLog(&#39;库存不够&#39;);
    mysqli_query($conn,"ROLLBACK");
}
?>

3. Idee der FIFO-Warteschlange

Okay, dann ändern wir das Obige in diesem Szenario leicht , stellen wir die Anfrage direkt in die Warteschlange und verwenden FIFO (First Input First Output, First In First Out). In diesem Fall werden wir nicht dazu führen, dass einige Anfragen niemals die Sperre erhalten. Fühlt es sich angesichts dessen so an, als würde man Multi-Threading gewaltsam in Single-Threading umwandeln?

Dann haben wir nun das Sperrproblem gelöst und alle Anfragen werden in einer „First In, First Out“-Warteschlange verarbeitet. Dann tritt in einem Szenario mit hoher Parallelität ein neues Problem auf, da der Warteschlangenspeicher augenblicklich „explodiert“ wird und das System dann wieder in einen abnormalen Zustand gerät. Oder das Entwerfen einer riesigen Speicherwarteschlange ist ebenfalls eine Lösung. Die Geschwindigkeit, mit der das System Anforderungen in einer Warteschlange verarbeitet, kann jedoch nicht mit der Anzahl der Anforderungen verglichen werden, die wie verrückt in die Warteschlange strömen. Mit anderen Worten, die Anzahl der Anforderungen in der Warteschlange wird immer größer, und schließlich wird die durchschnittliche Antwortzeit des Websystems immer noch erheblich sinken und das System wird immer noch in eine Ausnahme geraten.

4. Die Idee der Dateisperre

Für Anwendungen, bei denen die tägliche IP nicht hoch ist oder die Anzahl der Parallelität nicht sehr groß ist, besteht im Allgemeinen keine Notwendigkeit, dies zu berücksichtigen! Mit normalen Dateimanipulationsmethoden ist das überhaupt kein Problem. Wenn jedoch die Parallelität beim Lesen und Schreiben von Dateien hoch ist, ist es sehr wahrscheinlich, dass mehrere Prozesse an der nächsten Datei arbeiten. Wenn der Zugriff auf die Datei zu diesem Zeitpunkt nicht exklusiv ist, führt dies leicht zu Datenverlust

Optimierungsplan 4: Nicht blockierende dateiexklusive Sperren verwenden

<?php
//优化方案4：使用非阻塞的文件排他锁
include (&#39;./mysql.php&#39;);
//生成唯一订单号
function build_order_no(){
  return date(&#39;ymd&#39;).substr(implode(NULL, array_map(&#39;ord&#39;, str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
    global $conn;
    $sql="insert into ih_log(event,type)
    values(&#39;$event&#39;,&#39;$type&#39;)";
    mysqli_query($conn,$sql);
}
$fp = fopen("lock.txt", "w+");
if(!flock($fp,LOCK_EX | LOCK_NB)){
    echo "系统繁忙，请稍后再试";
    return;
}
//下单
$sql="select number from ih_store where goods_id=&#39;$goods_id&#39; and sku_id=&#39;$sku_id&#39;";
$rs =  mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row[&#39;number&#39;]>0){//库存是否大于0
    //模拟下单操作
    $order_sn=build_order_no();
    $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
    values(&#39;$order_sn&#39;,&#39;$user_id&#39;,&#39;$goods_id&#39;,&#39;$sku_id&#39;,&#39;$price&#39;)";
    $order_rs =  mysqli_query($conn,$sql);
    //库存减少
    $sql="update ih_store set number=number-{$number} where sku_id=&#39;$sku_id&#39;";
    $store_rs =  mysqli_query($conn,$sql);
    if($store_rs){
      echo &#39;库存减少成功&#39;;
        insertLog(&#39;库存减少成功&#39;);
        flock($fp,LOCK_UN);//释放锁
    }else{
      echo &#39;库存减少失败&#39;;
        insertLog(&#39;库存减少失败&#39;);
    }
}else{
  echo &#39;库存不够&#39;;
    insertLog(&#39;库存不够&#39;);
}
fclose($fp);
 ?>

5. Idee des optimistischen Sperrens

Zu diesem Zeitpunkt können wir die Idee des „optimistischen Sperrens“ diskutieren. . Beim optimistischen Sperren wird im Vergleich zum „pessimistischen Sperren“ ein entspannterer Sperrmechanismus verwendet, und die meisten von ihnen verwenden Versionsaktualisierungen. Die Implementierung besteht darin, dass alle Anforderungen für diese Daten geändert werden können, es wird jedoch eine Versionsnummer der Daten abgerufen. Nur diejenigen mit konsistenten Versionsnummern können erfolgreich aktualisiert werden, und andere Anforderungen werden als Fehler zurückgegeben. In diesem Fall müssen wir das Warteschlangenproblem nicht berücksichtigen, aber es erhöht den Rechenaufwand der CPU. Insgesamt ist dies jedoch eine bessere Lösung.

Es gibt viele Software und Dienste, die die Funktion „optimistisches Sperren“ unterstützen, wie z. B. Watch in Redis ist eine davon. Mit dieser Implementierung gewährleisten wir die Datensicherheit.

Optimierungsplan 5: In Redis ansehen

<?php
$redis = new redis();
 $result = $redis->connect(&#39;127.0.0.1&#39;, 6379);
 echo $mywatchkey = $redis->get("mywatchkey");
/*
  //插入抢购数据
 if($mywatchkey>0)
 {
     $redis->watch("mywatchkey");
  //启动一个新的事务。
    $redis->multi();
   $redis->set("mywatchkey",$mywatchkey-1);
   $result = $redis->exec();
   if($result) {
      $redis->hSet("watchkeylist","user_".mt_rand(1,99999),time());
      $watchkeylist = $redis->hGetAll("watchkeylist");
        echo "抢购成功！<br/>"; 
        $re = $mywatchkey - 1;   
        echo "剩余数量：".$re."<br/>";
        echo "用户列表：<pre class="brush:php;toolbar:false">";
        print_r($watchkeylist);
   }else{
      echo "手气不好，再抢购！";exit;
   }  
 }else{
     // $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12");
     //  $watchkeylist = $redis->hGetAll("watchkeylist");
        echo "fail！<br/>";    
        echo ".no result<br/>";
        echo "用户列表：<pre class="brush:php;toolbar:false">";
      //  var_dump($watchkeylist);  
 }*/
$rob_total = 100;   //抢购数量
if($mywatchkey<=$rob_total){
    $redis->watch("mywatchkey");
    $redis->multi(); //在当前连接上启动一个新的事务。
    //插入抢购数据
    $redis->set("mywatchkey",$mywatchkey+1);
    $rob_result = $redis->exec();
    if($rob_result){
         $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),$mywatchkey);
        $mywatchlist = $redis->hGetAll("watchkeylist");
        echo "抢购成功！<br/>";
     
        echo "剩余数量：".($rob_total-$mywatchkey-1)."<br/>";
        echo "用户列表：<pre class="brush:php;toolbar:false">";
        var_dump($mywatchlist);
    }else{
          $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),&#39;meiqiangdao&#39;);
        echo "手气不好，再抢购！";exit;
    }
}
?>

PHP löst das Problem von Website-Big Data, großem Datenverkehr und hoher Parallelität

Das erste, worüber ich sprechen möchte, ist die Datenbank, die eine gute Struktur haben muss. Vermeiden Sie die Verwendung von Indizes für häufige Abfragen und verwenden Sie die Sortierung, um nicht zu ersetzen. Sequentieller Zugriff. Wenn die Bedingungen dies zulassen, wird im Allgemeinen MySQL Der Server wird am besten auf dem Linux-Betriebssystem installiert. In Bezug auf Apache und Nginx wird empfohlen, Nginx in Situationen mit hoher Parallelität zu verwenden. Ginx ist eine gute Alternative zum Apache-Server. Nginx verbraucht weniger Speicher. Der offizielle Test kann 50.000 gleichzeitige Verbindungen unterstützen, und in der tatsächlichen Produktionsumgebung kann die Anzahl gleichzeitiger Verbindungen 20.000 bis 30.000 erreichen. Schließen Sie unnötige Module in PHP so weit wie möglich und verwenden Sie Memcached, ein leistungsstarkes verteiltes Speicherobjekt-Caching-System, das Daten direkt aus dem Speicher überträgt, ohne eine Datenbank zu verwenden. Dadurch wird die GZIP-Komprimierung erheblich verbessert Website und komprimieren Sie den Website-Inhalt, um den Website-Verkehr erheblich zu reduzieren. Zweitens ist das externe Hotlinking verboten. Hotlinking von Bildern oder Dateien von externen Websites bringt oft einen hohen Lastdruck mit sich, daher sollte das externe Hotlinken von Bildern oder Dateien auf die eigenen

strikt eingeschränkt werden, zum Glück kann man derzeit einfach darauf verweisen . Um Hotlinking zu steuern, kann Apache selbst

Hotlinking über die Konfiguration deaktivieren. IIS verfügt auch über einige ISAPIs von Drittanbietern, die dieselbe Funktion erreichen können.

Natürlich können Empfehlungen auch durch Code gefälscht werden, um Hotlinking zu erreichen. Allerdings gibt es derzeit nicht viele Leute, die absichtlich Empfehlungen und Hotlinking fälschen.

Sie können es ignorieren oder nichttechnische Mittel verwenden, um es zu lösen. Zum Beispiel auf Bildern.

Drittens kontrollieren Sie den Download großer Dateien.

Das Herunterladen großer Dateien nimmt viel Datenverkehr in Anspruch, und bei Nicht-SCSI-Festplatten verbraucht das Herunterladen einer großen Anzahl von Dateien

CPU, was die Reaktionsfähigkeit der Website verringert. Versuchen Sie daher, keine Downloads großer Dateien mit einer Größe von mehr als 2 MB bereitzustellen. Wenn

erforderlich ist, wird empfohlen, große Dateien auf einem anderen Server zu platzieren.

Viertens: Verwenden Sie verschiedene Hosts, um den Hauptverkehr umzuleiten.

Platzieren Sie Dateien auf verschiedenen Hosts und stellen Sie den Benutzern unterschiedliche Bilder zum Herunterladen zur Verfügung. Wenn Sie beispielsweise das Gefühl haben, dass RSS-Dateien viel Datenverkehr beanspruchen, verwenden Sie Dienste wie FeedBurner oder FeedSky, um die RSS-Ausgabe auf andere Hosts zu verteilen. Auf diese Weise wird der größte Teil des Datenverkehrsdrucks durch den Zugriff anderer Personen verursacht Konzentrieren Sie sich auf den Host von FeedBurner, und RSS ist nicht verfügbar. Es beansprucht zu viele Ressourcen.

Fünftens: Verwenden Sie verschiedene Hosts, um den Hauptverkehr umzuleiten.

Platzieren Sie Dateien auf verschiedenen Hosts und stellen Sie den Benutzern verschiedene Bilder zum Herunterladen zur Verfügung . Wenn Sie beispielsweise das Gefühl haben, dass RSS-Dateien viel Datenverkehr beanspruchen, verwenden Sie Dienste wie FeedBurner oder FeedSky, um die RSS-Ausgabe auf anderen Hosts zu platzieren. Auf diese Weise wird der größte Teil des Datenverkehrsdrucks durch den Zugriff anderer Personen konzentriert Der Host von FeedBurner und RSS belegen nicht zu viele Ressourcen.

Sechstens: Verwenden Sie eine Verkehrsanalyse- und Statistiksoftware.
Durch die Installation einer Verkehrsanalyse- und Statistiksoftware auf der Website können Sie sofort erkennen, wo viel Verkehr verbraucht wird und welche Seiten optimiert werden müssen. Daher ist eine genaue statistische Analyse erforderlich, um das Verkehrsproblem zu lösen. Zum Beispiel: Google Analytics.

Einschränkungen für hohe Parallelität und hohe Last: Hardware, Bereitstellung, Betriebssystem, Webserver, PHP, MySQL, Tests

Bereitstellung: Servertrennung, Datenbankcluster und Bibliothekstabellen-Hashing, Spiegelung, Laden Balancing

Lastausgleichsklassifizierung: 1), DNS-Round-Robin 2) Proxyserver-Lastausgleich 3) Adressübersetzungs-Gateway-Lastausgleich 4) NAT-Lastausgleich 5) Reverse-Proxy-Lastausgleich 6) Hybrider Lastausgleich

Bereitstellungsplan 1:

Anwendungsbereich: Websites und Anwendungssysteme mit statischen Inhalten als Hauptteil; Websites und Anwendungssysteme mit hohen Systemsicherheitsanforderungen.

Hauptserver: Der Hauptserver

trägt den Hauptlaufdruck des Programms und verarbeitet dynamische Anforderungen auf der Website oder im Anwendungssystem.

überträgt statische Seiten auf mehrere Veröffentlichungsserver.

Übertragen Sie die Anhangsdatei auf den Dateiserver.

Bei Websites mit hohen Sicherheitsanforderungen, die hauptsächlich statisch sind, kann der Server im internen Netzwerk platziert werden, um den Zugriff vom externen Netzwerk zu blockieren.

DB-Server: Der Datenbankserver

trägt den Lese- und Schreibdruck der Datenbank

tauscht nur Datenvolumen mit dem Hauptserver aus und blockiert den externen Netzwerkzugriff.

Datei-/Videoserver: Der Datei-/Videoserver

überträgt Datenströme, die große Systemressourcen und Bandbreitenressourcen im System beanspruchen.

dient zum Speichern, Lesen und Schreiben von Lager für große Anhänge

Als Videoserver verfügt er über automatische Videoverarbeitungsfunktionen.

Veröffentlichungsservergruppe:

ist nur für die Veröffentlichung statischer Seiten verantwortlich und überträgt die überwiegende Mehrheit der Webanfragen.

führt die Lastausgleichsbereitstellung über Nginx durch.

Bereitstellungsplan 2:

Anwendungsbereich: Websites oder Anwendungssysteme mit dynamischem interaktivem Inhalt als Hauptteil; Websites oder Anwendungssysteme mit hohem Lastdruck und ausreichendem Budget; >Webservergruppe:

Webdienst hat keine Master-Slave-Beziehung und ist ein paralleles redundantes Design

Der Lastausgleich wird durch Front-End-Lastausgleichsgeräte oder Nginx-Reverse-Proxy erreicht; >

Durch die Aufteilung dedizierter Dateiserver/Videoserver werden leichte/schwere Busse effektiv getrennt;

Jeder Webserver kann über DEC eine Verbindung zu allen Datenbanken herstellen und diese gleichzeitig in Master und Slave aufteilen.

Datenbankservergruppe:

Hält relativ ausgeglichenen Datenbank-Lese- und Schreibdruck bereit

Erreicht die Datensynchronisierung mehrerer Datenbanken durch die Zuordnung physischer Datenbankdateien.

Freigegebene Festplatte/Festplatten-Array

Wird für das einheitliche Lesen und Schreiben von physischen Datendateien verwendet.

Wird für die Speicherung großer Anhänge verwendet.

Gewährleistet die E/A-Effizienz und die Daten des Gesamtsystems durch Ausgewogenheit und Redundanz seine eigene physische Festplattensicherheit;

Merkmale der Lösung:

Angemessene Verteilung des Webdrucks durch Front-End-Lastausgleich

Angemessene Verteilung von leichten und schweren Datenflüssen; die Trennung von Datei-/Videoservern und regulären Webservern;

Verteilen Sie den Datenbank-IO-Druck angemessen über Datenbankservergruppen;

Jeder Webserver stellt normalerweise nur eine Verbindung zu einem Datenbankserver her und kann automatisch einschalten Durch die Heartbeat-Erkennung von DEC werden redundante Datenbankserver innerhalb kürzester Zeit erreicht.

Die Einführung von Festplatten-Arrays verbessert nicht nur die System-E/A-Effizienz erheblich, sondern erhöht auch die Datensicherheit erheblich.

Webserver:

Ein großer Teil der Ressourcennutzung des Webservers entsteht durch die Verarbeitung von Webanfragen. Dies ist der Druck, der von Apache erzeugt wird Verbindungen, Nginx ist Apache Eine gute Alternative zu Servern. Nginx („Engine x“) ist ein in Russland geschriebener Hochleistungs-HTTP- und Reverse-Proxy-Server. In China verwenden viele Websites und Kanäle wie Sina, Sohu Pass, NetEase News, NetEase Blog, Kingsoft Xiaoyao.com, Kingsoft iPowerWord, Xiaonei.com, YUPOO Photo Album, Douban, Xunlei Kankan usw. Nginx-Server.

Vorteile von Nginx:

Hohe gleichzeitige Verbindung: Der offizielle Test kann 50.000 gleichzeitige Verbindungen unterstützen, und in der tatsächlichen Produktionsumgebung erreicht die Anzahl gleichzeitiger Verbindungen 20.000 bis 30.000.

Geringer Speicherverbrauch: Unter 30.000 gleichzeitigen Verbindungen verbrauchen die 10 gestarteten Nginx-Prozesse nur 150 MB Speicher (15 MB * 10 = 150 MB).

Eingebaute Health-Check-Funktion: Wenn ein Webserver im Backend von Nginx Proxy ausfällt, ist der Front-End-Zugriff nicht beeinträchtigt.

Strategie: Im Vergleich zum alten Apache wählen wir Lighttpd und Nginx, Webserver mit geringerem Ressourcenverbrauch und höherer Lastkapazität.

MySQL:

Die MySQL-Optimierung selbst ist eine sehr komplizierte Aufgabe, da sie letztendlich ein gutes Verständnis der Systemoptimierung erfordert. Jeder weiß, dass die Datenbankarbeit eine große Anzahl kurzfristiger Abfragen, Lese- und Schreibvorgänge umfasst. Zusätzlich zu Softwareentwicklungstechniken wie der Indizierung und der Verbesserung der Abfrageeffizienz, auf die bei der Programmentwicklung geachtet werden muss, sind die Hauptauswirkungen auf die MySQL-Ausführungseffizienz Aus Sicht der Hardware kommt es auf die Festplattensuche, die Festplatten-IO-Level, die CPU-Zyklen und die Speicherbandbreite an.

Führen Sie eine MySQL-Optimierung entsprechend den Hardware- und Softwarebedingungen auf dem Server durch. Der Kern der MySQL-Optimierung liegt in der Zuweisung von Systemressourcen. Dies bedeutet nicht, dass MySQL unbegrenzt mehr Ressourcen zugewiesen werden muss. In der MySQL-Konfigurationsdatei führen wir einige der bemerkenswertesten Parameter ein:

Ändern Sie die Indexpufferlänge (key_buffer)

Ändern Sie die Tabellenlänge (read_buffer_size)

Einstellungen öffnen Die maximale Anzahl von Tabellen (table_cache)

Legen Sie ein Zeitlimit (long_query_time) für langsame lange Abfragen fest

Wenn die Bedingungen es zulassen, ist es im Allgemeinen am besten, den MySQL-Server im Linux-Betriebssystem zu installieren. und Nicht in FreeBSD installiert.
Strategie: Die MySQL-Optimierung erfordert die Formulierung verschiedener Optimierungspläne basierend auf den Datenbank-Lese- und Schreibeigenschaften des Geschäftssystems und der Server-Hardwarekonfiguration, und die Master-Slave-Struktur von MySQL kann nach Bedarf bereitgestellt werden.

PHP:

1. Laden Sie so wenige Module wie möglich.

2. Wenn es unter der Windows-Plattform läuft, versuchen Sie, IIS oder Nginx zu verwenden Verwenden Sie Apache;

3. Installieren Sie den Beschleuniger (beide verbessern die Ausführungsgeschwindigkeit von PHP-Code durch Zwischenspeichern von PHP-Code-Ergebnissen und Datenbankergebnissen)
eAccelerator, eAccelerator ist ein kostenloser und Open-Source-PHP-Beschleuniger, optimiert und dynamisch Inhalts-Caching verbessert die Caching-Leistung von PHP-Skripten, wodurch der Server-Overhead von PHP-Skripten im kompilierten Zustand fast vollständig eliminiert wird.

Apc: Alternative PHP Cache (APC) ist ein kostenloser und öffentlich optimierter Code-Cache für PHP. Es wird verwendet, um ein kostenloses, offenes und robustes Framework zum Zwischenspeichern und Optimieren von PHP-Zwischencode bereitzustellen.

Memcache: Memcache ist ein leistungsstarkes, verteiltes Speicherobjekt-Caching-System, das von Danga Interactive entwickelt wurde und dazu dient, die Datenbanklast zu reduzieren und die Zugriffsgeschwindigkeit in dynamischen Anwendungen zu verbessern. Der Hauptmechanismus besteht darin, eine einheitliche riesige Hash-Tabelle im Speicher zu verwalten, mit der Daten in verschiedenen Formaten gespeichert werden können, einschließlich Bildern, Videos, Dateien und Datenbanksuchergebnissen usw.

Xcache: von Chinesen entwickelt people Cache,

Strategie: Beschleuniger für PHP installieren.

Proxyserver (Cache-Server):

Squid Cache (als Squid bezeichnet) ist ein beliebter Proxyserver und Web-Caching-Server für freie Software (GNU General Public License). Squid hat ein breites Einsatzspektrum, von der Funktion als Front-End-Cache-Server für Webserver zur Erhöhung der Geschwindigkeit von Webservern durch Zwischenspeichern relevanter Anfragen bis hin zum Zwischenspeichern des World Wide Web, des Domain Name Systems und anderer Websuchen für eine Gruppe von Personen zur gemeinsamen Nutzung von Netzwerkressourcen, zur Unterstützung des Netzwerks durch Filterung des Datenverkehrs und zum LAN über ein Proxy-Netzwerk. Squid ist in erster Linie für die Ausführung auf Unix-ähnlichen Systemen konzipiert.

Strategie: Die Installation des Squid-Reverse-Proxy-Servers kann die Servereffizienz erheblich verbessern.

Stresstests: Stresstests sind ein grundlegendes Qualitätssicherungsverhalten, das Teil jedes wichtigen Softwaretests ist. Die Grundidee von Stresstests ist einfach: Anstatt manuelle oder automatisierte Tests unter normalen Bedingungen durchzuführen, führen Sie Tests unter Bedingungen durch, bei denen die Anzahl der Computer gering oder die Systemressourcen knapp sind. Zu den Ressourcen, die typischerweise einem Stresstest unterzogen werden, gehören der interne Speicher, die CPU-Verfügbarkeit, der Festplattenspeicher und die Netzwerkbandbreite. Parallelität wird im Allgemeinen für Stresstests verwendet.
Stresstest-Tools: Webbench, ApacheBench usw.

Schwachstellentests: Zu den Schwachstellen in unserem System gehören hauptsächlich: SQL-Injection-Schwachstellen, XSS-Cross-Site-Scripting-Angriffe usw. Sicherheit umfasst auch Systemsoftware, wie z. B. Schwachstellen im Betriebssystem, Schwachstellen in MySQL, Apache usw., die im Allgemeinen durch Upgrades behoben werden können.

Tool zum Testen von Sicherheitslücken: Acunetix Web Vulnerability Scanner

Kein verwandter Inhalt gefunden.