目標：
Key-List模型、千億萬億級別、分布式、可擴展、確保一定的性能、高可用
基本思想：
1、 同一個key對應的list盡量集中化
2、 通過表升級、表分裂限制表的大小
3、 參考HBase的方案管理表
表升級、分裂方案：
以典型數據<uid,mid>(聯合主鍵)為例，假設每條記錄40字節
確保每個表最大條數1千萬（每個數據文件不要超過400M，或者可以限制最大條數1百萬，最多40M），設置mysql每張表一個表空間
通過兩個條件來限制：uid個數、uid中最多的mid個數 相乘小於1kw
四個級別的表：
1級：十萬用戶 100條記錄，如果用戶數超過十萬則分裂為兩個或多個1級表；如果有用戶記錄數大於100則移動到最小的2級表中。(分裂或升級均凌晨閒時執行，升級優先)
2級：一萬用戶 1000條記錄，同上
3級：一千用戶 10000條記錄，同上
4級：一百用戶以下 100000條記錄以上
結構圖和各部分的功能
master職責（有備份、保證一主）：
1、維護key(即uid)所在的庫、表分布，在內存中構建hash索引
2、協調數據容量負載均衡，寫表盡量分散在各zone中
3、感知節點，如果有節點增刪，做相應的操作
zone職責：
負責監控表，實施表的分裂，分裂在本zone完成，期間需要和mater進行通信，完成之後其他zone進行備份
分裂操作（太復雜，沒想太清楚）：
分裂點界定：對uid按照mid從多到少排序，當相加個數大於總個數一半時為拆分點
拆分時選擇某一個從表，通知master對此表加讀鎖並記錄同步日志點p，拆分過程不能分配讀寫操作，拆分完畢後將日志點p後的數據同步至兩個新表，同步完畢通知master將寫全部映射到新表，其他的備份通過主從方式自動更新為兩個表，或者使用緩沖表or緩沖隊列來實現
分裂之後的數據副本：由master決定放在比較空閒的zone中
升級操作：
由master協調，具體升級在各zone內部進行，不涉及表數量的修改，相對分裂簡單許多，但是涉及key的分布修改
讀寫操作：
先從master中獲取對應表位置
讀數據：就近讀，優先讀取本機房的主表所在節點，不成功則取其他
寫數據：只寫主表，可能不是最近的機房，有單點問題，如果掛掉，通知master更換主，此過程過長則通過緩沖隊列解決
加入新機器：
計算各節點的表個數，數據最大的M個節點各分一部分表給新加機器，完畢後通知master
某一機器掛掉：
找到表最小的幾個機器，對掛掉節點的表數據按照一定規則復制過去
或者等待DBA處理，不需要立即處理
通知master
難點(不過解決起來有參照，例如HBase)：
自動化的表分裂、升級過程復雜
表管理復雜
如何保證讀寫服務正常、數據一致性
