<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??一站式輕松地調用各大LLM模型接口,支持GPT4、智譜、豆包、星火、月之暗面及文生圖、文生視頻 廣告
                > 原文出處:http://weibo.com/p/1001643880172431480781 > 作者:唐揚,[@唐揚TY](http://weibo.com/n/%E5%94%90%E6%89%ACTY) ![](https://box.kancloud.cn/2015-09-14_55f6685f4e461.jpg) 未讀提醒功能在各種社交平臺服務中較為常見,在微博中這些功能由Unread服務來提供。看似簡單的功能,當請求量級達到一定規模后,成本、性能、穩定性的平衡將是架構設計的重點。 **大綱** [TOC] ## 一 微博中Unread服務業務場景 在以timeline為核心的微博業務中, 未讀數場景出現的頻率較高,它可以是這樣的… ![](https://box.kancloud.cn/2015-09-14_55f6686235481.jpg) 也可以是這樣的… ![](https://box.kancloud.cn/2015-09-14_55f66862b2ad7.jpg) ## 二 從架構角度對各種業務場景的抽象 通過分析和比較這些未讀場景,我們抽象了unread服務中設計到的三種主要操作: 1.?incr:增加未讀數 2.?reset:未讀數清零 3.?get:獲取未讀數 我們發現unread服務中get操作是典型的無觸發操作,即不需要用戶執行任何操作都會對服務器造成請求。正是這個特點給unread服務帶來如下問題: 1.?高并發:高峰期單一業務的qps達到10萬+ 2.?性能要求高:接口4個9的響應時間在10ms 為了解決上述問題,unread架構針對不同的業務場景設計了不同的方案,保證了服務的高性能、高可用和可擴展。本文主要針對三種典型的未讀數場景介紹微博平臺是如何設計解決方案的。 ### 場景一.?一對一行為未讀提醒場景 在這種場景下,用戶的某一個操作只會影響一個用戶的未讀數字。典型的場景有:@未讀提醒、評論未讀提醒、贊評論提醒等等。 針對這種場景,我們采用最簡單的解決方案:為每一個用戶存儲一份未讀數字,如下圖 ![](https://box.kancloud.cn/2015-09-14_55f668633120e.jpg) 在設計的實現中,由于存儲容量可控,我們采用redis存儲未讀數。相比于通常使用的mysql+mc的存儲解決方案,redis有以下的優勢: 1.?存儲一體化,避免了緩存和持久化存儲之間一致性的問題 2.?快速恢復 這個設計方案主要基于如下的考慮: 1.?簡單直觀 2.?性能能夠達到SLA,每次操作只需要訪問一次資源 ### 場景二.?全量打點場景 打點主要指微博官方客戶端中的一些弱提醒功能,見下圖中的紅點 ![](https://box.kancloud.cn/2015-09-14_55f66863b3125.jpg) 而全量打點指對全量用戶都增加未讀提醒紅點。考慮到目前微博的用戶量,如果采用第一種場景的方案,打點過程會存在很大的延遲。因此我們采用了基于tag的解決方案。 1.?存儲公共的時間戳global 2.?每一個用戶存儲一個時間戳 3.?打點時,更新global時間戳為當前時間 4.?消點時,更新用戶的時間戳為global時間戳 5.?如果用戶時間戳小于global時間戳,則有點;否則沒有點 ![](https://box.kancloud.cn/2015-09-14_55f66863d2132.jpg) 這個方案適用于用戶間存在共享存儲,且共享存儲有限的場景。在這種場景下,我們為每一個用戶存儲一個tag用來記錄用戶在共享存儲中的已讀位置,這樣就可以通過比較這個已讀位置獲得用戶的未讀數。 在實際的應用過程中,我們通常會使用本地緩存來解決訪問共享存儲的極端峰值。這種基于已讀位置的解決方案雖然能很好的解決全量打點的問題,但是面對訪問量最大的微博未讀數場景卻是無能為力,原因有二: 1.?用戶的feed是無限的,不存在共享存儲,全部存儲下來的成本很高 2.?在高并發下獲取未讀數操作性能衰減嚴重 我們采用了下面這種方案來解決微博未讀數問題。 ### 場景三.?微博未讀數場景 眾所周知,微博未讀數就是微博主feed未讀數,當我關注的人發表一條微博,我的微博未讀數提醒就會加一。 對于微博微博數場景,我們采用了基于snapshot的解決方案,具體如圖所示: ![](https://box.kancloud.cn/2015-09-14_55f6686440c28.jpg) 1.?我們會存儲每一個用戶發微博數,用戶發微博時只會增加自身的微博數 2.?用戶reset時會觸發一次快照操作,存儲當時用戶的關注關系以及每一個關注者的微博數。 3.?用戶的未讀數由當前用戶所有關注人的微博數和快照中所有關注人的微博數的差值組成 基于快照的方案近乎完美的解決了微博未讀數的問題,目前微博平臺單機qps接近5萬,平均響應時間小于10ms 在基于快照的方案中,我們采用空間換時間的方式,額外存儲了一份snapshot來換取性能上達到SLA要求。因此這個方案主要的適用場景是快照的存儲有限或者是允許丟失。 在微博未讀數實現中,我們采用memcache存儲快照,使用本地內存存儲用戶的微博數,采用這種方式是基于以下考慮: 1.?存儲用戶微博數的空間有限,使用本地內存可以減少一次網絡開銷 2.?快照中需要存儲關系,理論上需要N*N的空間消耗(N為用戶數),利用memcache的LRU機制可以淘汰不活躍用戶的快照,節省空間開銷 memcache的容量評估也是這個方案實現中需要考慮的重要點。我們主要從兩個方面來考慮: 1.?容量:根據存儲的單個用戶快照大小和MAU評估 2\. QPS:依據前端QPS和每次調用帶來的對memcache的調用次數估算出memcache的QPS,以此QPS估算需要多少個memcache實例 以上就是我對于微博平臺不同的未讀場景設計的未讀架構的理解。在設計的過程中,我們沒有拷貝相似場景的方案,而是權衡需求、性能、成本和擴展性等多方面的因素,設計出最合適的架構。希望通過以上介紹能給大家以后工作有所幫助和啟發。 **------------------新兵訓練營簡介**------------------ 微博平臺新兵訓練營活動是微博平臺內部組織的針對新入職同學的團隊融入培訓課程,目標是團隊融入,包括人的融入,氛圍融入,技術融入。當前已經進行4期活動,很多學員迅速成長為平臺技術骨干。 微博平臺是非常注重團隊成員融入與成長的團隊,在這里有人幫你融入,有人和你一起成長,也歡迎小伙伴們加入微博平臺,歡迎私信咨詢。 **------------------講師簡介**------------------ 唐揚,[@唐揚TY](http://weibo.com/n/%E5%94%90%E6%89%ACTY),微博平臺及大數據部技術專家,負責微博平臺架構及基礎架構研發工作,在高并發可擴展架構設計方面有豐富的實戰經驗。新兵訓練營第一期學員。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看