【3.工程開發】-簡單分佈式id生成方案

通常方案：

簡單的基於DB方案：

DB1生成的ID%4=1，...，DB3的ID%4=3；
異地多活：要求跨IDC ID不重複。由於有每一個集羣IDC標識不一樣，可保證id不重。
性能

• 解決DB性能問題：一次從DB獲取N個ID，N可配置，對應DB的操做就兩個：
  query當前ID
  update current_id = current_id + 4*N where current_id=id_queried
  而後在內存中記錄4*N個ID中計算出模4爲DB_index的N個ID，放在內存list中。cas
• ice可水平擴展：每一個ice會訪問集羣內的4個DBs，實現對DB訪問的負載均衡；
• 高可用：合理配置N，單個DB能夠知足足夠高的ID QPS需求，所以，即便4個DB中的3個都掛了，單個DB徹底可以撐住任意高的ID QPS，服務仍是OK的；
• 接口低延遲：調用方獲取ID是從內存list中直接獲取，list有最低長度校驗，低於該值，將異步觸發從DB中獲取ID；
• 預加載：啓動時，ice會加載30w個ID到內存list中，以保證全部DB全掛時，按照QPS500計算，內存list還能支撐30分鐘的ID使用量；
• 降級：當全部DB全掛，而且內存list裏面的ID所有用光時，將會降級到timestamp方案；因爲timestamp位數的限制，咱們犧牲QPS容量，來提供可用年限，單個ice實例QPS容量爲8k，而且單個集羣最多隻能有16個ice實例，

思考：
64位中重複少，好比若時間，每s都同樣浪費了41位。數據生成快（zk估計不會生成這麼快，批量生成），有持久。載入內存。
忽然想到微博的短url的生成，是否是id生成後轉36位進制