【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位进制