Redis学习

基础语法的话可以自己去学习，这里主要记录一下一些有意思的使用方法

redis实现文章点赞效果

点赞的话第一下是点赞，第二下则是取消点赞，自然不能存储在数据库中，否则频繁点击的话多次对数据库进行读写会很影响性能，所以这里考虑使用redis来进行存储

第一种方法，因为点赞不能重复，所以最先想到的就是set，每次点击后就会将数字存到对应的set当中

sadd article:10 100

获得点赞总数

scard article:10

判断是否点赞

sismember article:10 100

取消点赞

srem article:10 100

但是这样其实有些问题，不是功能上的问题，而是内存上的问题，如果有1000篇文章，那就至少要设置1000个对应的set的key，且每个之内还需要储存N个用户id，如果文章和用户数量一大，就会占用较大的内存

那我们可不可以用别的方法来进行存储？
还记得Redis还有一种叫Bitmap的东西，是一串连续的二进制数组(0或1)，可以通过偏移量定位元素
那可不可以就用这二进制的一位来存储代表某个id的用户呢？

其实就是用bitmap的第n为来代表id为n的用户，如果点赞则设为1

查看id为100的数字是否点赞
getbit like:10 100

id为100的人进行点赞
setbit like:10 100 1

查看多少人点赞
bitcount like:10

这样每一位就可以存储一个会员id，只用100M就可以存储接近9亿个会员id

但其实看似很好，我觉得还是有缺陷的，比如如果我使用的是uuid作为用户的id，生成的一个id就是十几位，且最小的也是十几位，那一个bitmap的前面大量的空间就被浪费了，完全起不到作用，而由于uuid是随机的，所以也无法按照一定的规则将其减小，所以其实是自增id的话用bitmap就会很适合

而且bitmap并不会压缩，如果会员id很大，偏移量很高，可能几个会员id就会占用较大的内存，再加上bitmap的最大偏移量为2^32-1，但如果会员id的类型为long类型，int64，那会员id过大就会导致超出偏移量上限。

而且单一实例操作，因为key固定，所以bitmap存储的内容不会分散到集群，而是固定在一个实例上存储，如果集群模式，数据都存一个实例，且所有的对这个bitmap的操作redis请求全部打到一台实例上，尤其是这种判断是否参与过的程序放在程序的首要部分，并发度较高，导致单一实例负载过高，redis集群失去作用