分庫分表：
跨庫的問題
分布式事務問題
查詢資料結果集合並
全域性性唯一性id保證
要求：1.全域性唯一性：不能出現重複的id號(基本的要求)
2.資訊保安：防止惡意使用者規矩id的規則來獲取資料
3.資料遞增：保證我下乙個id一定大於上乙個id.
當前201709122030 下乙個；201709122031
互斥關係：資訊保安、資料遞增規律
create table 'tl_id' engine=innodb default charset=utf8;
業界方案：
uuid:通過唯一識別碼16個位元組128位的長數字。
組成部分：當前日期和時間序列+全域性的唯一性網絡卡mac位址
優點：**實現簡單、不占用寬頻、資料遷移不受影響
缺點：無序、無法保證趨勢遞增（要求3）字元儲存、傳輸、查詢慢、不可讀
snowflake雪花演算法
國外的twitter分布式下id生成演算法
1bit+41bit+10bit+10+bit=62bit
高位隨機+毫秒數+機器碼（資料中心+機器id）+10的流水好
國內：保證資料的唯一性就行了idc機房
優點：**實現簡單、不占用寬頻、資料遷移不受影響、低位趨勢遞增
缺點：強以來時鐘（多台伺服器時間一定要一樣）、無序無法保證趨勢遞增（要求3）
mysql方案
奇數跟我們偶數 遞增步長2
適合小型網際網路公司、比如可以知道我們一定生成的id數量 五萬的訂單量（預定義）
一年1千8百萬
mysql 一張表500萬
如果公司每天訂單量5萬的資料 我們用mysql設定步長位100的話可以用27年，只能為100庫，公司來到風投了，每天的訂單量50萬100萬的時候
優點：**實現方便、效能不錯、數字排序、可讀性很強
缺點：受限資料庫、擴充套件麻煩、插入資料庫才能拿到id、單點故障的問題
主從同步的時候：電商下單->支付insert master db select資料 ，因為資料同步延遲導致差不到這個資料。加cache(不是最好的解決方式)資料要求比較嚴謹的話查master主庫。
縮減版本、有關業務**沒有包含到裡頭、redis方案
優點：不依賴資料、靈活方便、效能優於資料庫的、沒有單點故障（高可用）
缺點：需要占用網路資源、效能要比本地生成慢、需要增加外掛程式
分布式儲存 Mysql 序列3 分庫分表策略
分庫分表是儲存層設計中乙個普遍而重大的問題，什麼時候分？怎麼分？分完之後引發的新問題，比如不能join 分布式事務？本篇將從最基本的策略出發，逐步深入講解這裡面涉及的一串行策略。分庫的首先目的就是做 業務分拆 關於業務分拆，在前面的序列文章 分布式系統 基本思想彙總 中已經有闡述。通過業務分拆，把乙...
常見的分布式定址演算法 借鑑到分庫分表
hash 演算法 來了乙個 key，首先計算 hash 值，然後對節點數取模。然後打在不同的 master 節點上。一旦某乙個 master 節點宕機，所有請求過來，都會基於最新的剩餘 master 節點數去取模，嘗試去取資料。這會導致大部分的請求過來，全部無法拿到有效的快取，導致大量的流量湧入資料...
如何保證分布式系統介面冪等？
這是實戰經常遇到的乙個問題，舉個例子 我們系統的開票介面受理對方系統的報文 結算單號settleno 開票單號ticketno 由於網路抖動或者前端提交多次導致同一筆重複請求，如果不設定冪等，我們系統就會受理多筆相同的請求，最終可能導致多次重複開票的問題。所以我們要保證介面冪等，使得重複請求只會成功...