任何脫離業務的架構設計都是耍流氓。
狀態同步，有好友狀態的同步，有群友狀態的同步，有的需要實時同步，有的能夠容忍延時。結合具體場景來看下，狀態同步，究竟是推還是拉。
什麼是服務端狀態？
服務端狀態離線，直接儲存離線訊息，等使用者下一次登入拉取
如何實時更新服務端狀態？
使用者uid-a登出時，會修改使用者的服務端狀態為離線。
經常的，服務端會將使用者的服務端狀態儲存在高可用的快取集群裡。
什麼是客戶端狀態？
如何獲取好友的狀態？
uid-a登入時，先去資料庫拉取自己的好友列表，再去快取獲取所有好友的狀態。
使用者uid-a的好友uid-b狀態改變時（由登入、登出等動作觸發），uid-a如何同步這一事件？
這裡就有推拉的設計折衷了。
uid-a向伺服器輪詢拉取uid-b（其實是自己的全部好友）的狀態，例如每1分鐘一次，其缺點是：
（1）如果uid-b的狀態改變，uid-a獲取不實時，可能有1分鐘時延
（2）如果uid-b的狀態不改變，uid-a會有大量無效的輪詢請求，非常低效
推送的優勢是：實時
群友狀態的一致性，和好友狀態的一致性相比，複雜在**？可不可以採用實時推送？
群這個業務場景大夥也非常之熟悉，你能夠加入若干群(例如20個)，假設平均每個群有200人，即你會有4000個群友。
理論上群友狀態也可以通過實時推送的方式實現，以保證實時性。進一步討論之前，先一起估算下這個業務場景下的「訊息風暴擴散係數」。
輪詢拉取群友狀態也會給伺服器帶來過大的壓力，還有什麼優化方式？
總結
狀態的實時性與一致性是乙個較難解決的技術問題，不同的業務實現方式不同，一般來說：
狀態同步，究竟是推還是拉？
好友狀態的同步 有群友狀態的同步 有的需要實時同步，有的能夠容忍延時。結合具體場景來看下，狀態同步，究竟是推還是拉。不同的狀態，對於不同的業務處理流程可能不同 例如對於訊息的處理 服務端狀態離線，直接儲存離線訊息，等使用者下一次登入拉取 登入時，會修改使用者的服務端狀態為。登出 時，會修改使用者的服...
究竟是內省還是內省
下面我們就對內省做一下簡單介紹 通過propertydescriptor類操作bean的屬性 通過introspector類獲得bean物件的 beaninfo，然後通過 beaninfo 來獲取屬性的描述器 propertydescriptor 通過這個屬性描述器就可以獲取某個屬性對應的 gett...
CMS究竟是CMS還是WCMS
最近因為公司的專案關係在研究cms，但是翻遍所有網上的資料都是 內容管理系統 這裡我稱之為wcms 不知道確切的cms定義是什麼，但是確實這點讓我很迷惑，難道cms就是乙個portal系統 比如manbo 在我的看法裡，cms就是乙個純粹的後台系統，它關心有哪些內容，內容的屬性，歸類，頻道繫結，歸屬...