Redis
- Feed
- Timeline
- GEO
- BitMap
- HyperLogLog
Feed
Feed流产品有两种常见模式:
Timeline:不做内容筛选,简单的按照内容发布时间排序,常用于好友或关注。例如朋友圈优点
:信息全面,不会有缺失。并且实现也相对简单缺点
:信息噪音较多,用户不一定感兴趣,内容获取效率低
智能排序:利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户优点
:投喂用户感兴趣信息,用户粘度很高,容易沉迷缺点
:如果算法不精准,可能起到反作用
Timeline
该模式有三种实现方案:
- 拉模式
也叫读扩散,在朋友圈中,用户发送消息伴随这一个时间戳发送到发件箱中,当我们需要进入朋友圈中,我们的收件箱,在从关注的人里面将消息拉过来
- 推模式
也叫做写扩散,发布的消息不需要写入到发件箱中,直接推送到被关注人的收件箱中并通过时间戳进行排序,延时低,但是比如说微博中的一些大V,粉丝人特别多,这样就会写很多
- 拉推结合
也叫读写混合,兼具推和拉两种模式,粉丝多的就设置发件箱,粉丝少的就使用推模式
GEO
GEO就是Geolocation的简写,代表地理坐标,Redis支持GEO结构,允许存储地理坐标信息,帮助我们根据经纬度检索数据GEOADD
:添一个地理空间信息,包含:经度(longitude)、纬度(latitude)、值(member)GEODIST
:计算指定的两个点之间的距离并返回GEOHASH
:将指定member的坐标转为hash字符串形式并返回GEOPOS
:返回指定member的坐标GEORADIUS
:指定圆心、半径,找到该圆内包含的所有member,并按照与圆心之间的距离排序后返回。6.2以后已废弃GEOSEARCH
:在指定范围内搜索member,并按照与指定点之间的距离排序后返回。范围可以是圆形或矩形。6.2.新功能GEOSEARCHSTORE
:与GEOSEARCH功能一致,不过可以把结果存储到一个指定的key。6.2.新功能
BitMap
我们通过BitMap的方式实现签到这种功能,将bit进行映射,实现签到功能
Redis中是利用String类型数据结构实现BitMap,最大上限是512M,转换为bit则是2^32个bit位
常用命令:SETBIT:
向指定位置(offset)存入一个0或1GETBIT:
获取指定位置(offset)的bit值BITCOUNT:
统计BitMap中值为1的bit位的数量BITFIELD:
操作(查询、修改、自增)BitMap中bit数组中的指定位置(offset)的值BITFIELD RO:
获取BitMap中bit数组,并以十进制形式返回BITOP:
将多个BitMap的结果做位运算(与、或、异或)BITPOS:
查找bit数组中指定范围内第一个0或1出现的位置
HyperLogLog
UV:
全称Unique Visitor,也叫独立访客量,是指通过互联网访问、浏览这个网页的自然人。1天内同一个用户多次访问该网站,只记录1次PV:
全称Page View,也叫页面访问量或点击量,用户每访问网站的一个页面,记录1次PV,用户多次打开页面,则记录多次PV。往往用来衡量网站的流量
如果我们需要统计UV值,我们可以使用HyperLogLog,它是从LogLog算法中派生出来的概率算法,用于确定非常大的集合的基数,但是它的单个存储的统计内存永远小于16kb,但是代价就是统计是概率性的有小于0.81%的误差,不过可以忽略
PFADD
:在所需要统计的数据通过该命令保存到PFADD中
PFCOUNT
:对保存其中的数据进行统计
PFMERGE
:将多个key进行合并在进行统计