（此文章，將隨著記憶與問題暴露做不斷的總結記錄）
im產品，做支撐的服務端系統，是乙個分布式的系統，按照對資料的處理職責來看，大致分為四大類：
1.閘道器層 （需要bind在外網網絡卡上，其他層模組bind在內網網絡卡上）
解決使用者接入問題，包括選擇負載均衡，極速連線，訪問控制，資料安全傳輸等。
常見的坑：
連線失敗，連線慢；
非法連線；
非法請求；
攻擊；
相容各種子系統的協議，把其他的產品接入到im體系裡，可能要解決http/https協議轉換；
解決接入層高併發是最有挑戰性的事情。
2.邏輯層
常見的坑：
訊息id的唯一性保證，不可重複性，丟訊息，分布式系統對維護與重啟的環節要求很高，稍有不慎就會丟訊息；
社交關係的維護，好友關係的正反推導是個複雜的問題；
大群問題，萬人群訊息的**；
訊息推送失敗；
維護不同使用者關於訊息收發的複雜配置；
使用者的狀態資訊維護是最痛苦的事情，伺服器重啟瞬間可能產生大量的廣播，狀態同步；
與其他業務系統的互動，依賴別人是最容易背黑鍋的事情，多乙份依賴多乙份不可靠性。（此處背黑鍋最多!）
3.資料訪問層 （此層一定要做節點備份）
解決一些耗時易阻塞的操作，往往是多程序多執行緒，
常見的坑：
重啟時一部分訊息被丟失，不可還原是最痛苦的事情，所以一定要做冗餘，灰度更新；
分布式快取，保證資料的一致性是技術難點；
庫表的設計需要對業務經驗的積累；
對狀態的同步，很難；
4.日誌分析層 （此層是查bug，後續無止境的工作，往往不被重視，實屬運維運營崗）
建立完整的日誌收集、搜尋、視覺化分析體系，對使用者行為做分析，介面呼叫統計，提供可靠的資料包表，對異常波動做報警等；
常見的坑：
產品設計之初就沒有把此層考慮進去，導致後面無法追蹤問題；
對海量資料儲存能力，與頻繁的io的處理，是個挑戰；
埋點日誌追蹤不到線上bug，是個痛苦的事情。
如果把這些層次都看成一體，得到使用者反饋，然後去思考問題，那麼常見的坑：
1.im系統的複雜性首先被產品低估；
2.出現問題時不能有效定位**在哪乙個節點，這是分布式系統與多人協作開發的最大的痛苦，大家都證明自己無問題，但是總體就是有問題；
3.配置檔案的一致性與即時更新，是個問題；對其中某個節點的重啟，可能必須關聯好幾個節點做協同，沒有對總體的把握性很容易產生髒資料。
tp5開發常見的問題與坑 關聯模型
關聯模型 與teacher表關聯public function profile return this order order with profile select 1 hasone 和belongsto區別 hasone 關聯模型 外來鍵 主鍵 belongsto 關聯模型 外來鍵 關聯主鍵 最...
Web產品的常見問題
15.安全考慮 直接url鏈結檢查 在web系統中，匿名在位址列直接輸入各個功能頁面的url位址，檢查系統是否處理了許可權控制 預防方法 開發 走查的方式確認所有頁面的具有許可權驗證邏輯 測試 獲取所有系統url，在非登入情況下進行遍歷截圖，或關鍵字判斷，驗證非登入狀態下無法訪問具有訪問許可權限定的...
開發中遇到的坑
new arraylist size 時確定list數量，指明list大小，但是確保 裡的.size 不是null listresult new arraylist authprioritydolist.size 判斷string型別的值是不是空時用stringutils.hastext strin...