打开朋友圈，手指向下滑了几下，又一“广告狗”！点击头像 ---- 右上角 ---- 设置朋友圈权限 ---- 不看他的朋友圈。一套动作下来，如行云流水，动作利索。再下拉刷新，不到一秒的时间，广告没了，朋友圈再度一片清新气象~
慢着，别走！我不是标题党！这就奔主题！！
”不到一秒的时间“，重新刷新，刚刚屏蔽的消息就没了，作为程序猿，当然好奇这是如何实现的，脑海里冒出了一个问题：”微信朋友圈的数据是如何存储和拉取的？“
首先假设A，B，C，D的关系如下：
好友关系.png
当A发布了一条朋友圈，B评论了A的朋友圈，来分析下微信朋友圈的设计需求：
-
A发布的消息谁能看？
- A的好友能查看
- 非屏蔽A的好友圈的好友能查看
- 非被A屏蔽的好友能查看
-
B在A的消息中的评论和赞谁能看？
- A和C的共同好友能查看
带着问题，我想到了两种方案：
方案一：
用最愚蠢的方法，每个用户都有一张表来保存自己的朋友圈的消息，当A发布一条消息时，除了屏蔽的和被屏蔽的的好友，把该消息插入A的所有好友中。同理，评论和赞都插入A和B的共同好友中。
- 优点：易实现；查询快。
- 缺点：数据量大，如果一个用户有几百的好友，发布一条消息就得存储几百份，单从这点，这方案就不可取了。更新数据量庞大，如果A把消息删除了，要通知所有好友删除... 不愿再想下去了...
方案二：
否定了方案一后，我想到了用索引。每个用户的朋友圈是维护了一条索引链和自己发布的消息表。A发布了一条消息，保存到自己的消息表中，除了屏蔽的和被屏蔽的的好友，把该消息的索引插入所有好友的索引链中。当如C打开朋友圈时，C按照索引从每个好友的消息表中拉取数据。同理，评论和赞也如此。
- 优点：相对方案一，数据量明显减少。
- 缺点：查询慢，每次刷新都从好友的表中查询，如果有几百个好友，是不可能做到”不到一秒时间“的！
因为当时是凭空想的，当然很多细节都没考虑到，但看上去好像能这样实现，只是不可取而已。其中大家可以注意到我加粗的文字，我犯了一个错误：把除了屏蔽的和被屏蔽的的好友与其他好友区分开来，从而导致了数据存储和加载的复杂度大大提高。我要考虑屏蔽或取消屏蔽时服务器如何处理消息与用户的关系，并如何通知客户端更新等等问题，结果想的东西越来越复杂，各种数据纵横交错，自己都不敢再想下去了。因为一旦复杂了就是错误的！这句话其实是我的好友跟我说的：”编程时，如果一个问题你觉得很复杂，那就永远无法解决。”
其实不但是编程，任何事情都这样，如果你先入为主地认为它复杂，到最后你肯定解决不了这件事情。并且，如果你处理事情时，使用的方法越来越复杂，这个方法肯定是错误或愚蠢的！肯定有更好的方法可以优雅地解决问题。
但由于我的能力和知识有限，并想不出更好的方案来处理朋友圈的数据存储和拉取问题，哈哈。但我会查阅资料。直到我看到了下面这篇文章才恍然大悟，果然，很优雅！很简单！！
看了上面的文章后，我自己也整理了一遍：
微信朋友圈的数据存储和拉取.png
下面对上图分析下：
关系：
A，B，C互相为好友，A与D为好友。
核心表：
- 发布表：所有用户共用（注意，公用不代表存储在同一个服务器）
- 相册表：每个用户都有自己独立的相册
- 评论或赞表：所有用户共用，跟发布表是多对一的关系
- 时间线表：每个用户都有自己独立的时间线，也就是朋友圈啦
流程：
- 假设A发布了一条朋友圈，服务器会做两件事：
- 把该消息存储到发布表中
-
把消息插入每个好友的时间线上，不区分屏蔽或被屏蔽的好友。
-
B评论或赞了A的朋友圈，服务器也是做两件事：
- 把该评论或赞存储到评论表或赞表中
-
关联对应的消息（其实这步在1中做了，为了更清晰分开讲）
-
C和D打开朋友圈
- 根据C的时间线向发布表请求数据
- 如果是共同好友，加载评论和赞，否则不加载
整个流程下来，逻辑非常清晰，思路非常简单！当然，实际的设计不会这么简单，还有很多细节，如数据缓存，服务器部署等等要考虑和处理，这里只是简述了基本的工作流程而已。
相信聪明的你已注意到，上面的文章根本就没讨论屏蔽与非屏蔽的问题，不是忘了，而是没必要。后面我想了想，因为消息或友好我们可以选择屏蔽或取消屏蔽，如果每次操作都要通知服务器进行增删，那效率不是很低？！所以应该是消息都会存储到每个用户的时间线上（这点我应该早点想到的...），至于是服务器查询时跳过屏蔽的消息，还是客户端选择性显示就不得而知了。
由于本人是搞客户端的，后端的技术我也不会哈哈，上面的内容只是突然好奇的所思与所想，所以难免会有错误的论述。若有错，欢迎指正。
低头看下表，从开始想这个问题到写完这篇文章，用了5个有多的小时，如果觉得有帮助或有趣的话，点下红心呗~
网友评论