唯一id的生成
下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求：1.全域性唯一 2趨勢有序
1. 用資料庫的auto_increment(自增id)來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。
優點：使用資料庫原有的功能，相對簡單；能夠保證唯一；能夠保證遞增性；id之間的步長是固定且可以自定義的
缺點：可用性難以保證，當生成id的那台伺服器宕機，系統就玩不轉了；由於寫入是單點的，所以擴充套件性差，效能上限取決於資料庫的寫效能。
2. 用uuid
優點：簡單方便；全球唯一，在遇見資料遷移、合併或者變更時可以從容應對；
缺點：沒有遞增性；uuid是很長的字串，作為主鍵對儲存空間有一定要求，查詢效率也較低。
3. 使用redis生成id，主要利用redis是單執行緒的，所以也可以用來生成唯一id。當使用的是redis集群的時候，比如集群中有5臺redis，初始化每台redis的值為1,2,3,4,5，設定步長為5，並且確定乙個不隨機的負載均衡策略，能夠保證有序，唯一。
優點：不依賴資料庫，靈活，且效能相對於資料庫有一定提高；使用redis集群策略還能排除單點故障問題；id天然有序
缺點：如果系統中沒有redis，還需要引入新的元件；編碼和配置工作量大
4. 使用twitter的snowflake演算法；其核心思想是乙個64位long型id，使用41bit作為毫秒數，10bit作為機器的id(5個bit是資料中心，5個bit的機器id)，12bit作為毫秒內的流水號(意味著每個節點在每毫秒可以產生 4096 個 id)，最後還有乙個符號位，永遠是0。具體實現的**可以參看可以根據自身需求進行一定的修改。
優點：不依賴資料庫，靈活方便，效能優於資料庫；id按照時間在單機上是遞增的
缺點：單機上遞增，但是當分布式環境下每台機器的時鐘不可能完全同步，有時並不能做做全域性遞增。
5. 使用zookeeper生成唯一id，主要通過znode資料版本來生成序列號，可以生成32為和64為的資料版本號。很少使用，因為是多步調用api，併發情況下還需要考慮分布式鎖，不是很理想。
6. mongodb的objectid，和snowflake演算法類似。4位元組unix時間戳，3位元組機器編碼，2位元組程序編碼，3位元組隨機數
1 單錶分表策略
a.當資料比較大的時候，對資料進行分表操作，首先要確定需要將資料平均分配到多少張表中，也就是：表容量。
這裡假設有100張表進行儲存，則我們在進行儲存資料的時候，首先對使用者id進行取模操作，根據 user_id % 100獲取對應的表進行儲存查詢操作.
user_id % 100 = 0 user_id % 100 = 1 user_id % 100 = 2
2 分表分庫策略
a.１、中間變數 ＝ user_id%(庫數量*每個庫的表數量);
２、庫序號 ＝ 取整(中間變數／每個庫的表數量);
３、表序號 ＝ 中間變數％每個庫的表數量;
例如：資料庫有256 個，每乙個庫中有1024個資料表，使用者的user_id＝262145，按照上述的路由策略，可得：
１、中間變數 ＝ 262145%(256*1024)= 1;
２、庫序號 ＝ 取整(1／1024)= 0;
３、表序號 ＝ 1％1024 = 1;
這樣的話，對於user_id＝262145，將被路由到第０個資料庫的第１個表中
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
mysql 分庫分表實戰 MySQL分庫分表實戰
為什麼要分庫分表 在大型 中，當使用者量以及使用者產生的業務資料量達到單庫單錶效能極限時，為了支撐業務可持續發展，對於重要的核心業務必然要進行分庫分表來儲存業務資料。對於非核心業務產生的大量資料，例如爬蟲爬取的資訊，論壇產生的資料等，可以考慮把資料儲存在像mongodb這樣的nosql儲存裡面，這些...
mysql分庫分表備份 mysql分庫分表備份
一 單獨備份資料庫 mysqldump uroot poldboy oldboy opt oldboy.sql 最簡單的備份 1 mysql基於myisam引擎 mysqldump uroot poldboy b x f oldboy gzip opt oldboy.sql.gz 2 5.5以後預設...