注意点就是。。尽量不使用bitmap
最近在做的一个项目，因为某个活动用户只能参与一次，一开始使用了redis的bitmap，想到bitmap每一位都可以存储一个会员id，这样只用1百兆就可以存快9亿个会员id，看似很美的做法。
但其实这样会有几个严重的问题，
- redis的bitmap并不会压缩，也就是说即使活动参加的人只有一个，而这个会员id如果很大，那偏移量就会非常高，那么可能就这一个会员id就会占用几百M的内存
- bitmap的最大偏移量为2^32次方，但大多数系统会员id的类型都为long类型，也就是int64，所以一旦会员id超过了这个偏移量上限，那系统判定就会出错
- 单一实例操作，因为bitmap并不会分散到集群上，而是固定一个实例上存储，会导致所有的redis请求全部打到一台实例上，尤其是这种判断是否参与过的程序往往都在程序的首要部分，并发度非常高。导致单一实例负载过高，redis集群失去作用
总结：redis的key最好和会员id绑定，这样可以保证redis集群的请求散列度高，负载均衡。最好不使用bitmap，如果使用最好是每个memberId对应一个bitmap，并且存的数据是从小到大升序上涨的。使用list，set，sortset，map之类里面的数据量不要太大，因为数据量多，而数据量也不能被分散，会导致集群的实例之间数据量不均匀