RabbitMQ進階筆記
專注於java。分享java基礎、原理性知識、JavaWeb實戰、spring全家桶、設計模式及面試資料、開源專案，助力開發者成長！
最近小林在求職面試中被詢問了這麼一個有趣的面試題：
假設當我們需要在一千萬個整數（整數的範圍在1-1億之間）裡面快速查詢某個整數是否存在於其中的話，如何快速查詢進行判斷會比較方便呢？
ps: int 型別的資料儲存的時候是會佔用四個位元組空間，假設儲存的資料範圍在1-1億之間，那麼資料儲存的時候大概佔用空間為：100 * 100 * 1000 * 4 byte 大概儲存空間大小消耗為 ：40000 kb 40mb左右。
1.散列表結構方案
通過散列表來實現該功能當然是可以的，但是散列表裡面除了需要儲存對應的數字以外，還需要儲存對應的連結串列指標，每個數字都採用int型別來進行儲存的話，光是數字佔用的記憶體大小大概是40mb左右，如果是加上了指標的儲存空間的話，那麼儲存的記憶體大小大概是80mb左右了。
2.布林陣列結構方案
通過使用不同型別的陣列來進行儲存。首先建立一個一千萬長度的布林型別陣列，然後根據整數，定位到相應的下標賦值true，那麼以後在遍歷的時候，根據相應的下標查詢到指定的變數，如果該變數的值是true的話，那麼就證明該數字存在。
布林型別變數在儲存的時候只有true和false存在，但是在陣列中儲存的時候實際上是佔用了1個位元組，該型別的變數在被編譯之後實際上是以int型別的資料0000 0000和0000 0001儲存的，因此還是佔用了較多的記憶體空間。
3.使用bitmap來進行儲存
例如說一個長度是10的bitmap，每一個bit位都儲存著對應的0到9的十個整形數字，此時每個bitmap所對應的位都是0。當我們存入的數字是3的時候，位於3的位置會變為1。
當我們儲存了多個數字的時候，例如說儲存了4,3,2,1的時候，那麼點陣圖結構就會如下所示：
那麼這個時候你可能就會疑惑了，到底在程式碼上邊該如何通過計算來獲取一個數字的索引定位呢？
首先我們將核心思路的程式碼先貼上來：
publicvoidset(intnumber){
//相當於對一個數字進行右移動3位，相當於除以8
intindex=number>>3;
//相當於number%8獲取到byte[index]的位置
intposition=number&0x07;
//進行|或運算參加運算的兩個物件只要有一個為1，其值為1。
bytes[index]|=1<<position;
}
為了方便理解核心思想，所以還是通過圖例來理解會比較好：
例如說往bitmap裡面儲存一個數字11，那麼首先需要通過向右移位（因為一個byte相當於8個bit），計算出所儲存的byte[]陣列的索引定位，這裡計算出index是1。由於一個byte裡面儲存了八個bit位，所以通過求餘的運算來計算postion，算出來為3。
這裡假設原有的bitmap裡面儲存了4和12這2個數字，那麼它的結構如下所示：
這個時候，我們需要儲存11進來，那麼就需要進行或運算了：
同理，當我們判斷數字是否存在的時候，也需要進行相應的判斷，程式碼如下：
publicbooleancontain(intnumber){
intindex=number>>3;
intposition=number&0x07;
return(bytes[index]&(1<<position))!=0;
}
整合一下，簡單版的一個bitmap程式碼如下：
publicclassMyBitMap{
privatebyte[]bytes;
privateintinitSize;
publicMyBitMap(intsize){
if(size<=0){
return;
}
initSize=size/(8)+1;
bytes=newbyte[initSize];
}
publicvoidset(intnumber){
//相當於對一個數字進行右移動3位，相當於除以8
intindex=number>>3;
//相當於number%8獲取到byte[index]的位置
intposition=number&0x07;
//進行|或運算參加運算的兩個物件只要有一個為1，其值為1。
bytes[index]|=1<<position;
}
publicbooleancontain(intnumber){
intindex=number>>3;
intposition=number&0x07;
return(bytes[index]&(1<<position))!=0;
}
publicstaticvoidmain(String[]args){
MyBitMapmyBitMap=newMyBitMap(32);
myBitMap.set(30);
myBitMap.set(13);
myBitMap.set(24);
System.out.println(myBitMap.contain(2));
}
}
從剛剛點陣圖結構的講解中，你應該可以發現，點陣圖通過陣列下標來定位資料，所以，訪問效率非常高。而且，每個數字用一個二進位制位來表示，在數字範圍不大的情況下，所需要的記憶體空間非常節省。
比如剛剛那個例子，如果用散列表儲存這 1 千萬的資料，資料是 32 位的整型數，也就是需要 4 個位元組的儲存空間，那總共至少需要 40MB 的儲存空間。如果我們通過點陣圖的話，數字範圍在 1 到 1 億之間，只需要 1 億個二進位制位，也就是 12MB 左右的儲存空間就夠了。
但是實際應用中，卻並非如我們所想象的那麼簡單，假設我們的實際場景進行改變一下：
還是剛剛的那個情況：
還是一千萬個數字，但是數字範圍不是 1 到 1 億，而是 1 到 10 億，那點陣圖的大小就是 10 億個二進位制位，也就是 120MB 的大小，消耗的記憶體空間反而更加大了，而且在bitmap裡面還會有部分空間浪費的情況存在。
假設我們對每一個數字都進行一次hash計算，然後通過hash將計算後的結果範圍限制在1千萬裡面，那麼就不需要再定義10億個二進位制位了。
但是這樣子還是會有相應的弊端，例如說hash衝突。那麼這個時候如果我們採用多個hash函式來進行處理的話，理論上是可以大大降低衝突的概率的。於是就有了下邊所說的布隆過濾器一說。
布隆過濾器
布隆過濾器通過使用多次的hash計算來進行數值是否存在的判斷，雖然大大降低了hash衝突的情況，但是還是存在一定的缺陷，那就是容易會有誤判的情況。例如說如下如所示：
布隆過濾器的誤判有一個特點，那就是，它只會對存在的情況有誤判。如果某個數字經過布隆過濾器判斷不存在，那說明這個數字真的不存在，不會發生誤判；如果某個數字經過布隆過濾器判斷存在，這個時候才會有可能誤判，有可能並不存在。
不過，只要我們調整雜湊函式的個數、點陣圖大小跟要儲存數字的個數之間的比例，那就可以將這種誤判的概率降到非常低。
那麼該怎麼調整這個點陣圖大小和儲存數字之間的比例呢？
這裡可能就需要用到一些數學公式來進行計算了。
在位陣列長度m的BF中插入一個元素，相應的位可能會被標誌為1。所以說，在插入元素後，該位元仍然為0的概率是：
現有k個雜湊函式，並插入n個元素，自然就可以得到該位元仍然為0的概率是：
反過來講，它已經被置為1的概率就是：
也就是說，如果在插入n個元素後，我們用一個不在集合中的元素來檢測，那麼被誤報為存在於集合中的概率（也就是所有雜湊函式對應的位元都為1的概率）為：
當n比較大時，在查詢了相關資料之後，可以近似得出誤判率的公式大致如下：（本人數學不是太好，這段公式是請教其他大佬得出的）
所以，在雜湊函式的個數k一定的情況下：
- 位陣列長度m越大，誤判率越低；
- 已插入元素的個數n越大，誤判率越高。
儘管說布隆過濾器在使用的時候會有誤判的情況發生，但是在對於資料的準確性有一定容忍度的情況下，使用布隆過濾器還是會比較推薦的。
在實際的專案應用中，布隆過濾器經常會被用在一些大規模去重，但又允許有小概率誤差的場景中，例如說我們對一組爬蟲網頁地址的去重操作，或者統計某些大型網站每天的使用者訪問數量（需要對相同使用者的多次訪問進行去重）。
實際上，關於bitmap和布隆過濾器這類工具在大型網際網路企業上已經受到了廣泛使用，例如說java裡面提供了BitSet類，Redis也提供了相應的點陣圖類，Google裡面的guava工具包中的BloomFilter也已經實現類布隆過濾器，所以在實際應用的時候只需要直接使用這些現有的元件即可，避免重複造輪子的情況發生。
4.Redis提供的BitMap
在redis裡有一個叫做bitmap的資料結構，使用技巧如下：
setbit指令
語法：setbit key offset value 127.0.0.1:6379>setbitbitmap-019990 (integer)0 127.0.0.1:6379>setbitbitmap-019991 (integer)0 127.0.0.1:6379>setbitbitmap-0110031 (integer)0 127.0.0.1:6379>setbitbitmap-0110030 (integer)1 127.0.0.1:6379>setbitbitmap-0110040 (integer)0
注意：
1.offset 引數必須大於或等於0，小於 2^32 (bit 對映被限制在 512 MB 之內)。
2.因為 Redis 字串的大小被限制在 512 兆(megabytes)以內， 所以使用者能夠使用的最大偏移量為 2^29-1(536870911) ， 如果你需要使用比這更大的空間， 請使用多個 key。
3.當生成一個很長的字串時， Redis 需要分配記憶體空間， 該操作有時候可能會造成伺服器阻塞(block)。在2010年出產的Macbook Pro上， 設定偏移量為 536870911(512MB 記憶體分配)將耗費約 300 毫秒， 設定偏移量為 134217728(128MB 記憶體分配)將耗費約 80 毫秒， 設定偏移量 33554432(32MB 記憶體分配)將耗費約 30 毫秒， 設定偏移量為 8388608(8MB 記憶體分配)將耗費約 8 毫秒。
getbit指令
語法：getbit key offset
返回值：
127.0.0.1:6379>setbitbm01 (integer)0 127.0.0.1:6379>getbitbm0 (integer)1
bitcount指令
語法：bitcount key [start] [end] ，這裡的start和end值為可選項
返回值：被設定為 1 的位的數量
127.0.0.1:6379>bitcountuser18 (integer)4
bitop指令
語法：bitop operation destkey key [key ...]
operation 可以是 AND 、 OR 、 NOT 、 XOR 這四種操作中的任意一種：
BITOP AND destkey key [key ...]，對一個或多個 key 求邏輯並，並將結果儲存到 destkey 。 BITOP OR destkey key [key ...]，對一個或多個 key 求邏輯或，並將結果儲存到 destkey 。 BITOP XOR destkey key [key ...]，對一個或多個 key 求邏輯異或，並將結果儲存到 destkey 。 BITOP NOT destkey key ，對給定 key 求邏輯非，並將結果儲存到 destkey 。
實戰案例
統計某個使用者在xx論壇的簽到次數，這裡假設使用者的id為u18
127.0.0.1:6379>setbituser1811 (integer)0 127.0.0.1:6379>setbituser1821 (integer)0 127.0.0.1:6379>setbituser1851 (integer)0 127.0.0.1:6379>setbituser18151 (integer)0 127.0.0.1:6379>bitcountuser18 (integer)4
通過使用bitcount指令可以快速從redis中計算出user18的簽到天數。
( ps:但是如果要計算出連續簽到的天數，或者記錄更多的簽到資訊，並且考慮上資料儲存的可靠穩定性，那麼此時bitmap就不太適用了，這裡我只是模擬了一個案例供大家學習這條指令的使用。)
按天統計網站活躍使用者
設計思路，用天來作為統計的key，然後以使用者ID作為Offset，一旦使用者登入訪問網站，則根據其使用者id計算出對應的offset並且將其設定為1。
//2020年10月21日使用者11034訪問網站 127.0.0.1:6379>setbit20201021110341 (integer)0 //2020年10月21日使用者11089訪問網站 127.0.0.1:6379>setbit20201021110891 (integer)0 //2020年10月21日使用者11034訪問網站 127.0.0.1:6379>setbit20201022110341 (integer)0 //2020年10月21日使用者11032訪問網站 127.0.0.1:6379>setbit20201023110321 (integer)0 //通過使用bitopor做多個集合的交集運算，計算出2020年10月21日至2020年10月22日 //內連續登入的使用者id，並且將其放入到名為active_user的bitmap中 127.0.0.1:6379>bitoporactive_user2020102120201022 (integer)1387 //提取活躍使用者資訊 127.0.0.1:6379>bitcountactive_user (integer)2 127.0.0.1:6379>
使用者線上狀態、線上人數統計
//模擬使用者98321訪問系統 127.0.0.1:6379>setbitonline_member983211 (integer)0 127.0.0.1:6379>setbitonline_member132841 (integer)0 127.0.0.1:6379>setbitonline_member8345211 (integer)0 127.0.0.1:6379>bitcountonline_member (integer)3 //模擬使用者13284離開系統，線上人數減1 127.0.0.1:6379>setbitonline_member132840 (integer)1 127.0.0.1:6379>bitcountonline_member (integer)2 127.0.0.1:6379>
這段指令案例將會員id作為來offset位置，存入到來bitmap中，通過設定相應到bitmap，當有對應會員登入訪問的時候，對應offset位置則置為1，最後通過bitcount來統計該bitmap中有多少個項為1，從而計算出使用者線上的人數。
Guava提供的布隆過濾器
對應的依賴：
<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>22.0</version> </dependency>
引入相關的依賴之後，可以通過編寫一個簡單的案例來理解guava裡面提供的布隆過濾器元件：
packageorg.idea.guava.filter;
importcom.google.common.hash.BloomFilter;
importcom.google.common.hash.Funnels;
/**
*@authoridea
*@datecreatedin11:05上午2020/10/25
*/
publicclassGuavaBloomFilter{
publicstaticvoidmain(String[]args){
//建立布隆過濾器時要傳入期望處理的元素數量，及最期望的誤報的概率。
BloomFilter<Integer>bloomFilter=BloomFilter.create(
Funnels.integerFunnel(),
100,//希望儲存的元素個數
0.01//希望誤報的概率
);
bloomFilter.put(1);
bloomFilter.put(2);
bloomFilter.put(3);
bloomFilter.put(4);
bloomFilter.put(5);
//判斷過濾器內部是否存在對應的元素
System.out.println(bloomFilter.mightContain(1));
System.out.println(bloomFilter.mightContain(2));
System.out.println(bloomFilter.mightContain(1000));
}
}
這段程式碼中你可能會疑惑，為什麼是mightContain而不是contain呢？
這一點其實和布隆過濾器本身的誤判機制有關。
布隆過濾器常用的場景為：
對於一些快取穿透的場景可以用於作為預防手段。
本身的優點：
儲存空間消耗較少。
時間效率高，查詢和插入的時間複雜度均為O(h)。（h為hash函式的個數）
缺點：
查詢元素是否存在的概率不能保證100%準確，會有部分誤判的情況存在。
只能插入和查詢元素，不允許進行刪除操作。
來源：https://mp.weixin.qq.com/s/tMomFS1jvuF86m-yrOR9dw