04 redis中的發布與訂閱模式用于(大型的 PHP應用 通常使用什么應用做 消息隊列 的)

1. 為什么要有哨兵機制？

原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，并通知應用方，實現高可用性。

其實整個過程只需要一個哨兵節點來完成，首先使用Raft算法（選舉算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知

任務1：每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，并當有新的從節點加入時可以馬上感知到

任務2：每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對于主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的

任務3：每隔1秒每個哨兵會向主節點、從節點及其余哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據

客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（選舉）個數，此時哨兵節點則認為該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線

a)每個在線的哨兵節點都可以成為領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，征求判斷并要求將自己設置為領導者，由領導者處理故障轉移；

b)當其它哨兵收到此命令時，可以同意或者拒絕它成為領導者；

redis sentinel的機制與用法一： 買粉絲s://segmentfault.買粉絲/a/1190000002680804

redis sentinel的機制與用法二： 買粉絲s://segmentfault.買粉絲/a/1190000002685515

redis和memcached的區別

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。

2 Redis支持數據的備份，即master-slave模式的數據備份。

3 Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。

在Redis中，并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別（我個人是這么認為的）。

Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據“swappability = age*log(size_in_memory)”計算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。

同時由于Redis將內存中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作后才可以進行修改。

可以參考使用Redis特有內存模型前后的情況對比：

VM off: 300k keys, 4096 bytes values: 1.3G used

VM on: 300k keys, 4096 bytes values: 73M used

VM off: 1 million keys, 256 bytes values: 430.12M used

VM on: 1 million keys, 256 bytes values: 160.09M used

VM on: 1 million keys, values as large as you want, still: 160.09M used

當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數據，然后再返回給請求方。這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中加載相應數據的讀取請求進行并發操作，減少阻塞的時間。

redis、memcache、mongoDB 對比

從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚

1、性能

都比較高，性能對我們來說應該都不是瓶頸

總體來講，TPS方面redis和memcache差不多，要大于mongodb

2、操作的便利性

memcache數據結構單一

redis豐富一些，數據操作方面，redis更好一些，較少的網絡IO次數

mongodb支持豐富的數據表達，索引，最類似關系型數據庫，支持的查詢語言非常豐富

3、內存空間的大小和數據量的大小

redis在2.0版本后增加了自己的VM特性，突破物理內存的限制；可以對key value設置過期時間（類似memcache）

memcache可以修改最大可用內存,采用LRU算法

mongoDB適合大數據量的存儲，依賴操作系統VM做內存管理，吃內存也比較厲害，服務不要和別的服務在一起

4、可用性（單點問題）

對于單點問題，

redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整個快照,無增量復制，因性能和效率問題，

所以單點問題比較復雜；不支持自動sharding,需要依賴程序設定一致hash 機制。

一種替代方案是，不用redis本身的復制機制，采用自己做主動復制（多份存儲），或者改成增量復制的方式（需要自己實現），一致性問題和性能的權衡

Memcache本身沒有數據冗余機制，也沒必要；對于故障預防，采用依賴成熟的hash或者環狀的算法，解決單點故障引起的抖動問題。

mongoDB支持master-slave,replicaset（內部采用paxos選舉算法，自動故障恢復）,買粉絲 sharding機制，對客戶端屏蔽了故障轉移和切分機制。

5、可靠性（持久化）

對于數據持久化和數據恢復，

redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響

memcache不支持，通常用在做緩存,提升性能；

MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性

6、數據一致性（事務支持）

Memcache 在并發場景下，用cas保證一致性

redis事務支持比較弱，只能保證事務中的每個操作連續執行

mongoDB不支持事務

7、數據分析

mongoDB內置了數據分析的功能(maprece),其他不支持

8、應用場景

redis：數據量較小的更性能操作和運算上

memcache：用于在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫少，對于數據量比較大，可以采用sharding）

MongoDB:主要解決海量數據的訪問效率問題

很赞哦!（1）