APP項目開發(fā)對于聊天功能制作數(shù)據(jù)庫架構(gòu)的演進，深圳APP開發(fā)公司結(jié)合多年項目開發(fā)經(jīng)驗整理歸納了幾種當(dāng)前主要形式，一般數(shù)據(jù)庫架構(gòu)的演進過程如下：
·單機部署。
·讀寫分離，從主從到主多從。
·分表分庫。
社交App后臺數(shù)據(jù)庫架構(gòu)的演進也是類似的．前兩個階段是比較通用，在分表分庫階段除了使用，博納網(wǎng)絡(luò)在前面APP開發(fā)時“分庫”一文中介紹的數(shù)據(jù)庫分布式處理軟件MyCAT外，還能用業(yè)務(wù)層的分表分庫策略。我們可能會有疑惑，為啥不用數(shù)據(jù)庫分布式處理軟件而要在業(yè)務(wù)層實現(xiàn)分表分庫？APP開發(fā)公司程序員認為因為在業(yè)務(wù)層實現(xiàn)分表分庫可以獲得更大的靈活性．例如可以實現(xiàn)冷熱數(shù)據(jù)的分離存儲：最近的數(shù)據(jù)存儲在高性能的設(shè)備上，舊的歷史數(shù)據(jù)存儲在廉價的設(shè)備以節(jié)省成本。下面介紹社交App后臺數(shù)據(jù)庫在業(yè)務(wù)層實現(xiàn)分表分庫的方案。數(shù)據(jù)庫的分表分庫，首先要解決的是數(shù)據(jù)庫自增id問題。
1.社交類APP開發(fā)聊天功能數(shù)據(jù)庫自增id處理方案
數(shù)據(jù)庫分表分庫后，程序聚合了多張表的數(shù)據(jù)時有可能出現(xiàn)的問題是出現(xiàn)重復(fù)的id。在實現(xiàn)分表分庫前，id是采用在表中自增的策略當(dāng)表分散后就不能保證id的唯一性。為了保證分表后id的唯一而且自增，需要個全局統(tǒng)的發(fā)id號服務(wù)。
假設(shè)業(yè)務(wù)上每秒峰值寫入是100萬，如果采用全局統(tǒng)的發(fā)id號服務(wù)，就是要區(qū)分每秒的100萬條數(shù)據(jù)。多數(shù)互聯(lián)網(wǎng)同行公司都會有自己的發(fā)id號算法，常見使用的是time+sequeue設(shè)計方式。例如，設(shè)計中id的長度為64位，則id的前32位（可表示數(shù)值。-4294967295）精確到秒（用時間戳表示），中間20位(可表示數(shù)值0-1048575)就可以表示O-100萬之間的任意整數(shù)(即sequeue)，最后12位存放其他業(yè)務(wù)信息。
2.APP開發(fā)聊天類功能處理方案之分表分庫策略
常見的分表分庫策略有下面兩種
·按hash拆分。
·按時間拆分。
(1)按hash拆分
按照特定的hash算法，把張表的數(shù)據(jù)分布到多張表。例如，把內(nèi)容表分為4張表，根據(jù)發(fā)表內(nèi)容的用戶id做hash運算，用算法id%4就能計算出這條數(shù)據(jù)落在哪張表上，如圖9-19所示。
按hash拆分是最常見、最簡單的分表分庫方案，適合于分表分庫的前中期使用，在這個階段數(shù)據(jù)庫的數(shù)據(jù)通常有下面的特點。
·數(shù)據(jù)規(guī)?？煽?。
·增長速度可控。
APP開發(fā)公司發(fā)現(xiàn)hash拆分有下面的缺點
·特殊用戶的查詢性能低。如果某些用戶數(shù)據(jù)特別多，按照用id值hash策略會造成數(shù)據(jù)集中在某個數(shù)據(jù)表，造成查詢和寫入操作都集中在某一張表上。
·冷熱數(shù)據(jù)沒法分離存取。例如某些熱點數(shù)據(jù)可以放在價格高、讀寫性能強的硬盤上提高凄寫速度，玲門的數(shù)據(jù)可放在價格低、讀寫性能稍弱的硬盤。對于社交類的App來說，熱門數(shù)據(jù)一般就是用戶最近發(fā)表的內(nèi)容，按照用戶id值，hash分表沒法滿足這個需求。
APP開發(fā)公司提醒您如果采用下面介紹的按時間拆分的策略，可以彌補hash分表的缺點。
(2)按時間拆分
按時間拆分的策略是將同時間段的數(shù)據(jù)放在同一張表，不同時間段的數(shù)據(jù)放在不同的表。例如，2015年9月份發(fā)表的內(nèi)容記錄在表
“table 201509”。時間拆分如圖9-20所示。
APP開發(fā)聊天功能數(shù)據(jù)庫結(jié)構(gòu)示意圖9-20時間拆分
(3)綜合的策略
分表分庫中可以綜合使用hash和時間兩種分表分庫策略：用戶發(fā)表內(nèi)容，先按照用戶的id的值hash到具體的庫，再按照時間落到具體的表，如圖9-21所示。
APP開發(fā)經(jīng)驗分享之?dāng)?shù)據(jù)庫圖9-21綜合使用hash和時間兩種分表分庫
在圖9-21中實現(xiàn)的是種數(shù)據(jù)庫內(nèi)的冷熱數(shù)據(jù)分離策略，還有種更大范圍內(nèi)的分表分庫方案可以實現(xiàn)玲熱數(shù)據(jù)分離，先按照年份選定一個數(shù)據(jù)庫集群，在集群內(nèi)部按照用戶id hash到具體的庫，再按照月份確定到具體的表，如圖9-22所示。
APP開發(fā)經(jīng)驗分享圖9-22更大范圍的分表分庫策略
按照時間拆分Feed數(shù)據(jù)后需要解決個問題：因為社交類App常見的業(yè)務(wù)場景是顯示用戶最近發(fā)表的內(nèi)容，怎么快速查找用戶最近發(fā)表的內(nèi)容？例如這樣的需求：快速找到id為1001的用戶最近發(fā)表的5條內(nèi)容，難道要把圖9-20中的4張表都查找一遍嗎？這樣效率太低了。
解決這個問題需要引入一個二級索引表，通過這個二級索引表查找到具體的數(shù)據(jù)，如圖9-23所示。
APP開發(fā)經(jīng)驗數(shù)據(jù)庫所以表處理方案示意圖9-23二級索引
例如需要查找id為l001的用戶的最近發(fā)表的5條數(shù)據(jù)，按圖9-23的表結(jié)構(gòu)，可在二級索引表“table_index”獲知有3條數(shù)據(jù)在索引表“table 201509”，有2條數(shù)據(jù)在索引表“table 201508”。通過索引表“table 201509”查到3條數(shù)據(jù)的feed_id為5552、5551、5550．通過索引表“table 201508”查到2條數(shù)據(jù)的id為4552、4551，根據(jù)查找到的id很容易就能獲取到詳細的數(shù)據(jù)。好了，APP開發(fā)公司本文關(guān)于我們在制作聊天社交類APP時對于數(shù)據(jù)庫演進處理方案的詳細方法就分享到這里，謝謝您的關(guān)注，希望給您的APP開發(fā)項目以及后期管理時的工作有所幫助。博納網(wǎng)絡(luò)編輯整理。
