内容简介:一般方案:简单的基于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估计不会生成这么快,批量生成),有持久。载入内存。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
How to Build a Billion Dollar App
George Berkowski / Little, Brown Book Group / 2015-4-1 / USD 24.95
Apps have changed the way we communicate, shop, play, interact and travel and their phenomenal popularity has presented possibly the biggest business opportunity in history. In How to Build a Billi......一起来看看 《How to Build a Billion Dollar App》 这本书的介绍吧!