换你来，你会如何设计微信朋友圈？

1、需求理解

朋友圈大家都熟悉不得了，不再赘述。

2、设计

这里要阐述一个最关键的设计点，那就是微信朋友圈具有明显的非实时性。不知道你有没有留意到，假如有两个人 A和B，其中A发了朋友圈，A是可以在朋友圈里马上看到自己发的那条朋友圈，但是对于B来说，B是不会跟A一样可以马上看到A发的朋友圈的，而是需要稍微等那么一下下才可以看到。

2.1异步发圈

如果选择同步发圈，那么要发送成功一条带有视频或者照片的朋友圈，必须会经过【照片或者视频上传】、文字等信息到微信后台这么一个耗时的操作。那么就会面临一个想象，你发一个圈，就会那里转个圈圈，等个2秒。不可忍受。所以此时，可以选择异步发圈来达到用户快速发圈“成功”。

用户在客户端发圈时，内容信息可以首先是储存到客户端上，达到快速发圈成功。发布者就可以马上看到他自己的朋友圈了。但是这仅仅是一种类似“自娱自乐”的样子，因为别人根本看不到。
接着进行异步发布，客户端先把照片或者视频利用CDN技术，就近上传到CDN上，再将返回的照片或者视频地址以及文字发送到微信后台，进行储存。只有异步发送完毕，微信后台正常处理完成，别人即可看到这条朋友圈。

2.2 你的好友是怎么看到这条朋友圈的

你发的这条朋友圈（假设是公开的），你的好友在刷圈的时候，是会看到的。其实朋友圈跟QQ空间有一个很相似的点就是它们是时间轴产物。顺着一条时间轴，在时间车轮下，你刷一下，时间轮滚一下。那么当微信后台接受你客户端发送的朋友圈的时候，要做的操作之一就是，获取你所有的朋友列表，做一个【离线批处理操作】，将这条朋友圈插入到这些好友中的时间轴里面去。这样你的朋友刷圈，根据自己的时间轴，就可以刷到了。刷的时候就根据图片url地址，去cdn拉取的。

时间轴怎么设计呢？说白了就是表，时间线表即可。

2.3 我的相册怎么实现

微信里面有个相册，就是你发过含有照片的朋友圈，那么就会在你的相册里，形成对应的照片内容。
这个跟上面类似。就是后台处理的操作之一，给你的相册写入索引，直接引向这些照片。里面存放的是对你的发布表里的数据引用，这样你以后浏览相册的时候，都是根据相册里的索引数据到发布表里找实际对应的数据的。

2.4 好友权限设计

朋友圈发的时候，可以选择给谁看或者不给谁看。甚至有你的朋友圈不给谁看或者不看谁的，还有什么几天可见等等权限设置。

如果按照普通的设计思路，由后台来判断我能不能看到这条朋友圈，那么必然会经过繁琐复杂的权限判断链路。权限是随时会变的，因为你可能今天能看到朋友这条朋友圈，明天你们可能吵架，拉黑了，你又不可以看了。刷圈是一个比较高并发的操作，如果全交给后台处理，那么要设计出高并发的接口，是很难的。

你有没有发现朋友圈没有下一页操作，都是滚轮操作。你也不知道你滚一下，新刷出来的是多少条。因为作为用户角度，你并不关心多少条，而是我滚一下，要有东西出来。

那么客户端就可以发挥作用了。

好友权限会同步在客户端存储一份。这个存储，可以大大提高系统抗揍能力。因为当你刷朋友圈时，读取自己的朋友圈的时间轴时，客户端可以利用这份权限数据进行数据过滤，然后进行合并。这样你刷朋友圈时，这一秒想看他的朋友圈，下一秒突然不看他的，那么都可以很快的满足你。当然后台也是会进行对应操作，只是不会如此及时。或者说就是那一秒你刷的时候，后台返回给你的时间轴，还是包含他那条朋友圈的，只是被你的客户端权限进行过滤了，所以你看不到了。

当然权限这块也不是谁都会动不动就改。它的频率甚至比你换微信头像还低。所以这块留有更有意思的设计，我相信微信官方是有精妙的实现方法的！

2.5 别人发圈，你的朋友圈上面的那个红点怎么实现

对你可见的好友发了的朋友圈，你的朋友圈角上会有一个小红点，注意不是数字，因为还没到评论点赞那里呢，别急。
这个又是怎么实现呢？

当你朋友圈时间轴被插入好友的朋友圈时，后台此时可以在redis，插入这么一个以用户为key,红点标志为value的数据。客户端与后台建立长链接，近实时感知我当前朋友圈的是否是红点状态。

微信目前用户还没有达到 13亿，而redis单机可以支持24亿key。可以干！

这里的长链接，可以借鉴nacos作为配置中心的经过优化的长链接设计。可以看我之前这篇文章从源码角度一步步窥探Nacos配置拉取与动态刷新、监听原理

2.6 点赞、评论怎么实现呢？

点赞很简单，就是给你点一下。那么我一直点点点呢？你是给我算几次？微信里是算一次！那么就意味着要去重，后台数据库表也不能这么暴力存储每一次点赞记录，然后就去重取一条。那这样必然搞垮你的数据库。

朋友圈的点赞和评论，是独立的数据，其实比如点赞，都是可以基于redis来做的，每个朋友圈里对应一个set数据结构，里面放谁给你点赞了，这样每条朋友圈的点赞人和点赞数量直接从redis出就可以了，可以实现高并发点赞、去重、计数。

假设通过数据库的表来存放点赞的数据，此时可以通过联合唯一键来保证幂等性，用户id+朋友圈id是一个联合唯一索引，就可以确保一个人对一条朋友圈只能点赞一次，如果通过redis里的set来实现，set本身就是可以去重的，你多次把一个人放到一条朋友圈的set里去，是不会重复的。这样利用sismember就可以找到哪些人给你点赞，scard就可以立刻得到点赞人数。

评论也是可以存表里的，都是以朋友圈为粒度来存储。评论可以发多个一模一样的，所以没要进行去重。但是需要计数。因为到时候朋友圈角上显示的数字是包含评论数的。

那么问题来了，就是共同好友问题！！！你给A点了个赞，A的好友B也给A点了赞，但是你跟A是共同好友，那么此时你也会跟着会有朋友圈角上有数字的提醒！你打开一看，你只能发现这条朋友圈点赞的人就只有你们的共同好友B，其他的点赞人你都看不到，因为那些都是A的好友！

那么你客户端用sismember时得到这条朋友圈的点赞人列表时，还需要跟自己的好友列表进行交集操作，找出共同好友来进行显示。

那么此时，这个朋友圈角上的数字，就有点不太好处理。首先之前做朋友圈那个红点显示，其思路是可以继续用在这里的。但是处理就没之前那么简单了。

首先，先不管数字多少。当我们发现数字，点开朋友圈，点击顶部中心的条目提醒时，就会弹出所有提醒信息，包含点赞、评论。一旦退出，就意味你全部已读！意思就是，不管怎样，一旦你点了，就“强迫”已读。所以这就好办了。将计数存进redis，一旦点了，则置空计数，重新计数。

之前做朋友圈红点显示，用的是string 数据结构，现在将其改为hash。key依旧为用户id，hash里面的第一个值为key为红点标志，value为是否。第二个值为key为红点数字，value为具体数值。

那么已读已经解决。现在来看看怎么进行计数累加。

当客户端来获取数值时，后台则直接向redis这个hash取相应的红点数字即可。

重点是在进行点赞或者评论时。我们来看画个图感受一下。
在这里插入图片描述