Cuid生成唯一id主键的设计文档

Cuid设计文档(new)
2015-09-07
1、现有cuid遇到的问题
Cuid的设计并没有任何问题，只是不能满足现有产品需求，需要升级改进已适应发展。

a.由于产品结构发生改变，与以往有很大的不同。

如：云部署，负载均衡，产品数量增加，且存在并库的需求。

b.现有前缀码（两个字节）存储空间仅有2^16=65536，重复概率较大，使用过程中很多不确定性，不清楚哪些前缀已经被谁使用，重复后不可控。

c.现有前缀码由各产品（调用平台）在各自的机器上生成的，每台机器的可能性比较多，如，机器码相同，存在不可控因素。

d.现有前缀码通过Hash和各种计算而来，存在重复的可能性增加。

2、如何解决？
沿用cuid原有设计不变：前缀码（2字节）+ 时间戳（6字节）
只是前缀码改由单独部署服务程序来管理，由服务统一生成前缀码后分配给各产品：每个产品在网站初始化时候传入产品唯一标识，全局仅调用一次服务可取得前缀码；这样唯一性就由服务来控制，这个服务调用过程是同步且加锁的，每次分配的前缀码是递增号，并记录各到中心库，运维比较方便的观察前缀码分配情况，这样相对比较可控。

3、各产品唯一标识问题
a.手动配置：
各产品唯一标识手动配置，由产品来决定每个网站的唯一性，这样比较可控；但增加了运维成本，产品多了后配置管理起来较麻烦。

b.自动生成：
机器码+机器名+网站路径。

过去也是这么做的，目前来看比较可靠；产品部署多了，不排除存在机器码、机器名或网站路径都相同的产品。

4、服务端如何生成前缀码？
服务接收到产品请求后，根据产品传递的唯一标识找出匹配的hi，如果不存在，在生一次hi的基础上递增生成一个新的hi返回，并记录，下次请求就直接返回。

5、同一部署在多个IIS进程下问题。

据相关了解，IIS多进程下不仅仅是cuid前缀码不唯一性的问题，其他业务逻辑问题会更多，session、缓存、静态变量等；因此不推荐IIS多进程的配置。

解决多并发问题，个人觉得应该从产品架构去着手处理。

比如去掉事务或移除与事务不相干的业务、对复杂的业务逻辑进行拆分简化后使用消息队列进行异步处理、分布式架构等.....
产品库其实可以部署到服务里面，诸多原因产品对这个改变可能比较困难。

目前仅针对解决cuid重复问题，增加了黄色模块的服务，方便以后更多的服务转移到该服务上面去，不过开发成本和运维会增加，解决cuid重复这个设计还需要先征求一下各部leader意见。

API服务由谁负责、服务由谁提供等等问题。

平台几乎不用任何改动也能满足这个设计，产品取得hi之后，传给cuid类就可以了。

大致设计图如下：。