6.談談點贊

6.談談點贊

來自專欄 產品方案的技術實現

點贊是現在很多APP都有的一個功能，從業務角度來講，和銷量、好評一樣，給人們了解對象（包括商品、文章、評論等）提供了一個簡單的維度，比如點贊的人越多，可能就會覺得這個對象被更多人接受，在知乎中，甚至點贊成了一種傳播機制，也即用戶對某一內容點贊後，被點贊的對象就會出現在這個用戶的信息流中（這個應用被微博抄襲了）。從產品角度來講，也跟銷量、好評率一樣，為產品的智能推薦、用戶需求搜集提供了一個維度，比如在諮詢的自助菜單中，被用戶點贊越多的問答，可能就對用戶越有用，因此我們在產品設計上要把這種問答做重，更直觀的展示給用戶。本期簡單講解點贊的內部機制——點贊信息的記錄。

點贊信息記錄跟其他信息的記錄一樣，也即可以記住點贊用戶的cid或uid，也可以什麼都不記，這最終要看產品設計中對點贊的重視程度，從技術實現角度來講，什麼都不記實現起來是最簡單的。記錄各種信息都會對點贊的數據造成不同影響：? 什麼都不記錄：也即同一用戶可以無限次點贊，可能只是頁面上記錄了一個用戶行為導致用戶在頁面點贊後，如果停留在頁面，無法第二次點贊（設置了取消點贊功能的話可以取消然後再次點贊），然而如果推出頁面重新進入，則可以繼續點贊。這種機制會造成同一用戶刷贊的行為，造成對象點贊數量虛高，如果這種點贊數量被作為排序等因子的話，就會有大量人刷贊，可以稱為一個bug了。? 記錄uid，也即用戶在點贊時，前端頁面傳輸了一個「點/取消贊」和一個「uid」給到後端，後端根據傳輸值記錄每一個uid對每個對象的點贊狀態，這樣也即只允許每個uid針對每個對象只能點一次贊，無論怎麼刷新頁面都永遠記錄著用戶對對象的點贊狀態。需要解決的是未登錄狀態下且無臨時uid時，可能仍會有刷贊行為的存在，否則就要強制登錄。? 記錄cid，也即在用戶點贊時，前端頁面傳輸一個「點/取消贊」和一個「cid」給到後端，後端根據傳輸值記錄每一個cid對每個對象的點贊狀態，這樣也即只允許每台設備對每個對象只能點一次贊，也就是即使在當前設備登陸了另一個賬戶或未登錄，也無法對同一內容進行二次點贊，也存在一定的不合理性。要想實現同一uid不可重複點贊且未登錄拿不到uid的狀況下不可重複點贊的功能，則應該同時記錄uid和cid，當存在uid時，校驗uid的點贊狀態，當不存在uid時，校驗cid的點贊狀態，這是對點贊數據最全面穩妥的一種處理方式，當然要記錄的信息比較多。

推薦閱讀：