- 布隆過濾器
bloom filter:判斷是否存在(用戶只能參加一次活動)
原理:
1.向布隆過濾器中添加 key 時，會使用多個 hash 函數對 key 進行 hash
運算,然後對位數組長度進行取模運算得到一個位置，這樣添加一個key會在多個位加1。
2. 向布隆過濾器詢問 key 是否存在時，跟 add 一樣，也會把 hash 的幾個位置都算出來，看看位數組中這幾個位置是否都爲 1，只要有一個位爲 0，那麼說明布隆過濾器中這個 key 不存在
總結:有點類似聯合國常任理事國的一票否決權
zookeeper等分佈式中的選舉策略有類似想法
- HyperLogLog
HyperLogLog:統計海量去重元素數量(統計頁面uv):
原理:限於個人表述能力,你可能需要先理解下文中的思考,才能理解其原理
16384個桶(16*1024),當一個元素到來時，它會散列(hash)到其中一個桶,每個桶佔6bit.
思考:一個隨機的整數值，這個整數的尾部有一個 0 的概率是 50%，要麼是 0 要麼是 1。同樣，尾部有兩個 0 的概率是 25%，有三個零的概率是 12.5%，以此類推，有 k 個 0 的概率是 2^(-k)。
如果我們隨機出了很多整數，整數的數量我們並不知道(前提)，但是我們記錄了整數尾部連續 0 的最大數量 K(分析整數[重在分析而不是存儲],記錄已存在的尾部聯續0的最大位數)。我們就可以通過這個 K 來近似推斷出整數的數量，這個數量就是 2^K
實際還需要加入各種因子,思路是:每個桶中使用概率論倒退出元素數而不存儲實際的元素
- 位圖
位圖:大量是否的統計(某用戶一年365天的簽到情況)
常用命令:bitcount(使用中注意是以8爲最小單位進行的,對周,月,年統計需要在代碼中增加邏輯)
- Stream
Stream:支持多播的可持久化的消息隊列()[5.0版本]
在此之前可使用:
消息隊列(不支持多播):借用list/zset(消息權重)結構使用lpush/rpop等實現,但是實際使用中需要考慮消費端輪詢機制和(爲了可用性已多個線程去取,防止線程掛掉消息傳遞就斷開的情況)多線程搶佔情況,而且無法保證消息的100%準確(丟失,取錯)
PubSub(不支持持久化):PubSub 的生產者傳遞過來一個消息，Redis 會直接找到相應的消費者傳遞過去。如果一個消費者都沒有，那麼消息直接丟棄。如果開始有三個消費者，一個消費者突然掛掉了，生產者會繼續發送消息，另外兩個消費者可以持續收到消息。但是掛掉的消費者重新連上的時候，這斷連期間生產者發送的消息,宕機期間的消息也不會持久化(很少使用)
試探究mq,kafka中對消息傳遞問題的解決方式?
試總結redis中的設計之美?
如何理解redis的單線程模型?