我有個點贊功能的邏輯實現，效能最佳化，高並發的問題想問

業務情境：假設現在有1000人在同時瀏覽同一個微博，而且這一千人都將會點贊，為了簡單化，我們假設這1000人是按照時間順序依次點贊的。

點贊控制項不可能讓使用者每點擊一次就發送一次ajax請求，一千人同時線上，我們不能保證這一千個使用者都不是一些無聊的人。如果他們同時（哪怕不是同時）點著這個控制項玩兒，伺服器肯定會宕機狗帶！那麼問題來了，前端方面在原有點贊數字上肯定是加1或者減1。後端方面把點贊的使用者id和點贊目標使用者的資料庫裡面儲存的點贊使用者（平常我們都會看到誰點贊我）進行匹配，如果存在那就減一，不存在那就加一。但是這個時候我們不能強調資料一致性，除非使用者重新整理，如果強調資料一致性，我點個贊就加125，這個體驗就不是很好。所以返回的還是原先使用者看到的那個點贊數字加一或者減一，那這樣就不可避免的每點擊一次都要發送ajax請求了，伺服器宕機指日可待。。。

有沒有好的解決方案

回複內容：

業務情境：假設現在有1000人在同時瀏覽同一個微博，而且這一千人都將會點贊，為了簡單化，我們假設這1000人是按照時間順序依次點贊的。

點贊控制項不可能讓使用者每點擊一次就發送一次ajax請求，一千人同時線上，我們不能保證這一千個使用者都不是一些無聊的人。如果他們同時（哪怕不是同時）點著這個控制項玩兒，伺服器肯定會宕機狗帶！那麼問題來了，前端方面在原有點贊數字上肯定是加1或者減1。後端方面把點贊的使用者id和點贊目標使用者的資料庫裡面儲存的點贊使用者（平常我們都會看到誰點贊我）進行匹配，如果存在那就減一，不存在那就加一。但是這個時候我們不能強調資料一致性，除非使用者重新整理，如果強調資料一致性，我點個贊就加125，這個體驗就不是很好。所以返回的還是原先使用者看到的那個點贊數字加一或者減一，那這樣就不可避免的每點擊一次都要發送ajax請求了，伺服器宕機指日可待。。。

有沒有好的解決方案

可以上redis，每日點贊存到redis裡，使用者點贊以及取消點贊操作的就是緩衝中的內容，而不是資料庫。然後在業務低峰時間(例如0:00) 再將每日最終點贊數寫入資料庫，這樣的話每天只需要對資料庫做一次資料寫入就解決問題了

也想不到更好的法子,儲存在redis是比較常規的做法,redis的操作都是原子性的,所以髒資料是不會產生的.
然後第二天就是資料持久問題,設定一個周期,定時將資料從redis往mysql跑一遍.

1、點贊請求儲存的到隊列（Redis RabbitMQ ZeroMQ etc.）
2、隊列消費會根據業務系統壓力判斷是否把點贊刷入Mysql
3、當然是否點贊也需要兩套邏輯判斷

如果量真的很大的話，可以redis+訊息佇列更新，先把資料寫入redis，然後用隊列的方法慢慢存入資料庫

我想了一個歪點子，不知道有用不：
在web端延遲發送ajax請求，比如，使用者點擊了一下點贊，然後js將點贊成功的樣式展現出來（點贊數+1，顯示點贊頭像等），但並不立即發送ajax請求，等待10s（或者使用者進行離開頁面、重新整理頁面等操作時），如果中途沒有再次進行點贊與取消點贊操作，再發送ajax請求，如果中途進行了點贊與取消點贊操作，那麼重新計時延時！對於那些喜歡點一下贊就重新整理一下再取消點贊的使用者，只能跪著叫爹吧，哈哈哈！

點贊不是 live = live + 1嗎？ “點個贊就加125”是什麼意思？

