web端常用架構(gòu)？首先，單數(shù)據(jù)庫(kù)架構(gòu)單DB架構(gòu)一般是nginx直接請(qǐng)求上游到后端Tomcat。擴(kuò)容的時(shí)候基本就是添加新的Tomcat實(shí)例，然后通過(guò)Ngin衡上游。這個(gè)時(shí)候數(shù)據(jù)庫(kù)不是瓶頸，但是當(dāng)訪問(wèn)量達(dá)

web端常用架構(gòu)？

首先，單數(shù)據(jù)庫(kù)架構(gòu)

單DB架構(gòu)一般是nginx直接請(qǐng)求上游到后端Tomcat。擴(kuò)容的時(shí)候基本就是添加新的Tomcat實(shí)例，然后通過(guò)Ngin衡上游。這個(gè)時(shí)候數(shù)據(jù)庫(kù)不是瓶頸，但是當(dāng)訪問(wèn)量達(dá)到一定程度的時(shí)候，過(guò)了關(guān)卡，數(shù)據(jù)庫(kù)的壓力就上來(lái)了，單個(gè)數(shù)據(jù)庫(kù)可能承受不了?？梢酝ㄟ^(guò)劃分表和數(shù)據(jù)庫(kù)或者讀寫(xiě)分離、添加緩存來(lái)解決。

二、DB緩存/數(shù)據(jù)庫(kù)讀寫(xiě)分離架構(gòu)

這時(shí)就用數(shù)據(jù)庫(kù)讀寫(xiě)分離或者Redis緩存來(lái)支持更多的訪問(wèn)。但是使用緩存會(huì)與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致，或者Redis無(wú)法直接命中數(shù)據(jù)庫(kù)，造成數(shù)據(jù)庫(kù)壓力過(guò)大?？梢钥紤]使用Redis的主從或者使用?；谝恢鹿Ｋ惴ǖ腞edis聚類(lèi)。使用這種緩存架構(gòu)，應(yīng)用程序?qū)?shù)據(jù)一致性的要求不是很高。

三、OpenResty本地Redis Mysql集群架構(gòu)

OpenResty首先通過(guò)Lua讀取本地Redis緩存。如果失敗，它返回到后端Tomcat集群，后端Tomcat集群讀取Mysql數(shù)據(jù)庫(kù)。Redis和OpenResty安裝在同一個(gè)服務(wù)器上。OpenResty可以通過(guò)直接從本機(jī)讀取來(lái)減少網(wǎng)絡(luò)延遲。Redis通過(guò)主從模式同步數(shù)據(jù)。

四。OpenResty Redis集群的Mysql集群架構(gòu)

此時(shí)的架構(gòu)與之前的架構(gòu)不同。此時(shí)我們使用一致哈希算法實(shí)現(xiàn)Redis集群，而不是讀取本地Redis，這樣可以保證當(dāng)其中一個(gè)不可用時(shí)，只丟失一點(diǎn)點(diǎn)數(shù)據(jù)，防止其滲透到數(shù)據(jù)庫(kù)中。Redis集群分片可以使用Twemp。Roxy如果Tomcat實(shí)例很多，就要考慮Redis和Mysql之間的鏈接數(shù)量，因?yàn)榇蟛糠諶edis/Mysql客戶(hù)端都是通過(guò)連接池實(shí)現(xiàn)的，這個(gè)時(shí)候鏈接數(shù)量就會(huì)成為瓶頸。一般的方法是通過(guò)中間件減少環(huán)節(jié)。

這時(shí)候的問(wèn)題是Twemproxy的實(shí)例比較多，應(yīng)用的維護(hù)和配置比較困難，需要平衡其上的負(fù)債。例如，通過(guò)LVS/HaProxy實(shí)現(xiàn)VIp(虛擬Ip ),切換可以對(duì)應(yīng)用透明，故障可以自動(dòng)轉(zhuǎn)移。你也可以實(shí)現(xiàn)一個(gè)內(nèi)部網(wǎng)DNS做它的負(fù)載平衡。

RabbitMQ如何通過(guò)持久化保證消息99.99%不丟失？

在單個(gè)服務(wù)器的情況下，如果打開(kāi)了消息持久性并且客戶(hù)端采用確認(rèn)模式，它仍然可能會(huì)丟失。這是因?yàn)橹髟O(shè)備在接收到消息并將其存儲(chǔ)在文件中后，會(huì)向客戶(hù)端發(fā)送ack。關(guān)鍵問(wèn)題是它存儲(chǔ)在一個(gè)文件中，只寫(xiě)入磁盤(pán)緩存，需要執(zhí)行。行fsync實(shí)際上將被寫(xiě)入磁盤(pán)。如果它在fsync之前關(guān)閉，消息仍然會(huì)丟失。如果你寫(xiě)文件時(shí)立即設(shè)置fsync，你就贏了 不會(huì)丟失消息，但是性能會(huì)差很多倍。

在集群的情況下，將ha-mode設(shè)置為all，所有鏡像節(jié)點(diǎn)同步到消息，然后主節(jié)點(diǎn)將響應(yīng)ack到客戶(hù)端。然后，包括主節(jié)點(diǎn)在內(nèi)的所有節(jié)點(diǎn)需要同時(shí)停機(jī)，因此有可能丟失消息。所以原因只有一個(gè)。在丟失的消息上，可靠性達(dá)到99.999。...