web端常用架構？首先，單數(shù)據(jù)庫架構單DB架構一般是nginx直接請求上游到后端Tomcat。擴容的時候基本就是添加新的Tomcat實例，然后通過Ngin衡上游。這個時候數(shù)據(jù)庫不是瓶頸，但是當訪問量達

web端常用架構？

首先，單數(shù)據(jù)庫架構

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

二、DB緩存/數(shù)據(jù)庫讀寫分離架構

這時就用數(shù)據(jù)庫讀寫分離或者Redis緩存來支持更多的訪問。但是使用緩存會與數(shù)據(jù)庫數(shù)據(jù)不一致，或者Redis無法直接命中數(shù)據(jù)庫，造成數(shù)據(jù)庫壓力過大?？梢钥紤]使用Redis的主從或者使用。基于一致哈希算法的Redis聚類。使用這種緩存架構，應用程序?qū)?shù)據(jù)一致性的要求不是很高。

三、OpenResty本地Redis Mysql集群架構

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

四。OpenResty Redis集群的Mysql集群架構

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

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

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

在單個服務器的情況下，如果打開了消息持久性并且客戶端采用確認模式，它仍然可能會丟失。這是因為主設備在接收到消息并將其存儲在文件中后，會向客戶端發(fā)送ack。關鍵問題是它存儲在一個文件中，只寫入磁盤緩存，需要執(zhí)行。行fsync實際上將被寫入磁盤。如果它在fsync之前關閉，消息仍然會丟失。如果你寫文件時立即設置fsync，你就贏了 不會丟失消息，但是性能會差很多倍。

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