注意點就是。。盡量不使用bitmap
最近在做的一個項目，因為某個活動用戶只能參與一次，一開始使用了redis的bitmap，想到bitmap每一位都可以存儲一個會員id，這樣只用1百兆就可以存快9億個會員id，看似很美的做法。
但其實這樣會有幾個嚴重的問題，
- redis的bitmap並不會壓縮，也就是說即使活動參加的人只有一個，但這個會員id如果很大，那偏移量就會非常高，那么可能就這一個會員id就會占用幾百M的內存
- bitmap的最大偏移量為2^32次方，但大多數系統會員id的類型都為long類型，也就是int64，所以一旦會員id超過了這個偏移量上限，那系統判定就會出錯。(很多人會覺得自己系統哪有這么多用戶，但是想下萬一公司有什么靚號之類的。。。我就是被這個坑了)
- 單一實例操作，因為key固定的，所以bitmap並存儲的內容不會分散到集群上，而是固定一個實例上存儲，如果是集群模式，數據都存一個實例，且所有的對這個bitmap的操作redis請求全部打到一台實例上，尤其是這種判斷是否參與過的程序往往都在程序的首要部分，並發度非常高。導致單一實例負載過高，redis集群失去作用
總結：redis的key最好和會員id綁定，這樣可以保證redis集群的請求散列度高，負載均衡。最好不使用bitmap，如果使用最好是每個memberId對應一個bitmap，並且存的數據是從小到大升序上漲的。同理使用list，set，sortset，map之類里面的數據量不要太大，因為數據量多，而數據量也不能被分散，會導致集群的實例之間數據量不均勻