任何脫離業務場景的架構設計都是耍流氓。
廣義系統通知，有1對1的通知，以及一對多的通知，有相對實時的業務通知，以及能夠容忍一定延時的系統通知。結合具體的場景來看下，這樣的一些系統通知，究竟是推還是拉？
一、系統對1的通知
典型業務，計數類通知：
很多業務經常有這類計數通知，通知結果只針對你，這類通知是推送，還是拉取的呢？常見的有這樣一些實踐：
如果業務需求對計數需求需要實時展現，例如微博的加好友計數，假如希望實現不重新整理網頁，計數就實時變化：
int getcountbytype(int counttype)
int addcountbytype(int counttype, int diff)
這裡的思路是，一開始得到初始值，後續推送增量值，由網頁端計算最終計數並呈現最終結果。需要注意，針對不同業務，計數變化的差值可增可減。
上述方案的壞處是，一旦有訊息丟失，網頁端的計數會一直不一致，直至再次登入重新初始化計數。這個計算計數可以優化為在伺服器直接計算並通知網頁端最終的結果，網頁端只負責呈現即可，這樣網頁端的邏輯會變輕。
如果業務對此類通知的展現不需要這麼實時，完全可以通過拉取：
int getcountbytype(int counttype)
這樣系統的實現會最簡單。需要注意，通知拉取要非同步，不要影響主頁面的快速返回。
系統對1的推送，例如針對1個使用者的業務計數推送，計數的變化頻率其實非常低，使用cache來儲存這些計數能夠極大提公升系統效能。
更多計數系統架構實踐可詳見《計數系統架構實踐一次搞定》。
二、系統對多的通知
系統對多的通知訊息，會比系統對1的通知訊息複雜一些，以兩個場景為例：
im登入彈窗新聞
這個通知的需求是：
不妨設有乙個表存放彈窗新聞：
t_msg(msg_id, date, msg_content)
有乙個表來存放使用者資訊：
t_user(user_id, user_info, …)
有乙個表來存放使用者收到的新聞彈窗：
t_user_msg(user_id, msg_id, date)
這裡的實現明顯不能採用推送的方式：
這個笨拙的方式，會導致t_user_msg裡有大量的髒資料，畢竟大部分使用者並不會登入。
如果改為拉取的方式會好很多：
這個方式雖然有所優化，但t_user_msg的資料量依然很大。
t_user(user_id, user_info, last_msg_date, …)
這樣業務流程會公升級為：
這種方式不再儲存訊息與使用者的笛卡爾關係，資料量會大大減少，是不是有點意思？
im右下角彈窗廣告
這個通知的需求是：
畫外音：如果1個推送一塊錢，5kw使用者推送收入就有5kw收入喲，一天推個幾次，實現1個億的小目標居然如此簡單。
最直觀的感受，這是乙個for迴圈批量推送的過程。如果是推送，必須要考慮的問題是，推送限速控制，避免短時間內對系統造成衝擊，引發雪崩。
能不能用拉取呢？
完全可以，這是乙個對實時性要求不太高的場景，使用者早1分鐘晚1分鐘收到這個廣告影響不大，其實可以借助im原本已有的keepalive請求，在請求返回時，告之「有訊息拉取」，然後採用拉取的方式拉取廣告訊息。
三、總結
廣義系統通知，究竟是推送還是拉取呢？不同業務，不同需求，實現方式不同。
系統對1的通知：
系統對n的通知：
系統通知究竟是推還是拉，是乙個相對比較簡單的場景。對於feed流，單聊群聊，狀態同步會更為複雜，這些場景，下期分解。
挖坑篇：《feed流，單聊群聊，系統通知，狀態同步，到底是推還是拉？》
系統通知，居然有人使用拉取？
任何脫離業務場景的架構設計都是耍流氓。廣義系統通知，有 1對1的通知 以及一對多的通知 有相對實時的業務通知，以及能夠容忍一定延時的系統通知。結合具體的場景來看下，這樣的一些系統通知，究竟是推還是拉？一 系統對1的通知 典型業務，計數類通知 很多業務經常有這類計數通知，通知結果只針對你，這類通知是推...
NSNotification系統通知優化
最近在github上看到了lrnotificationobserver這個專案，看了一下實現方式，作者通過arc機制例項化註冊物件子類與關聯物件的方法來管理註冊物件的生命週期。從而省去了系統通知移除的過程，本篇介紹該專案實現過程。註冊 nsnotificationcenter defaultcent...
iOS註冊系統通知
ios程式設計裡面，用到系統通知來接受事件是十分普遍的，最典型的就是鍵盤的通知事件。我們也可以自己定義通知的事件，讓系統來調去我們想要的函式。註冊通知 nsnotificationcenter defaultcenter addobserver self selector selector resp...