前提

微信朋友圈是我們每天都在用的功能, 但是如果讓你來實現一個微信朋友圈, 你會如何做呢? 我來簡單設想一下.

實現功能

1. 發朋友圈
2. 評論動態
3. 查看朋友圈(只能查看好友的)
4. 查看評論(只能查看共同好友的)

是不是看著很簡單? 也沒有幾個功能嘛. so easy.

開始實現

數據庫選用了MySQL, 熟悉的關係型數據庫

版本一

看了只有兩條內容, 朋友圈動態, 朋友圈評論, 直接設計數據庫.

簡單吧. 好, 按照這個數據模型, 當實現時, 就會發現問題.

1.如何獲取好友圈數據

如果簡單的拉取好友列表, 然後拉取出其中好友的動態, 不好意思, 你的接口慢到爆炸, 畢竟用戶基數就在那.

2.如何獲取動態下的共同好友評論

當然, 評論也可以獲取動態下的所有評論, 然後過濾掉非好友的評論, 同上, 太慢了.

想想哈

如何解決這個問題? 上面獲取數據慢主要是因為要做數據的篩選, 那如果我能夠直接拿到最終數據, 不就可以解決這個問題了麼?

版本二

為了能夠直接獲取到朋友圈的數據, 在現有基礎上是肯定不行的, 根據獲取數據的思路, 直接獲取朋友圈數據, 當然要加一張朋友圈的表了.

新增一張朋友圈表:

這樣就很方便了, 用戶查看朋友圈時, 可以直接定位查看的動態以及可以查看的評論, 在根據動態ID和評論ID將內容補充進去就行了.

但是相應的, 就需要維護用戶朋友圈這樣的一張表, 在用戶發帖、刪帖、加好友、刪好友、發評論、刪評論的時候, 去做數據的同步操作, 而且要異步的進行, 畢竟同步的話, 接口響應就會變慢. 但是我覺得, 這樣的代價是值得的, 可以換來拉取數據接口的快速響應.

你以為到這就完了麼? 天真. 看下圖:

這樣的消息在朋友圈都看到過吧. 它應該是所有用戶都可以看到的, 可以將它理解為官方發的動態. 如果按照我們現在的設計, 就要將它插到所有用戶的朋友圈中, 也就是說, 如果官方發一條動態, 有一百萬用戶的話, 就要插一百萬條同樣的數據, 而且有新註冊用戶, 還要將歷史數據插進去. 這樣不只難以維護, 而且有太多無用數據了.

想想哈

這種數據最好只需要插入一條, 所有用戶都去讀就好. 最直觀的方法, 在朋友圈表中, 指定一個用戶ID(比如0), 是所有用戶共同的數據, 這樣就解決了

但是, 之前我們的評論是直接保存到朋友圈中的, 可以這樣保存, 是因為每個用戶在朋友圈表中的每個動態是唯一的, 但是現在如果插入公共ID, 就不能這麼存了, 哪又該如何處理動態的評論呢? 難道回到開始的動態查詢嗎?

既然有用戶的朋友圈動態表, 那就可以有朋友圈評論表,

版本三

修改用戶朋友圈表結構如下:

這樣改動之後, 維護的數據和版本二基本一樣, 而且也解決了

來看看現在的相關操作

查看朋友圈

1. 從朋友圈動態查找可以查看的動態(包含用戶ID和公共ID)
2. 從朋友圈評論查看相關評論(包含用戶ID和公共ID)
3. 從動態表和評論表根據ID將相關數據取出

前兩步走索引, 第三步直接根據主鍵獲取, 而且拿出來的沒有無用數據

數據維護的操作(一下所有操作官方特判)

發動態

1. 查找用戶所有好友
2. 將動態添加到所有好友的
   朋友圈動態表中(包括用戶自己)

刪動態

1. 查找用戶的所有好友
2. 將動態從好友的朋友圈動態表中刪除
3. 將動態從好友的朋友圈評論表中刪除

發評論

1. 查找用戶的所有好友A
2. 從朋友圈動態中找出A可以查看此動態的好友B
3. 若評論是回覆某用戶, 則從B中過濾不是回覆用戶好友的用戶, 得到C
4. 將數據添加到C的朋友圈評論表中

刪評論

1. 查找用戶的所有好友A
2. 從朋友圈評論中找出A中可以查看此評論的用戶B
3. 刪除B的朋友圈評論數據

添加好友

1. 找到好友的所有動態, 添加到用戶的朋友圈動態中
2. 找到好友在用戶朋友圈動態中所有動態下的相關評論(包括評論和被評論), 並從中過濾掉用戶不可查看的評論, 同步
   好友圈評論

刪除好友

1. 找到好友在用戶朋友圈動態中所有動態下的相關評論, 刪除用戶好友圈評論數據
2. 找到好友的所有動態, 從用戶的朋友圈動態中刪除

以上, 基本就是我目前的設想

總結

可以看到, 最終的版本, 基本所有的邏輯都在異步數據的同步上, 業務邏輯基本很少, 這樣可以保證拉取數據的接口快速響應, 但因為是異步操作, 難免會造成數據的延遲. 比如說: 當處理數據過大時, 用戶發了動態, 但是還沒有做異步的處理, 他的好友時看不到他剛剛發表的動態的.

以及可能存在的其他暫時沒有發現的問題. 先這樣, 沒有更好的想法了.

以上!!!

閱讀更多 菸草的香味 的文章

關鍵字: 微信 MySQL 技術