Feed

Feed流产品有两种常见模式:
Timeline:不做内容筛选，简单的按照内容发布时间排序，常用于好友或关注。例如朋友圈
优点:信息全面，不会有缺失。并且实现也相对简单
缺点:信息噪音较多，用户不一定感兴趣，内容获取效率低
智能排序:利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户
优点:投喂用户感兴趣信息，用户粘度很高，容易沉迷
缺点:如果算法不精准，可能起到反作用

Timeline

该模式有三种实现方案：

1. 拉模式

也叫读扩散，在朋友圈中，用户发送消息伴随这一个时间戳发送到发件箱中，当我们需要进入朋友圈中，我们的收件箱，在从关注的人里面将消息拉过来

2. 推模式

也叫做写扩散，发布的消息不需要写入到发件箱中，直接推送到被关注人的收件箱中并通过时间戳进行排序，延时低，但是比如说微博中的一些大V，粉丝人特别多，这样就会写很多

3. 拉推结合

也叫读写混合，兼具推和拉两种模式，粉丝多的就设置发件箱，粉丝少的就使用推模式

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或1
GETBIT:获取指定位置(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进行合并在进行统计