内容简介:一般方案:简单的基于DB方案:
一般方案:
简单的基于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全挂时,按照当前专快订单QPS峰值500计算,内存list还能支撑30分钟的ID使用量;
- 降级:当所有DB全挂,并且内存list里面的ID全部用光时,将会降级到timestamp方案;由于timestamp位数的限制,我们牺牲QPS容量,来提供可用年限,单个ice实例QPS容量为8k,并且单个集群最多只能有16个ice实例,
思考:
64位中重复少,比如若时间,每s都一样浪费了41位。数据生成快(zk估计不会生成这么快,批量生成),有持久。载入内存。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。