拉模式
我發表資訊 存入資料庫
你獲取資料 通過查詢我的關注的人 的id 然後查他發的內容 ，拉的方式採用時間換空間的策略
資料庫框架的演變
資料庫自增id
資料庫自增加id 採用分表分庫的問題，可能導致 多張表資料有重複的id。為了保障id的唯一性，需要乙個統一發id的服務，例如每秒寫入100萬資料，為了區分沒秒的資料，常見的是time+sequeue設計方式，設計中id長度為64位，前32位客表示數值（0-4294967295）精確到秒（用時間錯描述），中間20位（可表示資料0-1048575就可以表示0-100萬之間的任意整數），最後12位重複其他業務資訊。
分表分庫策略
常見的分表策略有兩種
1。按hash拆分
2，按時間拆分
按hash拆分
將一張表的資料分不到多張表。例如內容表根分為4個表，根據分表內容的使用者做id做hash運算，吧演算法id%4計算改資料落在那個表上按hash拆分使用前中期使用，特在在於資料規模可控，增長速度可控，缺點在與 如果特殊使用者的查詢效能低，如果某些使用者比較多，按照id策略找成資料集中在摸個資料表上，造成寫入操作集中在某個表上。
冷熱資料無法分離訪問。如熱點資料可以放在效能強的硬碟上 冷們資料放在讀寫弱的硬碟上，但是hash表無法瞞住這個需求
按時間查分
某個時間點的資料放在乙個表上，不同時間端查不同時間表
綜合策略
兩者結合 使用者發表內容 按照id取hash值到具體庫中，在按時間取具體的表
在以時間查分的情況下有乙個問題
如果發表的內容是以時間分表，如果我要查使用者id為1000的人最近發的5條記錄，視乎需要遍歷所有表 導致效率過低 解決這個問題需要引入二級索引表 將使用者id和使用者在那個表上發的總內容數量的表
快取的架構引進
後台使用分布式快取後，每條快取伺服器快取總資料的一部分，需要解決兩個問題
這麼確定那個資料存在那個伺服器上
這麼才能讓資料均衡分布到快取伺服器上，避免趙成 某個資料多某個資料少
一致性的hash演算法
通過圓環的形式組成的 例如三個伺服器快取 講個各自的hash取出 構成乙個環形 當請求過來 判斷 是否在當前伺服器 上如果不是順著順時針尋找最近的key的hash執所在的伺服器上還有個問題 當增加一條伺服器可能導致 原來落在伺服器0上的請求有快取伺服器4和快取伺服器0共同承擔，但是其他兩個服務壓力不變，沒法充分利用每條伺服器。 可以加入乙個虛擬節點來處理。
如果其中一條伺服器宕機了 也會造成命中率答覆下降。方案 獲取資料時候 先訪問住快取 當主緩衝獲取失敗，在訪問從快取，
當資料更新住快取獲取資料更對主快取進行更新。更新後在更新從快取，如果住快取一致性更新失敗 則把主快取和從快取刪除。讀取資料庫後在載入到快取中
為了儲存快取失效的問題
定期吧主快取的資料同步到從快取 應用層控制請求有一定概率落到從快取上，讓從快取承擔部分請求
app後台設計總結
詳情參考博文 api 設計 1 後台不允許返回類似 null 資料，空字串可這樣寫 realname 3 db 設計時，所有欄位都需預設值 4 客戶端提示資訊需兩套 程式設計師看的資訊 使用者看的資訊 5 1 db 只儲存原圖的路徑 2 的尺寸通過 url 採用 get 的方式傳遞到客戶端 db 1...
判斷app是否在後台
1 通過runningtaskinfo類判斷 需要額外許可權 測試通過5.1可用，許可權名稱修改 判斷當前應用程式處於前台還是後台 activitymanager am activitymanager context.getsystemservice context.activity service...
iOS藍芽APP常駐後台
1.設定plist，藍芽許可權 2.到target capabilities background modes中開啟use bluetooth le accessories選項 3.建立central manager時設定restore identifier bluetoothmanager cbc...