一,redis正則表達式
RDB持久化方式會在一個特定的間隔保存那個時間點的一個數據快照redis
爲防止數據丟失,須要將 Redis 中的數據從內存中 dump 到磁盤,這就是持久化。Redis 提供兩種持久化方式:RDB 和 AOF。Redis 容許二者結合,也容許二者同時關閉。數組
RDB 能夠定時備分內存中的數據集。服務器啓動的時候,能夠從 RDB 文件中恢復數據集。tomcat
AOF(append only file) 能夠記錄服務器的全部寫操做。在服務器從新啓動的時候,會把全部的寫操做從新執行一遍,從而實現數據備份。當寫操做集過大(比原有的數據集還大),Redis 會重寫寫操做集服務器
rdb 優勢app
RDB的性能很好,須要進行持久化時,主進程會fork一個子進程出來,而後把持久化的工做交給子進程,本身不會有相關的I/O操做。ide
比起AOF,在數據量比較大的狀況下,RDB的啓動速度更快工具
缺點性能
RDB容易形成數據的丟失。假設每5分鐘保存一次快照,若是Redis由於某些緣由不能正常工做,那麼從上次產生快照到Redis出現問題這段時間的數據就會丟失了spa
快照並非很可靠。若是你的電腦忽然宕機了,或者電源斷了,又或者不當心殺掉了進程,那麼最新的數據就會丟失。而AOF文件則提供了一種更爲可靠的持久化方式。每當Redis接受到會修改數據集的命令時,就會把命令追加到AOF文件裏,當你重啓Redis時,AOF裏的命令會被從新執行一次,重建數據。
優勢
AOF日誌文件是一個純追加的文件。就算是遇到忽然停電的狀況,也不會出現日誌的定位或者損壞問題。甚至若是由於某些緣由(例如磁盤滿了)命令只寫了一半到日誌文件裏,咱們也能夠用redis-check-aof
這個工具很簡單的進行修復。
缺點
在某些fsync策略下,AOF的速度會比RDB慢。一般fsync設置爲每秒一次就能得到比較高的性能
二,rabbitmq
RabbitMQ主要是爲了實現系統之間的雙向解耦而實現的。當生產者大量產生數據時,消費者沒法快速消費,那麼須要一箇中間層。保存這個數據
RabbitMQ的Vhost主要是用來劃分不一樣業務模塊。不一樣業務模塊之間沒有信息交互。
Vhost之間相互徹底隔離,不一樣Vhost之間沒法共享Exchange和Queue。所以Vhost之間數據沒法共享和分享。若是要實現這種功能,須要Vhost之間手動構建對應代碼邏輯。
vhosts 主要用於用戶、
幾個概念說明:
1. Broker:簡單來講就是消息隊列服務器實體。
2. Exchange:消息交換機,它指定消息按什麼規則,路由到哪一個隊列。
3. Queue:消息隊列載體,每一個消息都會被投入到一個或多個隊列。
4. Binding:綁定,它的做用就是把exchange和queue按照路由規則綁定起來。
5. Routing Key:路由關鍵字,exchange根據這個關鍵字進行消息投遞。
6. vhost:虛擬主機,一個broker裏能夠開設多個vhost,用做不一樣用戶的權限分離。
7. producer:消息生產者,就是投遞消息的程序。
8. consumer:消息消費者,就是接受消息的程序。
9. channel:消息通道,在客戶端的每一個鏈接裏,可創建多個channel,每一個channel表明一個會話任務。
消息隊列的使用過程大概以下:
1. 客戶端鏈接到消息隊列服務器,打開一個channel。
2. 客戶端聲明一個exchange,並設置相關屬性。
3. 客戶端聲明一個queue,並設置相關屬性。
4. 客戶端使用routing key,在exchange和queue之間創建好綁定關係。
5. 客戶端投遞消息到exchange。
6. exchange接收到消息後,就根據消息的key和已經設置的binding,進行消息路由,將消息投遞到一個或多個隊列裏。
a)若是是Direct類型,則會將消息中的RoutingKey與該Exchange關聯的全部Binding中的BindingKey進行比較,若是相等,則發送到該Binding對應的Queue中。
b)若是是Fanout類型,則會將消息發送給全部與該 Exchange定義過Binding 的全部Queues中去,實際上是一種廣播行爲。
c)若是是Topic類型,則會按照正則表達式,對RoutingKey與BindingKey進行匹配,若是匹配成功,則發送到對應的Queue中。(符號」#」匹配一個或多個詞,符號」*」匹配正好一個詞)
詳細解釋:
Exchange可能bind了不少Queue,可是消息具體分到哪個或哪一些Q呢?具體要看exchange的類型。
具體exchange也有幾個類型:
一、徹底根據key進行投遞的叫作Direct交換機,例如,綁定時設置了routingkey爲」abc」,那麼客戶端提交的消息,只有設置了key爲」abc」的纔會投遞到隊列。
二、對key進行模式匹配後進行投遞的叫作Topic交換機,符號」#」匹配一個或多個詞,符號」*」匹配正好一個詞。例如」abc.#」匹配」abc.def.ghi」,」abc.*」只匹配」abc.def」。
三、還有一種不須要key的,叫作Fanout交換機,它採起廣播模式,一個消息進來時,投遞到與該交換機綁定的全部隊列。
HA
鏡像模式:把須要的隊列作成鏡像隊列,存在於多個節點,屬於rabbitMQ的HA方案。該模式解決了上述問題,其實質和普通模式不一樣之處在於,消息實體會主動在鏡像節點間同步,而不是在consumer取數據時臨時拉取
集羣中有兩種節點:
內存節點:只保存狀態到內存(一個例外的狀況是:持久的queue的持久內容將被保存到disk)
磁盤節點:保存狀態到內存和磁盤。內存節點雖然不寫入磁盤,可是它執行比磁盤節點要好。集羣中,只須要一個磁盤節點來保存狀態 就足夠了 若是集羣中只有內存節點,那麼不能中止它們,不然全部的狀態,消息等都會丟失。
三,graphite
四,zabbix
五,tengine
六,haproxy
七,keepalived
八,ansible
九,saltstack
十,tomcat
VM內存模型
1.1 Java棧
Java棧是與每個線程關聯的,JVM在建立每個線程的時候,會分配必定的棧空間給線程。它主要用來存儲線程執行過程當中的局部變量,方法的返回值,以及方法調用上下文。棧空間隨着線程的終止而釋放。StackOverflowError:若是在線程執行的過程當中,棧空間不夠用,那麼JVM就會拋出此異常,這種狀況通常是死遞歸形成的。
1.2 堆
Java中堆是由全部的線程共享的一塊內存區域,堆用來保存各類JAVA對象,好比數組,線程對象等
heap
它是JVM用來存儲對象實例以及數組值的區域,能夠認爲Java中全部經過new建立的對象的內存都在此分配,Heap中的對象的內存須要等待GC進行回收
JVM垃圾回收
GC (Garbage Collection)的基本原理:將內存中再也不被使用的對象進行回收,GC中用於回收的方法稱爲收集器,因爲GC須要消耗一些資源和時間,Java在對對象的生命週期特徵進行分析後,按照新生代、舊生代的方式來對對象進行收集,以儘量的縮短GC對應用形成的暫停
(1)對新生代的對象的收集稱爲minor GC;
(2)對舊生代的對象的收集稱爲Full GC;
(3)程序中主動調用System.gc()強制執行的GC爲Full GC。
因爲GC須要消耗一些資源和時間的,Java在對對象的生命週期特徵進行分析後,採用了分代
的方式來進行對象的收集,即按照新生代、舊生代的方式來對對象進行收集,以儘量的縮短GC對應用形成的暫停.
新生代 Young Generation
Eden Space 任何新進入運行時數據區域的實例都會存放在此
S0 Suvivor Space 存在時間較長,通過垃圾回收沒有被清除的實例,就從Eden 搬到了S0
S1 Survivor Space 同理,存在時間更長的實例,就從S0 搬到了S1
舊生代 Old Generation/tenured
同理,存在時間更長的實例,對象屢次回收沒被清除,就從S1 搬到了tenure
十一,打包
十二,kvm